CS 425/625 Software Engineering Software Requirements

1
CS 425/625 Software Engineering Software
Requirements

• Based on Chapter 5 of the textbook Somm00
• Ian Sommerville, Software Engineering, 6th Ed.,
  Addison-Wesley, 2000
• and on Ch5 PowerPoint presentation from the
  books web-site
• www.comp.lancs.ac.uk/computing/resources/IanS/SE6/
  Slides/index.html
• September 17, 2003

2
Outline

• Requirements
• Functional
• Non-functional
• Domain
• User Requirements
• Systems Requirements
• The Software Requirements Document

3
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
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
Requirements ..Introduction.

• Examples of user requirements definition and
  system requirements specification Fig. 5.1,
  Somm00

6
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
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
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
Requirements .Non-functional.

• A classification of non-functional requirements
  Fig. 5.3, Somm00

10
Requirements ..Non-functional

• Metrics that can be used to quantitatively
  specify and verify non-functional requirements
  Fig. 5.6, Somm-6

11
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
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
.User Requirements...

• Example of improperly stated requirement Fig.
  5.9, Somm00
• 2.6 Grid 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.

14
..User Requirements..

• Re-stated requirement Fig. 5.10, Somm00

15
User Requirements.

• Another example of requirements statement, well
  structured, more detailed and more precise Fig.
  5.11, Somm00

16
.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
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
.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
..System Requirements.

• Modalities for specifying requirements Fig.
  5.12, SE-6

20
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
.System Requirements..

• Example of a system requirement specified using
  structured natural language Fig. 5.13, Somm00

22
..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
System Requirements

• Example of PDL requirements specification Fig.
  5.14, Somm00

24
The Software Requirements Document..

• This document, also called Software Requirements
  Specification (SRS), is the official description
  of the systems 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
.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
..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