chapter 8: requirements analysis & allocation (pt. 2) ise 443 / etm 543 fall 2013
TRANSCRIPT
![Page 1: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/1.jpg)
Chapter 8: Requirements analysis & allocation (pt. 2)
ISE 443 / ETM 543
Fall 2013
![Page 2: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/2.jpg)
A minimum set of essential steps with respect to the analysis of requirements includes:
2443/543– 8
Automation of Requirements Analysis and Allocation (RAA)
Relationships and traceability Ambiguous requirements Incorrect requirements Incompatible requirements High-risk requirements Low-performance requirements Derived requirements
![Page 3: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/3.jpg)
In the development of large systems RAA is an automated process A list of commonly used tools is given on pages 244-245
of your textbook. We will be conducting the analysis by hand for your
project.
3443/543– 8
![Page 4: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/4.jpg)
A key step is to explicitly identify relationships & traceability The systems engineering team must always be aware of
and track requirements interdependencies. Will meeting one requirement (e.g., the allowable error in
stability in a satellite) influence the ability to meet another (e.g., the allowable error in tracking by instruments on the satellite)?
Traceability has at least two meanings: the explicit connection between all requirements, through all
documentation in which such requirements are stated how a requirement is traced through the life cycle of the system
being developed
4443/543– 8
![Page 5: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/5.jpg)
The Requirements Traceability Matrix (TRM) is a tool for documenting and tracking ....
Reqt. # Name/description Project Task Test Verified (Y/N)
No
No
No
5443/543– 8
Your turn ... list up to 3 requirements, identify the project task(s) to which each applies, and the test used to determine if the requirement has been met.
![Page 6: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/6.jpg)
Ambiguous or incorrect requirements must be identified and clarified Ambiguities may arise when requirements in different
sections are written by different people Some requirements are found to be incorrect when
analyzed, for example: “The system shall have an operational availability of 0.995 with
an MTBF (mean time between failures) of 500 hours and an MDT (mean down time) of 6 hours.”
If we use the standard relationship for availability as
the error in the requirement is clear. In both cases, these must be flagged and clarified or
corrected before proceeding.
6443/543– 8
![Page 7: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/7.jpg)
Incompatible and high risk requirements must be addressed, as well Incompatible requirements are those which cannot be
satisfied together For example, “the system shall run on both PC and Mac” and
“the system shall use Minitab for statistical analyses.” High risk requirements may involve new or state of the
art technology, tight schedule or cost constraints, the development of new skills, etc. These must be flagged early Plan specifically to meet them OR negotiate to have them
relaxed.
7443/543– 8
![Page 8: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/8.jpg)
Low performing requirements may result in an unsatisfactory product The most common type is specification of certain
software systems that may not be the most up to date by the time the product is finished.
8443/543– 8
![Page 9: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/9.jpg)
Once requirements have been evaluated and refined, the process of deriving and allocating requirements can begin ...
Requirements for subsystems are derived from this overall system requirement in order to design the subsystems. Derived requirements are not part of the requirements
document. The team must annotate all cases for which top-level system
requirements must be analyzed in greater detail to develop a set of derived requirements.
Such derived requirements are then “allocated” to the subsystems to give guidance to the subsystem design teams.
9443/543– 8
![Page 10: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/10.jpg)
Let’s look at an example ...
A requirements specification will usually identify the total maximum weight for the satellite based on constraints imposed by the launch vehicle
The team must use this requirement to derive weight requirements for satellite subsystems, such as: The satellite structure The stabilization and control subsystem The telemetry and data handling subsystem The thermal control subsystem The power supply subsystem The satellite payload subsystem
Each of these subsystems might then be examined to see if new derived weight requirements are needed.
10443/543– 8
![Page 11: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/11.jpg)
Let’s look at a second example
Sighting and pointing at a target in a shipboard environment.
The stated requirement for the system is that the sighting to the target have a maximum permissible error of one-half of a degree, which is equivalent to 0.00873 radian.
We further break down this error into three fundamental error sources:
1. Error in pointing by a human (operator error)
2. Error in the pointing instrument (instrument error)
3. Error in mounting the instrument to a platform (platform error) Assuming independent random errors associated with
the subsystems, i.e.,
σ2T = σ2
1+ σ22+ σ2
3
11443/543– 8
![Page 12: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/12.jpg)
We can create a model like this
Of course, we must ensure the human is capable of meeting the requirement; otherwise, we’ll have to revisit the derivation and allocation.
12443/543– 8
![Page 13: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/13.jpg)
Finally, let’s talk about special requirement problems These include:
1. Requirements creep/volatility
2. Not verifiable/testable
3. Unable to prioritize
4. Pre-defined solution
5. Incomplete
6. Stakeholders not sufficiently involved
13443/543– 8
![Page 14: Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013](https://reader035.vdocuments.mx/reader035/viewer/2022072011/56649e255503460f94b14a73/html5/thumbnails/14.jpg)
Homework (for your project notebook) Review your requirements and correct any ambiguous,
incorrect, or incompatible requirements. Identify high-risk and low-performance requirements and make a plan to address them (either through the development process or by revising the requirement).
Complete a Requirements Traceability Matrix for your project. If there are any requirements that do not apply to at least one
project task or subsystem, review your task list and project elements to be sure they are complete.
If there are any tasks or subsystems that do not have an associated requirement, your requirements are incomplete and must be updated.
Your complete requirements list and matrix should be in your project notebook by Tuesday, October 29.
14443/543– 8