0% found this document useful (0 votes)
445 views

Chapter 6 - Software Requirements

se-1
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
445 views

Chapter 6 - Software Requirements

se-1
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 26

Software Requirements

 Definition: Description and Specifications


of a system
 Topics covered:
• Functional and Non-functional requirement
• User Requirements
• System requirements
• The software requirements document

©Ian Sommerville Software Engineering Slide 1


Software Requirements
 The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed
 Requirements may be functional or non-functional
• Functional requirements describe system services or functions
• Non-functional requirements is a constraint on the system or on
the development process

©Ian Sommerville Software Engineering Slide 2


What is a requirement?
 It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
 This is inevitable as requirements may serve a dual
function
• May be the basis for a bid for a contract - therefore must be open to
interpretation
• May be the basis for the contract itself - therefore must be defined in
detail
• Both these statements may be called requirements

©Ian Sommerville Software Engineering Slide 3


Types of requirements
 User requirements
• Statements in natural language (NL) plus diagrams of the services the
system provides and its operational constraints. Written for customers

 System requirements
• A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor

 Software specification
• A detailed software description which can serve as a basis for a design or
implementation. Written for developers

©Ian Sommerville Software Engineering Slide 4


Requirements Targets

Client Managers
System end-users
User Contract managers
Requirements System architects
System end-users
System
Client engineers
Requirements
System architects
Software developers
Software
Specification Client engineers
System architects
©Ian Sommerville Software Engineering Software developers Slide 5
Requirements Types:
1. Functional requirements: services the system
should provide
2. Non-functional requirements: constraints on the
services of functions offered by the system. e.g.
speed, time to market
3. Domain requirements: related to the application
domain of the system (may be functional or non-
functional requirements)

©Ian Sommerville Software Engineering Slide 6


Functional requirements
 Functionality or services that the system is
expected to provide.
 Functional requirements may also explicitly state
what the system shouldn’t do.
 Functional requirements specification should be:
• Complete: All services required by the user should be defined
• Consistent: should not have contradictory definition (also avoid
ambiguity don’t leave room for different interpretations)

©Ian Sommerville Software Engineering Slide 7


Non-Functional requirements
 Requirements that are not directly concerned with
the specific functions delivered by the system
 Typically relate to the system as a whole rather
than the individual system features
 Often could be deciding factor on the survival of
the system (e.g. reliability, cost, response time)

©Ian Sommerville Software Engineering Slide 8


Non-Functional requirements
classifications:

Non-Functional
Requirements
Product requirements External requirements

•Efficiency •Interoperability
Organizational requirements
•Reliability •Ethics
•Delivery
•Portability •Legislative
•Implementation
•Usability •Privacy
•Standards
•Performance •Safety
•Space
©Ian Sommerville Software Engineering Slide 9
Domain requirements
 Domain requirements are derived from the application
domain of the system rather than from the specific needs
of the system users.
 May be new functional requirements, constrain existing
requirements or set out how particular computation must
take place.
 Example: tolerance level of landing gear on an aircraft
(different on dirt, asphalt, water), or what happens to fiber
optics line in case of sever weather during winter
Olympics (Only domain-area experts know)

©Ian Sommerville Software Engineering Slide 10


Problems with natural language
 Lack of clarity
• Precision is difficult without making the document difficult to read
 Requirements confusion
• Functional and non-functional requirements tend to be mixed-up
 Requirements amalgamation
• Several different requirements may be expressed together
 Ambiguity
• The readers and writers of the requirement must interpret the same
words in the same way. NL is naturally ambiguous so this is very
difficult
 Over-flexibility
• The same thing may be said in a number of different ways in the
specification

©Ian Sommerville Software Engineering Slide 11


Alternatives to NL specification
 Structured Natural language (via standard forms
& templates)
 Program Description Language (PDL)
 Use-Cases (scenario-based technique)
 Mathematical specification (notations based on
mathematical concepts such as finite-state
machines or set.)

©Ian Sommerville Software Engineering Slide 12


Structured language specifications
 A limited form of natural language may be used
to express requirements
 This removes some of the problems resulting
from ambiguity and flexibility and imposes a
degree of uniformity on a specification
 Often best supported using a form-based
approach

©Ian Sommerville Software Engineering Slide 13


Form-based specification
ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function: Add node


Description: Adds a node to an existing design.
Inputs: Node type, Node Position
Outputs: Design identifier
Pre/Post conditions:
Other attributes:
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

©Ian Sommerville Software Engineering Slide 14


PDL-based requirements definition
 Requirements may be defined operationally using a
language like a programming language but with
more flexibility of expression
 Most appropriate in two situations
• Where an operation is specified as a sequence of actions and the
order is important
• When hardware and software interfaces have to be specified
• Example: ATM machine

©Ian Sommerville Software Engineering Slide 15


PDL disadvantages
 PDL may not be sufficiently expressive to
express the system functionality in an
understandable way
 Notation is only understandable to people with
programming language knowledge
 The requirement may be taken as a design
specification rather than a model to help
understand the system

©Ian Sommerville Software Engineering Slide 16


ATM Specification: a PDL example
Class ATM {
// declaration here
public static void main (string args[]) InvalidCard {
try {
thisCard.read(); //may throw Invalid card
exception
pin = KeyPaD.READpIN(); attempts = 1;
While (!thisCard.pin.equal(pin) & attempts < 4)
pin = KeyPad.readPin(); attempts += 1;
.
.
.
©Ian Sommerville Software Engineering Slide 17
The requirements document
 The requirements document is the official
statement of what is required of the system
developers
 Should include both a definition and a
specification of requirements
 It is NOT a design document. As far as possible,
it should set of WHAT the system should do
rather than HOW it should do it

©Ian Sommerville Software Engineering Slide 18


Requirements Engineering (RE)
processes
 Processes used to discover, analyse and
validate system requirements
 RE vary widely depending on the application domain, the
people involved and the organization developing the
requirements
 However, there are a number of generic activities
common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

©Ian Sommerville Software Engineering Slide 19


Problems of requirements analysis
 Stakeholders don’t know what they really want
 Stakeholders express requirements in their own terms
 Different stakeholders may have conflicting requirements
 Organizational and political factors may influence the
system requirements
 The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change

©Ian Sommerville Software Engineering Slide 20


Use cases
 Use-cases are a scenario based technique in the
UML which identify the actors in an interaction
and which describe the interaction itself
 A set of use cases should describe all possible
interactions with the system
 Sequence diagrams may be used to add detail to
use-cases by showing the sequence of event
processing in the system

©Ian Sommerville Software Engineering Slide 21


Lending use-case

Lending services

Actor

©Ian Sommerville Software Engineering Slide 22


Library use-cases

Lending services

Library
User
User administration

Library
Staff
Catalog services
Supplier
©Ian Sommerville Software Engineering Slide 23
Ethnography
 Ethnography is an observational technique that
can be used to understand social and
organizational requirements.
 Developed in a project studying the air traffic
control process
 Problem with ethnography is that it studies
existing practices which may have some
historical basis which is no longer relevant

©Ian Sommerville Software Engineering Slide 24


Enduring and volatile requirements
 Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain
models
 Volatile requirements. Requirements which
change during development or when the system is
in use. In a hospital, requirements derived from
health-care policy

©Ian Sommerville Software Engineering Slide 25


Classification of requirements
 Mutable requirements
• Requirements that change due to the system’s environment
 Emergent requirements
• Requirements that emerge as understanding of the system
develops
 Consequential requirements
• Requirements that result from the introduction of the computer
system
 Compatibility requirements
• Requirements that depend on other systems or organisational
processes

©Ian Sommerville Software Engineering Slide 26

You might also like