1 Requirements definition

• Requirements definition
  • Customer-oriented descriptions of the system's functions and constraints on its operation

• Requirements specification
  • Precise and detailed descriptions of the system's functionality and constraints.

    Intended to communicate what is required to system developers and serve as the basis of a contract for the system development

• Should specify external behaviour of the system
• Includes functional and non-functional requirements
  • 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

1.0.0.0 Writing requirements definitions  

• Natural language, supplemented by diagrams and tables is the normal way of writing requirements definitions
• This is universally understandable but three types of problem can arise
  • Lack of clarity.
  • Requirements confusion.
  • Requirements amalgamation.

1.0.0.0 RSDIMU, p 2  

An RSDIMU consists of a skewed array of redundant inertial sensors and examplifies the current trend for designing hardware fault tolerant inerial measurement units (IMU's) for high reliability applications. The portion of the RSDIMU you will handle containes 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 expresses as components along the north, east, and down axes of a navigational frame of reference.

1.0.0.0 RSDIMU, p 3  

. . . an RSDIMU as described here would operate as follows. With the vehicle sttionary, 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.

1.0.0.0 Defining requirements  

• RSDIMU requirements mix up functional and non- functional requirements and is incomplete
• Easy to criticise but hard to write good requirements definitions
• Use of a standard format with pre-defined fields to be filled means that information is less likely to be missed out

1.0.0.0 Structured Definition  

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, or D.

3.1.2 Each face contains two sensors, named the x and y sensors.

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).

1.0.0.0 Requirements rationale  

• It is important to provide rationale with requirements
• This helps the developer understand the application domain and why the requirement is stated in its current form
• Particularly important when requirements have to be changed. The availability of rationale reduces the chances that change will have unexpected effects