Ilovepdf Merged PDF

Writing Better Requirements
Based on slides by Gunter Mussbacher

with material from:
Ian Zimmerman (Telelogic, 2001),
Ivy Hooks (Compliance Automation, 1998)
Table of Contents
• Martha can’t write requirements because…
• Anatomy of a Good / Bad User Requirement
• Standard for Writing a Requirement
• Writing Pitfalls to Avoid
• A Few Simple Tests…
• The greatest challenge to any thinker is stating the problem in

a way that will allow a solution.1
[1] Bertrand Russell, 1872-1970
2
3
Martha can’t … Good & Bad Standard Pitfalls to Avoid A Few Simple Tests Summary & Tools
Martha can’t write requirements because…

• She doesn’t know what to do!
• She was not taught at school
• She doesn’t know how to write
• She doesn’t understand the process
• She doesn’t have the necessary data
• She doesn’t know what she wants
• She doesn’t understand why!
• She doesn’t understand the impact / changes
• She thinks this is “just a document”
• She’d rather do something else!
• She’d rather design – she sees no reward
• She doesn’t have enough time
• She thinks the review process will catch the errors
Source: Compliance Automation, Inc., 1998
4
Anatomy of a Good User Requirement

Defines the system under discussion Verb with correct identifier (shall or may)
The Online Banking System shall allow the Internet user

to access her current account balance in less than 5 seconds.
Defines a positive end result Quality criteria
• Identifies the system under discussion and a desired end

result that is wanted within a specified time that is
measurable
• The challenge is to seek out the system under discussion,

end result, and success measure in every requirement
5
Example of a Bad User Requirement

Cannot write a requirement on the user No identifier for the verb
The Internet User quickly sees her current X

account balance on the laptop screen.
Vague quality criteria What versus how
6
Standard for Writing a Requirement

• Each requirement must first form a complete sentence
• Not a bullet list of buzzwords, list of acronyms, or sound bites on a
slide
• Each requirement contains a subject and predicate

• Subject: a user type (watch out!) or the system under discussion
• Predicate: a condition, action, or intended result
• Verb in predicate: “shall” / “will” / “must” to show mandatory nature;
“may” / “should” to show optionality
• The whole requirement provides the specifics of a desired

end goal or result
• Contains a success criterion or other measurable indication
of the quality
7

• Several standards define fairly precisely how to use key
words (verbs and adjectives) in their documents.
• Example: IETF RFC 2119: Key words for use in RFCs to

Indicate Requirement Levels
• MUST, REQUIRED or SHALL: mean that the definition is an absolute

requirement of the spec.
• MUST NOT or SHALL NOT: absolute prohibition
• SHOULD or RECOMMENDED: think twice about not doing it!
• SHOULD NOT or NOT RECOMMENDED: think twice about doing it!
• MAY or OPTIONAL: truly optional
8

• Look for the following characteristics in each requirement
• Feasible (not wishful thinking)
• Needed (provides the specifics of a desired end goal or result)
• Testable (contains a success criterion/other measurable indication of
quality)
• Clear, unambiguous, precise, one thought
• Prioritized
• ID
• Note: several characteristics are mandatory (feasible,

needed, testable) whereas others improve communication
9
Writing Pitfalls to Avoid

• Never describe how the system is going to achieve
something (over-specification), always describe what the
system is supposed to do
• Refrain from designing the system prematurely
• Danger signs: using names of components, materials, software objects,
fields & records in the user or system requirements
• Designing the system too early may possibly increase system costs
• Do no mix different kinds of requirements (e.g., requirements for users,
system, and how the system should be designed, tested, or installed)
• Do not mix different requirements levels (e.g., the system and
subsystems)
• Danger signs: high level requirements mixed in with database design,
software terms, or very technical terms
• Beware: may depend on the level of abstraction…
• Your what is my how!
10

• “What versus how” test
The system shall use Microsoft Outlook to send an
email to the customer with the purchase confirmation.
X
The system shall inform the customer
that the purchase is confirmed.
11

• Never build in let-out or escape clauses
• Requirements with let-outs or escapes are dangerous because of
problems that arise in testing
• Danger signs: if, but, when, except, unless, although
• These terms may however be useful when the description of a general
case with exceptions is much clearer and complete that an enumeration of
specific cases
• Avoid ambiguity
• Write as clearly and explicitly as possible
• Ambiguities can be caused by:
• The word or to create a compound requirement
• Poor definition (giving only examples or special cases)
• The words etc., …and so on (imprecise definition)
12

• Do not use vague indefinable terms
• Many words used informally to indicate quality are too vague to be
verified
• Danger signs: user-friendly, highly versatile, flexible, to the maximum
extent, approximately, as much as possible, minimal impact
The EasyEntry System shall be easy to use and require X

a minimum of training except for the professional mode.
13

• Do not make multiple requirements
• Keep each requirement as a single sentence
• Conjunctions (words that join sentences together) are danger signs:
and, or, with, also
• Do not ramble
• Long sentences with arcane language
• References to unreachable documents
The Easy Entry Navigator module shall consist of order X

entry and communications, order processing, result
processing, and reporting. The Order Entry module shall be
integrated with the Organization Intranet System and
results are stored in the group’s electronic customer record.
14

• Do not speculate
• There is no room for “wish lists” – general terms about things that
somebody probably wants
• Danger signs: vague subject type and generalization words such as
usually, generally, often, normally, typically
• Do not express suggestions or possibilities
• Suggestions that are not explicitly stated as requirements are
invariably ignored by developers
• Danger signs: may, might, should, ought, could, perhaps, probably
• Avoid wishful thinking
• Wishful thinking means asking for the impossible (e.g., 100% reliable,
safe, handle all failures, fully upgradeable, run on all platforms)
The Easy Entry System may be fully adaptable to all X

situations and often require no reconfiguration by the user.
15
A Few Simple Tests…(1)

• “What versus how” test discussed earlier
• Example: a requirement may specify an ordinary differential equation
that must be solved, but it should not mention that a fourth order
Runge-Kutta method should be employed
• “What is ruled out” test

• Does the requirement actually make a decision (if no alternatives are
ruled out, then no decision has really been made)
• Example: a requirement may be already covered by a more general
one
Source: Spencer Smith, McMaster U.

16
A Few Simple Tests…(2)

• “Negation” test
• If the negation of a requirement represents a position that someone
might argue for, then the original decision is likely to be meaningful
The software shall be reliable. X
Source: Spencer Smith, McMaster U.

17
Towards Good Requirements Specifications (1)

• Valid (or “correct”) • Consistent
• Expresses actual requirements • Does not contradict itself
• Complete (satisfiable)
• Specifies all the things the • Uses all terms consistently

system must do (including • Note: inconsistency can be hard
contingencies) to detect, especially in
• ...and all the things it must not do! concurrency/timing aspects and
condition logic
• Conceptual Completeness
(e.g., responses to all classes of • Formal modeling can help
input) • Beneficial
• Structural Completeness • Has benefits that outweigh the
(e.g., no TBDs!!!) costs of development
Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

18
Towards Good Requirements Specifications (2)

• Necessary • Verifiable
• Doesn’t contain anything that isn’t • A process exists to test
“required” satisfaction of each requirement
• Unambiguous • “every requirement is specified
• Every statement can be read in behaviorally”
exactly one way • Understandable (clear)
• Clearly defines confusing terms • E.g., by non-computer specialists
(e.g., in a glossary) • Modifiable
• Uniquely identifiable • Must be kept up to date!
• For traceability and version
control
Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

19
Typical Mistakes
• Noise = the presence of text that • Wishful thinking = text that defines
carries no relevant information to a feature that cannot possibly be
any feature of the problem validated
• Silence = a feature that is not • Jigsaw puzzles = e.g., distributing
covered by any text requirements across a document
• Over-specification = text that and then cross-referencing
describes a feature of the solution, • Inconsistent terminology =
rather than the problem inventing and then changing
• Contradiction = text that defines a terminology
single feature in a number of • Putting the onus on the
incompatible ways development staff = i.e. making the
• Ambiguity = text that can be reader work hard to decipher the
interpreted in >=2 different ways intent
• Forward reference = text that refers • Writing for the hostile reader (fewer
to a feature yet to be defined of these exist than friendly ones)
Source: Steve Easterbrook, U. of Toronto
20
Rate these Requirements
The Order Entry system provides for quick, user-

friendly and efficient entry and processing of all orders.
X
Invoices, acknowledgments, and shipping notices shall X
be automatically faxed during the night, so customers
can get them first thing in the morning.
Changing report layouts, invoices, labels, and form

letters shall be accomplished.
X
The system shall be upgraded in one whack. X
The system has a goal that as much of the IS data as X
possible be pulled directly from the T&M estimate.
21
Key Questions and Characteristics
• Remember the key questions “Why?” or

“What is the purpose of this?”
• Feasible
• Needed
• Testable
22
A Few Syntactic Analysis Tools

• QuARS
• Quality Analyzer of Requirements Specification
http://www.sei.cmu.edu/publications/documents/05.reports/05tr014.html
• ARM
• Automated Requirement Measurement Tool
http://www.stcsig.org/quality/newsletters/NL0603/NL0603_Doc_Value-pf.html
• TIGER Pro
• Tool to Ingest and Elucidate Requirements
• http://www.therightrequirement.com/TigerPro/TigerPro.html
23
Requirements Specification with
the IEEE 830 and IEEE 29148
Standards
Based on slides by Gunter Mussbacher (2009) and Stéphane Somé (2008)

with material from these standards:
IEEE 830-1998, ISO/IEC 12207, ISE/IEC/IEEE 29148:2011
Table of Contents
• Requirements Specification Document
• IEEE 830 Standard

• Relationship of IEEE 830 and ISO/IEC 12207
• ISO/IEC/IEEE 29148 Standard
2
Requirements Specifications IEEE 830-1998 Standard IEEE 830 and ISO/IEC 12207 ISO/IEC/IEEE 29148:2011
Requirements Specification Document (1)

• Clearly and accurately describes each of the essential
requirements (functions, performance, design constraints,
and quality attributes) of the system / software and its
external interfaces
• Defines the scope and boundaries of the system / software
• Each requirement must be described in such a way that it is

feasible and objectively verifiable by a prescribed method
(e.g., by inspection, demonstration, analysis, or test)
• Basis for contractual agreements between contractors or

suppliers and customers
• Elaborated from elicitation notes

3
Requirements Specification Document (2)

• Specifications are intended to a diverse audience
• Customers and users for validation, contract, ...
• Systems (requirements) analysts
• Developers, programmers to implement the system
• Testers to check that the requirements have been met
• Project Managers to measure and control the project
• Different levels of detail and formality is needed for each

audience
• Different templates for requirements specifications

• e.g. IEEE 830
4
IEEE 830-1998 Standard

• Title of Standard
• « IEEE Recommended Practice for Software Requirements
Specifications »
• Describes the content and qualities of a good software

requirements specification (SRS)
• Presents several sample SRS outlines
5
IEEE 830-1998 Standard – Objectives

• Help software customers to accurately describe what they
wish to obtain
• Help software suppliers to understand exactly what the

customer wants
• Help participants to:

• Develop a template (format and content) for the software requirements
specification (SRS) in their own organizations
• Develop additional documents such as SRS quality checklists or an
SRS writer’s handbook
6
IEEE 830-1998 Standard – Benefits

• Establish the basis for agreement between the customers
and the suppliers on what the software product is to do
• Reduce the development effort

• Forced to consider requirements early → reduces later redesign,
recoding, retesting
• Provide a basis for realistic estimates of costs and schedules
• Provide a basis for validation and verification

• Facilitate transfer of the software product to new users or new
machines
• Serve as a basis for enhancement requests
7
IEEE 830-1998 Standard – Considerations

• Section 4 of IEEE 830 (how to produce a good SRS)
• Nature (goals) of SRS
• Functionality, interfaces, performance, qualities, design constraints
• Environment of the SRS
• Where does it fit in the overall project hierarchy
• Characteristics of a good SRS
• Generalization of the characteristics of good requirements to the document
• Evolution of the SRS
• Implies a change management process
• Prototyping
• Helps elicit software requirements and reach closure on the SRS
• Including design and project requirements in the SRS
• Focus on external behavior and the product, not the design and the
production process (describe in a separate document)
8
IEEE 830-1998 Standard – Structure of the SRS

• Section 5 of IEEE 830
• Contents of SRS
• Introduction
• General description of the software product
• Specific requirements (detailed)
• Additional information such as appendixes and index, if necessary
9
IEEE 830-1998 Standard – Section 1 of SRS

• Title •Describe purpose of this SRS
• Table of Contents •Describe intended audience
• 1. Introduction •Identify the software product

• 1.1 Purpose •Enumerate what the system will and will not do
•Describe user classes and benefits for each
• 1.2 Scope
• 1.3 Definitions. Acronyms, and Abbreviations
• 1.4 References •Define the vocabulary of the SRS
(may reference appendix)
• 1.5 Overview
• 2. Overall Description •List all referenced documents including sources
(e.g., Use Case Model and Problem Statement;
• 3. Specific Requirements Experts in the field)
• Appendices •Describe the content of the rest of the SRS

• Index •Describe how the SRS is organized
IEEE 830-1998 Standard – Section 2 of SRS

• Title •Present the business case and operational concept of the system
•Describe how the proposed system fits into the business context
• Table of Contents •Describe external interfaces: system, user, hardware, software, communication
•Describe constraints: memory, operational, site adaptation
• 1. Introduction •Summarize the major functional capabilities
• 2. Overall Description •Include the Use Case Diagram and supporting narrative
(identify actors and use cases)
•Include Data Flow Diagram if appropriate
• 2.1 Product Perspective
• 2.2 Product Functions •Describe and justify technical skills
and capabilities of each user class
• 2.3 User Characteristics
• 2.4 Constraints
• 2.5 Assumptions and Dependencies
• 3. Specific Requirements •Describe other constraints that will limit developer’s
• 4. Appendices options; e.g., regulatory policies; target platform,
database, network software and protocols, development
• 5. Index standards requirements
IEEE 830-1998 Standard – Section 3 of SRS (1)

•…
• 1. Introduction Specify software requirements in sufficient
detail to enable designers to design a system to satisfy
• 2. Overall Description
those requirements and testers to verify
requirements
• 3. Specific Requirements State requirements that are externally perceivable by

users, operators, or externally connected systems
• 3.1 External Interfaces
Requirements should include, at a minimum, a
• 3.2 Functions description of every input (stimulus) into the system,
every output (response) from the system, and all
• 3.3 Performance Requirements functions performed by the system in response to an
input or in support of an output
• 3.4 Logical Database Requirements

(a) Requirements should have characteristics of
high quality requirements
• 3.5 Design Constraints (b) Requirements should be cross-referenced to
their source.
• 3.6 Software System Quality Attributes (c) Requirements should be uniquely identifiable
(d) Requirements should be organized to
• 3.7 Object Oriented Models maximize readability
• 4. Appendices
• 5. Index
IEEE 830-1998 Standard – Section 3 of SRS (2)

•… •Detail all inputs and outputs
• 1. Introduction (complement, not duplicate, information presented in section 2)
•Examples: GUI screens, file formats
• 2. Overall Description
• 3. Specific Requirements •Include detailed specifications of each
use case, including collaboration and
• 3.1 External Interfaces other diagrams useful for this purpose
• 3.2 Functions
•Include:
• 3.3 Performance Requirements a) Types of information used
b) Data entities and their relationships
• 3.4 Logical Database Requirements
• 3.5 Design Constraints •Should include:
a) Standards compliance
• 3.6 Software System Quality Attributes b) Accounting & Auditing procedures
• 3.7 Object Oriented Models •The main body of requirements organized in a variety of
• 4. Appendices possible ways:
a) Architecture Specification
• 5. Index b) Class Diagram

c) State and Collaboration Diagrams
d) Activity Diagram (concurrent/distributed)
IEEE 830-1998 Standard – Templates

• Annex A of IEEE 830
• Section 3 (Specific Requirements) may be organized in many

different ways based on
• Modes
• User classes
• Concepts (object/class)
• Features
• Stimuli
• Response
• Functional hierarchy
14
Relationship of IEEE 830 and ISO/IEC 12207 (1)

• 12207
• Common framework for « Software life cycle processes »
• ISO/IEC 12207 = IEEE/EIA 12207
• IEEE 830-1998 and IEEE/EIA 12207.1-1997 both place

requirements on documents describing software
requirements
• Annex B of IEEE 830 explains the relationship between the
two sets of requirements for those who want to produce
documents that comply with both standards simultaneously
• Such compliance may be required by customers when
requesting proposals or issuing call for tenders
15
Relationship of IEEE 830 and ISO/IEC 12207 (2)
• Note: Table B.3 is more detailed and shows the

correspondence between the two standards at the level of
requirements types
16
ISO/IEC/IEEE 29148:2011
• ISO/IEC/IEEE 29148:2011: Systems and software
engineering — Life cycle processes — Requirements
engineering
• http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6146379
• This International Standard provides a unified treatment of
the processes and products involved in engineering
requirements throughout the life cycle of systems and
software.
• Harmonizes IEEE 830, SWEBOK, and 7 other standards.
• More emphasis on characteristics of good requirements, RE
activities and processes, operations (and operation context),
and different information items (including their structures)
such as specification of requirements for stakeholders,
systems and software.
• Complies with ISO/IEC 15288 and ISO/IEC 12207
17
Stakeholder Requirements Specification Outline
18
System Requirements Specification Outline
19
Software Requirements Specification Outline
Verification: This section provides the

verification approaches and methods
planned to qualify the software. The
information items for verification are
recommended to be given in a parallel
manner with the information items in
section 3.
20
Tutorials and Tools
• http://plantuml.com/
• http://www.visual-paradigm.com
21
Tutorial 01 SEG3101 / Fall 2009
Writing Good Requirements 1)

1. Are these requirements for an electronic library system correctly written? If not, explain why and
suggest a better way to write them. Assume that this system is available to its users from 07:00 to 22:00
every day.
a. The electronic library system shall prevent a borrower from borrowing more than 5 books.
b. The electronic library system shall create a backup of the list of daily loans at 02:00 and allow the
administrator to view this list at will.
c. The electronic library system shall ensure that only authorized members can borrow books.
d. The borrower shall renew her membership every year.
e. Upon request from an authorized borrower, the electronic library system shall display the list of
currently borrowed books within 3 seconds.
f. The electronic library system shall provide foolproof identification of all borrowers to prevent
any unauthorized access to their account.
g. The borrower may use the electronic library system to query the availability of books by
providing the author’s name and to print the resulting list.
h. The electronic library system shall send an email to the borrower when her hold is ready for
pickup.
2. Are these requirements for an ATM system correctly written? If not, explain why and suggest a better
way to write them. Assume that readers know that an ATM is an Automated Teller Machine.
a. Often an ATM user may usually perform multiple transactions during a single account session.
b. The price of the ATM shall not exceed $30,000 and allow the maintainer to request a notification
be posted to indicate to all ATM users that the system is about to become unavailable.
c. The ATM user shall be able to view the current account balance after an update within 5 seconds.
3. Are these requirements correctly written? If not, explain why and suggest a better way to write them.
a. The elevator control software shall position the elevator cabin on the most frequently used floor.
b. The system shall move the elevator cabin to the required floor.
c. The system shall have one backup processor.
d. The system shall have a speedometer.
4. The following requirements have been taken from a NASA project. Are these requirements correctly
written? If not, explain why and suggest a better way to write them. Assume that all abbreviations have
been defined: SAFER (Simplified Aid for EVA Rescue), FTA (Flight Test Article), EVA (Extravehicular
Activity), EMU (Extravehicular Mobility Unit).
a. The SAFER FTA shall be stowed in the Orbiter Airlock Stowage Bag for launch, entry, landing,
and on-orbit.
b. The SAFER FTA shall be operated by an EVA Crewmember wearing EMU sizes medium
through extra large without limiting suit mobility.
5. These two sentences state requirements for an airplane and one of its subsystems. What is wrong with
these two requirements?
a. The A999 airplane shall be capable of operating over a planned operational life of twenty (20)
years.
b. The flight control subsystem shall have an operational life of twenty (20) years.
1) Sources: Guide for Managing and Writing Requirements, Compliance Automation, Inc.
Writing Good Requirements, Compliance Automation, Inc. 1/1
Requirements Inception
Based on Powerpoint slides by Gunter Mussbacher

with material from:
Wiegers: Software Requirements, Chapter 5
Leffingwell & Widrig: Managing Software Requirements…, Chapter 5
Table of Contents
• Problem Analysis
• Business Requirements
• Steps for Problem Analysis
• Vision and Scope Document
• Project Viability
• … Content covered in more detail in other courses, but
overviewed here as a starting point.
• The important thing is not to stop questioning. Curiosity has its own reason for existing. 1
[1] Albert Einstein (1879 - 1955)

2
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document
Problem Analysis
• Goal: gain a better understanding of the problem being
solved before development begins
• Identify root cause
• Identify stakeholders and their needs (or problems)
• Identify solution boundary
• Uses business requirements obtained from stakeholders
• Results in Product Vision and Project Scope
3
Business Requirements / Objectives (1)

• Business Opportunity
• Description of market opportunity, competing market, business
problem being solved or improved, advantage of proposed solution...
• Example: Exploit the poor security record of a competing product
• Business Objective and Success Criteria
• Important business benefits the product will provide in a quantitative
and measurable way, how success will be measured, factors that have
great impact on success...
• Examples: Achieve positive cash flow on the product within 6 months;
Get 50%+ of the market
• Business Risks
• Major risks associated with developing or not developing the product
(marketplace competition, timing, user acceptance, implementation
issues...)
• Can be modeled with GRL
4
Business Requirements (2)

• Important for:
• Ensuring that all project participants work for the same reasons
• Getting stakeholders agreement on requirements
• User and software requirements must align with the context

and objective defined by business requirements
• Requirements that do not help achieve business objectives

should not be included
5
Problem Analysis – Understand Root Causes (1)

• There is often a problem behind the problem
• Root cause analysis consists of finding underlying causes
that may not be immediately apparent
• Determine recursively what factors contribute to the problem
• Example: Our ecommerce site is not profitable

• Why is it not profitable?
• Poor site design?
• Bad pricing?
• Poor customer management after the sale?
• Some or all of the above?
6
Problem Analysis – Understand Root Causes (2)

• Address Root Causes
• Root causes do not all have same impact
• Some may not be worth fixing, at least not now
• Estimate relative impact of root causes (e.g., with the help of
a Pareto (bar) chart):
20% of causes →
80% of problems…
• Create problem
statement for root
cause problem
identified as worth
solving (and with
computer solution)
Source: Leffingwell & Widrig
7
“Low Hanging Fruits”
8
Problem Analysis – Product Vision and Project Scope

• Product Vision: describes what the product is about and what
it could eventually become
• Aligns all stakeholders in a common direction
• Project Scope: identifies what portion of the ultimate long-

term product vision the current project will address
• Draws boundary between what is in and what is out
Product Vision
Project Scope Project Scope Project Scope

…..
for release 1.0 for release 1.1 for release n
9
Vision Statement (1)

• Vision Statement template for Products (according to Moore)
• For [target customer]
• Who [statement of the need or opportunity]
• The [product name]
• Is [a product category]
• That [key benefit, compelling reason to buy or use]
• Unlike [primary competitive alternative, current system, or current
business process],
• Our product [statement of primary differentiation and advantages of
new product]
10
Vision Statement (2)

• Example
• For scientists who need to request containers of chemicals, the
Chemical Tracking System is an information system that will provide a
single point of access to the chemical stockroom and vendors. The
system will store the location of every chemical container within the
company, the quantity of material remaining in it and the complete
history of each container's location and usage. This system will save
the company 25% on chemical costs in the first year of use by allowing
the company to fully exploit chemicals that are already available within
the company, dispose of fewer partially used or expired containers and
use a single standard chemical purchasing process. Unlike the current
manual ordering processes, our product will generate all reports
required to comply with government regulations that require the
reporting of chemical usage, storage, and disposal.
11
Vision Statement (Enterprise Level) (3)

• uOttawa Vision (2010)
• We aspire to be, among universities, the essential reference on what
Canada represents: a university that is an integral part of its
community, open to the world, and distinguished by its search for
excellence in research, its high-quality learning environment, its
passion for knowledge and innovation, its leadership on language
issues, and its openness to diversity. Every member of our institution
will take part in our educational mission.
12
Vision Statement (Enterprise Level) (4)

• uOttawa Vision (Today)
• The University of Ottawa will offer an unparalleled university
experience and, through outstanding teaching and research, play a
vital role in defining the world of tomorrow. We will instil in each of our
graduates an ethic of service, a culture of engagement and an
awareness of shared responsibility that will prepare them for global
citizenship.
• http://destination2020.uottawa.ca/documents/destination-2020-
strategic-plan.pdf
• Vision at The Ottawa Hospital

• Provide each patient with the world-class care, exceptional service
and compassion we would want for our loved ones.
13
Dynamic Vision, Scope and Requirements…

• The product vision may apply to many projects
• Views of the customer, of the enterprise
• Evolves rather slowly (e.g., in years)
• The product scope focuses on one project

• Important to the project manager
• More dynamic than the vision
• Can be part of a requirements document
• Requirements focus on what is needed in order for the

product to meet business objectives
• Many and rapid changes!
14
Project Viability – Scope

• Scope: product's purpose and the system's boundaries
• How much of the work will be done by the system-to-be-developed?
• How much of the work will be done by interacting systems?
• Information needed for cost and time estimates
• Define more precisely the problem to solve
• List all the things the system should have to do
• Exclude as much as possible to reduce the complexity of the problem
• Establish broader goals if the problem is too simple
• Example: an automated system for university registration
Initial list of wide problems Reduced scope For other systems
Course Browser Course Browser Room Allocation

Room Allocation
Registration Registration Exam Schedule
Exam Schedule
Payment Payment
Later stage
Vision and Scope Document

• Business requirements
• Vision of the solution

• Including major features and dependencies
• Scope and limitation

• For initial and subsequent releases
• Business context
• Including priorities and operating environment
• Risks!!!
16
In Summary…
“The idea is to do just enough investigation to form a

rational, justifiable opinion of the overall purpose and
feasibility of the potential new system, and decide if it
is worthwhile to invest in deeper exploration”
[Craig Larman]
17
Introduction to Requirements
Elicitation

with material from:
Jo Atlee, Nancy Day, Dan Berry (all University of Waterloo);
Amyot 2008-2009, Somé 2008
Table of Contents
• Goals, Risks, and Challenges
• Sources of Requirements
• Requirements Elicitation Tasks
• Elicitation Problems
• I know that you believe that you understood what you think I
said, but I am not sure you realize that what you heard is not
what I meant.1
[1] Robert McCloskey, State Department spokesman

2
3
Goals, Risks, and Challenges
Goals, Risks, and Challenges Sources of Requirements Requirements Elicitation Tasks Elicitation Problems
What is Requirements Elicitation?

• Requirements elicitation is “the process of discovering the
requirements for a system by communicating with customers,
system users and others who have a stake in the system
development”1
• Elicitation means “to bring out, to evoke, to call forth”

• Elicitation might even require one to provoke!
• Human activity involving interaction between a diverse array

of human beings
[1] Ian Sommerville and Pete Sawyer

5
Elicitation Goals
• Determine sources of information & appropriate techniques
• Get information on domain, problem, constraints
• Produce a first document

• Mainly user requirements and elicitation notes
• Potentially incomplete, disorganized, inconsistent
• But we must start somewhere!
6
Elicitation Risks and Challenges (1)

• Problems of scope
• System boundaries inadequately defined or defined too soon
• Unnecessary technical details
• Problems of understanding
• Stakeholder not sure of what is needed
• Stakeholder has trouble communicating needs
• Stakeholder does not understand capabilities and limitation of
computing environment
• Requirements limited by what stakeholders think is possible
• Stakeholder does not have full understanding of domain
• Stakeholders state conflicting requirements
• Hard to detect, negotiate, and prioritize
• Problems of volatility
• Stakeholders will not commit to a set of written requirements
7
Elicitation Risks and Challenges (2)

• Other typical issues
• Experts seldom available
• Many stakeholders lack motivation or resist to change
• Finding an adequate level of precision/detail
• Mixing requirements with design
• Common vocabulary often missing
• Requirements do not fall from the sky!
• Sometimes hidden
• Sometimes too obvious, implicit, ordinary…
• Assume == “a**” of “u” and “me”
• Need for creative thinking in order to
produce innovative and adequate
requirements
8
RE: More an Art than Science
9
Sources of Requirements
Sources of Requirements
• Various stakeholders
• Clients, customers, users (past and future), buyers, managers, domain
experts, developers, marketing and QA people, lawyers, people
involved in related systems, anyone who can bring added value!
• Pre-existing systems
• Not necessarily software systems
• Pre-existing documentation
• Competing systems
• Documentation about interfacing systems
• Standards, policies, collective agreements, legislation
•…
11
Stakeholder – Customer/Client
• Person who pays for the software development
• Ultimately, has the final word on what will be the product

• For an internal product, the client is probably a product
manager
• For the consumer market, the customer may be the
marketing department
12
Stakeholder – Buyer
• Person who pays for the software once it is developed
• Possibly a user or a business owner buying a product for his

employees
• What features is he willing to pay for?
• Which are trivial or excessive?
• Must participate actively in the project (or have a
representative)
13
Stakeholder – User
• ... of the current system or future system
• Experts of the current system: indicate which functions to

maintain or improve
• Experts of competitors’ products: suggestions on designing a
superior product
• May have special needs or requirements
• Usability, training, online help ...
• Do not neglect interest groups
• Expert users, or with disabilities or handicaps
• Select users with care
• Different seniority
• Must speak with authority and be responsible and motivated
14
Stakeholder – Domain Expert

• Expert who knows the work involved
• Familiar with the problem that the software must solve. For
example:
• Financial expert for finance management software
• Aeronautical engineers for air navigation systems
• Meteorologist for weather forecasting system, etc…
• Also knows the environment in which the product will be used
15
Stakeholder – Software Engineer

• Expert who knows the technology and process
• Determines if the project is technically and economically

feasible
• Specifically estimates the cost and time of product
development
• Educates the buyer/client on the latest and innovative
hardware or software, and recommends new features that will
benefit from these technologies
16
Stakeholder – Others
• Inspector
• An expert in governmental rules and safety relevant to the project
• Examples: safety inspectors, auditors, technical inspectors,
government inspectors
• Market research specialist

• Can play the role of the customer if the software is developed for the
general public
• Expert who has studied the market to determine trends and needs of
potential customers
17
Stakeholder – Others
• Lawyer
• Familiar with laws and legal aspects
• Standards relevant to the project
• Expert of systems that interact with the system to be built

• Knows the interfaces of the interacting systems
• May be interested in product features (if the product can help the
interacting system to perform its tasks)
• Others that bring added value

• People who will use your product as a basic building block
18
On Stakeholders Availability…
• Stakeholders are generally busy!
• Have priorities other than you
• Are rarely entirely disconnected from their daily routine and tasks
• See their participation in the elicitation process as a supplementary
task
• Hence, you must have the support and commitment of
managers (especially theirs!)
• You must also avoid being perceived as a threat:
• Loss of jobs caused by the improved system
• Loss of autonomy, powers, or privileges
• To the recognition and visibility of their work
19
Requirements Elicitation Tasks
Tasks Performed as Part of Elicitation (1)

• Planning for the elicitation
• Why? Who? When? How? Risks?
• During the elicitation
• Confirm the viability of the project (is it worth it?)
• Understand the problem from the perspective of each stakeholder
• Extract the essence of stakeholders’ requirements
• Invent better ways to do the work of the user
• Following the elicitation
• Analyse results to understand obtained information
• Negotiate a coherent set of requirements acceptable by all
stakeholders and establish priorities
• Record results in the requirements specification
21
Tasks Performed as Part of Elicitation (2)

• Repeat as needed
• Elicitation is incremental
• Driven by information obtained
• You always do a bit of elicitation – analysis – specification –
verification at the same time
22
Elicitation Plan – Objectives / Strategies & Processes

• Objectives: Why this elicitation?
• Validate market data
• Explore usage scenarios
• Develop a set of requirements, etc..
• Set elicitation strategies and processes

• Approaches used
• Often a combination of approaches depending on the types and
number of stakeholders
• Examples: Surveys (questionnaires), workshops, interviews…
23
Elicitation Plan – Products

• Usually set of rough requirements
• Written, audio, video notes
• Documentation
• Deliverables depend on objective and technique
• Generally: un-organized, redundant, incomplete
24
Extract Essence
• Extract the essence of the stakeholders' requirements
• Interpret stakeholders' descriptions of requirements
• Possibly build models (may be part of your documentation!)
• Gaps in the model behavior may indicate unknown or ambiguous

situations
• Models help focus our efforts
• Should be resolved by asking the stakeholders (especially users)
25
Invent Better Ways

• Invent better ways to do the user's work
• Ask why documented requirements so far are desired
• The client/user’s view can be limited by past experiences...
• Brainstorm to invent requirements the stakeholders have not yet
thought of
26
Dilbert on Requirements Elicitation
27
Requirements Elicitation
Techniques
Based on PowerPoint slides by Gunter Mussbacher (2009)

with material from:
Jo Atlee, Nancy Day, Dan Berry (all University of Waterloo);
Lethbridge & Laganière, Chapter 7; Bruegge & Dutoit, Chapter 4;
I. Alexander; Amyot 2008-2009; Somé 2008, Bochmann 2010
Table of Contents
• Elicitation Techniques
• Analysis of Existing Systems
• Documentation, Observation, and Ethnography
• Interviews
• Questionnaires
• Brainstorming
• Prototyping
• Use Cases
• When people talk, listen completely. Most people never

listen.1
[1] Ernest Miller Hemingway (1899-1961)
2
3
Elicitation Techniques Existing Systems Interviews Questionnaires Brainstorming Prototyping Use Cases
Elicitation Techniques
• Elicitation techniques
• Stakeholder analysis
• Analysis of existing systems or documentation,
background reading
• Discourse analysis
• Task observation, ethnography
• Questionnaires
• Interviewing
• Brainstorming
• Joint Application Design (JAD)
• Prototyping
• Pilot system
• Use cases and scenarios
• Risk analysis
• See also: http://www.slideshare.net/hayriyesakarya/
elicitation-procedures-10618009
4
Comparison of Data-Gathering Techniques1

Technique Good for Kind of data Plus Minus
Questionnaires Answering specific Quantitative and Can reach many people The design is crucial.
questions qualitative data with low resource Response rate may be
low. Responses may
not be what you want
Interviews Exploring issues Some quantitative but Interviewer can guide Time consuming.
mostly qualitative data interviewee. Artificial environment
Encourages contact may intimidate
between developers interviewee
and users
Focus groups and Collecting multiple Some quantitative but Highlights areas of Possibility of dominant
workshops viewpoints mostly qualitative data consensus and conflict. characters
Encourages contact
between developers
and users
Naturalistic observation Understanding context Qualitative Observing actual work Very time consuming.
of user activity gives insight that other Huge amounts of data
techniques cannot give
Studying Learning about Quantitative No time commitment Day-to-day work will

documentation procedures, from users required differ from documented
regulations, and procedures
standards
[1] Preece, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p214
See also this intro and comparison from Ying Chen : http://www.umsl.edu/~ycnx6/
5
Analysis of Existing Systems
Analysis of Existing Systems (1)

• Useful when building a new improved version of an existing
system
• Important to know:
• What is used, not used, or missing
• What works well, what does not work
• How the system is used (with frequency and importance) and it was
supposed to be used, and how we would like to use it
7
Analysis of Existing Systems (2)

• Why analyze an existing system?
• Users may become disillusioned with new system or do not like the
new system if it is too different or does not do what they want (risk of
nostalgia for old system)
• To appropriately take into account real usage patterns, human issues,
common activities, relative importance of tasks/features
• To catch obvious possible improvements (features that are missing or
do not currently work well)
• To find out which "legacy" features can/cannot be left out
8
Review Available Documentation

• Start with reading available documentation
• User documents (manual, guides…)
• Development documents
• Requirements documents
• Internal memos
• Change histories
• …
• Of course, often these are out of date, poorly written, wrong,

etc., but it's a good starting point
• Discourse analysis
• Use of words and phrases is examined in written or spoken language
9
Observation and Related Techniques (1)

• Observation
• Get into the trenches and observe specialists “in the wild”
• Shadow important potential users as they do their work
• Initially observe silently (otherwise you may get biased information)
• Ask user to explain everything he or she is doing
• Session videotaping
• Ethnography also attempts to discover social, human, and

political factors, which may also impact requirements
10
Observation and Related Techniques (2)

• Can be supplemented later with questionnaires
• Based on what you know now – the results of observation
• To answer questions that need comparison or corroboration
(confirmation)
• To obtain some statistics from a large number of users (look for
statistical significance!), e.g.:
• How often do you use feature X?
• What are the three features you would most like to see?
• Can be supplemented later with interviews
• After getting a better idea of what is to be done, probably some
questions require more detailed answers
• You will not be wasting other people's time or your own
• This is very labour intensive!
11
Ethnography – Overview (1)

• Comes from anthropology, literally means "writing the culture"
• Essentially seeks to explore the human factors and social
organization of activities à understand work
• Studies have shown that work is often richer and more complex than is
suggested by simple models derived from interviews
• Social scientists are trained in observation and work analysis
• Discoveries are made by observation and analysis, workers

are not asked to explain what they do
• Collect what is ordinary/what is it that people do (aim at making the
implicit explicit)
• Study the context of work and watch work being done
12
Ethnography – Overview (2)

• Useful to discover for example
• What does a nuclear technician do during the day?
• What does his workspace look like?
• Less useful to explore political factors

• Workers are aware of the presence of an outside observer
13
Ethnography – Example
• Sommerville et al. were involved in a project where they had
to elicit the requirements of an air traffic control system
• They observed the air traffic controllers in action with the
existing system
• Surprising observations
• Controllers often put aircrafts on potentially conflicting headings with
the intention of fixing them later
• System generates an audible alarm when there is a possible conflict
• The controllers close the alarms because they are annoyed by the
constant warnings
• Incorrect conclusion
• The controllers do not like audible alarms because they close them
• More accurate observation
• The controllers do not like being treated like idiots
• Need to minimize false alarms (more generally: false positives) 14
False/True Positives/Negatives… Confusion Matrix
[http://en.wikipedia.org/wiki/Sensitivity_and_specificity]
15
Interviews
Interviews (1)
• Requires preparation and good communication management
• Achieve interview objectives without preventing the exploration of
promising leads
• Interview as many stakeholders as possible

• Not just clients and users
• Ask problem-oriented questions

• Ask about specific details, but…
• Detailed and solution-specific questions may miss the stakeholder’s
real requirements. Example:
• Would you like Word 2010, Excel 2010 or both?
vs.
• Would you like to do word processing, computations, or both?
17
Interviews – Objectives and Process (2)

• Three main objectives:
• Record information to be used as input to requirements analysis and
modeling
• Discover information from interviewee accurately and efficiently
• Reassure interviewee that his/her understanding of the topic has been
explored, listened to, and valued
• Process consists of four important steps:

• Planning and preparation
• Interview session
• Consolidation of information
• Follow-up
• Many strategies for questioning

18
Interviews – Planning and Preparation

• Important to plan and prepare interviews
• Set goals and objectives for the interview
• Acquire background knowledge of the subject matter to conduct an
effective interview
• About the domain (vocabulary, problems...) but also about the interviewee
(work tasks, attitude...)
• Prepare questions in advance, by subject
• Organize the environment for conducting an effective interview
• Determine how the elicitation notes will be taken (manually, audio, video,
by whom…)
19
Interviews – Session
• Make the interviewee comfortable and confident
• Be polite and respectful!
• Adjust to the interviewee
• You have your goals – be persistent but flexible
• Interview several people at once to create synergy
• Try to detect political aspects as they may influence the said

and the unsaid
20
Interviews – Elicitation Notes

• Revise and complete the elicitation notes after the interview
• Needs to be done soon after because one forgets the details (and
everything else)
• Identify inconsistencies and address them in a follow-up
interview or by email
• Keep all diagrams, charts, models created during the
discussions
• You are learning, so be precise
• Pay attention to terminology
• Use the interviewee’s terminology
• Identify synonyms
• Create a glossary if necessary
• Thank the participants (e.g., by email), and keep the door
open to future interactions
21
Common Interviewing Mistakes (1)

• Not interviewing all of the right people
• Different points of view of stakeholders
• Asking direct questions too early

• E.g., design of a transportation system:
• How much horsepower do you need? (direct)
• How many passengers? How far? How fast? (indirect)
• E.g., camera design for novice photographer:
• How important is control over shutter speed and aperture? (direct)
• Will you be taking action shots, still shots, or both? (indirect)
22

• Interviewing one-at-a-time instead of in small groups
• More people might help get juices flowing as in brainstorming
• Users cannot think of everything they need when asked individually,
but will recall more requirements when they hear others' needs
• Reduces spotlight on individuals (may produce more interesting
answers)
• This interaction is called synergy, the effect by which group responses
outperform the sum of the individuals' responses
• Exercise: Tell me 10 jokes each…
• Do not let one participant dominate the discussion
• Assuming that stated needs are exactly correct
• Often users do not know exactly what they want and order "what he is
eating"
• Need to narrow what is asked for down to what is needed
23

• Trying to convince stakeholders that YOU are smart – wrong
place to do that!
• Instead take every opportunity to show you think the stakeholder is
smart
• Contrast these two cases1
My Elevators
Are
Too Slow!
I See.
Tell Me Why I Don’t Think So.
You Feel They I Think You Have an
Are Too Slow. Elevator Throughput
Problem, not a Speed
Problem
[1] Alan M. Davis “Just enough requirements management”

24
Interviews – Start Up Questions (1)

• Context-free questions to narrow the scope a bit (Weinberg)
• Identify customers, goals, and benefits

• Who is (really) behind the request for the system?
• Who will use the system? Willingly?
• Are there several types of users?
• What is the potential economic benefit from a successful solution?
• Is a (pre-existing) solution available from another source?
25

• When do you need it by?
• Can you prioritize your needs?
• What are your constraints?
• Time
• Budget
• Resources (human or otherwise)
• Expected milestones (deliverables and dates)?
26

• Try to characterize the problem and its solution
• What would be a "good" solution to the problem?
• What problems is the system trying to address?
• In what environment will the system be used?
• Any special performance issues?
• Other special constraints?
• What is (un)likely to change?
• Future evolution?
• What needs to be flexible (vs. quick & dirty)?
27

• Calibration and tracking questions
• Are you the right person to answer these questions?
• Are your answers "official"? If not, whose are?
• Are these questions relevant to the problem as you see it?
• Are there too many questions? Is this the correct level of detail?
• Is there anyone else I should talk to?
• Is there anything else I should be asking you? Have you told me
everything you know about the problem?
• Do you have any questions?
28

• Questions that cannot be asked directly (ask indirectly)
• Are you opposed to the system?
• Are you trying to obstruct/delay the system?
• Are you trying to create a more important role for yourself?
• Do you feel threatened by the proposed system?
• Are you trying to protect your job?
• Is your job threatened by the new system?
• Is anyone else's?
29
Interviews – Specific Questions (1)

• Functional requirements
• What will the system do?
• When will the system do it?
• Are there several modes of operations?
• What kinds of computations or data transformations must be
performed?
• What are the appropriate reactions to possible stimuli?
• For both input and output, what should be the format of the data?
• Must any data be retained for any period of time?
30

• Design Constraints
• Physical environment
• Where is the equipment to be located?
• Is there one location or several?
• Are there any environmental restrictions, such as temperature, humidity, or
magnetic interference?
• Are there any constraints on the size of the system?
• Are there any constraints on power, heating, or air conditioning?
• Are there constraints on the programming language because of existing
software components?
31

• Design Constraints
• Interfaces
• Is input coming from one or more other systems?
• Is output going to one or more other systems?
• Is there a prescribed way in which input/output need to be formatted?
• Is there a prescribed way for storing data?
• Is there a prescribed medium that the data must use?
• Standards
• Are there any standards relevant to the system?
• Laws, policies, and regulations
• Are there any laws, policies, or regulations applicable here?
32

• Performance
• Are there constraints on execution speed, response time, or
throughput?
• What efficiency measure will apply to resource usage and response
time?
• How much data will flow through the system?
• How often will data be received or sent?
33

• Usability and Human Factors
• What kind of training will be required for each type of user?
• How easy should it be for a user to understand and use the system?
• How difficult should it be for a user to misuse the system?
34

• Security
• Must access to the system or information be controlled?
• Should each user's data be isolated from data of other users?
• Should user programs be isolated from other programs and from the
operating system?
• Should precautions be taken against theft or vandalism?
35

• Reliability and Availability
• Must the system detect and isolate faults?
• What is the prescribed mean time between failures?
• Is there a maximum time allowed for restarting the system after
failure?
• How often will the system be backed up?
• Must backup copies be stored at a different location?
• Should precautions be taken against fire or water damage?
36

• Maintainability
• Will maintenance merely correct errors, or will it also include improving
the system?
• When and in what ways might the system be changed in the future?
• How easy should it be to add features to the system?
• How easy should it be to port the system from one platform (computer,
operating system) to another?
37

• Precision and Accuracy
• How accurate must data calculations be?
• To what degree of precision must calculations be made?
38
More on Interviews
• Watch for unanswerable questions…
• How do you tie your shoelaces?
• See interesting video:

• http://www.youtube.com/watch?v=2WBef84bodc
39
“Ignorance is bliss”1
• According to Dan Berry, ignorance
of a domain is a good thing!
• Ignorance (not stupidity !) allows
one to expose hypotheses and
some implicit facts
• Berry even suggests that one day,
requirements engineers may
advertise their domains of
ignorance (rather than their
domains of expertise) to find a job!
• Actually, a mix of domain experts
and domain ignorants on a team is
a good thing2
[1] The Matrix, 1999
[2] Ali Niknafs, Daniel M. Berry: An industrial case study of the impact of
domain ignorance on the effectiveness of requirements idea generation
during requirements elicitation. RE 2013: 279-283
40
Questionnaires
Questionnaires and Surveys

• Some benefits:
• Can reach multiple people, maybe in an anonymous way
• Asynchronous, distributed, and can be quick to answer
• Cheap
• Challenges:
• Preparation time!
• Choice of questions: open-ended and close (lack of flexibility)
• Choice of answers and scales (nominal, intervals, Likert…); avoid
centralist tendencies!
• Statistical significance during analysis
• Validity of questions (bias, ambiguities)
• Repetition and order of questions
• Determining suitable participants to invite (risk of bias, of fraud)
• Getting people to answer everything (exhaustion, unattractive…)!
42
Types of Questions to Consider

• Demography questions (for classification)
• Age, country, occupation… For analysis from many angles
• Beware of re-identification risks if supposed to be anonymous
• Attitudinal questions
• What do you think of…? Do you agree with…?
• Scale with 4-6 values (no center) or 5-7 values (with neutral value)
1. Strongly agree
2. Agree somewhat
3. Neither agree nor disagree (Undecided)
4. Disagree somewhat
5. Strongly disagree
• Supplementary open questions (instructive, but qualitative)
• Optional/alternative questions, by population
• Redundant questions, for robustness…
43
Analysis to Consider… In Advance!

• Will the survey be repeated (before/after, for comparison)?
• Determine the type of (statistical) analysis, e.g.:
• Statistical significance?
http://en.wikipedia.org/wiki/Statistical_significance
• Test your questionnaire and your analysis on a small group!
• See also this important video on surveys and questionnaires:
• http://www.youtube.com/watch?v=rSwVZJT9j1c
44
Brainstorming
Brainstorming
• To invent new way of doing things or when much is unknown
• When there are few or too many ideas
• Early on in a project particularly when:
• Terrain is uncertain
• There is little expertise for the type of applications
• Innovation is important (e.g., novel system)
• Two main activities:
• The Storm: Generating as many ideas as possible (quantity, not
quality) – wild is good!
• The Calm: Filtering out of ideas (combine, clarify,
! !
prioritize, improve…) to keep the best one(s) –
!
may require some voting strategy
! !
• Roles: scribe, moderator (may also provoke), !
participants
46
Brainstorming – Objectives
• Hear ideas from everyone, especially unconventional ideas
• Keep the tone informal and non-judgemental
• Keep the number of participants “reasonable“ – if too many, consider a
“playoff “-type filtering and invite back the most creative to multiple
sessions
• Encourage creativity
• Choose good, provocative project name.
• Choose good, provocative problem statement
• Get a room without distractions, but with good acoustics, whiteboards,
coloured pens, provide coffee/donuts/pizza/beer
• Provide appropriate props/mock-ups
47
Brainstorming – Roles
• Scribe
• Write down all ideas (may also contribute)
• May ask clarifying questions during first phase but without criticizing
• Moderator/Leader
• Cannot be the scribe
• Two schools of thought: traffic cop or agent provocateur
• Traffic cop – enforces "rules of order", but does not throw his/her
weight around otherwise
• Agent provocateur – traffic cop plus more of a leadership role, comes
prepared with wild ideas and throws them out as discussion wanes
• May also explicitly look for variations and combinations of other
suggestions
48
Brainstorming – Participants
• Virtually any stakeholder, e.g.
• Developers
• Domain experts
• End-users
• Clients
• ...
• “Ideas-people” – a company may have a special team of

people
• Chair or participate in brainstorming sessions
• Not necessarily further involved with the project
49
Brainstorming – The Storm

• Goal is to generate as many ideas as possible
• Quantity, not quality, is the goal at this stage
• Look to combine or vary ideas already suggested
• No criticism or debate is permitted – do not want to inhibit
participants
• Participants understand nothing they say will be held against
them later on
• Scribe writes down all ideas where everyone can see
• E.g., whiteboard, paper taped to wall
• Ideas do not leave the room
• Wild is good!
• Feel free to be gloriously wrong
• Participants should NOT censor themselves or take too long to
consider whether an idea is practical or not – let yourself go!
50
Brainstorming – The Calm

• Go over the list of ideas and explain them more clearly
• Categorize into "maybe" and "no" by pre-agreed consensus
method
• Informal consensus
• 50% + 1 vote vs. “clear majority”
• Does anyone have veto power?
• Dutch auction: http://en.wikipedia.org/wiki/Dutch_auction
• Be careful about time and people
• Meetings (especially if creative or technical in nature) tend to lose
focus after 90 to 120 minutes – take breaks or reconvene later
• Be careful not to offend participants
• Review, consolidate, combine, clarify, improve
• Rank the list by priority somehow
• Choose the winning idea(s)
51
Brainstorming – Eliminating Ideas

• There are some common ways to eliminate some ideas
• Blending ideas
• Unify similar ideas but be aware not to force fit
everything into one idea
• Give each participant $100 to spend on the ideas
• Apply acceptance criteria prepared prior to meeting
• Eliminate the ideas that do not meet the criteria
• Various ranking or scoring methods
• Assign points for criteria met, possibly use a
weighted formula
• Vote with threshold or campaign speeches

• Possibly select top k for voting treatment
52
Brainstorming – Voting on Ideas

• Voting with threshold
• Each person is allowed to vote up to n times
• Keep those ideas with more than m votes
• Have multiple rounds with smaller n and m
• Voting with campaign speeches

• Each person is allowed to vote up to j < n times
• Keep those ideas with at least one vote
• Have someone who voted for an idea
defend it for the next round
• Have multiple rounds with smaller j
53
Brainstorming – Tool Support

• With many good ideas, some outrageous and even
farfetched, brainstorming can be really fun!
• Creates a great environment that stimulates
people and motivates them to perform well!
• Can be done by email, but a good moderator/leader is

needed to
• Prevent flamers to come into play
• Prevent race conditions due to the asynchronous communication
medium
• Be careful not to go into too much detail
• Collaboration tools are also possible
• TWiki and many other more appropriate tools such as BrainStorm and
IdeaFisher
54
Joint Application Design (JAD)
Joint Application Design (JAD)

• A more structured and intensive brainstorming approach
• Developed at IBM in the 1970s

• Lots of success stories
• "Structured brainstorming", IBM-style
• Full of structure, defined roles, forms to be filled out...
• Several activities and six (human) roles to be played
• JAD session may last few days
• The whole is more than the sum of its parts. The part is more
than a fraction of the whole.1
[1] Aristotle (384 BC – 322 BC)

56
Joint Application Design – Roles (1)

• Session leader
• Organizer, facilitator, JAD expert
• Good with people skills, enthusiastic, sets tone of meeting
• Analyst
• Scribe++
• Produces official JAD documents, experienced developer who
understands the big picture, good philosopher/writer/organizer
• Executive sponsor
• Manager who has ultimate responsibility for product being built
• Provides strategic insights into company's high-level goals/practices,
makes executive decisions later on as required
57
Joint Application Design – Roles (2)

• User representatives
• Selection of knowledgeable end-users and managers
• Come well-prepared with suggestions and ideas of needs, will
brainstorm for new or refined ideas, eventually review completed JAD
documents
• Information system representatives

• Technical expert on ISs
• Helps users think big, know what is easy/hard/cheap/expensive,
mostly there to provide information rather than make decisions
• Specialists
• Technical expert on particular narrow topics, e.g., security, application
domain, law, UI issues…
58
Challenges of Brainstorming and JAD Sessions
• Unnatural clusters of (uncomfortable) participants
• “Groupthink”
• Superficial responses to technical issues
• Bias and dominance
59
Prototyping
Prototyping
• A software requirements prototype is a mock-up or partial
implementation of a software system
• Helps developers, users, and customers better understand system
requirements
• Helps clarify and complete requirements
• Provides early response to “I'll know it when I’ll see (or won’t see) it”
attitude
• Effective in addressing the “Yes, But” syndrome
• Helps find new functionalities, discuss usability, and establish priorities
• Prototyping is effective in resolving uncertainties early in the
development process
• Focus prototype development on these uncertain parts
• Encourages user participation and mutual understanding
61
Prototyping – Types
• Evolutive: turned into a product incrementally, gives users a
working system more quickly (begins with requirements that
are more understood)
• Throw-away: less precise, thrown away, focusing on the less

well-understood aspects of the system to design, designed to
elicit or validate requirements
62
Prototyping – Realizations
• Prototypes can take many forms:
• Paper prototypes (see http://www.paperprototyping.com/)
• Prototype on index card
• Storyboard
• Screen mock-ups
• Interactive prototypes
• Using high-level languages (e.g., Visual Basic, Prolog)
• Using scripting languages (e.g., Perl, Python)
• Using animation tools (e.g., Flash/Shockwave)
• Models (executables)
• Pilot systems
• …
63
Prototyping – Fidelity (1)

• Fidelity is the extent to which the prototype is real and
(especially) reactive
• Fidelity may vary for throw-away prototypes
• High-fidelity
• Applications that "work" – you press a button and something happens
• Often involves programming or executable modeling languages
• Advantages:
provides an understanding of functionality, reduce design risk, more
precise verdicts about requirements
• Disadvantages:
takes time to build, more costly to build, sometimes difficult to change,
false sense of security, often focuses on details rather than on the
goals and important issues
64
Prototyping – Fidelity (2)

• Low-fidelity
• It is not operated – it is static
• Advantages:
easy and quick to build, cheaper to develop, excellent for interfaces,
offers the opportunity to engage users before coding begins,
encourage creativity
• Disadvantages:
may not cover all aspects of interfaces, are not interactive, may seem
non-professional in the eyes of some stakeholders (sigh!)
65
Use Cases
& Scenarios
Developing Use Case Models of Systems

• Description of a sequence of interactions between a system
and external actors
• Developed by Ivar Jacobson
• Not exclusively for object-oriented analysis
• Actors – any agent that interact with the system to achieve a
useful goal (e.g., people, other software systems, hardware)
• Use case describes a typical sequence of actions that an
actor performs in order to complete a given task
• The objective of use case analysis is to model the system
• … from the point of view of how actors interact with this system
• … when trying to achieve their objectives
• A use case model consists of
• A set of use cases
• An optional description or diagram indicating how they are related
67
Use Cases
• A use case should describe the user’s interaction with the
system ...
• Not the computations the system performs
• In general, a use case should cover the full sequence of

steps from the beginning of a task until the end
• A use case should only include actions in which the actor

interacts with the computer
• Some views differ on this one!!!
68
Use Cases – Abstraction Level

• A use case should be written so as to be as independent as
possible from any particular implementation / user interface
design
• Essential use cases (Constantine & Lockwood)

• Abstract, technology free, implementation independent
• Defined at earlier stages
• E.g., customer identifies herself
• Concrete use cases

• Technology/user interface dependent
• E.g., customer inserts a card, customer types a PIN
69
Scenarios (1)
• A scenario (according to the UML/UC community) is an
instance of a use case
• It expresses a specific occurrence of the use case (a specific path
through the use case)
• A specific actor ...
• At a specific time ...
• With specific data …
• Many scenarios may be generated from a single use case description
• Each scenario may require many test cases
• Rather used in a generic way in this course (as is often the

case in requirements engineering)
70
Scenarios (2)
• A use case includes primary and secondary scenarios
• 1 primary scenario
• Normal course of events
• 0 or more secondary scenarios
• Alternative/exceptional course of events, variations of primary scenario
• An alternative scenario meets the intent of the use case but with a
different sequence of steps
• An exceptional scenario addresses the conditions of main case and
alternative cases that differ from the norm and cases already covered
• Example with consensus as a goal
• Primary scenario: vote in a session
• Alternative scenario: voting in several sessions
• Exceptional scenario: what to do with a non-registrant who wishes to vote
71
Types of Scenarios
• As-is scenario
• Used in describing a current situation, usually used in re-engineering
projects, the user describes the system
• Visionary scenario
• Used to describe a future system, usually used in greenfield
engineering and reengineering projects
• Can often not be done by the user or developer alone
• Evaluation scenario
• User tasks against which the system is to be evaluated
• Training scenario
• Step by step instructions that guide a novice user through a system
72
Use Case-Driven Software Lifecycle Activities (1)
Requirements Requirements System Object Implemen-

Testing
Elicitation Analysis Design Design tation
Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By
class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Objects Code Cases
73
Use Case-Driven Software Lifecycle Activities (2)

• Scenarios guide elicitation, analysis, design, and testing
• There are many scenario-based approaches
• E.g., XP and other agile methods employ user stories (scenarios) to
directly generate tests that will guide software design and verification
• Developers are often unable to speak directly to users
• Scenarios provide a good enough approximation of the “voice

of the user”
74
Representation of Scenarios (1)

• Various approaches
• Text (informal, formal), diagrams (state, sequence ...), video,
animation, comics, storyboard, collaborative workshops (pass the
microphone or the ball)…
• There are specialized notation such as UML (sequence, activity, use
case, interaction, and collaboration diagrams), Message Sequence
Charts (MSC), Live Sequence Charts, and Use Case Maps (UCM)
75
Representation of Scenarios (2)

• Different representations may be useful in specific situations
• For example, storyboards, often used in the film industry, can describe
situations, roles, and sequences of tasks in a fast, compact, and
polyglot way1
• Some scenario-based approaches are very ideological or

dogmatic
[1] I. Alexander
76
Use Case Modeling with UML
• But: Where are the use cases? use case
<<extend>>
Reserve Facility Register Member
Handle Waiting List
generalization
<<include>>
<<include>>
Hotel Counter Staff
Customer Reserve Room
Check In Customer
Check Room
Details <<include>>
actor extension
<<extend>> point
Member Earn and Redeem Credits
Check Out Customer
77
Use Case Diagrams

• To define system boundary (subject), actors, and use cases
• Subject could be: a physical system, a component, a subsystem, a
class
• To structure and relate use cases
• Associate actors with use cases
• Include relation
• Extend relation
• Generalization (of actors and use cases)
78
Use Case Diagrams – <<include>> (Inclusions)

• Inclusions allow one to express commonality between several
different use cases
• Inclusions are included in other use cases
• Even very different use cases can share a sequence of actions (reuse)
• Enable you to avoid repeating details in many use cases (consistency)
• An inclusion represents the execution of a lower-level task
with a lower-level goal (à decomposition of complex tasks)
• Base use case references the included use case as needed

• Base use case cannot exist without the included use case
• When included use case is done, control returns to base use
case
• Disadvantage: have to look in multiple places to understand
use case
79
Use Case Diagrams – <<extend>> (Extensions)

• Used to make optional interactions explicit or to handle
exceptional cases
• By creating separate use case extensions, the description of
the basic use case remains simple
• Note: the base use case can still be executed without the use case
extension
• Extension points must be created explicitly in the base use

case
• Use sparingly: there is disagreement over the semantics
80
Use Case Diagrams – Generalizations

• Much like super-classes in a class diagram
• Need to satisfy “is-a” relation
• Applies to use cases and to actors

• A generalized use case represents several similar use cases
• One or more specializations provide details of the similar use cases
• Inheriting use case can replace steps of inherited use case
• Particularly useful for actors (clearer here, unlike use case
generalization where the semantics are unclear – use generalization of
use cases with caution)
81
Example: HR System
Update Medical Update Dental

Update
Plan Plan
Insurance Plan
<<include>> <<include>> <<include>>
Update Benefits
______________
Extension points extension point
benefit options: name and
after required enrollments location
Employee
<<extend>> <<extend>>
employee requests employee requests
reimbursement option stock purchase option
Elect
Elect Stock
Reimbursement extension
Purchase
for Healthcare condition
82
Use Case Templates (1)

• There are many different templates for use cases but they
often consist of a subset of the following items:
• Identifier: unique label for use case used to reference it
elsewhere
• Name: succinctly state user task independently of the
structure or implementation
• Suggested form “verb object” (e.g., Order a product)
• Authors: people who discovered use case
• Goal: short description of expected outcome from actors’
point of view
• Preconditions: what needs to be satisfied before use case
can begin
• Postconditions: state of system after completion of use case
• Minimal guarantee: state of system after completion regardless of
outcome
83
Use Case Templates (2)

• Primary actor: initiates the use case
• Participants (secondary actors): other actors involved in use
case, provide services to the system and interact with the
system after the use case was initiated
• Related requirements: identifiers of functional and non-
functional requirements linked to the use case
• Related use cases: identifiers of related use cases
• Specify relationship: e.g.
• Supposes use case UC2 has been successfully completed
• Alternative to use case UC3
• ...
• Description of events (scenarios)

• Different use case description formats
• Narrative, Simple column, Multiple columns
84
Use Case Templates – Narrative Form

• Paragraph focusing on the primary scenario and some
secondary ones
• Very useful when the stakeholders first meet
A User inserts a card in the Card reader slot. The System

asks for a personal identification number (PIN). The User
enters a PIN. After checking that the user identification is
valid, the System asks the user to chose an operation...
85
Use Case Templates – Simple Column Form

• Linear sequences (main and alternatives)
1. A User inserts a card in the Card reader slot.
2. The system asks for a personal identification number (PIN).
3. The User enters a PIN.
4. The System checks that the user identification is valid.
5. The System asks the user to chose an operation
1.a The Card is not valid.

1.a.1. The System ejects the Card.
4.a The User identification is not valid.
4.a.1 The System ejects the Card.
86
Use Case Templates – Multiple Column Form

• One column per actor
• Allows for a more detailed view
User's actions System responses

1. Insert a card in the Card reader 2. Ask for a personal
slot. identification number (PIN).
(card is not valid see alternative 1.1)
3. Enter a PIN. 4. Check that the user

identification is valid.
(identification is not valid see
alternative 4.1)
5. A sk User to chose an
operation
87
Use Case Development – Actors

• Choose actors’ names carefully
• Should reflect roles rather than actual people
• An actor specifies a role an external entity adopts when it interacts
directly with your system
• People / things may play multiple roles simultaneously or over time
• Use right level of abstraction
Poor act or nam e Good act or nam e
Clerk Pension Clerk
Third-level supervisor Sale supervisor
Data Entry Clerk #165 Product accountant
Eddie “The Dawg” Taylor Customer service representative
88
Use Cases Development (1)

• Heuristics for finding use cases
• Select a narrow vertical slice of the system (i.e., one scenario)
• Discuss it in detail with the user to understand the user’s preferred style of
interaction
• Could target high value or high risk first
• Select a horizontal slice (i.e., many scenarios) to define the scope of
the system
• Discuss the scope with the user
• Use illustrative prototypes (e.g., mock-ups) as visual support
• Find out what the user does
• Task observation (preferable to questionnaires)
89

• Alternative ways of identifying use cases (Ham, Larman)
• Identify external events to which the system must respond, and then
relate these events to participating actors and specific use cases
• Express business processes in terms of specific scenarios, generalize
the scenarios into use cases, and identify the actors involved in each
use case
• Derive likely use cases from existing functional requirements – if some
requirements do not trace to any use case, consider whether you
really need them
90

• Often one use case (or a very small number) can be identified
as central to the system
• The entire system can be built around this particular use case
• There are other reasons for focusing on particular use cases:

• Some use cases will represent a high risk because for some reason
their implementation is problematic
• Some use cases will have high political or commercial value
• Approach is iterative
• System scope and boundaries may change as more information is
known about actors, their goals, and use cases
91
Example: University Registration System (1)
Enroll in <<include>> Enroll in

Registrar University Course
<<extend>>
Applicant
Perform Enroll Family
Security Check Member of Staff
International Applicant
RCMP Security System
92

• Name: Enroll in University
• Identifier: UC 19
• Goal: Enroll applicant in the university
• Preconditions:
• The Registrar is logged into the system.
• The Applicant has already undergone initial checks to verify that they
are eligible to enroll.
• Postconditions:
• The Applicant will be enrolled in the university as a student if they are
eligible.
93

Main Flow:
• 1. An applicant wants to enroll in the university.
• 2. The applicant hands a filled out copy of form UI13 University Application Form
to the registrar.
• 3. The registrar visually inspects the forms.
• 4. The registrar determines that the forms have been filled out properly.
• 5. The registrar selects to Create New Student.
• 6. The system displays the Create Student Screen.
• 7. The registrar inputs the name, address, and phone number of the applicant.
• [Extension Point: XPCheck]
• 8. The system determines that the applicant does not already exist within the
system.
• 9. The system determines that the applicant is on the eligible applicants list.
• 10. The system adds the applicant to its records.
• 11. The registrar enrolls the student in courses via use case UC 17 Enroll in
Course.
• 12. The system prepares a bill for the applicant enrollment fees.
Alternate Flows:
• 4.a The forms have not been adequately filled…
94

• Name: Perform Security Check
At Extension Point XPCheck:

• 1. The registrar asks for security check results about
applicant.
• 2. The system asks RCMP Security System for applicant
security check results.
• 3. The RCMP Security System responds that applicant has
been cleared.
• 3.a The Security System responds that applicant has not
been cleared
95

• Name: Enroll Family Member of Staff
• Inherits From: UC 19
Main Flow:
• 1. An applicant family member wants to enroll in the
university.
• 2. The applicant hands a filled out copy of form UI15
University Application Form for Family Members to the
registrar.
•…
• 12. The system prepares a bill for the applicant enrollment
fees based on staff family members rate.
Alternate Flows: …
96
Use Case Development – Rules of Thumb (1)

• Be careful not to over specify behavior
• Keep it short, keep it simple: main flow should fit on a single page
• Focus on what, not how:
• Focus on externally visible behavior
• Are you specifying a sequence of events, in which the sequence does not
really matter?
• Example: Order of entering data for new customer
• Do you specify which elements from a set are selected, when any arbitrary
element is needed?
• Example: Selecting new arbitrary phone number
97

• Be careful not to under specify behavior
• Do not forget variations on basic flow
• Do not forget exceptions
• For example, what happens to a phone call if there are no resources to
allocate to it?
• Specify behavior for all possible inputs, both valid and invalid
input
98

• Keep names, data at an abstract level suitable for users
• For example, input and output events should have intuitive names
• Avoid data definition in use cases
• Use cases need to be understandable by users
• They must validate them
• Avoid functional decomposition

• Do not try to structure the use cases as nested functions with
«includes»
• Avoid deep hierarchies with «includes»
99

• Think of use cases before use case diagram
• Do not spend too much time on the use case diagram – the
textual description is the most important part
• Avoid too much use of "extends" and "includes" in use case
diagrams
• Do not describe the user interface
• You do not want too many use cases; if you have too many,
you have probably included too much detail
(“If in doubt, leave it out”)
• Do not attempt to describe everything – too many variations – too
many things that can go wrong
• The requirements specification captures a more complete picture
100
Benefits of Use Case-Based Software Development

• They can help to define the scope of the system
• They are often used to plan the development process
• They are used to both develop and validate the requirements

• Simple, easy to create
• All stakeholders understand them
• Often reflect user's essential requirements
• Separates normal behavior from exceptional behavior
• They can form the basis for the definition of test cases
• They can be used to structure user manuals
101
Use Cases are Not a Panacea…

• The use cases themselves must be validated
• Using the requirements validation methods
• Question/observe many types of users
• There are some aspects of software that are not covered by

use case analysis
• How to integrate non-functional requirements?
• Innovative solutions may not be considered
• Scalability and maintainability
• Others discussed by Stephen Ferg in “What's Wrong with

Use Cases”
102
Tools
• Many UML tools support use case diagrams, without really
supporting use cases well
• UCEd tool (Prof. Somé), to help capture/validate use cases

• Use Case edition (structured English)
• Domain model edition (and automatic extraction)
• Scenario edition
• Use Case & Domain model validation
• Use Cases combination in state models
• Simulation of executable model derived from Use Cases
• Scenario generation
• http://www.site.uottawa.ca/~ssome/Use_Case_Editor_UCEd.html
103
Use Case Edition with UCEd
Use Case
model edition Use Case
area description
edition area
Use Case model

(use case, extend,
include, actor…)
Use Case
description
104
Don’t be Negative, But…

• Be ready to face the music!
• In business, some people might wish to see you fail…
• There are unforeseen events in any project
• Open systems are subject to various threats
• Software contains various kinds of bugs
• Remember Murphy’s Law…

• “Anything that can go wrong will go wrong.”
105
Think about Negative Scenarios?

• A negative scenario is a scenario whose goal is
• Undesirable from the business organization’s viewpoint
• Desirable from a hostile agent’s viewpoint (not necessarily human)
• Consider them beforehand

• As well as potential solutions
• Or…
• Wait until it is too late to react…
106
Misuse Case
threatens
Drive Car Steal Car
Thief
• Proposed by Sindre et Opdahl (2000)

• Capture use cases that a system must be protected against
• Goal is to threaten the system
• Obvious applications for security and risk analysis
• The misuse case’s misactor is a hostile agent
• The colors of the ellipse are inverted
107
A MiniMax1 for Security

Drive the Car
threatens
includes Steal the Car
mitigates
Lock the Car includes
Driver threatens Car Thief
includes Short the Ignition
mitigates
Lock the Transmission
Use Cases for 'Car Security'

• Similar to a chess match…
• White’s best move is to find Black’s best move and to counter it
• New relations:
• threatens (from misuse case to use case)
• mitigates (from use case to misuse case)
[1] Minimax: minimizing the maximum possible loss
108
Finding Misuse Cases – Step 1

• Start from a normal use case diagram
• Find misactors (hostile roles)
• Who are the misactors, who want:
• To harm the system, its stakeholders, or their resources intentionally
or
• To achieve goals that are incompatible with the system's goals
Competitor
Crook
109

• Find misuse cases
• Ask what would a misactor do to harm system
• Express goals of misactors (if needed elaborate with scenarios)
• Add relationships (threaten)
Competitor
110

• Mitigate misuse cases
• Ask what would neutralize the threats
• New included use case, new extension use case, or new secondary
scenario to existing use case might be added
Competitor
111
Benefits and Risks of Misuse Cases

• Benefits
• Elicitation of security and safety requirements
• Early identification of threats, mitigations, and exceptions that could
cause system failure
• Early identification of test cases
• Documentation of rationales
• Risks
• Get into premature design solutions in step 3 (mitigation)
• Goal should be to find requirements (safety, security…)
• Missing misactors and threats in a partial view
112
Tool: DOORS Plug-in

• Scenario Plus (for Telelogic DOORS)
• Textual / Graphical output (HTML)
• Automatic links, metrics, etc.
• Upon referencing: automatic creation of use/misuse cases
• Automatic creation of links between misuse and use cases,

by searching for underlined use case names with simple
fuzzy matching
113
Conflict and Trade-off Analysis

Sabotage
threatens
Rogue Employee
Access the Services
threatens
aggravates
includes Frustrated by Controls
threatens
Service User mitigates Service User
includes
Control Loosely
threatens
aggravates
conflicts with
Denial-of-Service Attack
Security Officer aggravates
Control Strictly
mitigates
includes Intrude into System
Hacker
includesLog Access Attempts includes
mitigates
includes includes
Brute-Force Password Attack
Operate Firewall includes

mitigates
Attack Unblocked Ports
Recognize Users
mitigates
Impersonate Users
Use Cases for 'Web Portal Security'
• New relations: aggravates and conflicts with

114
Introduction to Requirements Analysis,
Specification and Modeling
Based on Powerpoint slides by Gunter Mussbacher (2009)

with material from:
Jo Atlee, Dan Berry (both University of Waterloo); R. Pressman;
D. Damian; Amyot 2008, Somé 2008
What is Requirements Analysis
• The process of studying and analyzing the customer and the
user needs to arrive at a definition of the problem domain
and system (including software) requirements
• Analysis goes hand-in-hand with modeling
2
Objectives of Requirements Analysis
• Detect and resolve conflicts between (user) requirements
• Negotiate priorities of stakeholders
• Prioritize and triage requirements (covered later)
• Elaborate system requirements,
• To be documented in the requirement specification document
• such that managers can give realistic project estimates
• and such that developers can design, implement, and test
• Classify requirements information into various categories and
allocate requirements to sub-systems
• Evaluate requirements for desirable qualities
• Make sure that nothing major is forgotten
3
Requirements Analysis
• Analysis and elicitation feed each other
Elicitation
Elicitation Questions and points

Notes to consider
Analysis Requirements Specification
4
Requirements Modeling
This is an essential task in specifying requirements
• Map elements obtained by elicitation to a more precise form
• Help better understand the problem
• Help find what is missing or needs further discussion
• Different modeling languages

• Informal:
natural language
• Goal-oriented modeling (GRL)
• Functional modeling:
UML (Unified Modeling Notation)
SDL (Specification and Description Language)
Logic, e.g. Z, temporal logic (CTL)
UCM (Use Case Maps)
...
5
Requirements Verification and Validation
• Need to be performed at every stage during the
(requirements) process
• Elicitation
• Checking back with the elicitation sources
• “So, are you saying that . . . . . ?”
• Analysis
• Checking that the domain description and requirements are correct
• Specification
• Checking that the defined system requirement will meet the user
requirements under the assumptions of the domain/environment
• Checking conformity to well-formedness rules, standards…
6
The Use of Models
Models
• According to Bran Selic, a model is a reduced representation
(simplified, abstract) of (one aspect of) a system used to:
• Help understand complex problems and / or solutions
• Communicate information about the problem / solution
• Direct implementation (especially in software)
• Qualities of a good model

• Abstract
• Understandable
• Accurate
• Predictive
• Inexpensive
8
Modeling Notations
• Natural language • Semi-formal notation (URN,
(English) UML...)
+ No special training + Syntax (graphics) well defined
required + Partial common understanding,
- Ambiguous, verbose, reasonably easy to learn
vague, obscure ... + Partial automation
- No automation - Meaning only defined informally
• Ad hoc notation (bubbles - Still a risk of ambiguities
and arrows)
• Formal notation (Logic, SDL,
+ No special training Petri nets, FSM ...)
required
+ Syntax & semantics defined
- No syntax formally defined
+ Great automation (analysis and
meaning not clear,
transformations)
ambiguous
- More difficult to learn & understand
- No automation
9
Modeling Notations (2)
• Informal language is better understood by all stakeholders
• Good for user requirements, contract
• But, language lacks precision
• Possibility for ambiguities
• Lack of tool support
• Formal languages are more precise

• Fewer possibilities for ambiguities
• Offer tool support (e.g., automated verification and transformations)
• Intended for developers
• Limited scope
Source (for decision table): Easterbrook and Callahan, 1997

10
Modeling Structure
Concepts of Entities and their Relationships. Use one of the
following notations:
• ERD (Entity Relationship Diagram – the traditional version)
• UML class diagrams
• Relational tables
• Can be used for the following
• Model of the problem domain (called “domain model”)
• The two versions: existing and to-be
• Model of input and output data structures of system-to-be
• Model of the stored data (database)
• not necessarily an image of the domain data
• Additional data is introduced (e.g. user preferences)
• Architectural design of the system-to-be
11
Modeling Inputs and Outputs
• Nature of inputs and outputs (IO):
• IO related to problem (problem data)
• Additional data related to solution (solution data)
• E.g., prompts, user options, error messages…
• Collected in Data Dictionary using
• Plain text (natural language)
• EBNF
• Code-like notations
• Logic (e.g., Z, B, CTL…)
• …
• Graphical output (screens, forms)
• Iconic (representational) drawings, prototype screens or forms,
printouts produced by operational prototype
12
Modeling Dynamic Behavior
• Behavior modeling techniques
• Text (plain, function statements, use cases)
• Decision tables
• Activity Diagrams / Use Case Maps
• Finite state machines
• Simple state machines (FSM) : use state diagrams or transition table
notation
• Extended state machines (e.g. UML State Machines – including SDL)
• Harel’s State Charts (concepts included in UML notation)
• Petri nets (allows for flexible concurrency, e.g. for data flow, similar to
Activitity Diagrams)
• Logic (e.g. Z, B, CTL) for describing input-output assertions and
relationships to internal object state that is updated by operations
• It is important to chose what best suits the problem
13
Model Analysis
• By construction
• We learn by questioning and describing the system
• By inspection
• Execute/analyze the model in our minds
• Reliable?
• By formal analysis
• Requires formal semantics (mathematical) and tools
• Reliable (in theory), but expensive (for certain modeling approaches)
• By testing
• Execution, simulation, animation, test...
• Requires well-defined semantics and execution/simulation tools
• More reliable than inspection for certain aspects
• Possible to interact directly with the model (prototype)
14
Typical Modeling Approaches
• Many approaches involve modeling to get a global picture of
the requirements
• Structured Analysis (1970)
• Object-Oriented Analysis (1990)
• Problem Frames (1995)
• State Machine-Based Analysis
• Conflict Analysis
• E.g. with mis-use cases or with GRL/UCM models and
strategies/scenarios
• It is important to distinguish between
• Notation used for defining the model
• Process defining a sequence of activities leading to a desired model
• Note: Analysis can be on individual requirements as well
• Remember tips and tricks on how to write better requirements
15
All models are false,
but some models are useful…
George Edward Pelham Box (1919-)
16
Non-Functional Requirements
and Quality Measures
with material from:

Jo Atlee, Dan Berry (both University of Waterloo); R. Pressman;
D. Damian; Amyot 2008, Somé 2008
Table of Contents
• Non-Functional Requirements and Software Quality

Attributes
• Software Quality
• Classifications of Non-Functional Requirements
• Quality Measures
• To measure is to know. If you cannot measure it, you cannot

improve it.1
[1] Lord Kelvin (1824 - 1907)
2
Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures
Software Quality (1)

• Most definitions require compliance with requirements
• “Conformance to explicitly stated functional and performance
requirements, explicitly documented development standards,
and implicit characteristics that are expected of all
professionally developed software.”1
• Implication:
• We need to be able to explicitly quantify requirements and verify that
any solution meets them
• We need measures
[1] Pressman, 1997

3
Software Quality (2)

• An interesting phenomenon:
Measurable objectives are usually achieved!
• Therefore, unless you have unrealistic values, requirements

are usually met
• Important to know what measures exist!
• The chosen values, however, will have an impact on the
amount of work during development as well as the number of
alternatives and architectural designs from which developers
may choose to meet the requirements
4
Types of Non-Functional Requirements (NFRs)
Non-functional
requir ements
Product Or ganizational External

requir ements requir ements requirements
Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements
Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements
Performance Space Privacy Safety

requirements requir ements requirements requirements
Source: Gerald Kotonya and Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998
5
Interesting Resources on Wikipedia

• ISO/IEC 9126 Software engineering — Product quality
• http://en.wikipedia.org/wiki/ISO/IEC_9126
• "ilities"
• http://en.wikipedia.org/wiki/Ilities
• Software Quality, and how to measure it

• http://en.wikipedia.org/wiki/Software_quality
6
ISO/IEC 9126 Qualities
Nowadays, more and more frequently replaced by: ISO/IEC 25000:2005

Software Engineering -- Software product Quality Requirements and Evaluation
(SQuaRE) -- Guide to SQuaRE
7
Quantification
• Non-functional requirements need to be measurable
• Avoid subjective characterization: good, optimal, better...
• Values are not just randomly specified

• Must have a rationale
• Stakeholder must understand trade-offs
• Important to rank and prioritize the requirements
• Precise numbers are unlikely to be known at the beginning of

the requirement process
• Do not slow down your initial elicitation process
• Ensure that quality attributes are identified
• Negotiate precise values later during the process
8
Measures vs. Metrics

• We use measures in a generic way but there is actually a
distinction between measures and metrics
• For example, consider availability:

• Metric: mean time between failures
• Measure: 23 days between failures (a specific observation!)
9
Performance Measures (1)

• Lots of measures
• Response time, number of events processed/denied in some interval
of time, throughput, capacity, usage ratio, jitter, loss of information,
latency...
• Usually with probabilities, confidence interval
• Can be modeled and simulated (mainly at the architectural

level) – performance prediction
• Queueing model (LQN), process algebra, stochastic Petri nets
• Arrival rates, distributions of service requests
• Sensitivity analysis, scalability analysis
10
Performance Measures (2)

• Examples of performance requirements
• The system shall be able to process 100 payment transactions per
second in peak load.
• In standard workload, the CPU usage shall be less than 50%.
• Production of a simple report shall take less than 20 seconds for 95%
of the cases.
• Scrolling one page up or down in a 200 page document shall take at
most 1 second.
11
Reliability Measures (1)

• Measure of the degree to which the system performs during a
request
• Ability to perform a required function under stated conditions for a
specified period of time
• Very important for critical, continuous, or scientific systems
• Can be measured using

• Defect rate
• Degree of precision for computations
12
Reliability Measures (2)

• Examples
• The precision of calculations shall be at least 1/106.
• The system defect rate shall be less than 1 failure per 1000 hours of
operation.
13
Availability Measures (1)

• Definition: Percentage of time that the system is up and
running correctly
• Probability that the system is up and running when needed!
• Can be calculated based on Mean-Time to Failure (MTBF)
and Mean-Time to Repair (MTTR)
• MTBF : Length of time between failures
• MTTR : Length of time needed to resume operation after a failure
• Availability = MTBF/(MTBF+MTTR)
• May lead to architectural requirements
• Redundant components (lower MTBF)
• Modifiability of components (lower MTTR)
• Special types of components (e.g., self-diagnostic)
• Modeling/Estimating availability
• e.g. Markov models
14
Availability Measures (2)

• Examples
• The system shall meet or exceed 99.99% uptime.
• The system shall not be unavailable more than 1 hour per 1000 hours
of operation.
• Less than 20 seconds shall be needed to restart the system after a
failure 95% of the time. (This is a MTTR requirement)
• Availability Downtime
• 90% 36.5 days/year
• 99% 3.65 days/year
• 99.9% 8.76 hours/year
• 99.99% 52 minutes/year
• 99.999% 5 minutes/year
• 99.9999% 31 seconds/year
15
Security Measures (1)

There are at least two measures:
1. The ability to resist unauthorized attempts at usage
2. Continue providing service to legitimate users while under denial of
service attack (resistance to DoS attacks)
• Measurement methods:
• Success rate in authentication
• Resistance to known attacks (to be enumerated)
• Time/efforts/resources needed to find a key (probability of finding the
key)
• Probability/time/resources to detect an attack
• Percentage of useful services still available during an attack
• Percentage of successful attacks
• Lifespan of a password, of a session
• Encryption level
16
Security Measures (2)

• Authentication, authorization, audit
• Detection mechanisms
• Firewall, encrypted communication channels
• Can also be modeled (logic ...)
• Examples of requirements
• The application shall identify all of its client applications before
allowing them to use its capabilities.
• At least 99% of intrusions shall be detected within 10 seconds.
17
Usability Measures (1)

In general, concerns ease of use and of training end users. The
following more specific measures can be identified:
• Learnability
• Proportion of functionalities or tasks mastered after a given training time
• Efficiency
• Acceptable response time
• Number of tasks performed or problems resolved in a given time
• Number of mouse clicks needed to get to information or functionality
• Memorability
• Number (or ratio) of learned tasks that can still be performed after not
using the system for a given time period
• Error avoidance
• Number of error per time period and user class
• Number of calls to user support
18
Usability Measures (2)

• Error handling
• Mean time to recover from an error and be able to continue the task
• User satisfaction
• Satisfaction ratio per user class
• Usage ratio
• Examples
• The system should enable at least 80% of users to book a guest within
5 minutes after a 2-hour introduction to the system.
• The system shall enable novice users to perform tasks X and Y in
less than 15 minutes.
• The system shall enable expert users to perform tasks X and Y in less
than 2 minutes.
• The satisfaction level of the system shall be “very good” or better for at
least 80% of customers polled after a 3 months usage period .
19
Maintainability Measures (1)

• Measures ability to make changes quickly and cost effectively
• Extension with new functionality
• Deleting unwanted capabilities
• Adaptation to new operating environments (portability)
• Restructuring (rationalizing, modularizing, optimizing, creating
reusable components)
• Can be measured in terms of
• Coupling/cohesion metrics, number of anti-patterns, cyclomatic
complexity
• Mean time to fix a defect, mean time to add new functionality
• Quality/quantity of documentation
• Measurement tools
• code analysis tools such as IBM Structural Analysis for Java
(http://www.alphaworks.ibm.com/tech/sa4j)
20
Maintainability Measures (2)

• Examples of requirements
• Every program module must be assessed for maintainability according
to procedure XYZ.
• 70% must obtain “highly maintainable” and none “poor”.
• The cyclomatic complexity of code must not exceed 7.
• No method in any class may exceed 200 lines of code.
• Installation of a new version shall leave all database contents and all
personal settings unchanged.
• The product shall provide facilities for tracing any database field to
places where it is used.
21
Testability Measures
Measures the ability to detect, isolate, and fix defects
• Time to run tests
• Time to setup testing environment (development and execution)
• Probability of visible failure in presence of a defect
• Test coverage (requirements coverage, code coverage…)
• Mechanisms for monitoring
• Access points and additional control
• Examples
• The delivered system shall include unit tests that ensure 100% branch
coverage.
• Development shall use regression tests allowing for full retesting in
less than 12 hours.
22
Portability Measures
Measure ability of the system to run under different computing
environments
• Hardware, software, OS, languages, versions, combination of these
• Can be measured as
• Number/Enumeration of targeted platforms (hardware, OS…)
• Proportion of platform specific components or functionality
• Mean time to port to a different platform
• Examples
• No more than 5% of the system implementation shall be specific to the
operating system.
23
Integrability and Reusability Measures

Integrability
• Measures ability to make separated components work together
• Can be expressed as
• Mean time to integrate with a new interfacing system
Reusability
• Measures ability that existing components can be reused in new
applications
• Can be expressed as
• Percentage of reused requirements, design elements, code, tests…
• Coupling of components
• Degree of use of frameworks
24
Robustness Measures
Measure ability to cope with the unexpected
• Percentage of failures on invalid inputs
• Degree of service degradation
• Minimum performance under extreme loads
• Active services in presence of faults
• Length of time for which system is required to manage stress conditions
• Examples
• The estimated loss of data in case of a disk crash shall be less than
0.01%.
• The system shall be able to handle up to 10000 concurrent users
when satisfying all their requirements and up to 25000 concurrent
users with browsing capabilities.
25
Domain-specific Measures
The most appropriate quality measures may vary from one
application domain to another, e.g.:
• Performance
• Web-based system:
Number of requests processed per second
• Video games:
Number of 3D images per second
• Accessibility
• Web-based system:
Compliance with standards for the blind
• Video games:
Compliance with age/content ratings systems (e.g., no violence)
26
Other Non-Functional Requirements

• What about NFRs such as “fun” or “cool” or “beautiful” or
“exciting”?
• How can these be measured?
• The lists of existing quality attributes are interesting but they

do not include all NFRs.
• It is sometimes better to let customers do their brainstorming
before proposing the conventional NFR categories.
• In any case, we must also refine those goals into measurable

requirements.
27
Dilbert on Quality
28
Requirements Modelling
with UML 2
with material from:

K.E. Wiegers, D. Leffingwell & D. Widrig, M. Jackson, I.K. Bray, B. Selic,
Volere, Telelogic, D. Damian, S. Somé 2008, D. Amyot 2008-2011, and
G.v. Bochmann 2010
Introduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram
History of UML (http://www.omg.org/uml/)

Rumbaugh
Booch Jacobson
http://www.omg.org/uml/
Official Version 2.4.1

(August 2011)
UML 2.5 Beta “simplified”:

831 pages!
Source: http://en.wikipedia.org/wiki/Unified_Modeling_Language
2
Dilbert on Standards
3
Thirteen Diagram Types in UML 2.x

• According to UML Reference Manual
• Structural
• Class, object, composite structure, component, and use case diagrams
• Dynamic (that is, describing dynamic behavior)
• State machine, activity, sequence, communication, timing, and interaction
overview diagrams
• Physical
• Deployment diagrams
• Model Management
• Package diagram
4
Most Relevant for Requirements Engineering

• Use case diagram
• Use cases structuring
• Class diagram
• Domain modeling
• Activity diagram
• Workflow and process modeling
• Concepts much related to concepts of Use Case Maps
• Sequence diagram
• Modeling of message exchange scenarios
• State machine diagram
• Detailed behavioral specification (of objects, protocols, ports…)
• System behaviour (black box)
5
Class Diagram
Entity-relationship modeling (ERM)

Entity-Relationship modeling (originally proposed by Peter Chen in 1976)
• Concepts:
• Entity: represents a type of entity instances, defines the properties that
hold for all such instances.
• Relationship: represents relationship instances that hold between
certain pairs of entity instances.
• The related entity types are also called roles.
• Multiplicity information indicate how many instances of the “other” side
may be related to a given instance of “this” side.
• Attribute: An entity or a relationship may have one or several
attributes. Each attribute is identified by a name and its type, where
such a type is usually some simple data type such as integer or
character string. Note: An entity type is normally not used as the type
of an attribute, because such a situation is rather represented by a
relationship between the given entity and the attribute type.
7
ERM – Notations
• There are a variety of notations that have been used for ERM
• Chen’s notation
8
UML Class Diagrams
9
Methodology for Object-Oriented Analysis (OOA)

• Five main steps
• Identify core classes within problem domain
• Model relationships between classes
• Class diagram
• Define the attributes associated with each class
• Determine relevant operations for each class
• Define the messages that may be passed between objects
• Interaction diagram, state machine diagram
10
Problems with Class Diagrams (1)

• Caution: OOA not always analysis
• Most OOA approaches actually address high-level design…
• Class diagrams can however be used for analysis, especially for the
description of domain concepts
• Further composition and decomposition problems

• Related requirements cannot all be assigned to a single component or
a single class
• One scenario may affect several classes at once
• OO modularization is not perfect either...
➔ Scattering and tangling effects - Motivation for aspect-oriented analysis
and design
11
Problems with Class Diagrams (2)
Scattering: design
Requirement1 (R1) elements to support R1
in many components
Requirement2 (R2) ComponentA
Requirement3 (R3) R1 elements
…
RequirementN (RN) ComponentB ComponentC ComponentD
R1 elements R1 elements R1 elements
ComponentF
Tangling: single
ComponentE R1 elements component has
elements for many
R2 elements requirements
R3 elements
RN elements
12
A Partial Solution – Aspects
intertype Aspect ClassA

declaration
F.R1 R1 elements
ClassG
Triggered
behavior R1 elements
(code)
advice ClassC
Predicate R1 elements
ClassB
R1 elements
pointcut ClassF
(identifies joinpoints
R1 elements
where advice is executed) R2 elements
R3 elements
RN elements
Terminology based on AspectJ: www.eclipse.org/aspectj

13
Activity Diagrams
Basic Notational Elements of Activity Diagrams

• Describe the
dynamic behavior
of a system as a
flow of activities
(workflow)
• Flow
• Sequence
• Alternative
• Parallel
• Note: in this diagram,

the data flow objects are
not shown. They may be
shown as boxes on the
control flow lines.
15
Partitions – Examples
16
Unique to Activity Diagrams

• Data flow modeling
• Conditions on parallelism (branches of an AND-fork)
• Can be captured in UCM with Synchronizing Stubs
• Constraints on action pins
• Integration with UML (including class diagrams and OCL)
17
Sequence Diagrams
Basic Notational Elements of Sequence Diagrams

• Describe the dynamic behavior as interactions between so-
called “participants” (e.g. agents, actors, the system, system
components). For each participant, there is a “lifeline”
participant
19
Lifelines and (A)synchronous Interactions

• Participants, shown using • Messages can be
lifelines, participate in the synchronous or
interaction sequence by asynchronous
sending / receiving
messages
20
Combined Fragments
• Allow multiple sequences to be represented in compact form
(may involve all participants or just a subset)
• Combined fragment operators
• alt, for alternatives with conditions
• opt, for optional behavior
• loop(lower bound, upper bound), for loops
• par, for concurrent behavior
• critical, for critical sections
• break, to show a scenario will not be covered
• assert, required condition
• ignore/consider(list of messages), for filtering messages
• neg, for invalid or mis-use scenarios that must not occur
• strict or seq, for strict/weak sequencing (WHAT IS THIS ?)
• ref, for referencing other sequence diagrams
21
Combined Fragments – Alternative

• Alternative (operator alt)
• Multiple operands (separated by
dashed lines)
• Each operand has guard condition
(no condition implies true)
• One will be chosen exclusively –
nondeterministically if more than one
evaluates to true
• Special guard: else
• True if no other guard condition is
true
22
Combined Fragments – Optional

• Optional (operator opt)
• To specify a
guarded behavior
fragment with no
alternative
• Special case of alt
• Equivalent to an alt
with two operands
• The first is the same
as the operand for
the opt
• The second is an
empty operand with
an else guard
23
Combined Fragments – Loop

• Loop (operator loop)
• Loop fragment may
execute multiple times
• At least executed the
minimum count
• Up to a maximum count
as long as the guard
condition is true (no
condition implies true)
minimum, maximum count
Source for Password Example: UML Reference Manual

24
Combined Fragments – Concurrency

• Concurrency (operator par)
• Two or more operands that execute in parallel
25
Concurrency Quiz – Part One!

• Is the interaction on the right a valid sequential trace that can
be generated from the interaction with the par combined
fragment on the left?
• No! The sequences of the two operands may be interleaved
but the ordering defined for each operand must be
maintained.
26
Nested Combined Fragments
27
State Machine Diagram
Basic Notational Elements of State Machine Diagrams

• Describe the dynamic behavior of an individual object (with
states and transitions)
29
Types of State Machines
on on
Lamp Lamp On
On print(”on”)
on/print(”on”) on
off off
off off
Lamp Lamp
Off Off
Mealy Automaton Moore Automaton
• UML allows both types to be mixed

30
Variables (“Extended” States)
on
ctr : Integer
Lamp On
on/ctr := ctr + 1
off
off
Lamp Off
31
Modeling Behavior
• In general, state machines are suitable for describing reactive
systems based or events
• Not appropriate to describe continuous systems (e.g.,
spacecraft trajectory control, stock market predictions)
threshold
time
32
UML State Machine Diagrams – Summary
Composite State
State
Initial
Pseudostate top
Trigger
Ready
Transition
stop /ctr := 0
Done
Final State Action
stop
33
Entry and Exit Actions
LampOn
e2
entry/lamp.on();
exit/lamp.off();
e1
34
Action Ordering
LampOn LampOff
off/printf(“to off”);
entry/lamp.on(); entry/lamp.off();
exit/printf(“exiting”); exit/printf(“exiting”);
Resulting action sequence:

off/printf(“needless”);
printf(“exiting”);
printf(“to off”);
printf(“exiting”);
lamp.off(); printf(“needless”);
lamp.off();
• Output actions: transition prefix

• Input actions: transition postfix
35
State Activity (Do)

• Creates a concurrent process that will execute until
• The action terminates, or
• We leave the state via an exit transition
“do” activity
Error
entry/printf(“error!”)
do/alarm.ring()
36
Guards (Conditions)
• Conditional execution of transitions
bid [value < 100] /reject
bid [value >= 200] /sell

Selling Happy
bid [(value >= 100) & (value < 200)] /sell
Unhappy
• Guards must not have side effects

37
Hierarchical State Diagrams

• Composed states, to manage complexity
LampOff
flash/ LampFlashing
entry/lamp.off()
FlashOn
off/ entry/lamp.on()
1sec/
1sec/
on/ on/
FlashOff
LampOn
on/
entry/lamp.off()
entry/lamp.on()
38
Group Transitions
Default transition to
Initial pseudostate
LampOff
flash/ LampFlashing
entry/lamp.off()
FlashOn
off/ entry/lamp.on()
1sec/
on/ 1sec/
FlashOff
LampOn
on/
entry/lamp.off()
entry/lamp.on()
Group transition
39
Completion Transition
• Triggered by a completion event
• Automatically generated when an embedded state machine terminates
Committing Completion transition

(without trigger)
Phase1
CommitDone
Phase2
40
Triggering Rules
• Many transitions can share the same triggering event
• When leaving, the most deeply embedded one takes precedence
• The event disappears whether it triggers a transition or not
LampFlashing
FlashOn
on/
off/
on/
FlashOff
41
Action Ordering – Composite States
S1 S2
exit/exS1 entry/enS2
/initS2
S11 E/actE S21
exit/exS11 entry/enS21
Action sequence on transition E:

exS11  exS1  actE  enS2  initS2  enS21
42
Orthogonal Regions
• Combine many concurrent perspectives – interactions across
regions typically done via shared variables
age financialStatus
Child
Poor
Adult
age financialStatus
Child Rich
Retiree
Poor
Adult
Retiree Rich
43
Semantics of Orthogonal Regions

• All mutually orthogonal regions detect the same events and
respond simultaneously (possibly interleaved)
legalStatus financialStatus
LawAbiding Poor
robBank/ robBank/
Outlaw Rich
44
Conclusion…
45
Requirements Triage and Negotiation

with material from:
K.E. Wiegers, D. Leffingwell & D. Widrig, M. Jackson, I.K. Bray, B. Selic,
Volere, Telelogic, D. Damian, S. Somé 2008, and D. Amyot 2008-2009
Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization
Requirements Negotiation (1)

• Possible conflicts to be resolved among stakeholders
• Between supplier and customers about costs, benefits, risks
• Power struggle within customer organization
• Conflicts with other projects about resources
• Conflicting goals, features, requirements
• ...
• Conflict resolution involves negotiation

• Negotiating a coherent set of requirements is not easy
• But it is one task of the requirements analyst
• Difficult to satisfy everyone, to achieve all goals, make good decisions!
• Involves a lot of (group) discussions
2
Requirements Negotiation (2)

• First, detect when requirements are inconsistent
• Then, convince all stakeholders to understand the essential

point of view of each other
• Have each party explain what they believe the other party wants and
why
• Finally, reach an agreement on a coherent set of

requirements that meets the needs of as many stakeholders
as possible
• Analyze each party’s goals, find solutions that do not conflict but
ideally support everybody’s goals
3
Let Schedule Drive Requirements (Not the Reverse)
“It Will
Take Us 9
“Okay, Here Are Our Months”
Requirements By When Can
You Build Them?”
“Sorry, They
Must Be
Completed in 6 Typical Scenario
Months”
NOW WHAT?
Source: Davis, A.: “Just Enough Requirements Management”, Dorset House, 2005; “The art of requirements triage”, IEEE Computer, 03/2003
4
Let Schedule Drive Requirements (Better Scenario)
“Let’s see. If
“Okay, we’re going to build in a we build reqts 1
series of 3 month increments. through 9 and
Here are all the requirements.” 12, we’ll be able
to do them in 3
months”
“But we
really need
reqt 17 in “Okay. How
that first about if we add
release.” reqt 17 and
drop reqt 12?”
5
Let Schedule Drive Requirements (Better Scenario)
“Well if we
“Hmmm. I really liked reqt
drop
12. Can we drop reqt 3
requirements 3
instead?.”
and 4, we could
do it.”
“Okay “Okay. How

” about if we add
reqt 17 and
drop reqt 12?”
Teamwork!!!
6
Requirements Negotiation – Key Aspects (1)

(by analogy with land negotiations)
• Territory: desired requirements
• The real requirements are those in the head of each stakeholder
• Map: requirements document
• An abstract model of intentions/requirements, imperfect and incomplete
• Interpretation of the map: included requirements
• May vary from one session to the next → need to be clear, precise, and
unambiguous
• Looking at the map through the magnifying glass: importance
• Each stakeholder has such a view about its requirements in the project
• For each stakeholder, see if a documented requirement is important,
conflicting, or optional
7
Requirements Negotiation – Key Aspects (2)

• Negotiating boundaries: counterproposals of stakeholders
• Reaction of a stakeholder (open, opposed, cooperative...) to a
documented requirement may indicate how far it is open for compromise
• Helps optimize the requirements of all stakeholders
• Can we be consistent? See techniques later on!
8
Difficulties (1)
• There are too many requirements!
• From many different sources
• Resources are limited (budget, time…)
• Establishing priorities is important, but

• Which requirements are important, and to whom?
• How to prioritize them? On what basis? What to minimize/maximize?
• In which iteration should the requirement be considered?
• Developers may not know the business value of some

requirements, and clients may not know the implementation
complexity of some requirements
9
Difficulties (2)
• Different stakeholders have different goals and different
priorities
• Some stakeholders’ decisions carry more weight than others
• Companies often lack systematic data, metrics, and

technologies to support the prioritization process
• Often done manually, informally, on an ad-hoc basis
• Difficult to establish and communicate
• Attitude!
• "No need for priorities, we can do everything in the specification!“
• Yes, but when and at what cost?
• Suddenly, when the deadline is fast approaching, some requirements
are put aside in order to deliver something on time...
10
Requirements Prioritization and Triage

• Requirements prioritization is also referred to as triage
• Need to decide which requirements really matter or on those
that need to be implemented in the current release
• Need for compromise, negotiation, priorities
• Prioritization is needed because there will almost always be
the need for trade-offs (e.g., required functionality vs. time
and resources)
• Must help:
• Make acceptable tradeoffs among goals of value, cost, time-to-market
• Allocate resources based on importance of requirements to the project
as a whole (project planning)
• Determine when a requirements should become part of the product
• Offer the right product!
11
80-20 Rule
• 20% of functionalities provide 80% of revenues
• Think of MS Word…
• The remaining 80% of functionalities offer a lower return on

investment while adding delays, development costs,
maintenance costs...
• How to find the most useful and beneficial 20% of

functionalities?
12
Which Sector Should We Focus On?
A lot!
R11
R10
R6
R9
R13
Value
R7
R3
R15 R8 R14
R1
R2 R12
R4 R5
To avoid!
R16
0
Cost A lot!
13
Requirements Triage Process

• Must be simple and fast, for industry adoption
• Must yield accurate and trustworthy results
• Must consider issues such as

• The value of requirements to stakeholder (maximize)
The cost of implementation (minimize)
Time to market (to minimize)
• Important to agree on requirements granularity

• E.g., use cases, features, detailed functional requirements
14
1st Technique – Prioritization Scales

• Determine criteria, granularity, scale dimensions
• Frequently used:
• Urgency
• High (mission critical requirement; required for next release)
• Medium (supports necessary system operations; required eventually but
could wait until a later release if necessary)
• Low (a functional or quality enhancement; would be nice to have someday
if resources permit)
• Importance
• Essential (product unacceptable unless these requirements are satisfied)
• Conditional (would enhance the product, but the product is acceptable if
absent)
• Optional (functions that may
or may not be worthwhile)
15
Prioritization Based on Cost and Value

• Calculate return on investment by
• Assessing the value of each requirement
• Assessing the cost of each requirement
• Calculating the cost-value trade-offs
• Difficulties:
• Hard to calculate absolute value/cost
• Relative value/cost figures are easier to obtain
• Interdependent requirements difficult to treat individually
• Inconsistencies or conflicts in priorities assigned by individual
stakeholders
16
2nd Technique – Wiegers’ Prioritization

• Semi-quantitative analytical approach to requirements
prioritization based on value, cost, and risk
• Relies on estimation of relative priorities of requirements
• Dimensions
• Relative benefit (for having requirement)
• Relative penalty to stakeholder (if requirement is not included)
• Relative cost (to implement requirement)
• Relative risk (technical and other risks)
• Each dimension is given a value on a given scale (e.g., 0..9)
• Dimensions have relative weights
• Formula used to derive overall priority
• priority = (value%) / ((cost% * cost weight) + (risk% * risk weight))
• Still limited by ability to properly estimate
• Requires adaptation and calibration
17
Wiegers’ Prioritization Example

• Chemical tracking system
Source: Wiegers, Karl E., First Things First: Prioritizing Requirements, http://www.processimpact.com/articles/prioritizing.html
Other Criteria to Consider

• Costs/benefits approach is good but sometimes insufficient
• The following criteria are not all applicable to all projects, but
they are there to be considered:
• Cost of implementation (how much does it cost to develop?)
• Value to customer (how much does the customer want it?)
• Time to implement (how much time does it take to deliver?)
• Ease of implementation at technical level
• Ease of implementation at the organizational level (business process)
• Value to company (how much will the business benefit?)
• Obligation to some external authority (laws, standards, patents…)
19
3rd Technique – Volere Prioritisation
Volere Prioritisation Spreadsheet

Copyright c The Atlantic Systems Guild 2002
Requirement/Product Use Factor - score %Weight Factor - score %Weight Factor - score out %Weight Factor - score %Weight Total
Number
Case/Feature out of 10 applied out of 10 applied of 10 applied out of 10 applied Weight
Minimise Ease of
Value to Value to Priority
40 20 Implementation 10 Implementati 30 100
Customer Business Rating
Cost on
Requirement 1 1 2 0.8 7 1.4 3 0.3 8 2.4 4.9
Requirement 2 2 2 0.8 8 1.6 5 0.5 7 2.1 5
Requirement 3 3 7 2.8 3 0.6 7 0.7 4 1.2 5.3
Requirement 4 4 6 2.4 8 1.6 3 0.3 5 1.5 5.8
Requirement 5 5 5 2 5 1 1 0.1 3 0.9 4
Requirement 6 6 9 4 6 1.2 6 0.6 5 1.5 6.9
Requirement 7 7 4 2 3 0.6 6 0.6 7 2.1 4.9
Requirement 6.9
• Editable Excel document

Source: Volere Prioritisation Analysis, http://www.volere.co.uk/prioritisationdownload.htm
20
Pairwise Comparisons (1)

• Finding scores and weights is difficult and subjective
• Potential solution: pairwise comparison
• Which requirements (A or B) is more important:
A << < = > >> B
• Benefits
• Indicates what is important to the client
• Identifies requirements of high value and low cost (priority!)
• Identifies requirements of low value and high cost (likely to be
removed)
• Has already been used to assist numerous corporate and government
decision makers
• Choosing a telecommunication system, formulating a drug policy, choosing
a product marketing strategy
21
Pairwise Comparisons (2)

• New problems
• Large number of pairs – pairwise comparison can be tedious
• Solved using transitivity and other tricks!
• Mathematical optimization of the number of pairs to be considered (no
need to cover all)
• Many dependencies between requirements
• Can actually be used to further reduce the # of pairs
• E.g., group many requirements as features, use cases, services…
• Example approach
• Analytic Hierarchy Process1
[1] Karlsson, J. and Ryan, K. A cost-value approach for prioritizing requirements, IEEE Software, Sept/Oct 1997
22
4th Technique – Analytic Hierarchy Process (AHP)

• Developed by Karlsson and Ryan (1997) based on work by
Saaty (early 1970)
• see also http://en.wikipedia.org/wiki/Analytic_Hierarchy_Process
• Use cost-value diagrams to analyze and discuss candidate
requirements
• Useful for requirements triage and release planning (but also
applicable in many other situations where complex decisions
are to be made)
• Basic procedure for rating a set of criteria

• Develop pairwise comparison matrix of each criterion
• Normalize the matrix
• Average the value of each row to get corresponding rating
• Criterion ratings are then used to evaluate different potential
decisions 23
Basic Rating Procedure (1)

• Pairwise comparison rating scale
• Values 2, 4, 6, or 8 represent preferences halfway between

the integers on either side
24

• Suppose two criteria, cost and quality, for product A & B
• The cost for A is $60 and the quality is above average.
• The cost for B is $15 and the quality is right at average.
• Which product do you choose?
• The matrix describes that the price of B is very strongly

preferred over A and A is only moderately preferred over B
25

• Suppose three products with the following pairwise
comparison (for one given criteria)
26

• Normalize the matrix
• First add up all the
values in each
column
• Next the values in

each column are
divided by the
corresponding
column sums
• Note: the values
in each column
add up to 1
27

• Average the value of each row to get corresponding rating
28
Analytic Hierarchy Process – Steps

• Requirements engineers check individual requirements for
ambiguities, completeness…
• Apply AHP’s pairwise comparison to estimate the relative
value of candidate requirements
• Experienced software engineers use AHP’s pairwise
comparison to estimate the cost of candidate requirements
• Plot these values on a cost-value diagram
• Stakeholders use this diagram for analysis and to make
trade-offs
29
Analytic Hierarchy Process – Example (1)
30
Analytic Hierarchy Process – Example (2)

• Cost-value diagram
31
Analytic Hierarchy Process – Stakeholders (1)

• Each client is unique!
• Each stakeholder group may have a different weight
• Process uses a weighting criteria to consider each individual
stakeholder group
• Example (stakeholders M1 to M10 are different markets)

• Revenue last release
• Profit last release
• Number of sold licenses last release
• Predictions of the above criteria for the coming release
• Number of contracts lost to competitors
• Number of potential customer with nil licenses to date
• Size of total market segment
• Growth potential
32

• Before adjustment based on stakeholders importance
Source: Damian, 2005

33

• After adjustment based on stakeholders importance
Source: Damian, 2005

34
Example of Commercial Tool

• IBM Rational (formerly Telelogic) Focal Point
• Decision support, portfolio management
• Pairwise comparisons of features
• Creation and validation of web questionnaires
• Dynamic algorithm for reducing the number of pairs, according to the
responses
• Detection of inconsistency between the answers
• Priorities
• For different markets
• Represented in various different ways
• Integration with DOORS
• http://www-01.ibm.com/software/awdtools/focalpoint/
35
Requirements Prioritization Model
Karl Wiegers
This spreadsheet contains a simple model for estimating the relative priorities of implementing
specific features or requirements in a software system. The "Example" worksheet contains an
example, from a project called the Chemical Tracking System. The worksheet called
"Template" contains several blank rows that contain all the formulas. To use this tool, copy
the "Template" worksheet into a new spreadsheet file and enter your own items to be prioritized,
copying and inserting blank rows as necessary to get enough space to handle all the items you
wish to prioritize in one pass.
The priority is considered to be a function of how desirable it is to include a specific feature

(where desirability considers both the benefit the feature would provide to the customer, and
the penalty you might incur in the customer's eyes if the feature is omitted), and both the
relative cost and technical risk associated with implementing the feature. Every proposed feature
is rated for each of the four dimensions (benefit, penalty, cost, risk) on a relative scale
of 1-9 (9 is high). You can also adjust the weighting factors for each of these four dimensions. For example,
if you feel that benefit is twice as important as penalty, which is the same importance as cost,
but risk is only half as important as cost, then you would use weighting factors (in row 1 of the
example) of 2, 1, 1, and 0.5, respectively.
After entering the relative numbers for all the features, the relative priority for each
feature is calculated by considering the percentage of the weighted feature desirability
(or value), cost, and risk attributable to each feature. If you sort the list of features
descending by the "Priority" column, the top priority items are at the top of the list.
You would not use this approach to estimate priorities for features that you know must be included,
for any reason (political, competitive advantage, regulatory or contractual requirement, etc.). Only
use this tool as a way to differentiate among requirements that are not on the list of "absolutely
must do"s.
The "Multiple Stakeholders" worksheet illustrates a refinement of the basic spreadsheet that accommodates
multiple stakeholders or user classes who have different ideas about requirement priorities. This example
handles three stakeholders. Each stakeholder has a separate pair of columns for rating benefit and penalty.
The numbers in row 1 indicate the relative weight that each stakeholder gets in the decision-making process.
Favored user classes get higher weighting factors. The spreadsheet incorporates those weights when it
calculates the overall benefit and penalty numbers for each proposed requirement. You can experiment
with the benefit and penalty values, and the weighting factors, in this worksheet to see the effect of different
stakeholder evaluations on the calculated priority numbers.
This spreadsheet is Copyright © 2002 by Karl E. Wiegers.

Permission is granted to use, modify, and distribute this spreadsheet file.
More information about the model can be found in Software Requirements by Karl E. Wiegers,
Microsoft Press 1999 (Second Edition due in 2003)
Requirements Verification and
Validation
Based on Powerpoint slides by Gregor v. Bochmann, Gunter Mussbacher

with material from:
G. Kotonya and I. Sommerville, M. Jackson, P. Heymans,
S. Somé 2008, and D. Amyot 2008
Table of Contents
• Introduction to Requirements Verification and Validation
• Requirements Verification and Validation Techniques
• Simple checks
• Prototyping
• Functional test design
• User manual development
• Reviews and inspections
• Model-based (formal) Verification and Validation
• The software is done. We are just trying to get it to work…1

[1] Anonymous
2
3
Introduction Simple Checks Prototyping Functional Test Design User Manual Formal V&V Reviews and Inspections
Requirements Verification and Validation

• Requirements Validation
• Check that the right product is being built
• Ensures that the software being
developed (or changed) will satisfy its
stakeholders
• Checks the software requirements specification
against stakeholders goals and requirements
• Requirements Verification
• Check that product is being built right
• Ensures that each step followed in the process of
building the software yields the right products
• Checks consistency of the software requirements
specification artefacts and other software
development products (design, implementation, ...)
against the specification
4
Requirements Verification and Validation (2)

• Help ensure delivery of what the client wants
• Need to be performed at every stage during the
(requirements) process
• Elicitation
• Checking back with the elicitation sources
• “So, are you saying that . . . . . ?”
• Analysis
• Checking that the domain description and requirements are correct
• Specification
• Checking that the defined system requirement will meet the user
requirements under the assumptions of the domain/environment
• Checking conformity to well-formedness rules, standards…
5
Introduction Simple Checks Prototyping Functional Test Design
1 User Manual Formal V&V Reviews and Inspections
The World and the Machine
(or the problem domain and the system) These 6 slides are taken from Introduction to Analysis
Specification (S)
⚫ Domain
properties (D)
these are assumptions problem solution
about the environment
interface
domain system
of the system-to-be
Hardware (C)
⚫ Requirements (R)
Software (P)
• Validation question (do we build • Verification question (do we

: if the domain-to-
the right system?) : if the
build the system right?)
be (excluding the system-to- hardware has the properties
be) has the properties D, and H, and the software has the
the system-to-be has the properties P, then the
properties S, then the system requirements S will
requirements R will be be satisfied.
satisfied. C and P  S
D and S  R • Conclusion:
D and C and P  R
[1] M. Jackson, 1995
6
Example
• Requirement
• (R) Reverse thrust shall only be enabled
when the aircraft is moving on runway.
• Domain Properties
• (D1) Deploying reverse thrust in mid-flight
has catastrophic effects.
• (D2) Wheel pulses are on if and only if wheels are turning.
• (D3) Wheels are turning if and only if the plane is moving on the
runway.
• System specification
• (S) The system shall allow reverse thrust to be enabled if and only if
wheel pulses are on.
• Does D1 and D2 and D3 and S  R?
• Are the domain assumptions (D) right? Are the requirement (R) or
specification
based on P. Heymans, 2005 (S) what is really needed?
7
Requirement specifications including assumptions
• Often the requirements for a system-to-be include
assumptions about the environment of the system.
• The system specification S, then, has the form:
S=AG
where A are the assumptions about the environment and G
are the guarantees that the system will provide as long as
A hold.
• If these assumptions (A) are implied by the known properties
of the domain (D), that is D  A, and we can check that the
domain properties (D) and the system guarantees (G) imply
the requirements (R), that is D and G  R, then the
“validation condition” D and S  R is satisfied.
8
Specification with assumptions and guarantees (example)
Example: A power utility provides electricity to a client. The
problem is that the monthly invoice is not related to the
electricity consumption, because there is no information
about this consumption.
• Idea of a solution: introduce an electricity counter.
• Specification of the electricity counter
• Inputs and outputs
• input power from utility (voltage, current) – voltage supplied by
utility
• output power to client (voltage, current) – current used by client
• Reset button (input)
• consumption (output - watt-hours of electricity consumption)
9
Example (suite)
• Assumptions
• Input voltage < 500 Volts (determined by utility)
• Output current < 20 Amps (determined by client)
• Guarantees
• Output voltage = input voltage
• Input current = output current
• Consumption output shall indicate the consumption since the last
reset operation, that is, the integral of (output voltage x output
current) over the time period from the occurrence of the last reset
operation to the current time instant.
• Software example
• Specification of a method providing the interface “List search(Criteria c.
Assumption: c is a data structure satisfying the Criteria class properties.
Guarantee: the returned result is a list satisfying the List class properties and
includes all items from the database that satisfy c.
10
Formal Verification and Validation

• Evaluating the satisfaction of “D and S  R” is difficult with
natural language
• Descriptions are verbose, informal, ambiguous, incomplete...
• This represents a risk for the development and organization
• Verification of this “validation question” is more effective with
formal methods (see below)
• Based on mathematically formal syntax and semantics
• Proving can be tool-supported
• Depending on the modeling formalism used, different

verification methods and tools may be applied. We call this
“Model-Based V&V”
• In the case of the aircraft example above, we used Logic to write down
statements about the model. This is a particular case of modeling
formalism.
11
V&V vs. Analysis

• Both have several activities in common
• Reading requirements, problem analysis, meetings and discussions...
• Analysis works with raw, incomplete requirements as elicited

from the system stakeholders
• Develop a software requirements specification document
• Emphasis on "we have the right requirements"
• Requirements V&V works with a software requirements

specification and with negotiated and agreed (and
presumably complete) domain requirements
• Check that this these specifications are accurate
• Emphasis on "we have the right requirements well done"
12
Requirements V&V Techniques
Various Requirements V&V Techniques

• Simple checks
• Traceability, well-written requirements
• Prototyping
• Functional test design
• User manual development
• Reviews and inspections
• Walkthroughs
• Formal inspections
• Checklists
• Model-Based V&V
• First-order logic
• Behavioral models
14
Simple Checks
• Various checks can be done using traceability techniques
• Given the requirements document, verify that all elicitation notes are
covered
• Tracing between different levels of requirements
• Checking goals against tasks, features, requirements…
• Involves developing a traceability matrix
• Ensures that requirements have been taken into consideration (if not
there should be a reason)
• Ensures that everything in the specification is justified
• Verify that the requirements are well written (according to the

criteria already discussed)
15
Prototyping (1)
• Excellent for validation by users and customers
• More accessible than specification
• Demonstrate the requirements and help stakeholders discover
problems
• Come in all different shapes and sizes

• From paper prototype of a computerized system to formal executable
models/specifications
• Horizontal, vertical
• Evolutive, throwaway
16
Prototyping (2)
• Important to choose scenarios or use cases for elicitation
session
• Prototyping-based validation steps

• Choose prototype testers
• Develop test scenarios
• Careful planning is required to draw up a set of test scenarios which
provide broad coverage of the requirements
• Users should not just play around with the system as this may never
exercise critical system features
• Execute test scenarios
• Document problems using a problem reporting tool
17
Comment on next two techniques
• The two V&V techniques, namely Functional Test Design and
User Manual Development, are not really V&V techniques.
• They are activities that must be performed anyway, and they
are based on the specification document.
• Through these activities, as for any other activities based on the
specification document, errors and other problems with this document
may be detected.
18
Functional Test Design

• Functional tests at the system level must be developed
sooner or later...
• Can (and should) be derived from the requirements specification
• Each (functional) requirement should have an associated test
• Non-functional (e.g., reliability) or exclusive (e.g., define what should
not happen) requirements are harder to validate with testing
• Each requirements test case must be traced to its requirements
• Inventing requirements tests is an effective validation technique
• Designing these tests may reveal errors in the specification
(even before designing and building the system)!
• Missing or ambiguous information in the requirements description may
make it difficult to formulate tests
• Some software development processes (e.g., agile methods)
begin with tests before programming ➔ Test-Driven
Development (TDD)
19
User Manual Development

• Same reasoning as for functional test design
• Has to be done at some point
• Reveals problems earlier
• Forces a detailed look at requirements
• Particularly useful if the application is rich in user interfaces /
for usability requirements
• Typical information in a user manual

• Description of the functionality
• How to get out of trouble
• How to install and get started with the system
20
Reviews and Inspections (1)

• A group of people read and analyze requirements, look for
potential problems, meet to discuss the problems, and agree
on a list of action items needed to address these problems
• A widely used requirements validation technique

• Lots of evidence of effectiveness of the technique
• Can be expensive
• Careful planning and preparation
• Pre-review checking
• Need appropriate checklists (must be developed if necessary and
maintained)
21

• Different types of reviews with varying degrees of formality
exist (similar to JAD vs. brainstorming sessions)
• Reading the document
• A person other than the author of the document
• Reading and approval (sign-off)
• Encourages the reader to be more careful (and responsible)
• Walkthroughs
• Informal, often high-level overview
• Can be led by author/expert to educate others on his/her work
• Formal inspections
• Very structured and detailed review, defined roles for participants,
preparation is needed, exit conditions are defined
• E.g., Fagan Inspection
22

• Different types of reviews (cont’d)
• Focused inspections
• Reviewers have roles, each reviewer looks only for specific types of errors
• Active reviews
• Author asks reviewer questions which can only be answered with the help
of the document to be reviewed
23
Typical Review / Inspection Steps (1)

• Plan review
• The review team is selected and a time and place for the review
meeting is chosen
• Distribute documents
• The requirements document is distributed to the review team members
24

• Prepare for review
• Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards, and other problems
• Hold review meeting
• Individual comments and problems are discussed and a set of action
items to address the problems is established
25

• Follow-up actions
• The chair of the review checks that the agreed action items have been
carried out
• Revise document
• Requirements document is revised to reflect the agreed action items
• At this stage, it may be accepted or it may be re-reviewed
26
Review Team
• Reviews should involve a number of stakeholders drawn from
different backgrounds
• People from different backgrounds bring different skills and knowledge
to the review
• Stakeholders feel involved in the RE process and develop an
understanding of the needs of other stakeholders
• Review team should always involve at least a domain expert and a
user
27
Review – Problem Categorization

• Requirements clarification
• The requirement may be badly expressed or may have accidentally
omitted information which has been collected during requirements
elicitation
• Missing information
• Some information is missing from the requirements document
• Requirements conflict
• There is a significant conflict between requirements
• The stakeholders involved must negotiate to resolve the conflict
• Unrealistic requirement
• The requirement does not appear to be implementable with the
technology available or given other constraints on the system
• Stakeholders must be consulted to decide how to make the
requirement more realistic
28
Pre-Review Checking
• Reviews can be expensive because they involve many
people over several hours reading and checking the
requirements document
• We can reduce this cost by asking someone to make a first
pass called the pre-review
• Check the document and look for straightforward problems such as
missing requirements (sections), lack of conformance to standards,
typographical errors, etc.
29
Fagan Inspection (1)

• Formal and structured inspection process
Note: the boss is not

involved in the process!
30

• Characterized by rules on who should participate, how many
reviewers should participate, and what roles they should play
• Not more than 2 hours at a time, to keep participants focused
• 3 to 5 reviewers
• Author serves as the presenter of the document
• Metrics are collected
• Important: the author’s supervisor does not participate in the inspection
and does not have access to data
• This is not an employee evaluation
• Moderator is responsible for initiating the inspection, leading the
meeting, and ensuring issues found are fixed
• All reviewers need to prepare themselves using checklists
• Issues are recorded in special forms
31

• The inspection meeting is like a brainstorming session to
identify (potential) problems
• Re-inspection if > 5% of the document change
• Some variants are less tolerant... too easy to introduce new errors
when correcting the previous ones!
32
Active Review
• Reviewer is asked to use the specification

• Author poses questions for the reviewer to
answer that can be answered only by
reading the document
• Author may also ask reviewer to simulate a
set of scenarios
33
Requirements Review Checklists (1)

• Essential tool for an effective review process
• List common problem areas and guide reviewers
• May include questions an several quality aspects of the document:
comprehensibility, redundancy, completeness, ambiguity, consistency,
organization, standards compliance, traceability ...
• There are general checklists and checklists for particular
modeling and specification languages
• Checklists are supposed to be developed and maintained
• See example on course website
34

• Sample of elements in a requirements review checklist
• Comprehensibility – can readers of the document understand what the
requirements mean?
• Redundancy – is information unnecessarily repeated in the
requirements document?
• Completeness – does the checker know of any missing requirements
or is there any information missing from individual requirement
descriptions?
• Ambiguity – are the requirements expressed using terms which are
clearly defined? Could readers from different backgrounds make
different interpretations of the requirements?
• Consistency – do the descriptions of different requirements include
contradictions? Are there contradictions between individual
requirements and overall system requirements?
35

• Sample of elements (cont’d)
• Organisation – is the document structured in a sensible way? Are the
descriptions of requirements organised so that related requirements
are grouped?
• Conformance to standards – does the requirements document and
individual requirements conform to defined standards? Are departures
from the standards justified?
• Traceability – are requirements unambiguously identified? Do they
include links to related requirements and to the reasons why these
requirements have been included?
36
Comments on Reviews and Inspections

• Advantages
• Effective (even after considering cost)
• Allow finding sources of errors (not only symptoms)
• Requirements authors are more attentive when they know their work
will be closely reviewed
• Encourage them to conform to standards
• Familiarize large groups with the requirements (buy-in)
• Diffusion of knowledge
• Risks
• Reviews can be dull and draining (need to be limited in time)
• Time consuming and expensive (but usually cheaper than the
alternative)
• Personality problems
• Office politics…
37
Requirements Inspection Checklist
1. Do requirements exhibit a clear distinction between functions and data?
2. Do requirements define all the information to be displayed to users?
3. Do requirements address system and user response to error conditions?
4. Is each requirement stated clearly, concisely, and unambiguously?
5. Is each requirement testable?
6. Are there ambiguous or implied requirements?
7. Are there conflicting requirements?
8. Are there areas not addressed in the SRS that need to be?
9. Are performance requirements (such as response time, data storage

requirements) stated?
10. If the requirements involve complex decision chains, are they expressed in
a form that facilitates comprehension (i.e., decision tables, decision trees,
etc.)?
11. Have requirements for performing software upgrades been specified?
12. Are there requirements that contain an unnecessary level of design detail?
13. Have the real-time constraints been specified in sufficient detail?
14. Has the precision and accuracy of calculations been specified?
15. Is it possible to develop a thorough set of tests based on the information

contained in the SRS? If not, what information is missing?
16. Have Assumptions and Dependencies been clearly stated?
17. Does the document contain all the information called out in the outline for
the SRS?
Requirements Management
Based on material from:

Kotonya & Sommerville, Z. Zhang, IBM and Telelogic,
S. Somé 2008, and D. Amyot 2008-2009
Table of Contents
• Introduction to Requirements Management
• Traceability
• Baselines
• Change Management
• Requirements Management Tools
• A factor present in every successful project and absent in

every unsuccessful project is sufficient attention to
requirements.1
[1] Suzanne & James Robertson, “Requirements-Led Project Management”, Addison-Wesley, 2004
2
Introduction to Requirements
Management
Introduction Traceability Baselines Change Management Requirements Management Tools
Why Do Requirements Change?

• Change in software development: as inevitable as difficult to
control!
• Better understanding: new requirements become apparent
• Everything else is changing…
• Business
• Context
• Technologies
• Markets
• …
• Possible responses to change
• Add, modify, or remove requirements
4
Some Problems Due to Changing Requirements

• Requirements changing towards the end of development
without any impact assessment
• Unmatched/outdated requirements specifications causing

confusion and unnecessary rework
• Time spent coding, writing test cases or documentation for

requirements that no longer exist
5
Requirements Management
• A systematic approach to eliciting, organizing, and
documenting the requirement of the system, and a process
that establishes and maintains agreement between the
customer and the project team on the changing requirements
of the system.1
[1] Leffingwell & Widrig 1999, p.16

6
Requirements Management Activities (1)

• Requirements management includes all activities intended to
maintain the integrity and accuracy of expected requirements
• Manage changes to agreed requirements
• Manage changes to baseline (increments)
• Keep project plans synchronized with requirements
• Control versions of individual requirements and versions of
requirements documents
• Manage relationships between requirements
• Managing the dependencies between the requirements document and
other documents produced in the systems engineering process
• Track requirements status
7
Requirements Management Activities (2)
Requirements
Management
Change control Version control Requirements Requirements

status tracking tracing
⚫ Proposing ⚫ Defining a version ⚫ Defining a ⚫ Defining links to
changes identification possible other
scheme requirement requirements
⚫ Analyzing impact
statuses
⚫ Identifying ⚫ Defining links to
⚫ Making decisions
requirements ⚫ Recording the other system
⚫ Updating document status of each elements
requirements versions requirement
documents
⚫ Identifying ⚫ Reporting the
⚫ Updates plans individual status distribution
requirement of all
⚫ Measuring
versions requirements
requirements
volatility
Source: Wiegers, 1999

8
Requirements Development (RD) and Management (RM)
Source: Wiegers, 1999

9
From Management to Tools

• Changes lead to a need for management
• There is no management without:
• Traceability
• Baselines enabling comparisons
• From a practical point of view, there is no traceability or
management without appropriate tools
In theory, practice and theory are similar…

But in practice they are different ☺
10
Requirements Change Factors (1)

• Requirements errors, conflicts, and inconsistencies
• May be detected at any phase (when requirements are analyzed,
specified, validated, or implemented)
• Evolving customer/user knowledge of the system
• When the requirements are developed, customers/users
simultaneously develop a better understanding of what they really
need
• Technical, schedule, or cost problems
• Difficult to plan and know everything in advance
• We may have to revisit the list of requirements and adapt it to the
current situation
11
Requirements Change Factors (2)

• Changing customer priorities, new needs
• May be caused by a change in the system environment (technological,
business, political...), i.e., the context
• Business and strategic goals may change
• May be caused by the arrival of a new competitor
• Laws and regulations may change
• Collaborating systems may change
• May also be caused by technology changes in the enterprise
(migration to a new operating system, DBMS…)
• May be caused by organizational changes (organizational structure,
business processes, employees…)
12
Requirements Volatility
• Requirements continuously change
• While the requirements are being elicited, analyzed, specified, and
validated and after the system has gone into service
• Some requirements are usually more subject to change than
others
• Stable requirements are concerned with the essence of a system and
its application domain
• Derived from the client’s principal business activities or the domain model
• They change more slowly than volatile requirements
• E.g., a hospital will always have doctors, nurses, patients…
• Volatile requirements are specific to the instantiation of the system in a
particular environment for a particular customer at a particular time
• E.g., in a hospital, we can think of requirements related to the policies of
the government health system
13
Types of Volatile Requirements

• Mutable requirements
• These are requirements which change because of changes to the
environment in which the system is operating
• Emergent requirements
• These are requirements which cannot be completely defined when the
system is specified but which emerge as the system is designed and
implemented
• Consequential requirements
• These are requirements which are based on assumptions about how
the system will be used
• Once the system is in place, some of these assumptions will be wrong
• Compatibility requirements
• These are requirements which depend on other equipment,
technology, or processes
14
Expectations of Requirements Management (1)

• Identification of individual requirements
• Traceability from highest level requirements to

implementation
• Established via links through a requirements database
• Links between requirements and design models, tests, code…
• Coverage and consistency analysis
• What are the traceability policies? What types of links? From where?
To where?
• Impact assessments of proposed changes

• Analysis tools let you see which other requirements (and other linked
artifacts) will be affected by a change
15
Expectations of Requirements Management (2)

• Controlled access to current project information
• A shared database ensures that all users are working with current data
(consistency, parallel access)
• A central repository allows all users to see the information that they
need to see (visibility)
• Change control
• Change proposal system implements controlled process for managing
change
• How do we collect, document, and address changes?
• Deployment of required tool support

• To help manage requirements change
16
Identification of Requirements
• It is essential for requirements management that every
requirement has a unique identification
• The most common approach is requirements numbering based on
chapter/section in the requirements document
• There are several problems with this approach
• Numbers cannot be unambiguously assigned until the document is
complete
• Assigning chapter/section numbers is an implicit classification of the
requirements ➔ may mislead readers of the document into thinking
that the most important relationships are with requirements in the
same section
17
Requirements Identification Techniques

• Dynamic renumbering
• Some word processing systems allow for automatic renumbering of
paragraphs and the inclusion of cross references
• As you reorganise your document and add new requirements, the
system keeps track of the cross references and automatically
renumbers your requirements depending on its chapter, section, and
position within the section
• Database record identification
• When a requirement is identified, it is entered in a requirements
database and a database record identifier is assigned which is then
used for all subsequent references to the requirement
• Symbolic identification
• Requirements can be identified by giving them a symbolic name which
is associated with the requirement itself (e.g., SEC1, SEC2, SEC3…
may be used for requirements which relate to system security)
18
BTW, Requirements Have Attributes!

• Apart from an identifier, requirements should have attributes
that establish context and background, and go beyond the
requirement description
• For filtering, analysis, metrics…
• Creation date, Last update, Author, Stakeholders (Owners / Source)
• Version number
• Status, Priority, Importance, Stability
• Rationale, Comments
• Acceptance criteria
• Subsystem / Product release number
• …
• The more complex the project, the richer the attributes…
• Many attributes are predefined in RM tools, others are
defined by requirements engineers as required by the project
19
Requirements Attributes
• Classes and attributes of a requirements management
database
SYS_MODELS RE QUIREMENT SOURCE_LIST

Model: MODEL Identifier: TEXT People: TEXT
Description: TEXT Statement: TEXT | GRAPHIC Documents: TEXT
Next: MODEL | NULL Date_entered: DATE Reqs: REQ_LIST
Date_changed:DATE
Sources: SOURCE_LIST
RE Q_LIST Rationale: REQ_RATIONALE RE Q_RATIONALE
Status: STATUS
Req: REQUIREMENT Dependents: REQ_LIST Rationale: TEXT
Description: TEXT Is_dependent_on: REQ_LIST Diagrams: GRAPHIC
Next: REQUIREMENT Model_links: SYS_MODELS Photos: PICTURE
| NULL Comments: TEXT
• Select only the necessary attributes!
20
Requirements Statuses
• Help manage the requirement lifecycle
• Their number and nature depend on the process in place
• Example of a set of statuses:
• Proposed: by some stakeholder
• Approved: part of baseline, committed to implement
• Rejected: after evaluation
• Implemented: designed and implemented
• Verified: Relevant tests have passed
• Deleted: Removed from list
• RM includes amongst its tasks the tracking of the status of all
requirements during the project
21
Version Control
• Another essential aspect of requirements management
• Every version of a requirement needs to be uniquely identified
• The last version of a requirement must be available to all team
members
• Changes need to be documented and clearly communicated
• A version identifier must be updated with every change to the
requirement
• Requirements documents should include
• A revision history: changes, dates, by whom, why...
• Standard markers for revisions (e.g., strikethrough or underlined text,
coloring, line markers…)
• Version control tool may be used
• To store and manage the revision history
• To store justifications (to add, modify, delete, reject a requirement)
22
Traceability
Traceability?
• "Can I ask you some questions?"
• "By all means."
• "Okay. Well, for starters I'll have

who, what, when and where and
then wither, whence and
wherefore for a follow-up, and
then one bit side-order of why."
Source: Zaphod Beeblebrox & Zarniwoop, The Hitchhiker's Guide to the Galaxy
24
Traceability Quotes (1)

• Requirements traceability refers to the ability to describe and
follow the life of a requirement, in both forwards and
backwards direction (i.e., from its origins, through its
development and specification, to its subsequent deployment
and use, and through all periods of ongoing refinement and
iteration in any of these phases)”.1
• A software requirements specification is traceable if the origin
of each of its requirements is clear and if it facilitates the
referencing of each requirement in future development or
enhancement documentation.2
• Traceability gives essential assistance in understanding the
relationships that exist within and across software
requirements, design, and implementation.3
• A link or relationship defined between entities.4
[1] Gotel & Finkelstein, 1994; [2] IEEE Standard 830-1998; [3] Palmer, 2000; [4] Watkins and Neal, 1994
25
Traceability Quotes (2)

• Traceability is often mandated by contracts and standards.1
• E.g., military and aerospace
• One cannot manage what cannot be traced.2
• Traceability information helps assess the impact of changes
to requirements, connecting these requirements as well as
requirements for other representations of the system. 3
• Traceability is a property of a system description technique
that allows changes in one of the three system descriptions –
requirements, specifications, implementation – to be traced to
the corresponding portions of the other descriptions. The
correspondence should be maintained through the lifetime of
the system.4
[1-2] Watkins and Neal, 1994; [3] Kotonya and Sommerville, 1998; [4] Greenspan, McGowan, 1978
26
Importance of Traceability (1)

• Requirements cannot be managed effectively without
requirements traceability
• A requirement is traceable if you can discover who suggested the
requirement, why the requirement exists, what requirements are
related to it, and how that requirement relates to other information
such as systems designs, implementations and user documentation
27
Importance of Traceability (2)

• Benefits of traceability
• Prevents losing knowledge
• Supports the verification process (certification, localization of defects)
• Impact analysis
• Change control
• Process monitoring (e.g., missing links indicate completion level)
• Improved software quality (make changes correctly and completely)
• Reengineering (define traceability links is a way to record reverse
engineering knowledge)
• Reuse (by identifying what goes with a requirement: design, code…)
• Risk reduction (e.g., if a team member with key knowledge leaves)
28
Traceability Difficulties
• Various stakeholders require different information
• Huge amount of requirements traceability information must
be tracked and maintained
• Manual creation of links is very demanding
• Likely the most annoying problem
• Specialized tools must be used
• Integrating heterogeneous models/information from/to
different sources (requirements, design, tests, code,
documentation, rationales…) is not trivial
• Requires organizational commitment (with an understanding

of the potential benefits)
29
Backward and Forward Traceability (1)

• Backward traceability
• To previous stages of development
• Depends upon each element explicitly referencing its source in earlier
documents
• Forward traceability
• To all documents spawned by a document
• Depends upon each element in the document having a unique name
or reference number
Business plan Requ irements Document Design Specification

Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
Source of figure: Kotonya and Sommerville

30

• Top to bottom from requirements’ point of view
• Forward-to traceability
• Links other documents (which may have preceded the requirements
document) to relevant requirements
• Help validation
• Help evaluate which requirements are affected by changes to users’ needs
• Forward-from traceability
• Links requirements to the design and implementation components
• Help assure that all requirements have been satisfied
31

• Bottom to top from requirements’ point of view
• Backward-to traceability
• Links design and implementation components back to requirements
• Help determine why each item is designed/implemented
• Backward-from traceability
• Links requirements to their sources in other documents or people
• Help validation
• Help evaluate how changes to requirements impact stakeholders needs
32
Types of Traceability (1)

• Requirements – source traceability
• Links requirements with a person or document
• Requirements – rationale traceability
• Requirements – requirements traceability
• Links requirements with other requirements which are, in some way,
dependent on them
• Requirements – architecture traceability
• Links requirements with the subsystems where these requirements are
implemented (particularly important where subsystems are being
developed by different subcontractors)
• Requirements – design traceability
• Links requirements with specific hardware or software components in
the system which are used to implement the requirement
33
Types of Traceability (2)

• Requirements – interface traceability
• Links requirements with the interfaces of external systems which are
used in the provision of the requirements
• Requirements – feature traceability
• Requirements – tests traceability
• Links requirements with test cases verifying them (used to verify that
the requirement is implemented)
• Requirements – code traceability
• Generally not directly established, but can be inferred
34
Representation – Traceability Table

• Show the relationships between requirements or between
requirements and other artifacts
• Table can be set up to show links between several different
elements
• Backward and forward traceability
• Difficult to capture different types of links
35
Representation – Traceability Matrix

• Define links between pairs of elements
• E.g., requirements to requirement, use case to requirement,
requirement to test case…
• Can be used to defined relationships between pairs
• E.g., specifies/is specified by, depends on, is parent of, constrains…
• More amenable to automation than traceability table
Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
36
Representation – Traceability List

• Traceability matrices become more of a problem when there
are hundreds or thousands of requirements as the matrices
become large and are sparsely populated
• A simplified form of a traceability matrix may be used where,
along with each requirement description, one or more lists of
the identifiers of related requirements are maintained
Requirement Depends -on

R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6
37
What are Suspect Links?

If documents are linked …
… a change by … shows up as a
this user here… warning flag to
this user here.
• Proactively know when changes effect your requirements

• Suspect link indicates that element may have been affected
by a change
• Help ensure ripple effects of changes are considered
38
Traceability Planning
• Planning traceability? Yes, just like any other project!
• Who are the stakeholders?
• What are the needs (analysis, reports…)?
• Useful, measurable, feasible objectives
• Definition of links and attributes
• Can some be inferred automatically?
• Process (who collects and when to collect traceability information)
• Roles, access
• Data/link input and updates
• Exceptional situations (e.g., lack of time)
• Representations, queries, tools
• …
• Traceability policies define what and how traceability information
should be maintained
39
Factors to Consider during Planning (1)

• Number of requirements
• The greater the number of requirements, the more the need for formal
traceability policies
• Expected system lifetime
• More comprehensive traceability policies should be defined for
systems which have a long lifetime
• Maturity level of organization
• Detailed traceability policies are more likely to be implemented and
used properly in a cost-effective way in organizations which have a
higher level of process maturity
• Size of project and team
• The larger the project or team, the greater the need for formal
traceability policies
40
Factors to Consider during Planning (2)

• Type of system
• Critical systems such as hard real-time control systems or safety-
critical systems need more comprehensive traceability policies than
non-critical systems
• Additional constraints from customer
• E.g., compliance to military standard
• Traceability links should be defined by whoever has the
appropriate information available
41
Modeling Traceability
• The types of links to use (and their attributes) must be
defined for different types of requirements
• It is a design problem!
• May be modeled with a UML class diagram (metamodel)

• Object types (classes)
• Object attributes (attributes)
• Structure of folders, modules, objects
• Stereotypes, composition…
• Link types (associations)
• Satisfies, tests, refines, contains, contributes to, threatens, justifies…
• Link attributes (association classes)
• …
42
Types of Traceability Links

• Note the types of links in the previous examples, as well as
the types of objects they relate
• Satisfies, Tests
• Refines, References, Contains...
• Others could be created
• Contributes, Contradicts, Justifies, Depends on...
43
Other Example of Traceability Links

Business
requirement
modifies
Drives specification of
System requirements, influences

Change modifies
use case, external Business rule
request
interface, quality attribute
Is origin of Is origin of
modifies modifies
Software functional
Depends on another
requirement
Is satisfied by
Is verified by Lead to creation of
Architectrue, Project plan
user interface, or System test
task
functional design
Is verified by Is implemented in
Integration test Code
Is verified by
Unit test
44
Cardinality of Traceability Links

• Depending on the traceability information, the cardinality of
traceability links may be
• One-to-one
• E.g., one design element to one code module
• One-to-many
• E.g., one functional requirement verified by multiple test cases
• Many-to-many
• E.g., a use case may lead to multiple functional requirement, and a
functional requirement may be common to several use cases
45
Baselines
Baseline
• Non-modifiable (read-only) version of a document
• Describes a moment in time
• May include multiple documents at the same time
• Enables document comparison and management
• Comes with a change history for the document
• Information on objects, attributes, and links created, deleted, or edited
since the creation of the baseline
• Often also contains information on user sessions (when the document
was opened, by whom…)
• Requires access control
• It is advisable to establish a baseline for a new document that

is imported into the document management system
• In order not to lose any changes
47
Baseline for Requirements

• Represents the set of functional and non-functional
requirements that the development team has committed to
implement in a specific release
• Before going into the baseline, the requirements should be
reviewed and approved by stakeholders
• Once in the baseline, all changes should follow a defined
change control process
Baseline
⚫ Different viewpoints ⚫ Shared understanding

⚫ No formal documents ⚫ Configuration management
⚫ Always changing ⚫ Change management
48
Baseline Usage
• Baselines may be
• Created
• Complete image of requirements state at a given time
• Deleted
• Visualized
• Possibility to go back
• Compared
• To see changes since a certain time
• Copied
• Signed
• For authorization, contract
49
Change Management
Change Management (1)

• The more things change…
• If you see change not as

an enemy, but as a
welcome friend, you will
secure the most valuable
prize of all – the future…
51
Change Management (2)

• Concerned with the procedures, processes, and standards
which are used to manage changes to a system requirements
• Change management policies may cover
• The change request process and the information required to process
each change request
• The process used to analyse the impact and costs of change and the
associated traceability information
• The membership of the body that formally considers change requests
• Software support (if any) for the change control process
• A change request may have a status as well as requirements

• E.g., proposed, rejected, accepted, included...
52
Change Management Process

• Some requirements problem is identified
• Could come from an analysis of the requirements, new customer
needs, or operational problems with the system
• The requirements are analysed using problem information and
requirements changes are proposed
• The proposed changes are analysed
• How many requirements (and, if necessary, system components) are
affected? Roughly how much would cost, in both time and money?
• The change is implemented
• A set of amendments to the requirements document or a new
document version is produced (of course this should be validated with
whatever normal quality checking procedures are in place)
Identified
problem
Problem analysis and Change analysis Change
change specification and costing implementation
Revised
requirements
53
Change Request Form

• Proposed changes are usually recorded on a change request
form which is then passed to all of the people involved in the
analysis of the change
• Change request forms may include
• Date, Customer, Requester, Product including version
• Description of change request including rationale
• Fields to document the change analysis
• Signature fields
• Status
• Comments
54
Change Analysis and Costing – Example

customers may misunderstand requirements and
their context and suggest unnecessary changes
with the help of traceability information
Rejected request
Change
request Req. list risk is too high
Check request Find directly Find dependent
validity affected requirements
Valid requirements
request
Requirements change list Rejected request
Cost
Requirements information Accep ted
Propose changes change
Assess costs Assess cost
requirements of change acceptability
changes
Rejected request Rejected request

Customer Customer
information information
negotiations with customers
consequential changes may be
unacceptable to user/customer cost/time required for the implementation
of change is too high/long
Source of figure: Kotonya and Sommerville
55
Different Management Aspects

• Change Management
• How does a customer submit change requests?
• How is this request being monitored, prioritized, and implemented?
• Configuration Management
• Versioning, labelling, and tracking code and other components during
the development cycle of software
• Release Management
• Defines how and when different hardware and software will be made
available together as a product
56
Tool Support for Change Management

• May be provided through requirements management tools or
through configuration management tools
• Tool facilities may include
• Electronic change request forms which are filled in by different
participants in the process
• A database to store and manage requests
• A change model which may be instantiated so that people responsible
for one stage of the process know who is responsible for the next
process activity
• Electronic transfer of forms between people with different
responsibilities and electronic mail notification when activities have
been completed
• Electronic signatures
• Discussion forums
• In some cases, direct links to a requirements database
57
Requirements Management Tools
What Kind of Tool Do We Need?

• Different companies will use different tools, which may or may
not be tailored to the requirements management task
• Word processor (Microsoft Word with templates…)
• Spreadsheet (Microsoft Excel…)
• Industrial-strength, commercial RM tools
• IBM/Telelogic DOORS, IBM Requisite Pro, Borland CaliberRM…
• Internal tools
• GenSpec (Hydro-Quebec)…
• Open source RM tools
• OSRMT: http://sourceforge.net/projects/osrmt
• Bug tracking tools (free or not)
• Bugzilla…
• Collaboration tools (free or not)
• TWiki…
59
What Should We Look For in a Tool?

• Types/attributes for • Requirements document
requirements and links generation
• Specifications and models • Monitoring of requirements
• Version and change statuses
management • Access control
• Database repository • Import/export
• Traceability • Communication with
• Analysis (impact, stakeholders
completeness, style, • Scripting language (for
differences…) automation)
• Automatic inspection of • Reuse of requirements,
requirements (according to models, projects
rules) •…
• Visualization and reports
60
Requirements Management Implies Integration!
Project-tracking
tool
Test
Version control
management
tool
tool
Requirements
management
tool
Change- Design
request tool modeling tool
Project
estimation tool
61
Approaches – Document or Database? (1)

• Requirements have to be stored in such a way that they can
be accessed easily and related to other requirements
• Document (e.g., Word)

• Easy to use, easy to access, simple training
• Requirements are all stored in the requirements document
• It is easy to produce the final requirements document
• But: Traceability? Status reports? Granularity of requirements? Search
and navigation facilities? Change management? Version control?
Analysis? Simultaneous access control?...
62
Approaches – Document or Database? (2)

• Database (e.g., DOORS)
• Good for management, controlled access, links, analysis, reports
• Good query and navigation facilities
• Support for change and version management
• But: hard (and costly) to configure, manage, and use; link between the
database and the requirements document must be maintained (final
requirements document must be generated)
• Ideally: Target the benefits of both
• E.g., DOORS and RequisitePro offer integrations with Word
(import/export) as well as document-oriented views (for the “look and
feel”…)
63
How About Evolving the Process Itself?

• Evolution of requirements types
• Adding / modifying / deleting
• Attributes
• Link types
• Requirements status
• …
• Evolution of change management

• Adding / modifying / deleting
• Attributes
• Lifecycle status
• Forms
• …
64
Thinking About Getting a RM Tool?

• The list of potential criteria and the list of products can be
rather long…
• See the INCOSE study:
http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx
• About 25 tools and 80 criteria, with explanations
• Which are relevant to you, in your context (project,

organization…)?
• Need a goal model to define criteria and for assessment!
65

Ilovepdf Merged PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ilovepdf Merged PDF

Uploaded by

Copyright:

Available Formats

Writing Better Requirements

Based on slides by Gunter Mussbacher

• Anatomy of a Good / Bad User Requirement

• Standard for Writing a Requirement

• Writing Pitfalls to Avoid

• A Few Simple Tests…

• The greatest challenge to any thinker is stating the problem in

Martha can’t write requirements because…

Anatomy of a Good User Requirement

The Online Banking System shall allow the Internet user

Defines a positive end result Quality criteria

• Identifies the system under discussion and a desired end

• The challenge is to seek out the system under discussion,

Example of a Bad User Requirement

The Internet User quickly sees her current X

Vague quality criteria What versus how

Standard for Writing a Requirement

• Each requirement contains a subject and predicate

• The whole requirement provides the specifics of a desired

Standard for Writing a Requirement

• Example: IETF RFC 2119: Key words for use in RFCs to

• MUST, REQUIRED or SHALL: mean that the definition is an absolute

Standard for Writing a Requirement

• Note: several characteristics are mandatory (feasible,

Writing Pitfalls to Avoid

Writing Pitfalls to Avoid

Writing Pitfalls to Avoid

Writing Pitfalls to Avoid

The EasyEntry System shall be easy to use and require X

Writing Pitfalls to Avoid

The Easy Entry Navigator module shall consist of order X

Writing Pitfalls to Avoid

The Easy Entry System may be fully adaptable to all X

A Few Simple Tests…(1)

• “What is ruled out” test

Source: Spencer Smith, McMaster U.

A Few Simple Tests…(2)

The software shall be reliable. X

Source: Spencer Smith, McMaster U.

Towards Good Requirements Specifications (1)

• Specifies all the things the • Uses all terms consistently

Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

Towards Good Requirements Specifications (2)

Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

Rate these Requirements

The Order Entry system provides for quick, user-

Changing report layouts, invoices, labels, and form

Key Questions and Characteristics

• Remember the key questions “Why?” or

A Few Syntactic Analysis Tools

Based on slides by Gunter Mussbacher (2009) and Stéphane Somé (2008)

• IEEE 830 Standard

• ISO/IEC/IEEE 29148 Standard

Requirements Specification Document (1)

• Each requirement must be described in such a way that it is

• Basis for contractual agreements between contractors or

• Elaborated from elicitation notes

Requirements Specification Document (2)

• Different levels of detail and formality is needed for each

• Different templates for requirements specifications

IEEE 830-1998 Standard

• Describes the content and qualities of a good software

• Presents several sample SRS outlines