In the course of my teaching CORE™ and GENESYS™ to customers I am often asked “How does all of the things you have taught us apply to completion of the System Requirement Review?” The answer to this question lies first in understanding why do we do the System Requirements Review (SRR). Then, in understanding how a model-based systems engineering (MBSE) process and toolset help you achieve the Exit Criteria for the SRR.
The System Requirement Review is used as a formal mechanism for the system development team to engage the stakeholder community with the goal of gaining system-level requirement understanding. Depending on the overarching system engineering process document used for the program or project, one will generally find a definition something like the following: “The SRR examines the functional and performance requirements defined for the system and the preliminary program or project plan to ensure that the requirements and selected concept will satisfy the objective mission” (adapted from NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev 1).
Fundamentally, the design team must have complete understanding of the system-level requirements that were provided by the acquiring organization. Through this understanding, the team must also have an overarching concept on how to achieve these requirements with a conceptual architecture. Note that final and detailed architectural decisions are not determined at the SRR, rather that the architectural concepts are understood through the collective understanding of the system-level requirements.
To gain a thorough understanding of the system-level requirements the design team needs to examine the complete set of system-level requirements provided by the acquiring authority. In practice, this means importing the requirements into the design repository, keeping the traceability to the original document and the location of the requirement in the original document. As the requirements are imported, the design team needs to ensure that all requirements are properly typed. Requirements are typed based on how they determine the system as: composite, functional, performance, constraint, programmatic, and, verification. Composite requirements are decomposed to provide singular requirement statements without changing the meaning and providing traceability to the originating/source statement.
This does not quite get us ready for the SRR. We next need to capture any concerns we have regarding the requirements. The design should ask themselves questions like: Are any of the requirements conflicting? Is the wording clear on all requirements? Does there exist an over or under specification in a requirement that will make final implementation hard to achieve? Whatever the case (and the list provided is not exhaustive), whenever it is not clear to the design what the requirement means or there is a question on how to implement the requirement, a CONCERN should be written.
Writing a CONCERN has many advantages. First, it provides a bookmark or list of all the things that need to be resolved. Second, it is traceable back to the REQUIREMENT generating the concern. And, third, it provides a way, through the attributes in the CONCERN element, to capture the design team assumptions and alternatives to be considered.
During the SRR the CONCERN information can be used to great advantage as a communication tool for the items that the design team needs clarity on in order to ensure that they know how to continue design below the system level following the SRR.
The best guidance I have to offer is to use the CONCERN category to your advantage to document all the questions you have regarding the system-level requirement set. The more questions you have, the more discussion you will have at SRR and the better informed and prepared you will be to continue the next lower level of your design.
