The purpose of establishing and managing software requirements is to ensure that the requirements are analyzed, defined, complete, consistent, stable, and verifiable, consistent with the software development life cycle to be used. Requirements identification, allocation, and verification are often a shared responsibility between the acquisition program office and the development contractor.

Establishment and management of requirements include the following steps: [1]

  1. Assess each top-level requirement for feasibility of implementation, consistency within program constraints, and its ability to be verified. If the requirement is impossible to implement within cost and schedule constraints, it must be identified as an issue and resolved by adjusting budget, relaxing schedule, and changing or eliminating the requirement.
  2. Use functional or object-oriented analysis to define a functional architecture that can be used as a basis for allocating requirements.
  3. Allocate all system, subsystem, and interface requirements to appropriate hardware and software configuration items. Ensure each requirement:
    • Is written as a single definitive statement.
    • Has a unique identification number for tracking purposes.
    • Can be traced to a higher level source requirement or analysis.
    • Has been allocated to a specific Computer Software Configuration Item (CSCI).
  4. Ensure that each performance requirement has one or more corresponding verification requirements. Involve those who will perform testing activities to ensure that requirements are testable. The specification section 4 verification requirement should define a means of objective measurement.
  5. Identify analyses, trade studies, prototyping, and demonstration efforts for risk reduction, considering the following:
    • Completeness: Are all higher level requirements allocated?
    • Consistency: Is the content, format, and notation from requirement to requirement, and specification to specification similar?
    • Feasibility: Can the requirement be met?
    • Balance: What are the trade-offs between requirements?
    • Verifiability/testability: Can the requirement be objectively verified?
    • Human factors: Is the design consistent with sound human factors principles?
  6. Complete the definition of derived software requirements and examine them for consistency with system requirements, feasibility, and the effects of various implementation strategies. Monitor derived requirements size volatility since derived requirements are often a significant source of software size growth.
  7. Apply early aggressive activities to verify that software intended for reuse fits the following criteria:
    • The advertised performance of the software to be reused satisfies performance requirements.
    • The software to be reused exists and is available.
    • The actual performance of the software to be reused satisfies performance requirements and does not have inherent shortfalls that will lead to additional growth.
    • There is a plan to address future upgrades/support of the reused software.
  8. Ensure developers flow top level requirements down to lower level specifications and to lower tier suppliers, including software configuration item specifications.
  9. Verify CSCI-to-CSCI and CSCI-to-Hardware Critical Item (HWCI) interface requirements identification and definition.
  10. Verify that an adequate and compatible set of tools are in place to capture multi-level requirements (systems down through software) and design evolution.
  11. Use operational scenarios to the extent possible to demonstrate, or bring to life, what the requirements are trying to capture. (Operational scenarios portray the product, end user, and other entities in the intended environment, and are a useful tool for discovering and refining requirements.)

AcqLinks and References:

Updated: 7/19/2017

Print Friendly, PDF & Email