- 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
Template for a Project Requirements Policy
1.0 PURPOSE. The purpose of this document is to provide a project policy concerning the requirements for a system. For purposes of performing system development or enhancement effort on this project, the following are included within the scope of the Requirements (RE) Process:
1.1 To define the functional/high level requirements for a new system or capability; or for enhancements or updates to a system or capability (Requirements Definition). This includes compliance with Process Area (PA) 06, Understand Customer Needs and Expectations, of the System Engineering Capability Maturity Model (SE-CMM).
1.2. To perform analysis of requirements and requirements elicitation (the use of a variety of techniques to achieve a more rigorous and agreed upon—with the Customer—description of system requirements); to resolve issues concerning requirements; to provide peer review of the requirements document; and to provide for review and approval by appropriate project managers. (Requirements Analysis) (Software Product Engineering (PE) KPA).
1.3 To evaluate requirements on the basis of a set of criteria deemed appropriate by the Project (such as feasible, appropriate to implement in software, clearly stated, consistent with each other, testable, and complete (when considered as a set). Note: The group responsible for system and acceptance testing of the software should verify that each software requirement can be tested. (Requirements Analysis).
1.4 To put the requirements document under configuration management.
1.5 To provide a basis for estimating, planning, performing, and tracking the software project's activities throughout the software development lifecycle.
1.6 To allocate requirements to software, hardware, training, documentation, installation, communications, database, and other system components (Requirements Allocation). This includes compliance with Process Area (PA) 02, Derive and Allocate Requirements, of the System Engineering Capability Maturity Model (SE-CMM).
1.7 To document the functional/high level requirements, create a documented requirements document, and put the requirements into an automated requirements traceability matrix or tool of some type that has the ability to track additional, lower-level requirements throughout the system lifecycle and to verify that all valid requirements are met and where in the system they are satisfied. (Requirements Management) (SE KPA).
1.8 To provide the ability to adjust the affected software plans, work products, and activities to remain consistent with the updated requirements whenever system requirements are changed during the system lifecycle (Requirements Management) (SE KPA).
1.9 To provide a draft Functional Description (FD)/functional baseline for the system or capability.
1.10 To ensure that appropriate support tools, methods, disciplines, and training are selected, utilized, and integrated in support of this process.
1.11 To provide for review of requirements by the QA group to ensure that they are complete, correct, consistent, feasible, and testable, and that the products comply with the standards and requirements specified for them.
2.0 BACKGROUND. Experience has shown that a formal process resulting in an agreed-upon definition of requirements for new systems, new capabilities, updates, or enhancements to systems is a prerequisite to proceeding to system/capability design; and also that failure to do this results in rework and unnecessary costs and delays in schedule. Accordingly the XYZ Project has adopted this policy for managing system requirements.
3.0 ASSUMPTIONS.
3.1 For purposes of systems and software development, Customer requirements are not limited to software but may also include hardware, training, documentation, installation, communications, database, and other system components.
3.2 The XYZ Project's RE Process will be compliant with the Requirements Management (RM) Key Process Area (KPA), in the Capability Maturity Model for Software (SW-CMM) as well as the requirements-related aspects of the Software Product Engineering (SE) KPA; and the Systems Engineering Capability Maturity Model (SE-CMM), specifically, PA01, Analyze Candidate Solutions; PA06, Understand Customer Needs and Expectations; PA02, Derive and Allocate Requirements; and PA03, Evolve System Architecture.
4.0 POLICY. The following organizational policy will be utilized for all systems and software efforts for managing the requirements:
4.1 Project requirements activities and processes will comply with the PRC Requirements Policy.
4.2 Requirements for systems/capabilities will be documented.
4.3 Requirements will be reviewed via a joint process of the Customer's management and technical representatives and PRC developers/other engineering groups (OEGs) including test, QA, CM, and documentation support.
4.3.1 The purpose of this process will be to document agreed-upon descriptions of the requirements, to communicate a thorough understanding of the requirements, and to prioritize requirements.
4.3.2 Each requirement will be evaluated on the basis of the following criteria:
-
Clearly stated.
-
Understandable.
-
Testable (in the new/updated system).
-
Complete (when considered as a set).
-
Feasible.
-
Consistent.
-
Documented.
-
Agreed-upon (between the Customer and PRC).
4.3.3 Requirements for each new/updated system/capability will be documented in a Requirements Definition (RD), including the rationale for the selected alternative.
4.3.4 Changes to requirements will be provided by the Customer in writing so that PRC can evaluate them and provide appropriate feedback and resolution. Note that industry experience is that a 30% change in requirements results in 100% increase in the cost of the project. Therefore changes in requirements should also include changes in the project's cost, schedule, and contract.
5.0 REFERENCES.
5.1 Requirements Processes and Process Descriptions.
5.2 Requirements Management Tools.
5.3 Requirements Process Training Course and Training Materials.
5.4 Related artifacts in the project Process Asset Library (PAL).