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

INFO 627 Lecture #7 1

Requirements Engineeringand ManagementINFO 627

Requirements Quality and Specification Methods

Glenn Booker


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


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.? Even this simple case has many interpretations


Finding the Sweet Spot

Ambiguity

Understand-ability

The Sweet Spot

Too obtuse

Too precise Too vague

Gibberish


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”


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”


“Had” Could Mean Held in possession

as property Acquired Accepted in marriage Was marked or

characterized by

Was held in a position of disadvantage or certain defeat

Was tricked Gave birth to Partook of (ate) Was bribed by


“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

A dear or pet A person easily cheated

or deceived The flesh of lamb used

as food


Conclusion? So “Mary had a little lamb” could mean:

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


Sounds Silly? I hope so But requirements for an unfamiliar area could

be just as easily preposterous if you aren’t careful!


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


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?


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


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


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:

Each requirement or specification Each technique, such as use case quality The entire SRS package


Each Requirement or Specification Simply having defined the requirements

is a good start Beyond that, quality for each requirement

or specification has nine aspects Correct Unambiguous Complete Consistent


Each Requirement or Specification Ranked Verifiable Modifiable Traceable Understandable

Most of these came from IEEE 830; the last one was added by the text


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


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

had-a-little-lamb example earlier


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


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


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


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 Process modeling may help


Ranked Requirements need to be ranked or

categorized at least two ways 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


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 “easy to use”, “pleasing to the eye”, etc.


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


Traceable Traceability means each requirement has a

clear origin, and can be referred to uniquely 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


Understandable Understandability is an obviously desirable

characteristic, but is easily lost as requirements get more detailed 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


Use Case Quality Text has lots of additional guidance for

applying these quality concepts to use cases 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?


Use Case Quality 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?


Use Case Quality 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?


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


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


Table of Contents Within MS Word, identify each heading

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)


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”


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


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


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


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!

Highlight glossary, then use Table / Sort


Numbering and Labeling Also recommended for any technical

document (not just the SRS) Page numbering

Hint: the TOC and Index don’t do much good otherwise!

Clear labels and numbering for figures and tables See my guidance for several numbering schemes


Technical Methods There are seven common ways to describe

requirements with more precision than natural language or use cases Pseudocode Finite state machines Decision trees Activity diagrams


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


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

Assignment statements, decisions, loops Good for short algorithm description

(business rules)

1E p. 299


Finite State Machines 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

1E p. 300


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


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

1E p. 302


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

1E p. 303


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

Customer Orderplaces


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


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.


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


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

1E p. 306


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


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 Effort devoted to it depends on how critical is the

models’ information Be clear if a model is allowed to lapse

Documents

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