1 / 26

CS 425/625 Software Engineering

Software Requirements

Based on Chapter 5 of the textbook [Somm00] Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6th Ed., Addison-Wesley, 2000

and on Ch5 PowerPoint presentation from the book’s web-site:www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html

September 17, 2003September 17, 2003

2 / 26

Outline

Requirements: Functional Non-functional Domain

User Requirements Systems Requirements The Software Requirements Document

3 / 26

Requirements: Introduction…

Requirements = services the system is expected to provide + constraints placed on the system

Requirements engineering = gathering, negotiating, analyzing, and documenting requirements

The requirements could be expressed at various levels of abstraction

The way requirements are defined has a major impact on the development of the software product

4 / 26

Requirements: .Introduction..

A classification of requirements: User requirements: higher level description of

services requested and constraints imposed System requirements: a more detailed, structured

description of services and constraints. Usually included in the contract between the developer and the client

An even more detailed description of requirements can be provided in a software design specification (closer to implementation)

5 / 26

Requirements: ..Introduction. Examples of Examples of user requirementsuser requirements definitiondefinition and and system system

requirementsrequirements specificationspecification [Fig. 5.1, Somm00] [Fig. 5.1, Somm00]

1. The software must provide a means of representing and1. accessing external files created by other tools.

1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.

Requirements definition

Requirements specification

6 / 26

Requirements: …Introduction

Types of software system requirements: Functional requirements, describe the requested

functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations

Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process

Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain

7 / 26

Requirements: Functional

Functional requirements: Depend on the system, the software, and the users Can be expressed at different levels of detail

(user/system requirements) For a system, it is desirable to have a complete and

consistent set of functional requirements ● Completeness: all required system facilities are defined

● Consistency: there are no contradictions in requirements

8 / 26

Requirements: Non-functional..

Non-functional requirements: Many apply to the system as a whole More critical than individual functional

requirements More difficult to verify

Kinds of non-functional requirements: Product requirements Organizational requirements External requirements

9 / 26

Requirements: .Non-functional. A classification of non-functional requirements [Fig. 5.3, Somm00]:

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

10 / 26

Requirements: ..Non-functional Metrics that can be used to quantitatively specify and verify

non-functional requirements [Fig. 5.6, Somm-6]

Property MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

11 / 26

Requirements: Domain

Domain requirements indicate specific computations, additional functionality, or constraints on other requirements

Example [Fig.5.7, Somm00]:

The deceleration of the train shall be computed as:

Dtrain = Dcontrol + Dgradient

where Dgradient = 9.81ms2 * compensated gradient/alpha

and where the values of 9.81ms2/alpha are known for different types of train.

12 / 26

User Requirements….

User requirements: Should be understood by the user, and should not address

design and implementation aspects Should focus on the key facilities required

Problems with requirements written in natural language: Lack of clarity, ambiguity, various interpretations possible Confusion, lack of separation between different types of

requirements Mixture of several requirements in the same statement Hard to modularize and thus hard to find connections

between requirements

13 / 26

.User Requirements...

Example of improperly stated requirement [Fig. 5.9, Somm00]

2.6 2.6 Grid facilitiesGrid facilities

To assist in the positioning of entities on a diagram, the user mayTo assist in the positioning of entities on a diagram, the user mayturn on a grid in either centimetres or inches, via an option on theturn on a grid in either centimetres or inches, via an option on thecontrol panel. Initially, the grid is off. The grid may be turned on control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggledand off at any time during an editing session and can be toggledbetween inches and centimetres at any time. A grid option will be between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid linesprovided on the reduce-to-fit view but the number of grid linesshown will be reduced to avoid filling the smaller diagram with shown will be reduced to avoid filling the smaller diagram with grid lines.grid lines.

14 / 26

..User Requirements..

Re-stated requirement [Fig. 5.10, Somm00]

15 / 26

…User Requirements. Another example of requirements statement, well structured, more

detailed and more precise [Fig. 5.11, Somm00]

3.5.1 Adding nodes to a design3.5.1.1 The editor shall provide a f acility for users to add nodes of a specified type to their

design.

3.5.1.2 The sequence of actions to add a node should be as follows:

1. The user should select the type of node to be added.

2. The user should move the cursor to the approximate node position in the diagram andindicate that the node symbol should be added at that point.

3. The user should then drag the node symbol to its final position.

Rationale: The user is the best person to decide where to position a node on the diagram.This approach gives the user direct control over node type selection and positioning.

Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1

16 / 26

….User Requirements

Guidelines for writing requirements: Create and use a standard format for the entire software

requirements specification Highlight important parts of the requirement statements Use consistently the language (difference between

“should” and “shall”) Avoid computer jargon

17 / 26

System Requirements……

System requirements: More detailed specifications of user requirements Included in the contract with the client Used by developers as basis for design May be specified using various models (object-oriented

models, data-flow diagrams, formal specs, etc.) Should indicate WHAT the system is required to do (not

HOW) and under what conditions and constraints

18 / 26

.System Requirements.….

There is nevertheless a blurred line between specification and design because: A system architecture may be needed to

structure the requirements specification Design constraints may be part of the system

requirements Factors such as interoperability may also

impose design constraints

19 / 26

..System Requirements…. Modalities for specifying requirements [Fig. 5.12, SE-6]:

Notation DescriptionStructurednaturallanguage

This approach depends on defining standard forms ortemplates to express the requirements specification.

Designdescriptionlanguages

This approach uses a language like a programming languagebut with more abstract features to specify the requirementsby defining an operational model of the system.

Graphicalnotations

A graphical language, supplemented by text annotations isused to define the functional requirements for the system.An early example of such a graphical language was SADT(Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) havebeen used. I discuss these in the following chapter.

Mathematicalspecifications

These are notations based on mathematical concepts suchas finite-state machines or sets. These unambiguousspecifications reduce the arguments between customer andcontractor about system functionality. However, mostcustomers don’t understand formal specifications and arereluctant to accept it as a system contract. I discuss formalspecification in Chapter 9.

20 / 26

…System Requirements…

Standard templates for structured natural language specification should include, as applicable: Description of the function/service Inputs and their sources Outputs and their destinations Dependencies (other elements required) Pre-conditions Post-conditions Side-effects

21 / 26

….System Requirements.. Example of a system requirement specified using structured

natural language [Fig. 5.13, Somm00]

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.

Inputs Node type, Node position, Design identifier.

Source Node type and Node position are input by the user, Design identifier from the database.

Outputs Design identifier.

Destination The design database. The design is committed to the database on completion of theoperation.

Requires Design graph rooted at input design identifier.

Pre-condition The design is open and displayed on the user's screen.

Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.

Side-effects None

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

22 / 26

…..System Requirements.

Another alternative to natural language (NL) for software specification is Program Description Languages (PDL) Derived from programming languages May contain more abstract constructs Their syntax and semantics could be checked Recommended for describing sequences of actions

whose order is important & for specifying software interfaces

However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough

23 / 26

……System Requirements

Example of PDL requirements specification [Fig. 5.14, Somm00]

24 / 26

The Software Requirements Document..

This document, also called Software Requirements Specification (SRS), is the official description of the system’s requirements (includes user and system reqs.)

Heninger (1980) recommends that an SRS should: Specify only external system behaviour Specify constraints on implementation Be easy to change Serve as a reference for maintainers Record forethought about the software life cycle Describe acceptable responses to undesired events

25 / 26

.The System Requirements Document.

SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard): Introduction General description Specific requirements Appendices Index

This structure needs to be tailored for each particular organization

26 / 26

..The System Requirements Document..The System Requirements Document

A more detailed structure suggested in [Fig. 5.17, Somm00]: Table of contents Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index