Latest Requirements Buzz

Capturing of Business Requirements - Technical Guideline
The purpose of this document is to provide a technical guidance on how to capture and document business requirements in order to produce BII profiles.

How Detailed Should Requirements Be? Part 3 - When More Requirements Detail Is Advisable
In the previous article in this series, I described several conditions in which writing less detailed requirements is appropriate. However, there are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article (adapted from my book More about Software Requirements), expect to spend more time than average developing detailed requirements specifications.

How Detailed Should Requirements Be? Part 2 - When Less Requirements Detail Is Appropriate
In the first article in this series, I pointed out that there’s no easy answer to the question of how detailed the requirements need to be. Instead, I can present a thought process the business analyst can use to assess the appropriate level of detail for each case.

How Detailed Should Requirements Be? - Part 1
Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?” It’s an insightful question, one that even experienced business analysts often ask me.  

Starting Your Requirements Education
So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period. Requirements are basic to business analysis, and so requirements education is basic to business analysts. “All team members who will function as analysts should receive basic training in requirements engineering,”[1] notes Wiegers in his modern analysis classic Software Requirements. Honing your craft is both admirable and achievable, and you have numerous, helpful outlets at your disposal. The method that you choose is co...

An Introduction to Requirements Traceability
 Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

Webinar: Leveraging Software Visualization to Elicit, Validate and Communicate Requirements
It’s no secret in the IT sector that bad requirements are at the heart of high failure rates for software development projects. Unfortunately, the logical – and unfair – conclusion is that those who are responsible for defining and communicating those requirements should shoulder the blame for their shortcomings. The unacknowledged fact is that the fault does not lie with the people involved, but rather with methods and processes that fail to confront the reality of our limited human capacity to communicate complex ideas with only text and abstract models.