Better, Cheaper and Faster
It is generally recognized that the development of good requirements is essential to quality product. However, it is well known that requirements for many programs are not adequately defined upfront. In some cases requirements evolve but it should take the overall impact into consideration and lifecycle should complement.
One of the fundamental problems associated with writing good requirements is that most business analysis / engineers are not specifically trained to write requirements. Second biggest challenge is with the shorter requirements cycles in order to adapt the change required for satisfying the growing customer needs and competition. Even if the requirements are defined there is huge difference by the time requirement gets build (changing requirements), this was seen unhealthy till recently but thanks to the changing mind set from both business and development, it’s now seen as how quickly change can be accommodated.
The basics of well-defined requirements are clarity, conciseness and simplicity. Irrespective of the delivery methodology (structured / empirical) no one can take requirements easy, it deserves due attention. During the structured methodology era we have seen the requirements being defined, reviewed and baselined and frequently revisited for the changing business dynamics and customer needs. Agile world is built around the “Change” hence change inevitable; the focus should be on handling “Change”. Change Management is more vital for agile projects without which the benefits offered by Agile will turn into disaster in no time. This can be achieved by matured team with the help of Change-Aware Product Owner.
Eliminating rework and the eliminating the inclusion of unnecessary features rooted in poor requirements definition can make projects and product development faster and cheaper without sacrificing better (many believe that one must sacrifice “better” to get “faster” or “cheaper”). At the same time, improving the fit between the product or solution and the customer’s needs also makes it better, this is possible when the Product Owner & team pays highest attention to the Quality of “Changing Requirements” (ensuring the correctness, completeness and timeliness). You can frame the structure of success – good requirements – early in a project. Focus on good requirements, and win on quality, cost, and schedule ultimate result “Better, cheaper, faster”.
Sreenu,
I agree with your post, and I want to mention that just having “Defined” requirements as you describe in a structured methodology is not the same as having “Good” requirements. You correctly point out that it’s critical to have business people who understand what they want the software to do as early as possible in the process. And the only time I’ve ever seen a business spec that was truly clear was when the system being developed had already been developed before – either the new one is a competitor copying the original, or a technology modernization effort replacing an existing system or a “redo” to address failing issues in the current system.
99% of the time in New Product Development the end-user “requirements” are not known until the end-users start to use the product. That’s the value in having a flexible “change” oriented agile development methodology – build something, let customers try it, learn from their experiences!
-Dave