During the last 6 weeks, I have provided some tips and guidelines on how to prepare (high-level) requirements documentation. I have also talked about some of the common pitfalls to avoid. Regardless of what tools or applications one uses to manage a body of requirements, these guidelines will be relevant. The focus of this post will be to dove-tail all of that material in an eloquent fashion. In essence, this post will summarize and serve as an index of my previous posts.
The GoodThe purpose of these habits is to promote understanding on a few different levels:
Each requirement statement is understood by all affected parties. To accomplish this requirements must be clear, feasible, correct & complete.
Each requirement fits in and does not conflict with any other requirement. Consistency within the body of work must be maintained.
Each requirement can be traced backwards and forwards easily. This improves the ease of verifying them as well as encouraging modularity.
High-level (business) requirements answer the question, "What should the system do?" not, "How should the system do it?" In other words, they must be design independent.
The acid test is, "Are my requirements readily understood? Can someone who is not familiar with my project, read my requirements and understand what I am trying to accomplish?"
The BadTo appreciate each pitfall, it is important to have an understanding of its impact.
Requirements are less clear when:
- They are ambiguous.
- There is excessive rambling.
- They contain vague or speculative references.
- They contain many possibilities.
- Multiple requirements are squished into one big one.
- They are ambiguous (surprise, surprise!)
Requirements are unattainable when:
- They are composed of wishful thinking and dreams.
It becomes very clear that these requirement pitfalls contribute to a lack of understanding. Which in turn will be detrimental to success.
The UglyNow I want to focus on why requirements are important. Requirements are the foundation for the other phases of a system development lifecycle.
Requirements are also viewed as the primary reason for project failure with estimates ranging from 50% to as high as 70-80%!
Requirement gathering occurs at one of the earliest stages of a project lifecycle but the impacts of problems are felt downstream during the design, build, implement and post-implementation periods. The later a requirement error is discovered, the more costly it is to fix.
This is simply because the later an error is uncovered, the more backtracking will be needed (an obvious need for solid traceability if ever there was one) to correct it. When a requirement is incorrect, the functional specifications will suffer from the same deficiency, likewise the design documentation will perpetuate it once again and finally, even the actual code itself will have the same problem.
If an error is discovered late in the development cycle, the costs may have risen anywhere from 10% to 100% (or worse) to find and fix versus if the error was discovered earlier.
The road aheadThe guidelines I have proposed are just that... guidelines. There is considerable interdependency between them. Each guideline should not be viewed as a singular item, but rather as a factor that will contribute to the success of the requirements gathering and articulation process.
Using all of these tips will, in itself, not guarantee success. Success is never guaranteed. Projects are often subjected to things beyond their control, however, requirement management practices are controllable.
These guidelines will help one bridge communication and understanding gaps. Then, the rest will be left to your wits, skills and resolve as a business analyst. Enjoy the ride!
There is an interesting post on Tyner Blain concerning the need for requirements management. Excellent synergy with my post.
ReplyDelete