Requirements Engineering
A Roadmap
Jichuan Chang
cjc@cs.cmu.edu
 Based on
 “RE roadmap” by Nuseibeh & Easterbrook
 RE course materials by Steve Easterbrook
http://www.cs.toronto.edu/~sme/CSC2106S/index.html
7/23/2016
1
Outline

Foundations





What is RE?
Why important?
Inter-disciplinary aspects of RE
Basic Requirements Engineering activities
Directions and Discussion
7/23/2016
2
Discussion

About requirements:




About RE:






What and How? Environment and Machine
Is there always a bridge from the real-world to the “machine”?
Is formal specification suitable for all requirements?
Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose?
What’s the process that integrates methods and activities?
RE tools? Traceability?
Future directions:

What’s the impact of imperfect requirements?




inconsistency? incomplete? evolving?
What’s the impact to other development activities?
What’s the impact of architectural decision to NFRs?
What’s the impact of requirement reuse?
7/23/2016
3
What is RE?

What’s Requirement? [IEEE Std]

A condition or capability needed by a user to solve a problem or
achieve an objective. The set of all requirements forms the basis
for subsequent development of the system or system component.

What is RE? [Zave94]


Requirements Engineering is the branch of systems
engineering concerned with real-world goals for, services
provided by, and constraints on software systems.
Requirements Engineering is also concerned with the
relationship of these factors to precise specifications of
system behavior and to their evolution over time and across
system families.
7/23/2016
4
Importance of Requirements

Engineering Argument


Economic Argument


Failure to understand and manage requirements is the
biggest single cause of cost and schedule over-runs.
Safety Argument


Defects are cheaper to remove if are found earlier.
Empirical Argument


A good solution can only be developed if the engineer has a
solid understanding of the problem.
Safety-related software errors arise most often from
inadequate or misunderstood requirements
……
7/23/2016
5
Research on RE

Early research: One epigram summarized all of RE.



1990’s: A field of study of it own right



Two series of international meetings: RE and ICRE
International journal by Springer.
Late 1990’s: Grown up enough





Reqts. say what the system will do and not how it will do it.
A time-consuming, bureaucratic & contractual process?
Many additional smaller meetings and workshops
Emphasize the use of contextualized enquiry techniques
Model indicative & optative properties of the environment
Handle inconsistent and evolving specification
Future: increasingly recognized as a critical activity
7/23/2016
6
RE Basics


Dimensions of RE
What vs. How


What does a web browser do?
‘What’ refers to a system’s purpose



‘How’ refers to a system’s structure & behavior



external to the system
A property of the application domain
internal to the system
A property of the machine domain
Foundations of RE – Multi-discipline

Systems Theory, Systems Engineering, Math & Logic,
Computer Science, Social Sciences, Cognitive Sciences,
Philosophy, AI
7/23/2016
7
RE process

RE in software lifecycle



Initial phase
may also span the entire life cycle
Essential RE process



Understand the problem

elicitation

specification, modeling
Formally describe the problem
Attain agreement on the nature of problem




validation, conflict resolution, negotiation
requirements management - maintain the agreement!
Sequential or iterative/incremental
RE groundwork


Feasibility, risk, concept of operations
Decide the RE process, methods and techniques
7/23/2016
8
Outline


Foundations
Basic Requirements Engineering activities







Eliciting Requirements
Modeling and Analyzing Requirements
Communicating Requirements
Agreeing Requirements
Evolving Requirements
RE Tool
Directions and Discussion
7/23/2016
9
Eliciting Requirements

Source of Requirements:




Customer-driven, Marketdriven, Hybrid
Affect the role of
Requirements



Things to elicit





System boundaries
Stakeholders & User
Classes
Viewpoints
Goals and tasks
Scenarios/Use cases
7/23/2016
Elicitation techniques




Interviews, questionnaires,
surveys, meetings
Prototyping
Ethnographic techniques
Knowledge elicitation
techniques
Conversation Analysis
Text Analysis
Elicitation process:


Inquiry cycle
Use case analysis
Ethnographic: a branch of sociology dealing with nonspecialists' commonsense
understanding of the structure and organization of society
10
Modeling Requirements

Why Modeling?

Modeling can guide elicitation


Modeling can provide a measure of progress:


if we’ve filled in all the pieces of the model, are we done?
Modeling can help to uncover problems



it help you ask the right questions?
Does inconsistency in the model reveal interesting things…?
conflicting or infeasible requirements; confusion over
terminology, scope, etc; reveal disagreements between
stakeholders
Modeling can help us check our understanding



7/23/2016
Can we test that the model has the properties we expect?
Can we reason over the model to understand its
consequences?
Can we animate the model to help us visualize/validate the
requirements?
11
Modeling Techniques






Goals & objectives
Organizational structure
Processes and products
Agents and work roles


Modeling Functional
Requirements





Modeling Enterprises



Structural views
Behavioral views
Timing requirements
Modeling Non-functional
Requirements


Product requirements
Process requirements
External requirements
7/23/2016



ERD

i*, SSM, ISAC

KAOS, CREWS
Organization modeling:
Goal modeling:
Structured Analysis:

SADT, SSADM, JSD

OOA, OOSE, OMT, UML

SCR, RSML, Z, Larch, VDM
Object Oriented Analysis:
Formal Methods:
Quality tradeoffs:


Information modeling:
QFD, win-win
Specific NFRs:
Performance:Timed Petri nets
Usability: Task models
Reliability: Probabilistic MTTF

12
Communicating Reqts - SRS

How do we communicate the Requirements to others?


It is common practice to capture them in an SRS
Purpose
 Communicates an
understanding of the
requirements
 Contractual
 Baseline for evaluating
subsequent products
 testing, V&V
 Baseline for change
control
7/23/2016

Audience

Users, Purchasers

Requirements Analysts

Developers, Programmers

Testers

Project Managers
13
SRS for Procurement

An ‘SRS’ may be written by:

the procurer (a call for proposals)



the bidders (a proposal to meet the CfP)





must be specific enough to demonstrate feasibility and competence
… and general enough to avoid over-commitment
the selected developer


Must be general enough to yield a good selection of bids
… and specific enough to exclude unreasonable bids
reflects the developer’s understanding of the customers needs
forms the basis for evaluation of contractual performance
or an independent RE contractor
Choice over what point to compete the contract



Early (conceptual stage)
Late (detailed specification stage)
IEEE Standard recommends SRS jointly developed by procurer
and developer
7/23/2016
14
Reqts Traceability

Importance:


Verification & Validation
Maintenance










Assessing change
requests
Tracing design rationale
change management
risk management
control of the
development process
Difficulties:

Current Practice

Cost
Delayed gratification
Size and diversity
7/23/2016
Focuses on baselined
requirements
Coverage

Document access
Process visibility
Management






links from requirements
forward to designs, code, test
cases,
links back from designs, code,
test cases to requirements
links between requirements at
different levels
Tools (manual, syntactic) ??

Approaches:


UID, hypertext linking
Ability:



Follow links
Find missing links
Measure overall traceability
15
Agreeing Requirements


Two key problems: validation & negotiation
Validation - What is “truth” and what is “knowable”?

Approaches (Based on philosophical assumptions):




Method in practice:



assumes there is an objective problem that exists in the world
design your requirements models to be refutable
validation is always subjective and contextualised
Inspections, Reviews and Walkthroughs
Prototyping: Throwaway or Evolve?
Negotiation - How to reconcile conflicting goals?




7/23/2016
Requirements Negotiation
Competition
Third Party Resolution
Bidding and Bargaining
16
Evolving Requirements

Software evolves because requirements evolve …




Traditional change management

Add, modify, remove requirements during development
Baselines, Change Requests, Review Boards

The product line approach



How to manage incremental change to reqts models?
How can multiple models (specifications) be compared?
How to capture the rationale for each change?
Software Families
Viewpoints





Requirements model is a collection of viewpoints
as a framework for understanding requirements evolution
Viewpoints are instantiated from viewpoint templates
Viewpoints contain consistency rules (no central control)
Internal rule, External rule, Work plan
7/23/2016
17
RE Tool examples

Requisite Pro






DOORS





http://www.rational.com/ products/reqpro/
Support Unified Process
Support use-case based, declarative, and mixed
representation (document templates)
Support Requirements Traceability
Integrated with change mgmt, modeling, testing, metrics and
project mgmt tools.
http://www.telelogic.com/doors/
Support Requirements Traceability
Inter-project linking, Multiple Views
Integration with MS Office and external communication tools
Cradle

7/23/2016
http://www.threesl.com/
18
Outline



Foundations
Basic Requirements Engineering activities
Directions and Discussion
7/23/2016
19
Future Research Directions

Trends in the 1990’s
Emphasize the use of contextualized enquiry techniques
 Model indicative & optative properties of the environment
 Handle inconsistent and evolving specification
Future Directions:








Modeling and analysis of problem domain, as opposed to the
behavior of software.
Models for non-functional requirements (NFR).
Bridging the gap between contextual enquiry and formal
specification techniques.
Impact of architectural choices on the prioritization and
evolution of requirements.
Reuse of requirements models to facilitate the development of
system families and COTS selection.
Multi-disciplinary training for requirements practitioners.
7/23/2016
20
Discussion

About requirements:




About RE:






What and How? Environment and Machine
Is there always a bridge from the real-world to the “machine”?
Is formal specification suitable for all requirements?
Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose?
What’s the process that integrates methods and activities?
RE tools? Traceability?
Future directions:

What’s the impact of imperfect requirements?




inconsistency? incomplete? evolving?
What’s the impact to other development activities?
What’s the impact of architectural decision to NFRs?
What’s the impact of requirement reuse?
7/23/2016
21