Transcript Requirements Engineering and Management INFO 627 Requirements Quality and Specification Methods Glenn Booker INFO 627 Lecture #7

Requirements Engineering
and Management
INFO 627
Requirements Quality and
Specification Methods
Glenn Booker
INFO 627
Lecture #7
1
Ambiguity and Specificity




The right level of detail for requirements is
the desired “sweet spot”
Too little detail can result in vague
requirements
Too much detail removes design creativity
and wastes time
Goal is to be understood correctly
INFO 627
Lecture #7
2
Light Box Example

In the text’s light box example, the
requirements state:


If either of the lights burns out, the remaining
bulb shall flash every 1 second
Does this mean the remaining light flashes
briefly every second? Or does it flash on for
one second, off for one second, etc.?

INFO 627
Even this simple case has many interpretations
Lecture #7
3
Finding the Sweet Spot
Understandability
Too precise
Too vague
The Sweet Spot
Too obtuse
Gibberish
Ambiguity
INFO 627
Lecture #7
4
No, I wanted



… a Bud Light!
Be careful what you ask for, or you
might get something completely different
than intended
Another silly example is to imagine the
possible ways to respond to the requirement
to “bring me a rock”
INFO 627
Lecture #7
5
Mary Had a Little Lamb


A cute example is from looking up various
interpretations of the nursery rhyme “Mary
had a little lamb”
Assuming we know who Mary is, and
“a little” is clear (though one could dispute
“little” easily!), play with possible
interpretations of “had” and “lamb”
INFO 627
Lecture #7
6
“Had” Could Mean




Held in possession
as property
Acquired
Accepted in marriage
Was marked or
characterized by





INFO 627
Lecture #7
Was held in a position
of disadvantage or
certain defeat
Was tricked
Gave birth to
Partook of (ate)
Was bribed by
7
“Lamb” Could Mean



A young sheep,
especially one less than
one year old or without
permanent teeth
A young antelope
A gentle or weak
person
INFO 627



Lecture #7
A dear or pet
A person easily cheated
or deceived
The flesh of lamb used
as food
8
Conclusion?

So “Mary had a little lamb” could mean:






INFO 627
Mary had a pet young sheep
Mary gave birth to an antelope
Mary was tricked by a gentle or weak person
Mary ate a person who was easily fooled
or deceived
Mary was bribed by a young sheep
Mary married the flesh of a lamb
Lecture #7
9
Sounds Silly?


I hope so 
But requirements for an unfamiliar area could
be just as easily preposterous if you aren’t
careful!
INFO 627
Lecture #7
10
How to Reduce Ambiguity

Ease of memorization; ask people which
requirements they remember


Those which are not easily remembered are more
likely to be unclear
Keyword technique; like used for Mary
earlier, look for key words and see what
definition best fits your context
INFO 627
Lecture #7
11
Emphasis Technique

Say the following out loud; each time you do,
shift the emphasis to a different word each
time


“I never said I beat my wife!”
How does the change of emphasis change the
implication of the statement?
INFO 627
Lecture #7
12
Which Technique to Use?



No one technique is best to use
What works best depends on your
organization, customer, and many other
factors
Good to try several techniques, particularly if
you get stuck
INFO 627
Lecture #7
13
To Improve Clarity





Use natural language whenever possible
Use pictures and diagrams to clarify your
intent
When in doubt, ASK!
Even if not in doubt, ask anyway just to make
sure
Use more formal methods where needed
INFO 627
Lecture #7
14
Quality Measures


Quality is challenging to measure
Some wish to view it as subjective


“I know it when I see it”
We’ll break it into quality for:



INFO 627
Each requirement or specification
Each technique, such as use case quality
The entire SRS package
Lecture #7
15
Each Requirement or Specification


Simply having defined the requirements
is a good start
Beyond that, quality for each requirement
or specification has nine aspects




INFO 627
Correct
Unambiguous
Complete
Consistent
Lecture #7
16
Each Requirement or Specification






Ranked
Verifiable
Modifiable
Traceable
Understandable
Most of these came from IEEE 830; the last
one was added by the text
INFO 627
Lecture #7
17
Correct



Requirements are correct if they address
needs of the user
Hence the system needs to perform the right
functions, and follow the business rules
established by the customer or user
Generally can’t automate proving correctness
of requirements
INFO 627
Lecture #7
18
Unambiguous



A requirement is unambiguous if it can only
have one interpretation
This is the key to capturing “what the user
had in mind”
Beware of cultural differences, and the Maryhad-a-little-lamb example earlier
INFO 627
Lecture #7
19
Complete


Completeness of requirements if they describe
“all requirements of concern to the user,
including requirements associated with
functionality, performance, design constraints,
attributes, or external interfaces” (IEEE 830)
Some aspects of completeness include
accurate labeling and referencing of figures
INFO 627
Lecture #7
20
Complete

Completeness can also include clear
definition of the scope, domain, or boundaries
of acceptable inputs


sqrt(-1), age<0, humidity>100%
Completeness can include setting limits
on acceptable performance, accuracy,
or reliability
INFO 627
Lecture #7
21
Complete

Missing functional requirements could
include handling of special cases


How processing is handled on a leap day,
holidays, or snow days
Prototyping can help identify “what-if”
questions, such as boundary conditions,
exceptions, and unusual events
INFO 627
Lecture #7
22
Consistent



Consistency within requirements means that
none of the requirements disagree or conflict
with any other requirements
Hardest to prove with performance or
reliability requirements
Inconsistent responses or actions need
to be deliberately avoided

INFO 627
Process modeling may help
Lecture #7
23
Ranked

Requirements need to be ranked or
categorized at least two ways


INFO 627
Importance (criticality), which is most often
used to determine which requirements get
implemented if money or time run tight
Stability (volatility), which affects how the
requirement is implemented, and could
reduce the chance it is implemented
Lecture #7
24
Verifiable



A requirement is verifiable if there is a
practical means possible to prove that the
requirement has been met
We’ll look at specific methods for this later,
but common verification methods include
testing or inspection
Don’t make subjective things a requirement

INFO 627
“easy to use”, “pleasing to the eye”, etc.
Lecture #7
25
Modifiable



The set of requirements need to be structured
so that changes to them can be done easily,
completely, and consistently, and without
changing the existing structure and style of
the set
This is to support requirements changes
Without this, requirements become outdated
INFO 627
Lecture #7
26
Traceable

Traceability means each requirement has a
clear origin, and can be referred to uniquely


INFO 627
Origin needed to know why the requirement
exists; backward to its source feature, and
forward to relevant design, code, or tests
Unique (short) name or identifier needed to
ensure that each requirement can be readily cited
in other plans
Lecture #7
27
Understandable

Understandability is an obviously desirable
characteristic, but is easily lost as
requirements get more detailed



INFO 627
Both developer and user need to understand
Beware of technical terms, existing terminology,
and buzzwords
May use storyboards or use cases to show the
context for how the requirement is used
Lecture #7
28
Use Case Quality

Text has lots of additional guidance for
applying these quality concepts to use cases




INFO 627
Are all existing functions described by one or
more use cases?
Are all functional requirements described by at
least one use case? Is the reverse true, too?
Look for interdependencies among use cases
Are all use case assumptions described?
Lecture #7
29
Use Case Quality





INFO 627
Does each use case involve at least one actor?
Look for flows of activity which always follow
each other (then merge into one use case)
Look for subsets of activity which are used in
several places (which may become included
use cases)
Are use case names unique and clear?
Is there a clear start and end to each use case?
Lecture #7
30
Use Case Quality





INFO 627
Is it clear when each use case is performed?
Are all of the users related to some actor?
Do any actors interact with the system in the
same ways? If so, consider merging them into
one actor, or use generalization
Are all decisions within use cases covered?
What happens if something doesn’t succeed?
Do use cases account for all information flow?
Lecture #7
31
SRS Quality

A good quality SRS, like any other technical
document, should have a
good structure





Table of Contents
Index (optional, IMHO)
Revision History
Glossary
See also my document review guidelines
INFO 627
Lecture #7
32
Table of Contents



The table of contents (TOC) helps define the
structure of the document
Always update the TOC before printing or
publishing the document
Large documents may need a separate TOC
for each volume
INFO 627
Lecture #7
33
Table of Contents

Within MS Word, identify each heading




INFO 627
Click on a paragraph which is a section heading
On the Formatting toolbar, select the style for the
right level of header (Heading 1 for top level
sections, Heading 2 for second level, etc.)
Repeat first two steps for all section headings
Use Format / Style to Modify the headings’
Format to suit (e.g. Font and Paragraph)
Lecture #7
34
Table of Contents

Click where you want the TOC to be placed

Generate the TOC using “Insert / Index and
Tables…” and click on “Table of Contents” tab



Usually want to Show and Right align page numbers
Make sure the correct number of heading levels
are selected
To update the TOC, right click over it and
“Update Field”
INFO 627
Lecture #7
35
Index


An index is handy for looking up topics
alphabetically within the document
Need to determine what words or phrases
need to be in the index


INFO 627
After document is written, highlight a key word
or phrase anywhere it appears
Go back to “Insert / Index and Tables…” and
click on the Index tab
Lecture #7
36
Index






Select Mark Entry and Mark All of that phrase
Repeat for each key word or phrase
Click where the Index will go
Generate the Index with “Insert / Index and
Tables…”; but here you don’t want to “Right
align page numbers”
Update the same as a TOC
Good for large, frequently-used documents
INFO 627
Lecture #7
37
Revision History



Every controlled document should have
a revision history
At a minimum, cite the revision date, author,
and what changes were made
Could add the revision number (version
1.0, 1.1, 1.2, etc.), and who approved
the document
INFO 627
Lecture #7
38
Glossary


Any technical document should consider
having a glossary
The glossary should define all acronyms,
abbreviations, and project-specific terms


Helps avoid confusion over user versus developer
terminology
Sort the glossary alphabetically!

INFO 627
Highlight glossary, then use Table / Sort
Lecture #7
39
Numbering and Labeling

Also recommended for any technical
document (not just the SRS)

Page numbering


Clear labels and numbering for figures
and tables

INFO 627
Hint: the TOC and Index don’t do much
good otherwise!
See my guidance for several numbering schemes
Lecture #7
40
Technical Methods

There are seven common ways to describe
requirements with more precision than natural
language or use cases




INFO 627
Pseudocode
Finite state machines
Decision trees
Activity diagrams
Lecture #7
41
Technical Methods




Entity-relationship models
Object-oriented analysis
Structured analysis
Don’t want a lot of these methods used in an
SRS – most likely to use them during analysis
and design phases
INFO 627
Lecture #7
42
Pseudocode



Pseudocode is a fake form of programming
language which captures the main intent of
the logic without the formality
Uses a limited vocabulary of phrases
Allows basic programming concepts


1E p. 299
Assignment statements, decisions, loops
Good for short algorithm description
(business rules)
INFO 627
Lecture #7
43
Finite State Machines




1E p. 300
Best known as state transition diagrams
Each bubble corresponds to a state of the
system – off hook, Odd light lit, etc.
Lines between bubbles describe what event is
needed to make the state transition – hang up,
press Count button, etc.
Key challenge is to identify all states and
events correctly
INFO 627
Lecture #7
44
Finite State Machines



Events might be grouped by similar result –
all outcomes on this path are similar if I type
any number, for example
Can make a matrix of all states and events, to
ensure complete understanding
Used for OO analysis and in the
Cleanroom methodology
INFO 627
Lecture #7
45
Decision Trees



1E p. 302
A decision tree is a graphic If statement
Each decision path is labeled Yes or No, and
all possible outcomes should be shown
Calculations, if needed, should be phrased in
the question – “Is budget overrun positive?” –
instead of putting numbers in the decision
paths
INFO 627
Lecture #7
46
Activity Diagrams




1E p. 303
An activity diagram is the UML version
of a flowchart
Boxes represent activities to be performed
(processes or procedures)
Lines between boxes show the sequence
of actions
Decisions are shown in diamonds
INFO 627
Lecture #7
47
Entity-relationship Models



An entity-relationship diagram (ERD) shows
how data is structured in a system
Each box represents an entity, which
will later correspond to data tables
Lines between boxes describe the relationship
between the entities

Customer places Order
places
Customer
INFO 627
Lecture #7
Order
48
Entity-relationship Models

The ends of the lines show the cardinality of
the relationship, whether the distant entity
may have zero, one, or many corresponding
entries in the nearer entity



Customer may have zero, one, or many Orders
But each Order is from exactly one Customer
May be hard for non-technical people
to understand
INFO 627
Lecture #7
49
Object-oriented Analysis



Object-oriented methods not only model
the data in a system, but limits the ways
in which that data may be used
Data is isolated in objects, and can only be
set, read, or changed using “methods”
Hence an object Employee might have
methods to AddEmployee, UpdateEmployee,
DismissEmployee, etc.
INFO 627
Lecture #7
50
Object-oriented Analysis



A drawing to show those objects and whether
they are allowed to communicate is a class
diagram
Looks like an ERD, but each box is a class,
and the lines between them show visibility
Again, may be way too complex unless
customer is very technology-savvy
INFO 627
Lecture #7
51
Structured Analysis



1E p. 306
Where the ERD focused on data structure, the
structured analysis tool called the Data Flow
Diagram (DFD) focuses on processes
Has shapes for data stores (Inventory),
users or external systems, and processes
(Manufacture Products)
Lines among them show what kind of data
flows (product info)
INFO 627
Lecture #7
52
Structured Analysis

Is used to help identify:




Who performs a process
Where that process gets data from
Where the results of that process go
Less technical than the ERD, but still may be
too detailed for laypeople
INFO 627
Lecture #7
53
Maintaining Requirements



Make sure to use technical methods for
requirements sparingly
Focus on system behavior, not design
Tough part is to keep the models consistent
with the evolution of the system


INFO 627
Effort devoted to it depends on how critical is the
models’ information
Be clear if a model is allowed to lapse
Lecture #7
54