Software Requirements
“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.”
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.
System end-users
Client engineers
System requirements
System architects
Software developers
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
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 70
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 71
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 72
Feasible
Feasible (‘fee-ze-bel)
• capable of being done or carried out;
• capable of being used or dealt with successfully;
• reasonable, likely.
Inexpensive
• We are deciding whether to continue the project.
• Shouldn’t invest resources with no return.
Quick
Accurate
• Conflicts with other items here …
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:
Design
Design
Implementation
Implementation
Testing
Testing
Maintenance
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 100
Different Phases
Develop Prototype
Evaluate Prototype.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 101
Types of Prototyping
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 102
Types of Prototyping
Evolutionary prototyping
.
Operational prototyping
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 103
Throw away prototyping
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 104
Evolutionary Prototyping
Evolutionary prototyping is the one in which a system is build using the well
understood requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 105
Evolutionary Prototyping
Advantages –
Accelerated Delivery
Disadvantages –
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 106
Operational Prototyping
Used when requirements are either critical and understood or not critical
and poorly understood .
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 107
Tools and Techniques
Visual programming .
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 108
Benefits of Software Prototyping
It makes the developers clear about the missing requirements. Lets the
developers know what actually the users want.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 109
Troubles of Software Prototyping
Prototyping will not reveal the non functional requirements like robustness,
safety etc .
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 110
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 111
A Generic Requirements Process
Requirements
specification
Design activities
Software Data
System Interface Comp onent Algorithm
specification structure
architecture specification specification specification
specification
Design products
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 112
Analysis Concepts and Principles
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 113
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 115
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 116
Requirement elicitation for software
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 117
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 118
Requirement elicitation for software
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 119
Requirement elicitation for software
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 120
Requirement elicitation for software
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 121
Requirement elicitation for software
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 122
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 123
• 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 124
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 125
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 126
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 127
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 130
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 131
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 132
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 133
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 134
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 135
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 136
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 137
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 138
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 139
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 140
SRS
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 141
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 142
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 144
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 145
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 146
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 147
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 148
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 149
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 150
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 151
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 152
SOFTWARE REQUIREMENT SPECIFICATION
Railway Reservation system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 153
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 154
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 155
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 156
SOFTWARE REQUIREMENT SPECIFICATION
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 157
SOFTWARE REQUIREMENT SPECIFICATION
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 158
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 159
Analysis Modeling
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 160
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 161
Analysis Model Objectives
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 162
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)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 163
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 164
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 165
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 166
Data Modeling
and
Entity Relationship (E-R)
Diagramming
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 167
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 168
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 169
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)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 170
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 171
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 172
Cardinality and Modality
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 173
ERD Notation
One common form:
(0, m)
object relationship object 2
1 (1, 1)
attribute
Another common form:
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 174
Building an ERD
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 175
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 176
Creating a Flow
Model
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 177
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 178
Flow Modeling Notation
external entity
process
data flow
data store
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 179
External Entity
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 180
Process
A data transformer (changes input
to output)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 181
Data Flow
base
compute
area
triangle
height area
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 182
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 183
Ward and Mellor Extensions
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 184
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 185
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 186
Level 0 DFD Example
processing
user request requested
digital video
video signal monitor
processor
video
NTSC
source video signal
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 187
Constructing a DFD—II
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 188
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 189
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)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 190
DFDs: A Look Ahead
analysis model
Maps into
design model
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 191
Behavioral Modeling
and Process
Specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 192
Behavioral Modeling
events behavior
Outside
Application
world
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 193
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 194
Behavioral Modeling
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 195
State Transition Diagram
Notation
state
new state
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 196
State Transition Diagram
full and start
reading
invoke manage-copying operator
commands
full
copies done invoke read-op-input
invoke read-op-input
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 197
Control Specification
(CSPEC)
activation tables
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 198
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 199
A Design Note
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 200
Creating Mini-Specs
Software
Specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 201
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 202
Control Flow
Diagrams
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 203
The Data
Dictionary
a quasi-formal grammar for describing the content
of data that the software will process and create
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 204
Dictionary
Name: the primary name of the composite data item
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 205
Notation
Notation Meaning
= is composed of
+ and
[ ] either-or
n
{ } n repetitions of
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 206
Example
integrated
telephone number office system output
phone
system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 207
Writing the Software
Specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 208