 |
|
|
Problems of requirements analysis
Waterfall processes often distinguished between
Requirements definitions: Customer-oriented descriptions of the system’s functions and constraints on its operation
Requirements specifications: Precise and detailed descriptions of the system’s functionality and constraints.
Functional requirements are statements of the services that the system should provide
Non-functional requirements are constraints on the services and functions offered by the system
Can lead to problems with
Physically, the RSDIMU consists of a square-based pyramid with the triangular faces being equilateral triangles (a semi-octahedron).
On each triangular face are mounted two sensors, at right angles to each other.
That gives a total of 8 sensors, all at varying angles to one another. That’s more than enough to determine the acceleration of the aircraft in 3 dimensions.
This redundancy (the “R” in RSDIMU) is important because:
Over time, some sensors may fail,
Like all physical measurement devices, the sensors are noisy – there are random errors in any real measurement process.
From the RSDIMU Requirements Definition:
An RSDIMU consists of a skewed array of redundant inertial sensors and exemplifies the current trend for designing hardware fault tolerant inertial measurement units (IMU’s) for high reliability applications. The portion of the RSDIMU you will handle contains eight linear accelerometers mounted on the four triangular faces of a semioctahedron.
Your procedure will have two functions, both of which are a consequence of the redundancy in the sensor complement of the RSDIMU. The first function is to perform a consistency check to detect and isolate failed sensors. The second is to use the sensors found to be good by the first check to provide estimates of the vehicle’s linear acceleration expressed as components along the north, east, and down axes of a navigational frame of reference.
⋮an RSDIMU as described here would operate as follows. With the vehicle stationary, as series of sensor readings would be taken over time, and this would comprise the calibration data set for that particular flight. During flight, the sensors would be read periodically at regular time intervals to provide input for the navigation software.
Critique
The preceding requirements mix up functional and non-functional requirements and are incomplete.
A simpler requirements definition.
Read through this.
The SRS (Software Requirements Specifications) adds detail to the requirements definition.
An SRS should be
Most of these are self-explanatory.
Requirements should be written so that they can be objectively verified
This is not good:
The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.
The error rate should be been quantified
Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.
Making the Subjective Objective
Some possible objective measures of properties that we often consider to be subjective:
| Property | Measure |
|---|---|
| (subjective) | (objective) |
| Speed | processed transactions / sec. |
| Response time | |
| screen refresh time | |
| Size | k bytes |
| Ease of use | training time |
| number of help frames | |
| Reliability | mean time to failure |
| probability of unavailability | |
| failure rate | |
| Robustness | time to restart after failure |
| probability of data corruption after failure | |
| Portability | % of target dependent statements |
| number of target systems |
Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source
Improving Traceability
"23: The system shall do A and B.
into
"23: The system shall do A.
"24: The system shall do B.
so that we can talk about requirements being satisfied or failed on an individual basis.
Cross-reference related requirements using this unique number
Produce a cross-reference matrix for each requirements document showing related requirements.
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
⋮
Appendixes
Index
(Source: IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications, sect 5)
Describe the general background affecting the product and its requirements.
Product perspective
Skipping forward for just a moment,…
"This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.
Important: Remember that this is requirements, not design.
If we organize by object/class, we are talking about classes discovered and documented in the domain model or analysis model.
(You would not choose this organization if you had not started with OOA.)
They are not necessarily classes that will appear in the design or implementation.
If we organize by “function”, we are not talking about C++/Java functions, but about functionality as observed by a user of the system.
E.g. our spreadsheet might have a functionality of propagating changes in values through the spreadsheet, but it is highly unlikely that you would be able to point to any single function in the code and say that it fulfilled that responsibility.
Whatever organization is chosen, Section 3 documents both functional and non-functional requirements, and does so separately.
“The system shall…”
These include
rather than,
“An operator shall not have to wait for the transaction to complete.”
Non-functional requirements examples
Product requirement
4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.
Organizational requirement
9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External requirement
7.6.5 The system shall provide facilities that allow any user to check if personal data is maintained on the system. A procedure must be defined and supported in the software that will allow users to inspect personal data and to correct any errors in that data.
There are many different styles for documenting functional and non-functional requirements.
The choice often depends on
Local culture – what the developers are familiar with.
Overall organization
Perhaps most common is the use of a mixture of natural language, mathematics, and diagrams, in a detailed numbered list:
3. Physical structure:
The RSDIMU is composed of an instrument and a display. The display is discussed in Section 6.3. This section is devoted to the structure of the instrument package.
3.1 The instrument package is a semi-octahedron (a square-based pyramid) (Figure 1).
3.1.1 It has four non-base faces, named
A,B,C, orD.3.1.2 Each face contains two sensors, named the
xandysensors.3.1.2.1 Associated with each sensor is a set of misalignment angles. These are specified further in Section 2.3.2.
Rationale: There is an ideal position for each sensor, but the physical mounting may differ slightly.
3.1.2.2 The misalignment angles are assumed to be small enough (less than 5 degrees) for the sine of the angle to be approximately equal to the value of the angle expressed in radians.
3.1.3 The temperature of the face,
temp, determines the temperatures of the sensors mounted on the face.Rationale: Sensor output varies with temperature (see section 4.6).
A pre-condition is what must be true before a function can be performed.
A post-condition describes what the function will accomplish as a boolean expression that will be true upon completion
There is a long tradition of documenting both functions (design and implementation) and functionality (requirements) with pre-conditions and post-conditions:
RSDIMU/Calibration/4.1
Function: Check for Noise
Description: The variance in a number of readings taken from one sensor while the vehicle was at rest are compared to a threshold value. Sensors whose variance exceeds the threshold are marked as failed due to excessive noise.
Inputs: Face, Sensor, raw sensor data collected on ground, noise threshold
Source: raw sensor data
offrawfrom external measurement procedureOutputs: Sensor failure
linFail& noise indicatorslinNoiseDestination: Edge consistency check and acceleration estimation functions
Requires: Instrument
Pre-condition: Sensor is not already marked as failed
Post-condition:
linFail[Face,Sensor]andlinNoise[Face,Sensor*]will be set to true ifstd-dev(offraw) > 3 * linstd.Side effects: Changes to sensor status affect face status as well.
The “Description” here is informal documentation.
The “real” specification is in the pre- and post- conditions and the side-effects.
Not surprisingly, this style probably works best if Section 3 is organized by function(ality).
Here is a complete SRS in the IEEE 830 style.
Organized by feature
Pick a feature out of section 3 (e.g., “Assignments”).
How does this stack up against our desired quality attributes:
There is always a dedicated group of advocates who maintain that the use of natural language in requirements specifications is a fundamental flaw.
They argue for any of several techniques of formal specification.
The influence of formal specification languages on conventional practice lies in the concepts of preconditions and postconditions.
A formal specification of the RSDIMU
Some schemas from the RSDIMU specification:
|
|