Requirmentanalysis

Writing the Software
Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
What Are the Real
Problems?
the customer has only a vague idea of what is
required
the developer is willing to proceed with the

"vague idea" on the assumption that "we'll fill in
the details as we go"
the customer keeps changing requirements
the developer is "racheted" by these changes,

making errors in specifications and development
and so it goes ...
2
Software Requirements
Analysis
❏ identify the “customer” and work
together to negotiate “product-level”
requirements
❏ build an analysis model
❏focus on data
❏define function
❏represent behavior
❏ prototype areas of uncertainty
❏ develop a specification that will guide
design
❏ conduct formal technical reviews
3
Requirements
Gathering
Facilitated Application Specification Techniques
Software Customer
Engineering Group
Group
4
FAST Guidelines
❏ participants must attend entire
meeting
❏ all participants are equal
❏ preparation is as important as meeting
❏ all pre-meeting documents are to be
viewed as “proposed”
❏ off-site meeting location is preferred
❏ set an agenda and maintain it
❏ don’t get mired in technical detail
J. Wood & D. Silver
5
Quality Function
Deployment
❏ Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
❏ Information deployment identifies data
objects and events
❏ Task deployment examines the behavior of
the system
❏ Value analysis determines the relative priority
of requirements
6
UseCases
❏ A collection of scenarios that describe the
thread of usage of a system
❏ Each scenario is described from the pointof
view of an “actor”—a person or device that
interacts with the software in some way
❏ Each scenario answers the following questions:
➯ What are the main tasks of functions performed by the actor?
➯ What system information will the actor acquire, produce or
change?
➯ Will the actor inform the system about environmental
changes?
➯ What information does the actor require of the system?
➯ Does the actor wish to be informed about unexpected
changes
7
The Analysis Process
build a
prototype
requirements develop
the problem elicitation Specification Review
create
analysis
models
8
Analysis Modeling:
Where to Begin?
❏ A statement of scope can be acquired from:
➯ the FAST working document
➯ A set of use-cases
❏ the statement of scope must be “parsed” to
extract data, function and behavioral domain
information
9
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
10
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
11
Analysis Principle I
Model the Data Domain
❏ define data objects
❏ describe data attributes
❏ establish data relationships
12
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
13
Analysis Principle II
Model Function
❏ identify functions that transform data objects
❏ indicate how data flow through the system
❏ represent producers and consumers of data
14
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system
15
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
16
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
17
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
18
Level 0 DFD Example
processing
user request requested
digital video
video signal
monitor
processor
video
source NTSC
video signal
19
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
20
The Data Flow Hierarchy
a b
x P y level 0
a c p2
p1
f
d p4 5 b
p3 e g
level 1
21
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)
22
DFDs: A Look Ahead
analysis model
Maps into
design model
23
Analysis Principle III
Model Behavior
❏ indicate different states of the system
❏ specify events that cause the system to
change state
24
Behavioral Modeling
events behavior
Outside
Application
world
25
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
26
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
27
State Transition Diagram
full and start
invoke manage-copying reading
operator
commands
full
invoke read-op-input
copies done
invoke read-op-input
making copies reloading paper

empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
problem state invoke read-op-input
28
The Analysis Model
Data Model
Functional
Model
Behavioral
Model
29
Analysis Principle IV
Partition the Models
❏ refine each model to represent lower
levels of abstraction
➯ refine data objects
➯ create a functional hierarchy
➯ represent behavior at different levels of detail
30
Analysis Principle V
Essence
❏ begin by focusing on the essence of
the problem without regard to
implementation details
31
Davis’ Principles
❏ Understand the problem before you begin to create
the analysis model.
❏ Develop prototypes that enable a user to understand
how humanmachine interaction will occur.
❏ Record the origin of and the reason for every
requirement.
❏ Use multiple views of requirements.
❏ Prioritize requirements.
❏ Work to eliminate ambiguity.
32
Specification
Guidelines
use a layered format that provides increasing detail
as the "layers" deepen
use consistent graphical notation and apply textual

terms consistently (stay away from aliases)
be sure to define all acronyms
be sure to include a table of contents; ideally,

include an index and/or a glossary
write in a simple, unambiguous style (see "editing

suggestions" on the following pages)
always put yourself in the reader's position, "Would

I be able to understand this if I wasn't intimately
familiar with the system?"
33
Specification
Guidelines
Be on the lookout for persuasive connectors, ask why?
keys: certainly, therefore, clearly, obviously, it follows that ...
Watch out for vague terms
keys: some, sometimes, often, usually,ordinarily, most, mostly ...
When lists are given, but not completed, be sure all items are understood
keys: etc., and so forth, and so on, such as
Be sure stated ranges don't contain unstated assumptions
e.g., Valid codes range from 10 to 100.Integer? Real? Hex?
Beware of vague verbs such ashandled, rejected, processed, ...
Beware "passive voice" statements
e.g., The parameters are initialized.By what?
Beware "dangling" pronouns
e.g., The I/O module communicated with the data validation module and
its contol flag is set. Whose control flag?
34
Specification
Guidelines
When a term is explicitly defined in one place, try
substituting the definition forother occurrences of the term
When a structure is described in words, draw a picture
When a structure is described with a picture, try to redraw

the picture to emphasize different elements of the structure
When symbolic equations are used, try expressing their

meaning in words
When a calculation is specified, work at least two

examples
Look for statements that imply certainty, then ask for proof
keys; always, every, all, none, never
Search behind certainty statements—be sure restrictions
or limitations are realistic
35

Requirmentanalysis

Uploaded by

Document Information

Original Description:

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

Requirmentanalysis

Uploaded by

Copyright:

Available Formats

Writing the Software

the developer is willing to proceed with the

the customer keeps changing requirements

the developer is "racheted" by these changes,

and so it goes ...

Examples: compute taxes, determine area,

making copies reloading paper

use consistent graphical notation and apply textual

be sure to define all acronyms

be sure to include a table of contents; ideally,

write in a simple, unambiguous style (see "editing

always put yourself in the reader's position, "Would

When a structure is described with a picture, try to redraw

When symbolic equations are used, try expressing their

When a calculation is specified, work at least two

You might also like