How Detailed Should Requirements Be? Part 3 - When More Requirements Detail Is AdvisableIn 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 1Recently 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 EducationSo 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 RequirementsIt’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.

What are Requirements?

BABOK® Guide, Version 2.0, states:

“A requirement is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).”

From Wikipedia:

"In engineering, a requirement is a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user."