Unit II

Chapter 5
Software Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1

Software Requirements
 Descriptions and specifications of a system

Objectives
 To introduce the concepts of user and system
requirements
 To describe functional and non-functional
requirements
 To explain two techniques for describing system
requirements
 To explain how software requirements may be
organised in a requirements document

Topics covered
 Functional and non-functional requirements
 User requirements
 System requirements
 The software requirements document

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
 The requirements themselves are the descriptions of
the system services and constraints that are
generated during the requirements engineering
process

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

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

Types of requirement
 User requirements
• Statements in natural language 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

Definitions and specifications
Requirements definition
1. The software must provide a means of repr esenting and

1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.

Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects
System end-users
Client engineers
System requirements
System architects
Software developers
Client engineers (perhaps)

Software design
System architects
specification
Software developers

Functional and non-functional requirements
 Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.
 Non-functional requirements
• constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.
 Domain requirements
• Requirements that come from the application domain of the system
and that reflect characteristics of that domain

Functional requirements
 Describe functionality or system services
 Depend on the type of software, expected users and
the type of system where the software is used
 Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe the
system services in detail

Examples of functional requirements
 The user shall be able to search either all of the
initial set of databases or select a subset from it.
 The system shall provide appropriate viewers for the
user to read documents in the document store.
 Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to
the account’s permanent storage area.

Requirements imprecision
 Problems arise when requirements are not precisely
stated
 Ambiguous requirements may be interpreted in
different ways by developers and users
 Consider the term ‘appropriate viewers’
• User intention - special purpose viewer for each different document
type
• Developer interpretation - Provide a text viewer that shows the
contents of the document

Requirements completeness and consistency
 In principle requirements should be both complete

and consistent
 Complete
• They should include descriptions of all facilities required
 Consistent
• There should be no conflicts or contradictions in the descriptions of
the system facilities
 In practice, it is impossible to produce a complete
and consistent requirements document

Non-functional requirements
 Define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
 Process requirements may also be specified
mandating a particular CASE system, programming
language or development method
 Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless

Non-functional classifications
 Product requirements
• Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.
 Organisational requirements
• Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.
 External requirements
• Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.

Non-functional requirement types
Non-functional
requir ements
Product Or ganizational External

requir ements requir ements requirements
Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements
Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements
Performance Space Privacy Safety

requirements requir ements requirements requirements

Non-functional requirements examples
 Product requirement
• 4.C.8 It shall be possible for all necessary communication between
the APSE and the user to be expressed in the standard Ada character
set
 Organisational requirement
• 9.3.2 The system development process and deliverable documents
shall conform to the process and deliverables defined in XYZCo-SP-
STAN-95
 External requirement
• 7.6.5 The system shall not disclose any personal information about
customers apart from their name and reference number to the
operators of the system

Goals and requirements
 Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify.
 Goal
• A general intention of the user such as ease of use
 Verifiable non-functional requirement
• A statement using some measure that can be objectively tested
 Goals are helpful to developers as they convey the
intentions of the system users

Examples
 A system goal
• The system should be easy to use by experienced controllers and
should be organised in such a way that user errors are minimised.
 A verifiable non-functional requirement
• Experienced controllers shall be able to use all the system functions
after a total of two hours training. After this training, the average
number of errors made by experienced users shall not exceed two
per day.

Requirements measures
Property Meas ure
Speed Process ed trans actions/s econd
User/Event respons e time
Screen refres h time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustnes s Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements interaction
 Conflicts between different non-functional
requirements are common in complex systems
 Spacecraft system
• To minimise weight, the number of separate chips in the system
should be minimised
• To minimise power consumption, lower power chips should be used
• However, using low power chips may mean that more chips have to
be used. Which is the most critical requirement?

Domain requirements
 Derived from the application domain and describe
system characterisics and features that reflect the
domain
 May be new functional requirements, constraints on
existing requirements or define specific computations
 If domain requirements are not satisfied, the system
may be unworkable

Library system domain requirements
 There shall be a standard user interface to all
databases which shall be based on the Z39.50
standard.
 Because of copyright restrictions, some documents
must be deleted immediately on arrival. Depending
on the user’s requirements, these documents will
either be printed locally on the system server for
manually forwarding to the user or routed to a
network printer.

Train protection system
 The deceleration of the train shall be computed

as:
• Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of 9.81ms2
/alpha are known for different types of train.

Domain requirements problems
 Understandability
• Requirements are expressed in the language of the application
domain
• This is often not understood by software engineers developing the
system
 Implicitness
• Domain specialists understand the area so well that they do not think
of making the domain requirements explicit

User requirements
 Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
 User requirements are defined using natural
language, tables and diagrams

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

Guidelines for writing requirements
 Invent a standard format and use it for all
requirements
 Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements
 Use text highlighting to identify key parts of the
requirement
 Avoid the use of computer jargon

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

Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements
Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process
Use the requirements to

System engineers understand what system is to
be developed
System test Use the requirements to

engineers develop validation tests for
the system
Users of a
System Use the requirements to help requirements
maintenance understand the system and
engineers the relationships between its document
parts
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

IEEE requirements standard
 Introduction
 General description
 Specific requirements
 Appendices
 Index
 This is a generic structure that must be instantiated
for specific systems

Requirements document structure
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index

Key points
 Requirements set out what the system should do
and define constraints on its operation and
implementation
 Functional requirements set out services the system
should provide
 Non-functional requirements constrain the system
being developed or the development process
 User requirements are high-level statements of what
the system should do

Key points
 User requirements should be written in natural
language, tables and diagrams
 System requirements are intended to communicate
the functions that the system should provide
 System requirements may be written in structured
natural language, a PDL or in a formal language
 A software requirements document is an agreed
statement of the system requirements

Requirements Engineering Process

Requirements Engineering Processes
 Processes used to discover,

analyse and validate system
requirements

Objectives
 To describe the principal requirements engineering
activities
 To introduce techniques for requirements elicitation
and analysis
 To describe requirements validation
 To discuss the role of requirements management in
support of other requirements engineering processes

Topics covered
 Feasibility studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management

Requirements engineering processes
 The processes used for RE vary widely depending

on the application domain, the people involved and
the organisation developing the requirements
 However, there are a number of generic activities
common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

The requirements engineering process

Feasibility studies
 A feasibility study decides whether or not the
proposed system is worthwhile
 A short focused study that checks
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within
budget
• If the system can be integrated with other systems that are used

Feasibility study implementation
 Based on information assessment (what is required),
information collection and report writing
 Questions for people in the organisation
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?

Elicitation and analysis
 Sometimes called requirements elicitation or
requirements discovery
 Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
 May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders

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
 Organisational and political factors may influence the
system requirements
 The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change
A spiral view of the requirements
engineering process
©Ian Sommerville 2000 Chapter 4

Software Engineering, 6th edition. Chapter 5 48 Slide 48
The requirements analysis
process

Process activities
 Domain understanding
 Requirements collection
 Classification
 Conflict resolution
 Prioritisation
 Requirements checking

System models
 Different models may be produced during the
requirements analysis activity
 Requirements analysis may involve three structuring
activities which result in these different models
• Partitioning. Identifies the structural (part-of) relationships between
entities
• Abstraction. Identifies generalities among entities
• Projection. Identifies different ways of looking at a problem
 System models covered in Chapter 7

Viewpoint-oriented elicitation
 Stakeholders represent different ways of looking at a
problem or problem viewpoints
 This multi-perspective analysis is important as there
is no single correct way to analyse system
requirements

Banking ATM system
 The example used here is an auto-teller system
which provides some automated banking services
 I use a very simplified system which offers some
services to customers of the bank who own the
system and a narrower range of services to other
customers
 Services include cash withdrawal, message passing
(send a message to request a service), ordering a
statement and transferring funds

Autoteller viewpoints
 Bank customers
 Representatives of other banks
 Hardware and software maintenance engineers
 Marketing department
 Bank managers and counter staff
 Database administrators and security staff
 Communications engineers
 Personnel department

Types of viewpoint
 Data sources or sinks
• Viewpoints are responsible for producing or consuming data.
Analysis involves checking that data is produced and consumed and
that assumptions about the source and sink of data are valid
 Representation frameworks
• Viewpoints represent particular types of system model. These may
be compared to discover requirements that would be missed using a
single representation. Particularly suitable for real-time systems
 Receivers of services
• Viewpoints are external to the system and receive services from it.
Most suited to interactive systems

External viewpoints
 Natural to think of end-users as receivers of system
services
 Viewpoints are a natural way to structure
requirements elicitation
 It is relatively easy to decide if a viewpoint is valid
 Viewpoints and services may be sued to structure
non-functional requirements

Method-based analysis
 Widely used approach to requirements analysis.
Depends on the application of a structured method to
understand the system
 Methods have different emphases. Some are
designed for requirements elicitation, others are
close to design methods
 A viewpoint-oriented method (VORD) is used as an
example here. It also illustrates the use of viewpoints

The VORD method

VORD process model
 Viewpoint identification
• Discover viewpoints which receive system services and identify the
services provided to each viewpoint
 Viewpoint structuring
• Group related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy
 Viewpoint documentation
• Refine the description of the identified viewpoints and services
 Viewpoint-system mapping
• Transform the analysis to an object-oriented design

VORD standard forms

Viewpoint identification

Viewpoint service information

Viewpoint data/control

Viewpoint hierarchy

Customer/cash withdrawal templates

Scenarios
 Scenarios are descriptions of how a system is used
in practice
 They are helpful in requirements elicitation as people
can relate to these more readily than abstract
statement of what they require from a system
 Scenarios are particularly useful for adding detail to
an outline requirements description

Scenario descriptions
 System state at the beginning of the scenario
 Normal flow of events in the scenario
 What can go wrong and how this is handled
 Other concurrent activities
 System state on completion of the scenario

Event scenarios
 Event scenarios may be used to describe how a
system responds to the occurrence of some
particular event such as ‘start transaction’
 VORD includes a diagrammatic convention for event
scenarios.
• Data provided and delivered
• Control information
• Exception processing
• The next expected event

Feasibility Study

Requirements Engineering
Requirements
Definition
Feasibility
Study
Requirements
Elicitation and
Feasibility Analysis
Report
Requirements
Specification
System
Models V&V
SRS
Requirements *Software Project
Definition Management User Manual
Document (RDD) Plan Test Plan
Requirements
Definition
Feasibility
Study
Requirements
Elicitation and
Report
Requirements
Specification
System
Models V&V
SRS
Requirements
Definition
Feasibility
Study
Requirements
Elicitation and
Report
Requirements
Specification
System
Models V&V
SRS
Feasible
 Feasible (‘fee-ze-bel)
• capable of being done or carried out;
• capable of being used or dealt with successfully;
• reasonable, likely.

Questions:
Can we build a (software) system to meet the client’s
expectations?
Can we build it under the constraints (cost, time,
personnel, …)?

Motivation?
 Not everything that is imaginable is feasible.
 Not everything that is possible is feasible.
 Not everything that is technically feasible makes
good business sense, i.e., is not feasible in the
business environment.

Three Main Questions About the
Feasibility of a Project
 Does it contribute to the overall objective of the
organization?
 Can it be implemented using current technology
within cost and schedule constraints?
 Can it be integrated with existing systems (data
transfer, procedures)?

More Questions:
 What are problems with the current
system/procedure, and how will the new system
address those?
 How will the new system contribute to the business
objectives?
 Does it require “new” technology (technology new to
this organization)?
 What must be supported in order for the proposed
system to function adequately?

Feasibility Study Needs to be …
 Inexpensive
• We are deciding whether to continue the project.
• Shouldn’t invest resources with no return.
 Quick
 Accurate
• Conflicts with other items here …

Cost Estimation Approaches
 Delay estimation until later
• Accurate, but not useful
 Base estimation on similar project
• Assumes you have this experience
 Use models to project
• Estimates based on size
• COCOMO (and others)

Feasibility Study
 Dimensions of feasibility
• Technology
• Finance
• Time
• Resources

Dimension of Feasibility Study-1
 Technology
• Is the project technically feasible?
• Is it within the state of the art?
• Can defects be reduced to a level matching the
application needs?
 Finance
• Is the project financially feasible?
• Can development be completed at a cost the software
organization, the client, or the market can afford?

Dimension of Feasibility Study-2
 Time
• Will the project’s time-to-market beat the competition?
 Resource
• Does the organization have the resources needed to succeed?

Document Outline
A. DOCUMENT CONTROL
1. INTRODUCTION
2. CONSIDERATIONS
3. EXISTING SYSTEMS AND TECHNOLOGIES
4. SOLUTIONS
5. RISKS AND COST ESTIMATES
6. COMPARISON OF SOLUTIONS
7. CONCLUSIONS
8. REFERENCES

Contents of Report
 Definition of the problem.
 Criteria for comparing solutions.
 Alternate solutions
• Cost estimation
• Resources
 Input: outline of system description and how it
will be used.
 Output: brief report recommending if it is worth
doing.

For this class
 Report has a different purpose.
 We want to research existing solutions and
compare technologies.

Document Control
Approval
The Guidance Team and the customer, Dr. Victor Winter, shall approve this document.
Document Change Control
Initial Release: February 3, 2000

Current Release: March 2, 2000
Indicator of Last Page in Document: 
Date of Last Review: March 10, 2000
Date of Next Review: March 30, 2000
Target Date for Next Update: March 28, 2000
Distribution List
This following list of people shall receive a copy of this document every time a new version of
this document becomes available:
Guidance Team Members:
Dr. Ann Gates
Dr. Steve Roach
Francisco Leyva
Customer: Dr. Greg Lush
Dynamite Software Team Members:
Joe Smith
Pat Garcia
Gabe Rios
Natalie Jones
Tina Ramos
Change Summary
The following table details changes made between versions of this document:
Version Date Modifier Description

1.1 8/15/00 Natalie Jones Revised definitions
1.2 8/30/00 Gabe Rios Use-case modification

Introduction
 Introduction
• Purpose of the Feasibility Report.
• Project Description.
• Justification for the Proposed System.
• Desired System Functionality.
• Use Case Diagram
• Actors
• Use Case Descriptions
• User Interface Description.

Considerations
 This section establishes the criteria upon which you
will evaluate possible solutions.
 Identify the primary concerns related to this project.
 Decide what aspects of the system are most
important. Performance? Security? Usability?
 What features in the system matter most?

Existing Systems
 Describe existing systems that achieve or partially
achieve the goals of the proposed system.
 The section includes
• language discussions.
• software development tools and libraries.
• database systems.
• other tools or software that you might use to build a solution.

Solutions
 Describe possible solutions.
• Each solution should be complete in the sense that it will
fully achieve the goals of the proposed system.
• If you are using existing software, that software should
be described in “Existent Systems” section.
 Solution X.
• Description (include requirements met).
• Resources Needed.
• Include software, hardware, experience, training.
• Limitations.

Risks
 Risks and Cost Estimates.
• Risks and risk mitigations.
• Schedule and cost estimates.

Comparison
 Discuss how each option measures up against constraints set
forth in the statement of requirements and how each
compares with the others.
 Include:
• Specific hardware and software requirements
• Time constraints
• Ease of use
• Staffing levels and training required
• User preference
• Security issues
 A matrix that compares features is required.

What you have to provide
 Possible solution
• May be combination of technologies
 Estimation of cost
• Hardware & software
• level of effort
 Estimation of risks
• ability to build
• stability of technology
• …
 Recommendations
• Give me your professional opinion based on the criteria

What you have to consider
 Customer needs
• Reliability
• Robustness
• Maintainability
• Delivery time
• ???

Level of Detail
 Assume that the reader is a competent graduate of a
CS program.
• Don’t tell us about Java, C++, or SQL.
• Tell us about technology for the system.
 Provide information, not advertising.
• What does a technology do for us?
• The solution you recommend may be the one you implement.

Grand Challenge Question
 Can you trace requirements to the Feasibility Report
?

SOFTWARE PROTOTYPING

Introduction
 what is software prototyping ?

It is the process of implementing the presumed software requirements
with an intention to learn more about the actual requirements or
alternative design that satisfies the actual set of requirements .
 Need for software prototyping

-To assess the set of requirements that makes a product
successful in the market
-To test the feasibility without building the whole system.
-To make end-user involved in the design phase

Prototype
Requirements
Design
Design
Implementation
Implementation
Testing
Testing
Maintenance

Phases of prototyping
Different Phases
 Define the prototype objectives
 Define the functionality
 Develop Prototype
 Evaluate Prototype.
Types of Prototyping
Types of Prototyping
 Throw away prototyping
 Evolutionary prototyping
.
 Operational prototyping
Throw away prototyping
 Objective - Derive end system requirements
 Throw away prototyping is one type of approach where an initial prototype is

built mainly focusing on the poorly understood requirements
 Once the requirements are understood requirements document is updated and a

conventional development process is followed to build system
Evolutionary Prototyping
 Objective – Deliver a working system + requirements
 Evolutionary prototyping is the one in which a system is build using the well
understood requirements.
Evolutionary Prototyping
 Advantages –
Accelerated Delivery
Makes User Commit
Look like feel
 Disadvantages –
Availability of specialist skills
Maintenance over long term
Operational Prototyping
 Used when requirements are either critical and understood or not critical
and poorly understood .
 Throw away prototypes are selectively built on top of evolutionary

prototype
 A trained prototyper keeps track of user .
Tools and Techniques
 Low level tools
 High Level languages
 Fourth Generation Languages (4GL)
 Visual programming .
Benefits of Software Prototyping
 It makes the developers clear about the missing requirements. Lets the
developers know what actually the users want.
 Reduces the loss by bringing the manufacturer to a conclusion weather

the system which we are about to build is feasible or not rather than
building the whole system and finding it .
 One can have a working system in before hand.

 It brings the user to get involved in the system design
Troubles of Software Prototyping
 Developers may loose the focus on real purpose of prototype and

comprise with the quality of system .
 New born ideas will be plundered at the initial stages
 Prototyping will not reveal the non functional requirements like robustness,
safety etc .
A Generic Requirements Process
Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements
Requirements
document
A Generic Requirements Process
Requirements
specification
Design activities
Architectural Interface Comp onent Data Algorithm

Abstract
design design design structur
e design
specification
design
Software Data
System Interface Comp onent Algorithm
specification structure
architecture specification specification specification
specification
Design products
Analysis Concepts and Principles
 Software requirement engineering also called
requirement analysis bridges the gap between
system engineering and software design.
System
Engg.
S/w
req.
analysi S/w design
s
Participated by both the customer and

developer
Software requirements and analysis--
 Problem recognition
 Evaluation and synthesis
• focus is on what not how
 Modeling
 Specification
 Review
Requirement elicitation for software
 Before requirements can be analyzed, modeled or
specified, they must be gathered through an
elicitation process.
1. Initiating the process
• The most commonly used requirement elicitation technique is to
conduct a meeting/interview.
• Participants- analyst and the customer.
• Type of question asked---
Context free, process questions, meta questions.
2. Facilitated Application Specification
Technique (FAST) :
• A team oriented approach to requirement
gathering.
• Encourages creation of a joint team of
customers and developers who work together to
identify the problem, propose solution and
identify a preliminary set of requirements.
Basic guidelines for FAST :
• Meeting is arranged at a neutral site and attended by both
s/w engineers and customers.
• Rules for preparation and participation are established.
• Agenda is set.
• Appoint a facilitator to control the meeting (can be
developer, customer or outside expert.)
• Participants should not criticize and debate.
Goal should be to identify problems, propose solution and
identify a preliminary set of requirements
FAST session preparation :
• Initial meetings between customer and
developer occur where scope is established and
an overall perception of a solution is
determined.
• ½ page product request is documented .
• Meeting place, time, date for FAST are selected
and facilitator is chosen.
• Product request is distributed to all attendees
before meeting date.
Every FAST attendee is asked to make :
1. List of objects.
2. List of services.
3. List of constraints.
4. List of performance criteria.
Activities of FAST session.
• Each participant presents his/her list of constraints.
• Combined list is prepared eliminating redundant entries
and adding new ideas.
• List is finalized by the facilitator.
A microprocessor based home security system needs to be built that
would protect against a variety of undesirable situations such as
smoke, fire , illegal entry etc.
The product would use appropriate fire and smoke detectors, window
and door sensors and an alarm that would be set when an untoward
situation occurs and automatically telephone a monitoring agency.
List of objects : Fire detector, smoke detector, window and door
sensors, telephone, alarm.
List of services : setting the alarm , monitoring the sensors,
dialing the phone etc.
List of constraints : Manufacturing cost less than 80 $, must be
user friendly, must interface directly to the standard phone
line.
Performance Criteria : Sensor event should be recognized within 1 sec.
3. Quality Function Deployment
This is a technique that translates the needs of the customer into technical
requirements for software.
 It emphasizes an understanding of what is valuable to the customer.
Customer satisfaction is of prime importance.
 It identifies three types of requirements
• Normal requirements: These requirements are the objectives and
goals stated for a software during meetings with the customer.
Eg : For a Result management system –
Normal requirement could be-
• Merit list report
• Failed student report
• Calculation of results
• Expected requirements: These requirements are
implicit to the software and are so fundamental that the
customer does not explicitly state them.
Eg. Usability, Reliability, ease of installation
• Exciting requirements: These requirements are features

that go beyond the customer's expectations and prove to
be very satisfying when present.
Eg :Sophisticated virus protection system
4. Use Case
 It describes the sequence of interactions
between actors and the system necessary to
deliver the service that satisfies the goal.
How to create a use case ?
• Identify the different users (actors) of the
system.
• Create use cases which captures who (actor)
does what (interaction) without dealing with the
system internals.
Software Prototyping
• Used to gain a better understanding of the problem.
• Based on constructing a partial implementation of a
system
• Prototyping can be :
1. Throwaway (Closed ended)
• Here the prototype serves only to demonstrate
requirements and is discarded after the desired
knowledge is gained.
• Since the prototype is ultimately discarded it need not be

maintainable or use efficient algorithms.
2. Evolutionary (Open ended)
• Once the prototype has been used and requisite knowledge has
been gained it is eventually incorporated into the final system.
• Must exhibit all quality attributes of the final product.
Tools used to conduct rapid prototyping :
1. Fourth generation techniques :
• 4GLs reduce programming effort, the time it takes to develop
software, and the cost of software development.
Report generators (Oracle repots,QUEST, GEMbase)
Screen generators (Oracle forms etc)
Database Query Languages (SQL, Ingres etc )
• These tools generate an executable code quickly and hence are

ideal for rapid prototyping
2. Reusable software components :
• Assemble rather than build the prototype by
using a set of existing s/w components
3. Formal Specification languages:
• Replace natural language specifcation
• Eg. Set notation , algebraic notation.
• There are tools which convert these formal
language specifications into executable code.
Requirement Specification
 The software requirement specification is produced at the culmination of
the analysis task.
 SRS document is a contract between the development team and the
customer.
 The SRS document is known as black-box specification since the system is
considered as a black box whose internal details are not known and only
its external is visible
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
Specification Review
 SRS-foundation of the development stage.
 Review is conducted to ensure completeness,
accuracy and consistency in SRS.
 Avoid vague terms in SRS(usually,often)
 Once review is complete SRS is signed off by
both customer and developer.
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
 A Software Requirements Specification (SRS) - a

requirements specification for a software system - is a
complete description of the behavior of a system to be
developed.
 It includes a set of use cases that describe all the interactions
the users will have with the software. Use cases are also
known as functional requirements.
 In addition to use cases, the SRS also contains non-
functional (or supplementary) requirements. Non-functional
requirements are requirements which impose constraints on
the design or implementation (such as performance
engineering requirements, quality standards, or design
constraints).
 1. INTRODUCTION:
 1.1. PURPOSE:The purpose of this source is to describe the railway
reservation system
 which provides the train timing details, reservation, billing and cancellation
on various types
 of reservation namely,
 • Confirm Reservation for confirm Seat.
 • Reservation against Cancellation.
 • Waiting list Reservation.
 • Online Reservation.
 • Tatkal Reservation
1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

• NTES – National Train Enquiry System
• IVRS – Interactive Voice Response system
• PRS – passenger reservation system
1.3. SCOPE
• Freight Revenue enhancement.
• Passenger Revenue enhancement.
• Improved & optimized service
1.4 REFERNCES
2.OVERALL DESCRIPTION:
2.1.PRODUCT PERSPECTIVE
 It enables us to maintain the railway train details like their timings, number
of seat available and reservation billing and cancelling the tickets
2.1.1. USER INTERFACE:
Keyboard and Mouse.
2.1.2. HARDWARE INTERFACE:
Printer
Normal PC
2.1.3. SOFTWARE INTERFACE:
Front end -> Visual Basic
Back end -> MS-Access
2.1.4. COMMUNICATION INTERFACES
• Indian Railway’s web-site, www.indianrail.gov.in offers PRS enquiries on the
internet Berth/Seat availability, Passenger Status, Fare, Train Schedule
etc,.
• National Train Enquiry System (NTES) website, www.trainenquiry.com gives
dynamic information about the running status of any train and its expected
arrival/departure at any given station.
• Mobile telephone based SMS enquiry service. A new mobile phone
based facility for rail users’ viz.,
2.1.5. OPERATING ENVIRONMENT:
The OS types are
Windows NT
Windows XP
Windows 98
Linux
2.1.7.OPERATIONS
• Any Reservation counter from 8 am to 8 pm.
• Prior to 60 days of Journey.
• One form for 6 persons only.
• Reserved ticket done through pre defined Logic.
• To save time & queues Agent is others guides.
2.2.PRODUCT FUNCTIONS:
It tells the short note about the product.
2.2.1. TRAIN DETAILS:
Customers may view the train timing at a date their name and number of
tickets.
2.2.2. RESERVATION:
After checking the number of seats available the customers reserve the tickets.
 2.2.3. BILLING:
 After reserving the required amount of tickets, the customer paid the
amount.
 2.2.4. CANCELLATION: If the customers want to cancel the ticket,
then half of the amount
 paid by the customer will be refunded to him.
 2.3. USER CHARACTERISTICS:
 Knowledgeable user
 No voice user
 Expert user
2.4.CONSTRAINTS
• Less than 1 sec for local transactions.
• 3 sec for network transaction.
• Capable for providing transaction for 22 hrs per day.
• Uptime of PRS is 99.5 + %.
SOFTWARE CONSTRAINTS:
• Designing -> Rational Rose
• Developing -> Visual Basic
3.SPECIFIC REQUIREMENTS
3.1. EXTERNAL INTERFACES
• Train Delay Alert Service.
• Booking Terminals.
• Interactive voice Response System.
• Touch Screen.
• Passengers operated Enquiry Terminals.
3.2. PERFORMANCE REQUIREMENTS:

It is available during all 24 hours.
• Offered through Mail express, super fast , Rajdhani & Shatabdi
Trains. About 1520 Trains
runs daily. Variety of compartments based on comfort :
• AC first class. Types of concerns &
• AC sleeper. complexities:
• First class. • 44 types of quotas.
• AC three tier. • 8 types of trains.
• AC chair car. • 9 types of classes.
• Sleeper class • 162 types of concessions.
• Ordinary chair car. • 127 types of bogies.
 3.3. SOFTWARE SYSTEM ATTRIBUTES:
 Reliable
 Available
 Secure
 4.DOCUMENT APPROVAL
 The bill passed on any proposals related to railway
management needs approval of
 Ministry of railway department.
 A data flow diagram (DFD) is a graphical representation of the "flow"

of data through an information system. DFDs can also be used for the
visualization of data processing (structured design).
 On a DFD, data items flow from an external data source or an internal data
store to an internal data store or an external data sink, via an internal
process.
 A DFD provides no information about the timing of processes, or about
whether processes will operate in sequence or in parallel.
 It is therefore quite different from a flowchart, which shows the flow
of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what
circumstances, but not what kinds of data will be input to and output
from the system, nor where the data will come from and go to, nor
where the data will be stored (all of which are shown on a DFD).
SOFTWARE REQUIREMENT SPECIFICATION Railway
Reservation system DFD
 It is common practice to draw a context-level data flow diagram first, which shows
the interaction between the system and external agents which act as data sources
and data sinks.
 On the context diagram (also known as the 'Level 0 DFD') the system's
interactions with the outside world are modeled purely in terms of data flows
across the system boundary.
 The context diagram shows the entire system as a single process, and gives
no clues as to its internal organization.
 This context-level DFD is next to produce a Level 1 DFD that shows some of the
detail of the system being modeled.
 The Level 1 DFD shows how the system is divided into sub-systems (processes),
each of which deals with one or more of the data flows to or from an external
agent, and which together provide all of the functionality of the system as a whole.
 It also identifies internal data stores that must be present in order for the system to
do its job, and shows the flow of data between the various parts of the system.
Railway Reservation system -Use Case
 A use case diagram in the Unified Modeling Language (UML) is a type
of behavioral diagram defined by and created from a Use-case analysis.
Its purpose is to present a graphical overview of the functionality provided
by a system in terms of actors, their goals (represented as use cases), and
any dependencies between those use cases.
 The main purpose of a use case diagram is to show what system functions
are performed for which actor.
 Roles of the actors in the system can be depicted. Interaction among
actors is not shown on the use case diagram. If this interaction is essential
to a coherent description of the desired behavior, perhaps the system or
use case boundaries should be re-examined.
Railway Reservation system -Use Case
 Alternatively, interaction among actors can be part of the assumptions
used in the use case.
 Use cases
 A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
 Actors
 An actor is a person, organization, or external system that plays a role in
one or more interactions with the system.
 System boundary boxes (optional)
 A rectangle is drawn around the use cases, called the system boundary
box, to indicate the scope of system. Anything within the box represents
functionality that is in scope and anything outside the box is not.
Analysis Modeling
Structured Analysis (DeMarco)
 Analysis products must be highly maintainable, especially the
software requirements specification
 Problems of size must be dealt with using an effective methods of
partitioning
 Graphics should be used whenever possible
 Differentiate between the logical (essential) and physical
(implementation) considerations.
 Find something to help with requirements partitioning and
document the partitioning before specification
 Devise a way to track and evaluate user interfaces.
 Devise tools that describe logic and policy better than narrative
text
Analysis Model Objectives
 Describe what the customer requires

 Establish a basis for the creation of a software
design
 Devise a set of requirements that can be validated
once the software is built
Analysis Model Elements
 Data Dictionary – contains the descriptions of all data
objects consumed or produced by the software
 Entity Relationship Diagram (ERD) – depicts
relationships between data objects
 Data Flow Diagram (DFD) – provides a indication of how
data are transformed as they move through the system;
also depicts functions that transform the data flow ( a
function is represented in a DFD using a process
specification or PSPEC)
 State Transition Diagram (STD) – indicates how the
system behaves as a consequence of external events,
states are used to represent behavior. Arcs are labeled
with the events triggering the transitions from one state to
another (control information is contained in control
specification or CSPEC)
Analysis Modeling:
Where to Begin?
 A statement of scope can be acquired
from:
• the FAST working document Facilitated
Application Specification Technique
• A set of use-cases
 the statement of scope must be
“parsed” to extract data, function and
behavioral domain information
Statement of Scope
 a relatively brief description of the
system to be built
• indicates data that are input and output and
basic functionality
• indicates conditional processing (at a high
level)
• implies certain constraints and limitations
Identifying Objects
and Operations
 define “objects” by underlining all nouns in
the written statement of scope
• producers/consumers of data
• places where data are stored
• “composite” data items
 define “operations” by double underlining
all active verbs
• processes relevant to the application
• data transformations
 consider other “services” that will be
required by the objects
Data Modeling
and
Entity Relationship (E-R)
Diagramming
Why Data Modeling?
 examines data objects independently
of processing
 focuses attention on the data domain
 creates a model at the customer’s
level of abstraction
 indicates how data objects relate to
one another
What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be
manipulated within the software (system)
each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items
Typical Objects
external entities (printer, user, sensor)
things (e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles (e.g., manager, engineer, salesperson)
organizational units (e.g., division, team)
places (e.g., manufacturing floor)
structures (e.g., employee record)
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, character-istic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code
What is a Relationship?
relationship —indicates “connectedness”;
a "fact" that must be "remembered"
by the system and cannot or is not computed
or derived mechanically
 several instances of a relationship
can exist
 objects can be related in many
different ways
Cardinality and Modality
 Cardinality – in data modeling, cardinality specifies

how the number of occurrences of one object are
related to the number of occurrences of another
object (1:1, 1:N, N:M)
 Modality – zero (0) for an optional object relationship
and one (1) for a mandatory relationship
ERD Notation
One common form:
(0, m)
object relationship object 2
1 (1, 1)
attribute
Another common form:
object relationship object 2

1
(0, m) (1, 1)
Building an ERD
 Level 1—model all data objects (entities)

and their “connections” to one another
 Level 2—model all entities and
relationships
 Level 3—model all entities, relationships,
and the attributes that provide further
depth
The ERD: An Example
request
Customer places
(1,1) (1,m) for service
(1,1)
standard generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w) consists
from (1,w) tasks of
(1,i)
materials lists
Creating a Flow
Model
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system
Flow Modeling Notation
external entity
process
data flow
data store
External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based

system
Data must always originate somewhere
and must always be sent to something
Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some
way to achieve system function
Data Flow
Data flows through a system, beginning

as input and be transformed into output.
base
compute
area
triangle
height area
Data Stores
Data is often stored for later use.
sensor #
sensor #, type,
look-up location, age
sensor
report required
data
type,
sensor number location, age
sensor data
Ward and Mellor Extensions
 An extended basic structured analysis notation to

accommodate the following demands imposed by
real-time systems:
• Information is gathered or produced on a time-continuous
basis
• Control information is passed throughout the system and
associated control processing
Data Flow Diagramming:
Guidelines
 all icons must be labeled with
meaningful names
 the DFD evolves through a number of
levels of detail
 always begin with a context level
diagram (also called level 0)
 always show external entities at level 0
 always label data flow arrows
 do not represent procedural logic
Constructing a DFD—I
 review ERD to isolate data objects
and grammatical parse to determine
“operations)
 determine external entities
(producers and consumers of data
 create a level 0 DFD
Level 0 DFD Example
processing
user request requested
digital video
video signal monitor
processor
video
NTSC
source video signal
Constructing a DFD—II
 write a narrative describing the transform

 parse to determine next level transforms
 “balance” the flow to maintain data flow
continuity
 develop a level 1 DFD
 use a 1:5 (approx.) expansion ratio
The Data Flow Hierarchy
a b
x P y level 0
a c p2 f
p1
d p4 b
5
p3 e g
level 1
Flow Modeling Notes
 each bubble is refined until it does
just one thing
 the expansion ratio decreases as the
number of levels increase
 most systems require between 3 and
7 levels for an adequate flow model
 a single data flow item (arrow) may
be expanded as levels increase (data
dictionary provides information)
DFDs: A Look Ahead
analysis model
Maps into
design model
Behavioral Modeling
and Process
Specification
Behavioral Modeling
events behavior
Outside
Application
world
The States of a System
 state—a set of observable circum-
stances that characterizes the
behavior of a system at a given time
 state transition—the movement from
one state to another
 event—an occurrence that causes
the system to exhibit some
predictable form of behavior
 action—process that occurs as a
consequence of making a transition
Behavioral Modeling
 make a list of the different states of a

system (How does the system behave?)
 indicate how the system makes a
transition from one state to another
(How does the system change state?)
• indicate event
• indicate action
 draw a state transition diagram
State Transition Diagram
Notation
state
event causing transition

action that occurs
new state
State Transition Diagram
full and start
reading
invoke manage-copying operator
commands
full
copies done invoke read-op-input
invoke read-op-input
making copies reloading paper

empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
problem state invoke read-op-input
Control Specification
(CSPEC)
The CSPEC can be:

state transition diagram
(sequential spec)
state transition table combinatorial spec

decision tables
activation tables
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
A Design Note
PSPEC one or more ”components"

in the software design
Creating Mini-Specs
Software
Specification
Real-Time Analysis
Methods
 each introduces its own notation, but all:
• propose an approach for representing
control and separating it from data
• provide a mechanism for specifying
events, states, and distributed processing
• begin at the analysis level and work to
derive processor assignments, tasks and
program architectures
Control Flow
Diagrams
 Begin by stripping all the data flow arrows from the

DFD
 Events (solid arrows) and control items (dashed
arrows) are added to the diagram
 Add a window to the CSPEC (contains and STD that
is a sequential specification of the behavior) for each
bubble in the final CFD7
The Data
Dictionary
a quasi-formal grammar for describing the content
of data that the software will process and create
a notation for describing control data and the

values that control data can take, e.g., "on," or "off"
a repository that also contains "where-used" / "how

used" information
a notation that can be represented manually, but is

best developed using CASE tools
Dictionary
Name: the primary name of the composite data item
Aliases: other names for the data item
Where used: data transforms (processes) that use the

composite data item
How used: the role of the data item (input, output,

temporary storage, etc.
Description: a notation for representing content (presented

on next slide)
Format: specific information about data types, pre-set

values (if known)
Notation
Notation Meaning
= is composed of
+ and
[ ] either-or
n
{ } n repetitions of
( ... ) optional data
* ... text ...* delimits a comment
Example
integrated
telephone number office system output
phone
system
Build the requirements dictionary:

Name: telephone number
Aliases: phone number, number
Where/How read-phone-number (input)

used: display-phone-number (output)
analyze-long-distance-calls (input)
Description: telephone no. = [ local extension | outside no. | 0 ]

outside no. = 9 + [ service code | domestic no. ]
service code = [ 211 | 411 | 611 | 911 ]
domestic no. = ( ( 0 ) + area code ) + local number
area code = *three numeral designator*
Format: alphanumeric data
Writing the Software
Specification
Everyone knew exactly

what had to be done
until someone wrote it
down!

Unit II

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit II

Uploaded by

Copyright:

Available Formats

Chapter 5

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1

 Descriptions and specifications of a system

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 2

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 3

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 5

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 6

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8

1. The software must provide a means of repr esenting and

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9

Client engineers (perhaps)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 14

 In principle requirements should be both complete

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 15

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 16

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 17

Product Or ganizational External

Ef ficiency Reliability Portability Interoperability Ethical

Usability Delivery Implementation Standards Legislative

Performance Space Privacy Safety

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 18

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 19

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 20

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 21

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 23

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 24

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 25

 The deceleration of the train shall be computed

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 26

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 27

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 28

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 29

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 30

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 31

Use the requirements

Use the requirements to

System test Use the requirements to

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 33

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 34

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 35

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 36

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 37

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 38

 Processes used to discover,

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 39

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 40

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 41

 The processes used for RE vary widely depending

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 42

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 43

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 44

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 45

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 46

©Ian Sommerville 2000 Chapter 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 49

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 50

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 51