Requirements Analysis starts with the inputs defined in Section 6.2 of the previous post and analyzes the mission and associated environments to establish a Requirements Database. Figure 6.4 in the second previous post shows that the Requirements Analysis Task is carried out iteratively with Functional Analysis/Allocation, with Technical Management and with Verification tasks. The NASA and IEEE handbooks define the subtasks of Requirements Analysis with flowcharts. The DoD SEF lists the 15 subtasks named in the IEEE flowchart and provides a description of each. Figure 6.5 below is a streamlined version of the IEEE flowchart; listing the 15 tasks using the IEEE and DoD SEF numbering. Several of the tasks are renamed to explicitly include analyzing the entire life cycle for environments, scenarios and modes rather than just those associated with the system in its operational mode. Task 13 is retitled from Technical Performance Measures (TPM) to broaden the scope to include TPMs, Key Performance Parameters (KPP) and any other metrics or Measures of Effectiveness (MOE) the team or customers believe are needed.
There are five types of requirements as defined in the DoD SEF:
• Functional Requirements - The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the top level functions for functional analysis.
• Performance Requirements - The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.
• Design Requirements - The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.
• Derived Requirements - Requirements that are implied or transformed from higher-level requirement.
• Allocated Requirements - A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements.
The 15 tasks are structured so that all necessary requirements of each type are identified and documented in the Requirements Database. Each requirement must be traceable back to the input documentation or to a mission need derived from analyzing mission needs to ensure that no extraneous requirements are added.
The requirements analysis process is presented as a sequential process. These steps typically overlap and work previously completed may need to be adjusted as the detailed knowledge of all the requirements becomes more fully understood. Tasks are grouped in Figure 6-5 because the tasks in a group don’t need to be done in any specific order and some can be done in parallel. Tasks 1 to 9 and 12 to 15 analyze the system as a single entity. Tasks 10 and 11 begin the decomposition of the system into logical functional components (task 10) and begin to allocate performance parameters to these components (task 11). Tasks 10 and 11 feed directly into the Functional Analysis/Allocation and Systems Analysis tasks and receives information back from these associated tasks as indicated in the figure.
Executing the 15 tasks involves making many decisions and defining many relationships. As the many decisions are made and relationships are examined, it is critical that they are documented and tracked to facilitate updating tasks as new information is available.
Attempting to do requirements analysis without the use of supporting methods and diagrams is like trying to do math without equations and special symbols. It is possible but much more difficult and leads to more mistakes. The methods and diagrams selected for discussion in the following sections are not meant to be the only possible choices or a complete set; rather those presented are selected because they illustrate an important part of systems thinking or offer alternatives to conventional approaches covered in standard handbooks.
A principle behind offering alternatives is that when there are two ways to do a systems engineering task or two ways to present the results it is often beneficial to use both ways. This is because one offers a self-check on the other and some reviewers are able to critique one way better than another when the work is presented to peer reviewers. Once something is complete in one format or by using one tool repeating it in another format or with another tool takes little more time than carefully reviewing the accuracy of the first way and is much better at catching errors.
No comments:
Post a Comment