Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1 Requirements Engineering:
What will the system do?
 Easy thing to do is postpone thinking about the details until later – “we’ll get to this stuff later.”
o Putting the details off just postpones problems.
o Adds cost and schedule risk to a project.
 Requirements Engineering systematically identifies requirements to minimize errors and risks.
 Ensures requirements are necessary and sufficient: users and developers will want to add lots
of extras, developers want to do “cool” things – “requirements creep”. Requirements
engineers need to determine:
o Is it a real requirement
o Is it actually needed
o Are there any gaps
1.1
Three overlapping phases of Requirements Engineering
Elicitation – Obtaining enough data/information/knowledge about a system so that a complete and
formal specification can be produced.
Specification – Involves the assimilation and analysis of the data/information/knowledge about a
system so that we can organize and produce a formal record of what the system should do.
Validation – Testing the formal specification of the requirements w.r.t. their Completeness,
Consistency, Verifiability, Modifiability, Traceability, Priority, …
1.2
Obtaining Requirements -- Elicitation
What are the challenges of requirements engineering?
 Only the simplest systems can be fully specified.
o When is a system specified well enough?
 Determining what is important/critical and what is fluff.
 What are the benefits associated with each requirement? What will be missing in a system if
any requirement is left out.
 Users may be very knowledgeable about their domain. But,
o They may have trouble expressing the details in words.
o They may use jargon with which we are unfamiliar.
o They may not understand the language of Software folks.
 Grandma doesn’t know what a database is.
 Users may have no idea what will be difficult to implement and what is a piece of cake.
 It is difficult to talk abstractly about a problem with most users – they don’t see that
generalization is possible or present.
©2011 Mike Rowe
12:37 PM
Page 1
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design




1.3
Requirements Engineers may not have any idea how a particular domain functions.
No one person may know the big picture.
o We may need to extract bits and pieces from many users and then integrate what one
gets into the big picture (beware of gaps).
Different stakeholders may have non-equivalent views of requirements and their priorities.
Requirements must be verifiable.
Ways to improve requirement quality



1.4
Go and study the domain directly; go sit in a bank; go watch Campbell’s make soup, go look at
a satellite; go to a cheese plant, go watch donuts being made, go on a brewery tour, … go to
the domain and watch it.
Have multiple stakeholders review requirements and agree on
o validity,
o importance,
o completeness, and
o priority.
Track changes in requirements and get concurrence on validity, importance, and priority of the
changes.
Characteristics of good requirements


System Requirements need to be understood by many stakeholders. Having requirements
that are only understood by a developer may not be good requirements.
o Sometimes there are even grade level reading requirements for all system
documentation.
o Why?
System level requirements should be stated in the terminology of the customer’s domain.
©2011 Mike Rowe
12:37 PM
Page 2
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design




o We as software folks may want to include a glossary of terms that are non-common so
that we can make sure that we, as a requirements engineer, and others who will use a
requirements document will understand terms.
Feasibility / Cost - with stakeholders, identify those requirements that are absolutely required.
o Estimate costs so the customer can weigh the value of each requirement. They may
change their mind on what is required based on the cost.
Make sure each requirement can be verified (testable) – a good test of a requirement one
which you can write a test case to verify.
Help identify risks.
Language: readable, precise, unambiguous, break complex sentences into simple sentences,
use terms consistently – use your project glossary, organize the requirement (by functionality,
real-world components – something that the users and developers both can follow.
http://geekandpoke.typepad.com/geekandpoke/2007/08/the-consultan-3.html
©2011 Mike Rowe
12:37 PM
Page 3
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1.5
Practices





Baseline requirements as early as possible.
o Baseline involved getting the customer to approve them and putting them under
configuration control. This way everyone knows the state of all requirements, including:
 Their content
 Who approved them
 If they were changed – how were they changed
 Who approved the changes.
In practice: need to start analysis and design before all requirements can be collected.
o We may never get all requirements collected.
o Try to get the critical ones as early as possible to get enough for a good start.
Be prepared for requirements to change – they always will.
o Hopefully, the major requirements will be relatively stable and it will be the minor
requirements that change most.
o Phased development approaches help as you implement the gross structure first and
then add details as you go on.
o If major requirements keep changing, one solution is to let the customer know what the
impact of each change is w.r.t. Schedule and Money, …
Traceability of requirements – since we must expect changes in requirements, we need to
trace requirements to models, code, documentation, test cases, etc. so that when something is
changed, the change can be propagated throughout the system.
Requirements Engineers must have many skills –
o Must be able to rapidly assimilate the key features of new domain
o Must communicate well
o Be able to talk with users at all levels
o Be able to read and comprehend technical material and documentation
o Be able to write well to capture the requirements in a form that others can
understand.
o Must be able to relate at many levels to many stakeholders from the deep carpet all the
way on down to the concrete.
o Must have political skills – refrain from telling a stakeholder they are full of crap.
o Must help customers resolve differences in priorities and wishes.
©2011 Mike Rowe
12:37 PM
Page 4
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2 Requirements:
The [IEEE STD (830-1998)] defines eight (see table1) major quality criteria for Software
Requirements Specifications, which are also applicable to individual requirements.
Core Quality Criteria for Requirements
IEEE STD (830-1998)]
Correctness
Unambiguity
Consistency
Completeness
Ranked for
Importance
(Priority, Necessity
and Stability)
Verifiability
(Testable)
Modifiability
Traceability
A requirement is correct iff the constraint / capability stated therein is
one the software shall meet. VALID
A requirement is unambiguous iff all information stated therein has
only one interpretation.
A requirement is internally consistent iff no individual
constraint/capability stated therein conflicts, and
a requirement is externally consistent if, and only if, no other
requirement conflicts with it.
A requirement is complete iff it defines the response of the software to
all realizable classes of situations. This includes both valid and invalid
inputs.
A requirement is ranked with respect to importance and/or stability.
Often we use the identifier to encode this “R” – required; “O” –
objective or optional (not required). May use “P” for pending.
A requirement is verifiable iff there exists some finite cost-effective
process with which a person or machine can determine if the software
meets the requirement.
A requirement is modifiable iff its structure and style are such that
changes can be made easily, completely, and consistently. Lack of
coupling and redundancy across requirements helps keep
requirements consistent when changes occur. Hint: Reference or link
details in other requirements rather than restating them.
A requirement is traceable iff it has a clear origin, all modification
reasons are tracked, and all future artifacts can be easily mapped back
to requirements.
Other characteristics not specifically covered by IEEE 830
Understandable
Non-prescriptive
Concise
Precise
Feasibility
©2011 Mike Rowe
12:37 PM
To facilitate validation, requirements should be understandable by the
end user. This includes using the terms of the domain and the user. A
glossary may be useful for the software people to understand the user
domain terminology. Keep the language level at the level of the end
user.
Should stick to WHAT the system needs to do and NOT HOW the
system will be designed or implemented.
“Less is more”, don’t add material that is not necessary. Rambling
hides information and confuses old folks like me.
A hybridization of Completeness and Ambiguity. See below.
Reasonable with respect to economic, schedule, resource and
technological parameters.
Page 5
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.1




2.2



2.3

Testable (verifiable)
If all parties cannot agree that a requirement has been satisfied it is of little value (and is a
potential liability).
o Example: “The software error rate will be at most one failure per 1000 hours of use.“
 untestable: what load will the system be under during the 1000 hours, idle or
heavy?
 qualifying it with exactly under what conditions we will test for 1000 hours. Need
something more specific than something like "normal use".
 Also to be reasonably certain about 1 failure per 1000 hours we would need to test
it over many 1000 hour periods!
 Can we test something too much?
vague: "software will be user friendly"/"respond quickly"/"efficient" use “pretty colors”
Go beyond precision: must be able to establish a test to determine if system meets a given
requirement.
o We must be able to answer YES or NO to whether requirement has been satisfied.
Writing test plans while writing requirements helps find untestable requirements!
Non-prescriptive
what, not how
We want the opportunity to analyze and design and then determine technologies
Constraints deal with technological issues (must use MS .Net or Linux). This may just be reality and
is not prescriptive.
Concise (succinct)
Who likes to read overly wordy descriptions?
o Quote from book:
"We feel that good systems provide the end user with good value. Because of this, we think
that the system should provide adequate performance with a 200 GB disk, since this is the least
expensive disk that we may purchase from the designated vendor. Of course, the user may
elect to configure the system with a larger disk, and we recommend this, but we have
attempted to come to grips with most of the problems raised by use of the smaller disk, and we
feel that they can be, by and large, satisfactorily resolved."
How could the above be made better?
Better: The system shall fulfill all specified functions when configured with a 80-GB disk.
Rambling prose hides information. Less it more!
o

©2011 Mike Rowe
12:37 PM
Page 6
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.4

2.5




2.6


Precise
Don't allow for misinterpretations or room for assumptions.
o example: "The system shall accept valid employee ID numbers from 1 to 9999."
 Are all values between 1 to 9999 valid, or can some be invalid?
 Are leading zeros, like 0001, acceptable/required?
 Better: "The system shall accept only valid ID numbers as defined in [reference]. All
valid ID numbers are in the range 1 to 9999 inclusive, represented without leading
zeroes.
Unambiguous
Worst case: both developer and client have a different meaning in mind, but neither one realizes
the other is thinking something different
o Example: “The system shall be capable of seeing the person in the park with a telescope.”
o Example: “Fruit flies like a banana.”
Be careful with pronouns and prepositional phases
Be careful with adjectives that could be nouns and nouns that could be adjectives.
Issue: what's a requirement and what's a design suggestion
o use shall to indicate an actual requirement
o use may for suggestions or wishes.
Modifiable
Keep information in a single place
o Rather than referring to a limit such as "support 1000 customers" over and over and over
each time we need to talk about the limit, we need to specify the limit in one place and
refer to that specification elsewhere.
o No magic numbers! -- Anyone heard that before?
o Example:
 R-4.1 The system shall allow up to 1000 customers simultaneously logged on.
 R-8.1 If the maximum number of customers (see R-4.1) are logged on, new attempts
shall be rejected with the error message "The maximum number of customers are
currently logged on, please try again later."
Don't merge a number of requirements together
o Example: R0: The program will process each customer, flagging all those customers that are
out of order and creating an error log for those customers, which includes both the
customer before the invalid customer and the customer after.
o Better:
 R1: The system shall process each customer one at a time.
 R2: The system shall flag a customer if they are out of order.
©2011 Mike Rowe
12:37 PM
Page 7
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
R3: The system shall create an error log of out of order customers that includes the
following: preceding customer, the out of order customer, and the customer
following the out of order customer.
This also helps in status tracking. For example R1 and R2 may be implemented and tested,
but R3 may be implemented by fails its test. Whereas if we have just R0, then we do not
have as much precision in tracking status.

o
2.7

Feasible
Economic feasible:
o May not know that something is impossible till later. Try to identify risks A.S.A.P.
3 Verification techniques for Requirements
Requirements are the input to the Design Process. The quality of our requirements will impact the
quality of the Design, Code, Tests, and the final deployed system.
(Much of the below material is from Andreas Altmannsberger’s Thesis 2005)
3.1
Inspection
Inspections help to improve the quality of requirements by detecting defects in the
requirements documents. In addition to that, inspecting a document in a systematic manner
teaches the developers to write better requirements documents. Different inspection nonexclusive techniques have been proposed and are summarized in the following:
1. ad-hoc technique: a non-systematic way of identifying defects.
2. checklist-based technique: the inspectors are provided with a list of general defect classes
to check against.
3. review: a manual process that involves multiple readers checking document for anomalies
and omissions.
4. walkthrough: a peer group review of a software document
5. scenario-based technique: the use of scenarios to guide inspectors on how to find
required information as well as what that information should look like.
6. perspective-based reading: one step deeper than scenario-based, various people read
the (requirements) document from a particular point of view according to the perspective
represented by different stake-holders in the project.
7. usage-based reading: a prioritized use case model is taken as input. It makes the
inspectors focus on the defects that are important for the future users of the system.
©2011 Mike Rowe
12:37 PM
Page 8
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
3.2
Simulation
The goal of a simulation is to understand the behavior of a system. When requirements are written in
a mathematically formal language, like Z (pronounced “Zed”), VDM-SL, state charts, etc. the
requirements can be simulated to test for correctness, consistency, and completeness.
3.3
Natural Language Analysis
Analyze the requirements as written in a natural language (English, German, …) to spot problems.
Fantechi, et al., Quality Analyzer of Requirements Specification and Automated Requirement
Measurement grade requirements. See below for an example of analysis for Testability. Each
dimension of good requirements has a similar set of indicators.
Property
Testability
Indicator
Vagueness
Subjectivity
Optionality
Weakness
Under
Specification
Description
It points out when parts of the sentence hold inherent
vagueness, i.e. words having a non-uniquely
quantifiable meaning (e.g. adequate, clear, effective,
….)
It points out if the sentence refers to personal opinions
or feeling (e.g. similar, as appropriate, having in mind,
considered, …)
It reveals a requirement containing an optional part (e.g.
possibly, alternatively, if case, if needed, …
It points out sentences that contain weak verbs (e.g.
may, could, should, might, …)
It points out sentences where the subject of the
sentence contains a word identifying a class of objects,
without a modifier specifying an instance of this class
(e.g. procedure, manual, interface, …)
There are tables similar to the above for each characteristic of good requirements. A requirements
document can be processed to determine an average overall score and individual requirements can be
flagged for improvement.
©2011 Mike Rowe
12:37 PM
Page 9
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
William, Rosenberg and Hyatt propose a similar tool (ARM) for automated quality assurance of natural
language requirements specifications. Below is a partial list form ARM.
Quality
Indicator
Description
Key Words
Imperative
This word category contains all words and
phrases that command that something must
be provided by the future system.
Shall, must or shan’t must not, is
required to, responsible for, will,
should (a very weak expression of an
imperative)
Continuances
These phrases and words are used to
introduce the specification of requirements at
a lower level.
Below, as follows, following,
listed, support, in particular
Directives
The approach defines directives as words and
phrases, which point to an illustrative
information within the requirements
document. The developers of ARM think that
many directives are hints that the
requirement is a precise specification.
If a requirements specification contains words
or phrases of this category, the requirement
forms a basis for possible misunderstandings,
ambiguities and risks. This is a result of the
fact that words as those listed to the right
give the developer several possibilities to
satisfy the requirement.
Like the words of the options category the
words and phrases of this category also lead
to misunderstandings and multiple
interpretations. Requirements containing
weak phrases are always open to subjective
interpretations.
Note, table, for example
Options
Weak Phrases
©2011 Mike Rowe
12:37 PM
Page 10
Can, may, optionally
Adequate, as a minimum, as applicable,
easy, as appropriate. be able to, be
capable, but not limited to, capability
of, capability to, effective, if practical,
normal, provide for, timely, should be
considered.
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Fantechi et al. developed a list of several metrics. In the following a sub-set of Fantechi's metrics are
listed. The acronyms used in the Type column of the below table mean: UN = Understandability, RE =
Readability, TR = Traceability, MA = Maintainability, AM = Ambiguity, SC = Specification Completion, CS
= Consistency. Some of these are in the table below.
Metric
Coleman-Liau
Type
RE
Continuance
Index
TR,
MA
Directive
Frequency
UN
Vagueness
AM
Formula
5.89*(Nl/Nw)-0.3*(Ns/Nw/100))-15.8
Where:
Nl = number of letters in document
Nw = number of words in the document
Ns = number of sentences in the
document
Ncon/Ns
Where
Ncon = number of continuance in a
sentence. Phrases like “as follows”
Nd/Ns
Where
Nd = number of directives. Directives
are words that indicate examples.
Nvag/Ns
Where
Nvag = number of sentences including
words holding inherent vagueness
(from a list).
Rationale
Reading difficulty index
– big words, long
sentences are harder to
read.
Continuances indicate
well structured
document. Too many
indicate requirements
are too complex.
Directives make
documents more
understandable.
The presence of vague
sentences points to
ambiguity.
4 Importance of High Quality Requirements
(from Andreas Altmannsberger’s Thesis 2005)
Referring to the CHAOS report of the Standish Group from 1994
“The Standish Group research shows a staggering 31.1% of projects will be canceled before they
ever get completed. Further results indicate 52.7% of projects will cost 189% of their original
estimates.[...]”
What are the reasons for such a high canceling rate? The Standish Group surveyed IT executive managers
for their opinions about why projects fail. Thus, 12.3 % of all canceled project were canceled
because of unclear and incomplete requirements and specification. In [LefWid2003], Leffingwell and
Widrig have pointed out three more studies about the impact of requirements. Unfortunately, it was not
possible to get access to the original sources of these studies. Therefore the following summery refers to
[LefWid2003].
©2011 Mike Rowe
12:37 PM
Page 11
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1. Leffingwell and Widrig mention a survey of the European Software Process Improvement
Training Initiative (ESPITI) from 1995, which identifies the relative importance of various
types of software problems in industry. The two largest problems, appearing in about 50% of
3,800 responses, were requirements specifications and the management of customer’s
requirements.
2. Leffling and Widrig summarize a study by Capers Jones from 1994, that provides data
regarding the likely number of potential defects and delivered defects. According to this
study, requirements errors top the delivered defects and contribute approximately one-third
of the total delivered defects.
3. Leffling and Widrig describe a report by Alan Davis from 1993, where Davis demonstrate
that the costs to detect and repair a defect or error during the maintenance phase is twenty
times more than during the requirements phase.
Leffling and Widrig came to the conclusion that requirements errors likely to consume 25 percent to 40
percent of the total project budget.
Final
©2011 Mike Rowe
12:37 PM
Note:
Page 12
03/18/2016
Notes: 002 Requirements
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Figure 1: http://www.linuxkungfu.org/images/fun/geek/project.jpg
©2011 Mike Rowe
Page 13
03/18/2016 12:37 PM