Sie sind auf Seite 1von 35

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 ...

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
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

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
3
Requirements 
Gathering
Facilitated Application Specification Techniques

Software Customer
Engineering Group
Group

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
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
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
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

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
6
Use­Cases
❏ A collection of scenarios that describe the 
thread of usage of a system
❏ Each scenario is described from the point­of­
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

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
7
The Analysis Process

build a
prototype

requirements develop
the problem elicitation Specification Review

create
analysis
models

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
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

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
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

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
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

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
11
Analysis Principle I
Model the Data Domain
❏ define data objects
❏ describe data attributes
❏ establish data relationships

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
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

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
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

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
14
The Flow Model
Every computer-based system is an
information transform ....

computer
input based output
system

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
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

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
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

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
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

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
18
Level 0 DFD Example

processing
user request requested
digital video
video signal
monitor
processor
video
source NTSC
video signal

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
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

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
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

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
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)

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
22
DFDs: A Look Ahead

analysis model
Maps into
design model

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
23
Analysis Principle III
Model Behavior
❏ indicate different states of the system
❏ specify events that cause the system to 
change state

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
24
Behavioral Modeling

events behavior
Outside
Application
world

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
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

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
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

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
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

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
28
The Analysis Model

Data Model

Functional
Model
Behavioral
Model

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
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

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
30
Analysis Principle V
Essence
❏ begin by focusing on the essence of 
the problem without regard to 
implementation details

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
31
Davis’ Principles
❏ Understand the problem before you begin to create 
the analysis model. 
❏ Develop prototypes that enable a user to understand 
how human­machine interaction will occur.  
❏ Record the origin of and the reason for every 
requirement.  
❏ Use multiple views of requirements.  
❏ Prioritize requirements.  
❏ Work to eliminate ambiguity.  

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
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?"

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
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?

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
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

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
35