This paper describes the process of defining, structuring, tracking, and automating requirements management.
We've all read the dire statistics where most IS-related projects are late, over budget, lacking in functionality or never delivered. Requirements drive the development process. Effective requirements management helps to control quality, cost, organization and schedule thus substantially improving your odds of a successful project.
Requirements are the agreed upon facts about what an application or system must accomplish for its users. They are largely independent of the methods or notations used to analyze, design, implement or test the target application. The process of managing requirements can determine project success and is especially important for larger systems, out-sourced projects or life critical software. Although primarily focused on software development, much of this discussion also applies to other activities like hardware development or systems engineering.
A typical project will have hundreds or even thousands of requirements. Identifying and specifying those requirements will take time and effort, but the project payback can be enormous since it impacts every aspect of a project including design, implementation, testing, user documentation and project management. A solid foundation can substantially reduce project risk and increase the efficiency of the entire development effort.
Historical data shows that defects occurring in the requirement identification phase are costly to correct. Requirement defects include missing, incomplete, non-essential, ambiguous, overlapping or non-implemented requirements. A methodical approach to dealing with requirements can greatly reduce these deficiencies. Peers or customers can review written requirements to expose gaps in the understanding of what the project must accomplish.
When developers spend time on design and implementation of non-essential or defective requirements, they’re not just wasting time that delays the project. The added project bloat often increases future maintenance costs, slows the final product execution, complicates the user experience and makes the project more ridged and susceptible to errors during future enhancements. An accurate requirement list keeps the development effort clean and focused.
Developers, testers, managers and users need an organized approach to identify, specify, track and control requirements. In the Definition section, we'll define requirements and common approaches to identify and group them. The Process section shows how requirements drive the project using a disciplined process. The Structure section suggests a collection of information retained for each requirement entry. The Traceability section discusses links and navigation through project deliverables. The Automation section illustrates how tools can streamline the process of managing requirements.
A requirement statement is an unambiguous, testable statement defining processing, information, performance, error handling or capacity parameters about a condition or capability needed by a user to solve a problem or achieve an objective. System and product requirements are typically derived from market demands, quality, reliability, performance criteria and safety considerations.
The first step in creating a list of requirements is to designate a definite boundary around the system to be considered. A simple picture or a few paragraphs of text can be a good starting point to ensure a clear, consistent mental picture. This boundary helps determine what belongs in the requirement list and what does not, since only externally visible aspects of the system need be included.
Each requirement is uniquely named and becomes one entry in a hierarchy list of requirements. Since a requirement entry can express a system requirement, product requirement or UML style use case for a wide variety of software systems, the granularity, style and format of a requirement entry can vary greatly. It can be a simple, free format sentence or a more structured collection of data fields created with a user-defined template.
The names of each requirement entry can form a hierarchical structure. Usually three levels of hierarchy is sufficient where the