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:

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

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

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

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.

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

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

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

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

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

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

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

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

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