Chapter 8: Requirements analysis & allocation (pt. 2) ISE 443 / ETM 543 Fall 2013

A minimum set of essential steps with respect to the analysis of requirements includes: 2 443/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

In the development of large systems RAA is an automated process A list of commonly used tools is given on pages of your textbook. We will be conducting the analysis by hand for your project /543– 8

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 4 443/543– 8

The Requirements Traceability Matrix (TRM) is a tool for documenting and tracking.... Reqt. #Name/descriptionProject TaskTestVerified (Y/N) No 5 443/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.

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 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 /543– 8

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 /543– 8

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 /543– 8

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 /543– 8

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 /543– 8

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 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., σ 2 T = σ σ σ /543– 8

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 /543– 8

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 /543– 8

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 /543– 8