Requirements management begins with the identification and documentation of the user need. This need should be expressed in user defined terms detailing both their real needs and their expectations. The essence of system requirements analysis is the translation of these needs and expectations (through a defined, repeatable, and reversible process) into unambiguous, measurable, technical requirements (e.g., specifications).
Additionally, non-technical requirements should also be developed and managed. These requirements include such things as contractual terms and conditions, license and royalty arrangements, and financial reporting requirements. For all but the very smallest projects, a formal requirements identification, analysis, tracking, and adjudication process should be used.
- Identifying the Requirements Owner
As part of the project planning process, it is essential to identify the user or user surrogate with the authority and responsibility to state the user needs and expectations. This individual or organization should be able to state explicit needs, or at least describe the desired outcome if the need is met.
In cases where the identified requirements owner is unable to articulate specific needs, the project office may assist in performing the equivalent of a market or technology analysis to define the possible and feasible outcomes of applying technology to the problem stated by the user. However, the responsible user should then specifically state the need in user—not specification—terms.
The need should be captured in a formal statement of need that includes the initial concept of how the system will be used or operated. This initial concept of operations should evolve into detailed operational processes and procedures as the system is implemented.
- Identifying the Requirements
Using the systems engineering management process, requirements are identified through a repeated, recursive process over the acquisition phases of a project. First, the user need is defined and evolved into a top-level requirements hierarchy (requirements architecture). As development proceeds, these requirements are assigned to functional groupings (functional architecture), which are later allocated to system components (physical architecture). For software intensive information systems, these architectures are typically contained in the system specification, the software development specifications, and the code listings/version description documents. Data development/synchronization requirements should also be specifically addressed (data architecture).
3.3.1 Identifying the Need
A statement of need should be prepared by the user and summarized in the System Boundary Document (SBD) — which provides a basis for internal project management. Additionally, non-technical needs or unusual externally imposed constraints should also be listed in the initial SBD. In each case, the stated needs should have an owner (originator), and, if possible, a hierarchy of priority in relationship to each other. It should be stated if the needs are inflexible.
For poorly defined or unknown needs on potentially large information systems, the initial acquisition strategy associated with the system development life cycle model should be modified to include interractive or experimental needs assessments (to include extensive subsystem prototyping) prior to moving into a more formal acquisition program. Initiating formal projects with unstable user needs typically results in significant cost and schedule problems for the project.
3.3.2 Defining System Requirements
The user need is first translated into high-level technical needs that are not system specific. During the initial project phases, these technical needs are analyzed and evolved into system-level requirements. Even at this early stage of development, a formal, robust requirements traceability process is essential to allow tracing system requirements back to the stated user needs. At each phase of development, all system requirements should trace to a need and all needs should trace to system requirements.
3.3.3 Requirements Development by System Element
System functions are allocated to one or more system element: Products (software, hardware, facilities, data, materials, communications), Processes (services, techniques), and People (personnel). At each phase of development, requirements are decomposed into more detailed functions and further allocated to system sub-elements.
They should also be written as testable statements. For example, in the end, a very specific, detailed requirement is allocated to a single software module.
- Controlling the Requirements
The beginning and most essential step in controlling the requirements of an information technology project is to determine what they are. Having a definitive set of technical and nontechnical requirements is critical in controlling project cost and schedule. “Requirements creep” is a common, and sometimes fatal, problem for a project. The only cure is a clear understanding of user needs and expectations.
- Requirements Baseline Management
Everyone associated with the project manages requirements. However, only a selected set of requirements needs to be baseline and then formally tracked and controlled. These controlled requirements are developed incrementally over the acquisition phases and are captured in formal documentation and tool sets. These baseline documents may include:
- User Statement of Need
- Acquisition Program Baseline
- Functional Baseline (e.g., system specification)
- Allocated Baseline (e.g., software development specifications)
- Product Baseline (e.g., source code listings)
Depending on the complexity of the project, requirements baselines may be tracked, using software tools specifically designed for that purpose. These tools allow tracing individual requirements from the stated user need, through the system and subsystem specifications, down to the individual software unit or module.
Additionally, changes to key documentation that describe the basic processes used on the project should be controlled, but not necessarily through a formal process.
3.5.1 Changing the Requirements
Needs change; opportunities are discovered; errors are found; technical efforts fail; schedules slip; cost estimates are inaccurate; budgets are cut; priorities are adjusted – many things cause requirements to change. As a result, the project team should continuously assess the impact of changes on the project cost, implementation schedule, and system performance.
The key to performing these assessments is to be able to trace any requirements change back to highest requirement (user need) and forward to the lowest requirement (software module). This allows accurate identification of changes to development activities, schedules, and costs.
3.5.2 Reactive System Change Management
Requirements changes are a normal part of the development process. Since the project team must react to these issues and still keep the project within the parameters set in the Acquisition Program Baseline, most projects should establish technical, schedule, and budget management reserves. In the technical area, this is sometimes called design margin — that margin above the minimum acceptable need that is justified by design uncertainty. Similarly, schedules are designed with slack and budgets have reserve (or at least have lower priority items which can be eliminated, if needed). The key to successful reactive change management is actually successful cost, schedule, and performance reserve management.
3.5.3 Proactive System Change Management
During project development, opportunities may arise that lead to system changes. For example, a new commercial off-the-shelf product may eliminate the need for a development task or advanced state-of-the-art hardware can be applied to the project to either increase performance or reduce life-cycle costs. Proactively, the project office should perform cost-benefit analyses to assess these opportunities. However, incorporating these changes should not unacceptably increase the risk of meeting the stated user need.
Requirements management takes the concept of end-user computing a step further in fashioning out specific channels and pathways through which requirements are identified through a repeated, recursive process over the acquisition phases of a project. These revolve around the defining user needs, and being dynamic enough to reconfigure these needs as system development begins.