Beruflich Dokumente
Kultur Dokumente
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
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
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
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)
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
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 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.
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
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
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