1 / 26

CS 425/625 Software Engineering

Software Requirements

Based on Chapter 6 of the textbook [SE-8] Based on Chapter 6 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006

and on Ch6 PowerPoint presentation from the book’s web-site

October 12, 2009October 12, 2009

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…

““If a company wishes to let a contract for a large softwareIf a company wishes to let a contract for a large softwaredevelopment project, it must define its needs in a sufficiently development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both client understands and can validate what the software will do. Both of these documents may be called the of these documents may be called the requirements documentrequirements document for for the system.” [Davis]the system.” [Davis]

5 / 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)

6 / 26

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

specificationspecification [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8] [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8]

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

7 / 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

8 / 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

9 / 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

10 / 26

Requirements: .Non-functional. A classification of non-functional requirements [Fig. 6.3, SE-7]:

Performancerequirements

Spacerequir ements

Usabilityrequirements

Ef ficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

11 / 26

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

non-functional requirements [Fig. 6.6, SE-8]

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

12 / 26

Requirements: Domain

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

Example [Fig.6.7, SE-8]:

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.

13 / 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

14 / 26

.User Requirements.. Example of improperly stated requirement [Fig. 6.9, SE-8]

2.6 2.6 Grid facilitiesGrid facilities

To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the 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 toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

15 / 26

..User Requirements. Another example of requirements statement, well structured and

more precise [Fig. 6.10, SE-08]

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. 6.11, SE-8]:

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, Sommerville 2000] – see also [Fig 6.12, SE-8]

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 RequirementsExample of PDL requirements specification [Fig. 5.14, Somm2000],See also Fig. 6.15 [SE-7]

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