1 A “Classical” Approach to Requirements

Problems of requirements analysis

• Stakeholders don’t know what they really want
• Stakeholders express requirements in their own terms (conflicting with developers’ familiar terminology)
• Different stakeholders may have conflicting requirements
• Organizational and political factors may influence the system requirements
• The requirements may change during the analysis process.
• New stakeholders may emerge

1.1 The Primary Requirements Documents

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.

2 Requirements Definition

• Should specify external behavior of the system
• Includes functional and non-functional requirements

  • Functional requirements are statements of the services that the system should provide

    • Basically, what outputs should be produced for a given class of inputs

  • Non-functional requirements are constraints on the services and functions offered by the system

    • Anything that isn’t “what outputs should be produced for a given class of inputs”

2.1 Writing requirements definitions

• Commonly in natural language, supplemented by diagrams and tables

  Can lead to problems with

  • Lack of clarity.
  • Requirements confusion (mixing functional and non-functional reqts)
  • Requirements amalgamation: mixing requirements together

2.2 Example (RSDIMU)

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,

  • Redundancy means the system continues to function even after multiple failures.

• Like all physical measurement devices, the sensors are noisy – there are random errors in any real measurement process.

  • Redundancy allows us to “average” together the readings to get a more accurate estimate.

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.

The preceding requirements mix up functional and non-functional requirements and are incomplete.

• Easy to criticize 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 omitted

2.3 Example (Spreadsheet)

3 Requirements Specification

The SRS (Software Requirements Specifications) adds detail to the requirements definition.

• It should be consistent with the RD.
• Often presented with system models which are developed during the requirements analysis.
• Usually written in natural language but this can be problematical

3.1 Characteristics of a good SRS

An SRS should be

1. Correct;
2. Unambiguous;
3. Complete;
4. Consistent;
5. Ranked for importance and/or stability;
6. Verifiable (see below)
7. Modifiable;
8. Traceable (see below)

Most of these are self-explanatory.

• Requires precision in terminology

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

Some possible objective measures of properties that we often consider to be subjective:

3.1.2 Requirements traceability

Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source

• Traceability is a property of a requirements specification which reflects the ease of finding related requirements.
• Some CASE tools provide traceability support facilities. For example, they may be able to find all requirements which use the same terms.
• Test specifications may attempt to trace tests back to reqts,
  • thereby demonstrating that each reqt has been tested.

• Assign a unique number or label to all requirements
• Keep individual requirements small.

  E.g., Break up

  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.

4 Documenting Individual Requirements

There are many different styles for writing requirements.

The choice often depends on

• Local culture – what the developers are familiar with.

• Overall organization

  • Different schemes for organizing the overall SRS lend themselves to different approaches for writing the specific requirements.

4.1 Structured English

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

• Each numbered item is a separate functional requirement.

• These are often described as “The system shall…” statements.

  • As you can see, however, they often (and maybe preferably) refer to previously introduced subsystems.

• Works well when organizing by feature.

4.2 Pre and Post Conditions

A pre-condition is what must be true before a function can be performed.

4.3 Functional and Non-Functional Requirements.

Requirements are generally divided into functional and non-functional.

4.4 Functional Requirements

Functional requirements are the ones that say “if the input is … the output will be …”.

These can include statements about:

1. Validity checks on the inputs
2. Exact sequence of operations
3. Responses to abnormal situations, including
   • Overflow
   • Communication facilities
   • Error handling and recovery
4. Effect of parameters
5. Relationship of outputs to inputs, including
   • Input/output sequences
   • Formulas for input to output conversion

4.4.1 Examples of functional requirements:

Structured English style requirements will always have a number or label followed by a short (1-2 sentences) statement that the system (or some subsystem) must do something.

4.5 Non-functional requirements

Any requirement that isn’t functional, including

• Performance requirements
  • Should be stated in measurable terms.
  • e.g., “95% of the transactions shall be processed in less than 1 sec.”

    rather than,

    “An operator shall not have to wait for the transaction to complete.”

• Database reqts
  • data entities, integrity constraints, data retention
• Standards compliance
• Software attributes
  • Reliability (general, not when applied to specific output behaviors)
  • Security (although specific actions to enforce security are usually functional if they relate to I/O behaviors)
  • maintainability
  • portability

• Performance requirement

4.1 All searches for customer records must complete within 0.5 sec.

• 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. An administrative 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.

4.5.1 Requirements separation

• Functional and non-functional requirements should, in principle, be distinguished in a requirements specification
• However, this can be difficult as requirements may be expressed as whole system requirements rather than constraints on individual functions
• It is sometimes difficult to decide if a requirement is functional or a non-functional
  • E.g., requirements for safety are concerned with non-functional properties but may require functions to be added to the system

5 The IEEE standard SRS outline

There are many ways to organize a requirements document, but this has been an industry standard for a long time.

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

5.1 The Supporting Text

Much of this outline describes descriptive text that will “surround” the real requirements.

Section 1 is about the SRS document itself, not the system being described.

The primary subsections are 1. Purpose: indicate purpose of the document and its intended audience 2. Scope: identifies software products to be developed, benefits, objectives * Identify the software products to be produced * Explain what they will (and will not) do * Describe the application area, including benefits and objectives

Although this subsection does describe the product, it should do so in the
context of revealing why someone would read the rest of the document. Hence this is still, primarily, describing the document.

1. Definitions, acronyms, and abbreviations;
2. References;
3. Overview.
   • Describe organization of the remainder of the SRS document
     • As we will see, the SRS authors have choices as to how they will organize section 3 of the SRS. This overview must identify which of those choices they have selected.

At the end of section 1, readers know whether they want to read the reset of the document and have an overall map of what is coming.

Section 2 turns its focus to the product being specified.

• Describe the general background affecting the product and its requirements.

• Product perspective

  • related products and systems
  • diagram of major components
  • architectural constraints (e.g., required interfaces)
• Product functions (functionality)
  • major functions to be performed
• User characteristics;
• Constraints;
  • regulatory, hardware, required interfaces, audit functions, reliability, safety, security
• Assumptions and dependencies;
• Apportioning of requirements
  • What can be deferred to future versions?

Skipping forward for just a moment,…

• Sample I/O formats
• GUI screens(?)
• Additional background info

Don’t add appendices just to pad out the document. Each appendix must be referenced somewhere in the main document.

5.2 The Actual Requirements

3. Specific Requirements

The is the real heart of the IEEE SRS — this is where we actually put the requirements.

• Everything else is supporting text. It exists only to make section 3 of the SRS easier to read and understand.

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

5.2.1 Choices of Organization

5.2.2 Organizing by Mode

Some systems have distinct modes of operation that server to strictly limit what functions can be performed at any one time.

• Example: The RSDIMU has two distinct modes: a calibration mode when the plane is on the ground, and a navigation mode when the plane is in the air.

3. Specific Requirements
3.1 External Interface Requirements
   3.1.1 User Interfaces
   3.1.2 Hardware Interfaces
   3.1.3 Software Interfaces
   3.1.4 Communications Interfaces
3.2 Functional Requirements
   3.2.1 Mode 1
      3.2.1.1 Functional reqt 1.1
      3.2.1.2 Functional reqt 1.2
        ⋮
   3.2.2 Mode 2
      3.2.2.1 Functional reqt 2.1
      3.2.2.2 Functional reqt 2.2
        ⋮
   ⋮ 
3.3 Performance reqts
3.4 Design constraints
3.5 Software system attributes
3.5 Other Reqts

• This is supporting text. Refer to the IEEE standard for details.

  • An alternate form of the organization by mode allows separate supporting text for each distinct mode.

• This is where the functional reqts are stated. This is the core of the SRS.

  • If you don’t get this right, you might as well not have written the whole document.

• This is where the non-functional reqts are placed.

5.2.3 Organizing by User Class

Some systems have multiple user classes or roles, with very different functionality seen by each role.

This organization is similar to the previous one, replacing modes by user roles

3. Specific Requirements
3.1 External Interface Requirements
   3.1.1 User Interfaces
   3.1.2 Hardware Interfaces
   3.1.3 Software Interfaces
   3.1.4 Communications Interfaces
3.2 Functional Requirements
   3.2.1 User class 1
      3.2.1.1 Functional reqt 1.1
      3.2.1.2 Functional reqt 1.2
        ⋮
   3.2.2 User class 2
      3.2.2.1 Functional reqt 2.1
      3.2.2.2 Functional reqt 2.2
        ⋮
   ⋮ 
3.3 Performance reqts
3.4 Design constraints
3.5 Software system attributes
3.5 Other Reqts

• Both the supporting text and non-functional reqts areas are unchanged.

5.2.4 Organizing by Stimulus

This organization is used when the most distinctive characteristic of the system is the different kinds of stimuli – external events or inputs – to which the system must respond.

3. Specific Requirements
3.1 External Interface Requirements
   3.1.1 User Interfaces
   3.1.2 Hardware Interfaces
   3.1.3 Software Interfaces
   3.1.4 Communications Interfaces
3.2 Functional Requirements
   3.2.1 Stimulus 1
      3.2.1.1 Functional reqt 1.1
      3.2.1.2 Functional reqt 1.2
        ⋮
   3.2.2 Stimulus 2
      3.2.2.1 Functional reqt 2.1
      3.2.2.2 Functional reqt 2.2
        ⋮
   ⋮ 
3.3 Performance reqts
3.4 Design constraints
3.5 Software system attributes
3.5 Other Reqts

• Both the supporting text and non-functional reqts areas are unchanged.

5.2.5 Organizing by Object

If you have performed a full object-oriented analysis and formulated domain and analysis models as a collection of interacting objects, you can use your analysis model as the basis for organizing and stating your reqts.

3. Specific Requirements
3.1 External Interface Requirements
   3.1.1 User Interfaces
   3.1.2 Hardware Interfaces
   3.1.3 Software Interfaces
   3.1.4 Communications Interfaces
3.2 Specific Requirements
   3.2.1 Class/Object 1
      3.2.1.1 Attributes
          3.2.1.1.1 Attribute 1.1
           ⋮
      3.2.1.2 Functions
         3.2.1.2.1 Functional reqt 1.1
         3.2.1.2.1 Functional reqt 1.2
          ⋮
   3.2.2 Class/Object 2
      3.2.2.1 Attributes
          3.2.2.1.1 Attribute 2.1
           ⋮
      3.2.2.2 Functions
         3.2.2.2.1 Functional reqt 2.1
         3.2.2.2.1 Functional reqt 2.2
          ⋮
   ⋮ 
3.3 Performance reqts
3.4 Design constraints
3.5 Software system attributes
3.5 Other Reqts

• Both the supporting text and non-functional reqts areas are unchanged.

• The division of section 3.2 is very different from what came before, but makes sense from an OOA point of view.

  • Notice that attributes are listed separately, but we don’t list functions but instead jump straight into requirements.
  • That’s probably because many functional requirements will express a relationship between multiple functions,
    • e.g., “The top() function of the stack returns the value most recently supplied to a push(...)”.
    • Such statements cannot be cleanly divided into separate lists per function.

• I would expect any SRS using this organization to include lots of UML, amounting to the entire analysis model being embedded in the SRS.

  • And presumably, the domain model appeared in the earlier requirements Definition.

5.2.6 Organizing by Feature

Features can be any readily observable behavior or functionality.

3. Specific Requirements
3.1 External Interface Requirements
   3.1.1 User Interfaces
   3.1.2 Hardware Interfaces
   3.1.3 Software Interfaces
   3.1.4 Communications Interfaces
3.2 System features
   3.2.1 System feature 1
      3.2.1.1 Introduction/Purpose of feature
      3.2.1.2 Stimulus/Response sequence
      3.2.1.3 Associated functional requirements
         3.2.1.3.1 Functional reqt 1.1
         3.2.1.3.1 Functional reqt 1.2
          ⋮ 
   ⋮
3.3 Performance reqts
3.4 Design constraints
3.5 Software system attributes
3.5 Other Reqts

• This has supporting text for describing each feature, but the core content is still the functional reqts.

• The reference to “Stimulus/Response” means that we want to document the inputs/events that trigger the use of this feature, and summarize the effects/outputs of the feature.

5.2.7 Organizing by Functional Hierarchy

This organization supports a form of data-flow analysis that was wide-spread in the pre-OOA days.

A data-flow analysis views a system as a series of data transformations converting input into output.

Here’s an overview of a system that was designed using data-flow.

• The rectangular areas represent data storage.
• The arrows indicate pathways along with different kinds of data can flow.
• Each ellipse (or rectangle with rounded corners) is a transformation that takes data in and emits reformatted or reformulated data out.

  A key idea is that computation (the transforms) cannot create new information. Any information that appears in the output had to be present, however hard to find, in the input data.

Data-flow analysis is not widely used anymore, having been supplanted by OO modelling.

5.3 Example: Spreadsheet

6 A Minority View - Formal Requirements

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.

6.1 Example of Formal Specification