SEC 308 Yazılım Mühendisliği
Software Requirements
1
Requirements Engineering Process: A
Basic Framework
0 3 fundamental activities:
understand, (formally) describe, attain an agreement on,
the problem
User
User reqs
knowledge
Elicitation
User feedback
Req. models
Validation
Specification
Val. result
For more knowledge
Domain knowledge
Problem
Domain
Domain knowledge
(domain experts, laws, standards, policies, documents, etc.)
2
Requirements Engineering
0 Inception—ask a set of questions that establish …
0 basic understanding of the problem
0 the people who want a solution
0 the nature of the solution that is desired, and
0 the effectiveness of preliminary communication and collaboration
between the customer and the developer
0 Elicitation—elicit requirements from all stakeholders
0 Elaboration—create an analysis model that identifies data,
function and behavioral requirements
0 Negotiation—agree on a deliverable system that is realistic
for developers and customers
3
Requirements Engineering
(cont.)
0 Specification—can be any one (or more) of the following:
0
0
0
0
0
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
0 Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or systems are
engineered)
0 conflicting or unrealistic (unachievable) requirements.
0
0
0
0
0 Requirements management
4
Inception
0 Identify stakeholders
0 “who else do you think I should talk to?”
0 Recognize multiple points of view
0 Work toward collaboration
0 The first questions
0 Who is behind the request for this work?
0 Who will use the solution?
0 What will be the economic benefit of a successful
solution
0 Is there another source for the solution that you need?
5
Eliciting Requirements
0 meetings are conducted and attended by both software engineers and
0
0
0
0
0
customers
rules for preparation and participation are established
an agenda is suggested
a "facilitator" (can be a customer, a developer, or an outsider) controls the
meeting
a "definition mechanism" (can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room or virtual forum) is used
the goal is
0
0
0
0
to identify the problem
propose elements of the solution
negotiate different approaches, and
specify a preliminary set of solution requirements
6
Eliciting Requirements (cont.)
Conduct FA ST
m eet ings
Make list s of
f unct ions, classes
Make list s of
const raint s, et c.
f orm al priorit izat ion?
El i c i t re q u i re m en t s
no
yes
Use QFD t o
priorit ize
requirem ent s
def ine act ors
inf orm ally
priorit ize
requirem ent s
draw use-case
diagram
writ e scenario
Creat e Use-cases
com plet e t em plat e
7
Quality Function Deployment
0 Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
0 Information deployment identifies data
objects and events
0 Task deployment examines the behavior of the
system
0 Value analysis determines the relative priority
of requirements
8
Elicitation Work Products
0 a statement of need and feasibility.
0 a bounded statement of scope for the system or product.
0 a list of customers, users, and other stakeholders who
participated in requirements elicitation
0 a description of the system’s technical environment.
0 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.
0 a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
0 any prototypes developed to better define requirements.
9
Building Analysis Model
0 Elements of the analysis model
0 Scenario-based elements
0 Functional—processing narratives for software functions
0 Use-case—descriptions of the interaction between an “actor” and
the system
0 Class-based elements
0 Implied by scenarios
0 Behavioral elements
0 State diagram
0 Flow-oriented elements
0 Data flow diagram
10
Diagrams
Sensor
(Use Case, Class, State)
name/id
type
location
area
characteristics
Arms/ disarms
syst em
Accesses syst em
via Int ernet
identify()
enable()
disable()
reconfigure ()
sensors
Reading
Commands
homeow ner
Responds t o
alarm event
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables
Encount ers an
error condit ion
syst em
administ rat or
Reconf igures sensors
and relat ed
syst em f eat ures
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State activities
11
Negotiating Requirements
0 Identify the key stakeholders
0 These are the people who will be involved in the
negotiation
0 Determine each of the stakeholders “win
conditions”
0 Win conditions are not always obvious
0 Negotiate
0 Work toward a set of requirements that lead to
“win-win”
12
Validating Requirements
0 Is each requirement consistent with the overall objective for
the system/product?
0 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level
of technical detail that is inappropriate at this stage?
0 Is the requirement really necessary or does it represent an
add-on feature that may not be essential to the objective of
the system?
0 Is each requirement bounded and unambiguous?
0 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
0 Do any requirements conflict with other requirements? 13
Validating Requirements (cont.)
0 Is each requirement achievable in the technical environment
that will house the system or product?
0 Is each requirement testable, once implemented?
0 Does the requirements model properly reflect the
information, function and behavior of the system to be built.
0 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
0 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
14
requirements?
Requirements Analysis
0 Requirements analysis
0 specifies software’s operational characteristics
0 indicates software's interface with other system elements
0 establishes constraints that software must meet
0 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
0 elaborate on basic requirements established during earlier
requirement engineering tasks
0 build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class
behavior, and the flow of data as it is transformed.
15
Requirements Modeling Strategies
• One view of requirements modeling, called structured
analysis, considers data and the processes that transform the
data as separate entities.
– Data objects are modeled in a way that defines their attributes and
relationships.
– Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the
system.
• A second approach to analysis modeled, called object-oriented
analysis, focuses on
– the definition of classes and
– the manner in which they collaborate with one another to effect
customer requirements.
16
Domain Analysis
0 Define the domain to be investigated.
0 Collect a representative sample of
applications in the domain.
0 Analyze each application in the sample.
0 Develop an analysis model for the objects.
0 In terms of data modeling, function/process
modeling, behavioral modeling, etc.
17
Building the Analysis Model
0 Elements of the analysis model
0 Scenario-based elements
0 Functional—processing narratives for software functions
0 Use-case—descriptions of the interaction between an “actor” and
the system
0 Class-based elements
0 Implied by scenarios
0 Behavioral elements
0 State diagram
0 Flow-oriented elements
0 Data flow diagram
A Bridge
system
description
analysis
model
design
model
18
Elements of Analysis
Model
19
Data Modeling
0 examines data objects independently of processing
0 focuses attention on the data domain
0 creates a model at the customer’s level of abstraction
0 indicates how data objects relate to one another
20
What is a Data Object?
0 Object-something that is described by
a set of attributes (data items) and
that will be manipulated within the
software (system)
0 each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
0 each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
0 each is described by attributes that are
themselves data items
object: automobile
attributes:
make
model
body type
price
options code
21
What is a Relationship?
0 Data objects are connected to one another in different
ways.
0 A connection is established between person and
car because the two objects are related.
0 A person owns a car
0 A person is insured to drive a car
0 The relationships owns and insured to drive define the
relevant connections between person and car.
0 Several instances of a relationship can exist
0 Objects can be related in many different ways
22
Entity-Relationship
Diagrams
0 Entity-Relationship Diagram (ERD) is a detailed logical representation
of data for an organization and uses three main constructs.
23
Entity-Relationship
Diagrams
0 Entities: Fundamental thing about which data may be maintained. Each
entity has its own identity.
0 Entity Type is the description of all entities to which a common
definition and common relationships and attributes apply.
• Consider an insurance
company that offers
both home and
automobile insurance
policies .These policies
are offered to
individuals and
businesses.
24
Entity-Relationship
Diagrams
• Relationships: A relationship is a reason for associating two entity types.
– Binary relationships  involve two entity types
– A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made against a POLICY.
• Relationships are represented by diamond notation in a ER diagram.
25
Entity-Relationship
Diagrams
26
Entity-Relationship
Diagrams
0 Cardinality defines “the maximum number of objects that can
participate in a relationship”[TIL93].
0 Two entity types A and B, connected by a relationship.
The cardinality of a relationship is the number of instances of entity B that can be
associated with each instance of entity A
0 Modality specifies if the relationship is optional (0) or mandatory (1).
27
Entity-Relationship
Diagrams
• Attributes: An attribute is a property or characteristic of an
entity that is of interest to organization.
• Each entity type has a set of attributes associated with it.
28
ERD Notation
One common form:
object 1
(0, m)
relationship
(1, 1)
object 2
attribute
Another common form:
relationship
object 1
(0, m)
(1, 1)
object 2
29
Building an ERD
0 Level 1—model all data objects (entities) and their
“connections” to one another
0 Level 2—model all entities and relationships
0 Level 3—model all entities, relationships, and the
attributes that provide further depth
30
The ERD: An Example
Customer
(1,1)
places
request
(1,m) for service
(1,1)
standard
task table
generates
(1,1)
selected
from
work
(1,w) tasks
materials
(1,w)
(1,i)
(1,n) work
order
(1,1)
(1,1)
consists
of
lists
31
Scenario-Based Modeling
0 Use-Cases
0 “[Use-cases] are simply an aid to defining what exists outside the
system (actors) and what should be performed by the system
(use-cases).”
0 a scenario that describes a “thread of usage” for a system
0 actors represent roles people or devices play as the system
functions
0 users can play a number of different roles for a given
scenario
32
What to Write About?
0 Inception and elicitation—provide you with the information
you’ll need to begin writing use cases.
0 Requirements gathering meetings, QFD, and other requirements
engineering mechanisms are used to
0
0
0
0
0
0
identify stakeholders
define the scope of the problem
specify overall operational goals
establish priorities
outline all known functional requirements, and
describe the things (objects) that will be manipulated by the system.
0 To begin developing a set of use cases, list the functions or
activities performed by a specific actor.
33
Developing a Use-Case
0 Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
0 Each scenario answers the following questions:
Who is the primary actor, the secondary actor (s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What extensions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external
environment?
0 What information does the actor desire from the system?
0 Does the actor wish to be informed about unexpected changes?
0
0
0
0
0
0
0
0
34
Use-Case Diagram
Use-case diagram for surveillance function
35
Alternative Actions
0 Can the actor take some other action at this
point?
0 Is it possible that the actor will encounter
some error condition at this point?
0 Is it possible that the actor will encounter
behavior invoked by some event outside the
actor’s control?
36
Activity Diagram
Supplements the use case
by providing a graphical
representation of the flow
of interaction within a
specific scenario
37
Swimlane Diagrams
Allows the modeler to
represent the flow of
activities described by
the use-case and at the
same time indicate
which actor (if there are
multiple actors involved
in a specific use-case) or
analysis class has
responsibility for the
action described by an
activity rectangle
38
Flow-Oriented Modeling
0 Represents how data objects are transformed as they move through the
system
0 A data flow diagram (DFD) is the diagrammatic form that is used
0 Considered by many to be an ‘old school’ approach, flow-oriented
modeling continues to provide a view of the system that is unique—it
should be used to supplement other analysis model elements
0 Every computer-based system is an information transform ....
input
computer
based
system
output
39
Flow Modeling Notation
external entity
process
data flow
data store
40
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
41
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
42
Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
height
compute
triangle
area
area
43
Data Stores
Data is often stored for later use.
sensor #
report required
look-up
sensor
data
sensor number
sensor #, type,
location, age
type,
location, age
sensor data
44
Data Flow Diagramming:
Guidelines
0 all icons must be labeled with meaningful names
0 the DFD evolves through a number of levels of detail
0 always begin with a context level diagram (also called
level 0)
0 always show external entities at level 0
0 always label data flow arrows
0 do not represent procedural logic
45
Constructing a DFD—I
• review the data model to isolate data objects and use
a grammatical parse to determine “operations”
• determine external entities (producers and
consumers of data)
• create a level 0 DFD
• Level 0 DFD Example
user
video
source
processing
request
digital
video
processor
requested
video
signal
monitor
NTSC
video signal
46
Constructing a DFD—II
0 write a narrative describing the transform
0 parse to determine next level transforms
0 “balance” the flow to maintain data flow continuity
0 develop a level 1 DFD
0 use a 1:5 (approx.) expansion ratio
47
The Data Flow
Hierarchy
x
a
a
c
p1
d
level 1
b
P
p2
level 0
f
p4
p3
y
e
g
5
b
48
Example: SafeHome Software
Level 0 DFD for SafeHome security function
49
Level 1 DFD for SafeHome security function
50
Level 2 DFD that refines the monitor sensors process
51
Flow Modeling Notes
0 each bubble is refined until it does just one thing
0 the expansion ratio decreases as the number of levels
increase
0 most systems require between 3 and 7 levels for an
adequate flow model
0 a single data flow item (arrow) may be expanded as
levels increase (data dictionary provides information)
52
Process Specification
(PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
53
DFDs: A Look Ahead
analysis model
Maps into
design model
54
Control Flow Diagrams
0 Represents “events” and the processes that manage
events
0 An “event” is a Boolean condition that can be
ascertained by:
0 listing all sensors that are "read" by the software.
0 listing all interrupt conditions.
0 listing all "switches" that are actuated by an operator.
0 listing all data conditions.
0 recalling the noun/verb parse that was applied to the
processing narrative, review all "control items" as possible
CSPEC inputs/outputs.
55
The Control Model
• the control flow diagram is "superimposed" on the DFD and
•
•
•
•
•
•
shows events that control the processes noted in the DFD
control flows—events and control items—are noted by dashed
arrows
a vertical bar implies an input to or output from a control spec
(CSPEC) — a separate specification that describes how control is
handled
a dashed arrow entering a vertical bar is an input to the CSPEC
a dashed arrow leaving a process implies a data condition
a dashed arrow entering a process implies a control input read
directly by the process
control flows do not physically activate/deactivate the
processes—this is done via the CSPEC
56
Control Flow Diagram
beeper on/off
read
operator
input
empty
jammed
copies
done
manage
copying
full
problem
light
start
reload
process
perform
problem
diagnosis
create
user
displays
display panel
enabled
57
Control Flow Diagram
State diagram for SafeHome security function
58
Flow-Oriented Modeling
The CSPEC can be:
state diagram
(sequential spec)
state transition table
combinatorial spec
decision tables
activation tables
59
Class-Based Modeling
• Class-based modeling represents:
– objects that the system will manipulate
– operations (also called methods or services) that will be applied to
the objects to effect the manipulation
– relationships (some hierarchical) between the objects
– collaborations that occur between the classes that are defined.
• The elements of a class-based model include classes and
objects, attributes, operations, CRC models, collaboration
diagrams and packages.
60
Class-Based Modeling
• Identify analysis classes by examining the problem
•
•
•
•
statement
Use a “grammatical parse” to isolate potential classes
[Abb83]
Identify the attributes of each class
Identify operations that manipulate the attributes
Potential classes
–retained information
–needed services
–multiple attributes
–common attributes
–common operations
–essential requirements
61
Analysis Classes
0 External entities (e.g., other systems, devices, people) that produce or
consume information to be used by a computer-based system.
0 Things (e.g., reports, displays, letters, signals) that are part of the
information domain for the problem.
0 Occurrences or events (e.g., a property transfer or the completion of a
series of robot movements) that occur within the context of system
operation.
0 Roles (e.g., manager, engineer, salesperson) played by people who
interact with the system.
0 Organizational units (e.g., division, group, team) that are relevant to an
application.
0 Places (e.g., manufacturing floor or loading dock) that establish the
context of the problem and the overall function of the system.
0 Structures (e.g., sensors, four-wheeled vehicles, or computers) that
define a class of objects or related classes of objects.
62
Class Diagram
Class name
attributes
operations
Class diagram for the system class
63
Class Diagram
Class diagram for FloorPlan
64
CRC Modeling
0 Class-responsibility-collaborator (CRC) modeling
[Wir90] provides a simple means for identifying and
organizing the classes that are relevant to system or
product requirements. Ambler [Amb95] describes
CRC modeling in the following way:
0 A CRC model is really a collection of standard index cards
that represent classes. The cards are divided into three
sections. Along the top of the card you write the name of the
class. In the body of the card you list the class
responsibilities on the left and the collaborators on the right.
65
CRC Modeling
A CRC model index card for FloorPlan class
66
Class Types
0 Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and
Sensor).
0 Boundary classes are used to create the interface (e.g., interactive
screen or printed reports) that the user sees and interacts with
as the software is used.
0 Controller classes manage a “unit of work” [UML03] from start to
finish. That is, controller classes can be designed to manage
0 the creation or update of entity objects;
0 the instantiation of boundary objects as they obtain information
from entity objects;
0 complex communication between sets of objects;
0 validation of data communicated between objects or between the
user and the application.
67
Responsibilities
0 System intelligence should be distributed across
classes to best address the needs of the problem
0 Each responsibility should be stated as generally as
possible
0 Information and the behavior related to it should
reside within the same class
0 Information about one thing should be localized with
a single class, not distributed across multiple classes.
0 Responsibilities should be shared among related
classes, when appropriate.
68
Collaborations
0 Classes fulfill their responsibilities in one of two ways:
0 A class can use its own operations to manipulate its own attributes,
thereby fulfilling a particular responsibility, or
0 a class can collaborate with other classes.
0 Collaborations identify relationships between classes
0 Collaborations are identified by determining whether a
class can fulfill each responsibility itself
0 three different generic relationships between classes
[WIR90]:
0 the is-part-of relationship
0 the has-knowledge-of relationship
0 the depends-upon relationship
69
Composite Aggregate
Class
70
Associations and
Dependencies
0 Two analysis classes are often related to one another in some
fashion
0 In UML these relationships are called associations
0 Associations can be refined by indicating multiplicity (the
term cardinality is used in data modeling)
0 In many instances, a client-server relationship exists between
two analysis classes.
0 In such cases, a client-class depends on the server-class in
some way and a dependency relationship is established
71
Class Diagrams
Top: Multiplicity
Bottom: Dependencies
72
Analysis Packages
0 Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that packages
them as a grouping
0 The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility and
are therefore accessible from other packages.
0 Other symbols can precede an element within a package. A
minus sign indicates that an element is hidden from all
other packages and a # symbol indicates that an element is
accessible only to packages contained within a given
package.
73
Analysis Packages
74
Behavioral Modeling
0 The behavioral model indicates how software will
respond to external events or stimuli. To create the
model, the analyst must perform the following
steps:
0 Evaluate all use-cases to fully understand the sequence of
interaction within the system.
0 Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
0 Create a sequence for each use-case.
0 Build a state diagram for the system.
0 Review the behavioral model to verify accuracy and
consistency.
75
State Representations
• In the context of behavioral modeling, two different
characterizations of states must be considered:
– the state of each class as the system performs its function
and
– the state of the system as observed from the outside as the
system performs its function
• The state of a class takes on both passive and active
characteristics [CHA93].
– A passive state is simply the current status of all of an
object’s attributes.
– The active state of an object indicates the current status of
the object as it undergoes a continuing transformation or
76
process
State Diagram
State diagram for the ControlPanel class
77
The States of a System
0 state—a set of observable circumstances that
characterizes the behavior of a system at a
given time
0 state transition—the movement from one
state to another
0 event—an occurrence that causes the system
to exhibit some predictable form of behavior
0 action—process that occurs as a consequence
of making a transition
78
Behavioral Modeling
0 make a list of the different states of a system
(How does the system behave?)
0 indicate how the system makes a transition
from one state to another (How does the
system change state?)
0 indicate event
0 indicate action
0 draw a state diagram or a sequence diagram
79
Sequence Diagram
Sequence diagram (partial) for the SafeHome security
function
80
Requirements Documentation
0 This is the way of representing requirements in a consistent
format
0 called Software Requirements Specifications (SRS) document
0 SRS serves many purposes depending upon who is writing it.
0 written by customer and/or developer
0 Serves as contract between customer & developer.
0 SRS Should
0 Correctly define all requirements
0 not describe any design details
0 not impose any additional constraints
81
Requirements Documentation
0 Characteristics of a good SRS
0 Correct : An SRS is correct if and only if every requirement
stated therein is one that the software shall meet.
0 Unambiguous : An SRS is unambiguous if and only if, every
requirement stated therein has only one interpretation.
0 Complete : An SRS is complete if and only if, it includes the
following elements
0 All significant requirements, whether related to functionality, performance,
design constraints, attributes or external interfaces.
0 Responses to both valid & invalid inputs.
0 Full Label and references to all figures, tables and diagrams in the SRS and
definition of all terms and units of measure.
82
Requirements Documentation
(cont.)
0 Characteristics of a good SRS (continued)
0 Consistent : An SRS is consistent if and only if, no subset of
individual requirements described in it conflict.
0 Ranked for important and/or stability : If an identifier is
attached to every requirement to indicate either the
importance or stability of that particular requirement.
0 Verifiable : An SRS is verifiable, if and only if, every
requirement stated therein is verifiable.
83
Requirements Documentation
(cont.)
• Characteristics of a good SRS (continued)
– Modifiable : An SRS is modifiable, if and only if, its
structure and style are such that any changes to the
requirements can be made easily, completely, and
consistently while retaining structure and style.
– Traceable : An SRS is traceable, if the origin of each
of the requirements is clear and if it facilitates the
referencing of each requirement in future
development or enhancement documentation.
84
Requirements
Documentation
• Organization of the SRS
– IEEE has published guidelines and standards to organize an
SRS.
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
1.5 Overview
85
Requirements
Documentation
2. The Overall Description
2.1 Product Perspective
2.2 Product Functions
2.1.1 System Interfaces
2.3 User Characteristics
2.1.2 Interfaces
2.4 Constraints
2.1.3 Hardware Interfaces 2.5 Assumptions for dependencies
2.1.4 Software Interfaces
2.6 Apportioning of
requirements
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
86
Requirements
Documentation
3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
87
Writing the Software
Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
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?"
89
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 as handled, 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?
90
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
91