Requirements Engineering

1
Requirements Engineering

• Dr Z He
• University of Ulster

2
Lecture 3 Requirements Engineering

• Objectives
• About requirements engineering
• What is a requirement?
• Requirements definition and specification
• Requirements engineering process
• Requirements documentation
• Requirements validation
• Requirements analysis strategies
• Software requirements specification
• Tools for specification (Analysis modelling) (SA,
  DFD, ERD, DD)

3
Requirements Engineering

• 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 are constraints on
  the system or on the development process

4
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
• A requirement
• tells us what the user requires
• says nothing about how it can be implemented

5
Requirements Definition/Specification

• Requirements definition
• A statement in natural language plus diagrams of
  the services the system provides and its
  operational constraints.
• Written for customers
• Requirements specification
• A structured document setting out detailed
  descriptions of the system services. Written as a
  contract between client and contractor.
• Written for customers also developers
• Software specification
• A detailed software description which can serve
  as a basis for a design or implementation.
• Written for developers
• Should be on what, clear, correct, complete ,
  testable

6
Definitions and Specifications
7
Problems with Requirements Definition

• It is hard to anticipate the effects that the new
  system will have on the organisation
• Different users have different requirements and
  priorities. There is a constantly shifting
  compromise in the requirements
• System end-users and organisations who pay for
  the system have different requirements
• Prototyping is often required to clarify
  requirements

8
Requirements Engineering Process

• Feasibility study
• Find out if the current user needs be satisfied
  given the available technology and budget?
• Requirements analysis
• Find out what system stakeholders require from
  the system
• Requirements definition
• Define the requirements in a form understandable
  to the customer
• Requirements specification
• Define the requirements in detail

Feasibility Report
Requirements Document
9
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 out WHAT the system should do
  rather than HOW it should do it

10
Requirements Document Requirements

• Specify external system behaviour
• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the
  system i.e. predict changes
• Characterise responses to unexpected events
• Should be complete and consistent
• Specify all system functions without or with
  minimum conflicts
• Should clear, correct, understandable, testable...

11
Requirements Document Structure

• Introduction
• Describe need for the system and how it fits with
  business objectives
• Glossary
• Define technical terms used
• System models
• Define models showing system components and
  relationships
• Functional requirements definition
• Describe the services to be provided
• use natural languages, diagrams etc.
  Understandable by customers
• Non-functional requirements definition
• Define constraints on the system and the
  development process

12
Requirements Document Structure

• System evolution
• Define fundamental assumptions on which the
  system is based and anticipated changes
• Requirements specification
• Detailed specification of functional requirements
• Appendices
• System hardware platform description
• Database requirements (as an ER model perhaps)
• Index

13
Requirements Validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing a
  requirement error
• Prototyping is an important technique of
  requirements validation
• throwaway prototyping
• evolutionary prototyping

14
Requirements Analysis - Strategies

• Asking - interview, questionnaire, brainstorming
• presupposes that user can bypass his own
  limitations/ bias
• Derivation from an Existing System
• existing system may have its own peculiar
  circumstances
• Synthesis of Environmental Characteristics
• look at the problem situation and establish
  patterns
• Prototyping
• Experiment with prototypes to determine user
  requirement

15
Requirements Specification

• Results of requirements analysis
• Input to the design stage
• Must be
• unambiguous
• complete
• exact (verifiable/testable) e.g. graphical user
  interface is not verifiable
• consistent e.g using the same term
• modifiable - requirements change
• traceable - where did a requirement come from?
• usable

16
Software Requirements Specification

• IEEE standard 830
• 1. Introduction
• An overview of the document
• Purpose
• Scope
• Definitions, acronyms and abbreviations
• References
• Overview
• 2. General Description
• about overall product and matters relating to
  this
• Product Perspective - where it fits
• Product Functions
• User characteristics
• General Constraints
• Assumptions and dependencies

17
Software Requirements Specification

• 3. Specific Requirements
• all the details
• 3.1 Functional Requirements - a description of
  each transformation of inputs to outputs
• 3.2 External interface requirements - User
  interface, Hardware interfaces, Software
  interfaces(e.g. operating system), Communication
  interfaces (e.g. protocols)
• 3.3 Performance Requirements
• static - no. of terminals, no. of users etc.
• dynamic - how frequent?, how fast?
• 3.4 Design Constraints
• Standards
• hardware limitations

18
Software Requirements Specification

• 3.5 Attributes
• Availability
• Security
• Maintainability
• 3.6 Other Requirements
• For more details
• Vliet, H.V, Software Engineering, John Wiley
  Sons, 1993, p145-, P515-

19
SRS An Example

• Software Requirements Specification
• AN AUTOMATED LIBRARY SYSTEM

20
SRS An Example
21
SRS An Example
22
Tools for Specification

• Structured Systems Analysis
• late 1970s - DeMarco, Gane and Sarson, Yourden
  and Constantine
• a structured way of modelling systems
• 2 aspects
• processes
• data
• Processes - DFDs
• Data - Entity Modelling
• Data Dictionary - All data is documented in a
  central repository as the analysis is done

23
Tools for Specification

1
2
X
Y
Z
S
D
P1
P2
W
D1
24
Process Specification

• Decision Trees - graphical representation of the
  decision process
• Decision Tables -Tabular representation of a
  decision process
• Structured English - restricted form of English
  akin to a programming language.

25
Semantic Data Models

• Used to describe the logical structure of data
  processed by the system
• Entity-relation model sets out the entities in
  the system, the relationships between these
  entities and the entity attributes
• Widely used in database design. Can readily be
  implemented using relational databases

26
An Entity-Relationship Model
27
Data Dictionaries

• A data dictionary is a list of names and
  associated descriptions of entities used in the
  system
• It represents a shared repository of system
  information
• It serves as
• A mechanism for name management. As a system
  model may be developed by different people, there
  is potential for name clashes
• A link from analysis to design and implementation
• The structure of a data dictionary can be
  described by a semantic data model (next slide)

28
Structure of Data Dictionary