- The Process Approach
- Mechanisms, Methods, Tools, and Training
- Best Practices
- Summary
- Template for a Project Requirements Policy
- Guidelines for System Development Based on Requirements Considerations
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Guidelines for System Development Based on Requirements Considerations
-
Developers must be trained not to add any features or capabilities beyond those stated in the approved requirements. Industry experience is that developers add capabilities, increasing the scope of the product and adding to the effort required throughout the system's lifecycle.
-
Methods such as requirements workshops (conducted as needed), storyboards, requirements reviews, idea reduction, role playing, and prototyping should be used. See Dean Leffingwell, Managing Software Requirements: A Unified Approach, for a lot of experience and suggestions.
-
"What if" questions should be asked, focusing on the boundary conditions, exceptions, and unusual events.
-
A careful manual review and analysis of the complete set of requirements, supported by the user and utilizing appropriate automated tools, will be needed to ensure consistency in the requirements set.
-
Developers, customers, and other stakeholders need to rank the individual requirements in terms of their importance to the customer. This technique helps to manage the project scope. Requirements should also be ranked in terms of their stability. This is only a beginning to defining the releases of the product. Data dependencies must be considered as well. See Bill Wiley, Essential System Requirements: A Practical Guide to Event-Driven Methods, Chapters 8 and 9 for discussion of data/process interaction and transition to physical design.
-
One of the most difficult requirements challenges is writing the requirements detailed enough to be well understood without over-constraining the system and annoying users with details intended to remove ambiguity. Here are some guidelines:
-
Use natural language whenever possible.
-
Use pictures and diagrams to further illustrate the intent.
-
When in doubt, ask for more information.
-
Augment specifications with more formal methods when it is critical not to be misunderstood (life-and-death situations or grave consequences of erroneous behavior).
-
Train people to recognize the problem and the solution.
-
Use diagrams and structured pseudo-code to describe complex technical specifications.
- We know that the requirements will change for several reasons:
-
External factors:
-
Change in the problem (the business) we are attempting to solve.
-
Users change their minds.
-
The external environment has changed, creating new constraints and/or opportunities (for example, the availability of the Internet and the World Wide Web).
-
The very existence of the new system causes the requirements for the system to change!
-
Internal factors:
-
Failure to discover the real requirements during the initial requirements-gathering effort.
-
Failure to create a practical process to help manage changes.
-
Requirements leakage:
-
Direct user/customer requests to programmers.
-
Functionality inserted by programmers "because it's a good thing."
Change must be managed. Here are some guidelines:
-
Recognize that change is inevitable and provide methods to deal with it.
-
Baseline the requirements.
-
Establish a single channel to control change (such as the joint team).
-
Use a change-control system to capture changes. Keep requirements under vigorous configuration management (CM).
-
Manage changes hierarchically so that the downward ripple effect of a change will be highlighted by the traceability in the requirements tool.
-
Industry data show that a change of 30% in the requirements results in doubling of the costs of the project. The joint team is critical to provide joint customer and contractor responsibility for the requirements and for the impacts of any approved changes.