Requirements Engineering
Nupul Kukreja,
Barry Boehm
7th September 2012
1
Agenda
• Part 1
–
–
–
–
–
Defining Requirements Engineering (RE)
Why is RE important?
Vision, Context and relation to RE
Three Dimensions of RE
Generic RE Framework
• Part 2
–
–
–
–
Requirements Practice in 577
System and Software Requirements Document
User Stories
Documenting Requirements in 577
2
Requirements Engineering
• Specifications of what should be implemented or
as a constraint of some kind on the system
• Defined during the early stages of system and
software development
• Types:
– General property of the system (e.g. response time)
– Detailed behavioral description (step by step scenario)
– Specific constraint (must communicate with Amazon’s
web service)
– Information about computation details (e.g. interest
computation for loans/mortgages etc.,
3
Requirements Engineering*
• Engineering implies application of systematic
and repeatable processes
• A systems and software engineering process
which covers all of the activities involved in
discovering, documenting and maintaining a
set of requirements for a computer-based
system
*http://en.wikipedia.org/wiki/Requirements_engineering
4
Requirements Engineering*
A cooperative, iterative and incremental process
which aims at ensuring that:
1. All relevant requirements are explicitly known
and understood at the required level of detail
2. A sufficient agreement about the system
requirements is achieved between the
stakeholders involved
3. All requirements are documented and specified
in compliance with the defined
documentation/specification formats and rules
*Requirements Engineering: Fundamentals, Principles & Techniques – Klaus Pohl
5
Why Is RE Important?
• Flawed requirements a major cause of project
failure – one of top ten failures in Standish
CHAOS Reports
• Fixing an error in later phases 10x more
expensive
• Incorrect requirements  Incorrect system
leads to wasted costs
• System maybe unreliable for practical use
disrupting normal day-to-day operations
• The primary vehicle for going from “vision” to
“realization”
6
Understanding “Vision”
• Requirements Engineering processes start with
an aim to change current reality
• Vision: (a.k.a “system vision”)
– Essence of desired change defined briefly and
precisely
– Describes overall goal(s) of the system
– Usually associated with particular point in time of
when the vision should be realized
– Serves as a guide during development for all Success
Critical Stakeholders (SCS) involved in the project
7
Understanding “Context”
• Each system is embedded within a given
context (a.k.a. “system context”)
• Context: Part of the system environment
relevant for:
– Defining
– Understanding &
– Interpreting system requirements
8
Visualizing “Vision” and “Context”
Vision
defines focus
• Establish system vision within existing system context
• Deal with parts of the real world that are relevant
and their relation to the development context
9
Requirements Engineering: “Three Dimensions”
• Content:
Understanding of the system requirements
attained
• Agreement:
Level of agreement achieved between
stakeholders about defined requirements
• Documentation:
Documenting and specifying the requirements
using different documentation and
specification techniques
10
Visualizing The “Three Dimensions”
Content
Goal
complete
Agreement
consolidated views
vague
individual views
informal
compliant
with rules
Documentation
11
Framework For RE
Core Activities
Management
Validation
System Context
Requirements Artifacts
12
Framework For RE
System Context
Subject Facet
Maintain
information about
subjects in the real
world. (Subjects
subsume objects)
Usage Facet
Desired workflows,
usage goals,
different user
groups, interaction
models, laws &
standards etc.,
IT System Facet
Existing hardware,
software,
communication
networks,
peripheral devices
etc.,
Development Facet
Process guidelines
and constraints, QA
methods, maturity
models,
development
environments etc.,
13
Framework For RE
Core Activities
Documentation
Document & specify elicited
requirements as per defined
documentation and
specification rules. Also
capture rationale and other
relevant information
Negotation
1.Detect conflicts and make
them explicit
2. Resolve identified conflicts
Elicitation
14
Framework For RE
Elicitation
Identifying Requirement
Sources
Developing new &
innovative requirements
Stakeholders
Existing Documentation
Existing System(s)
Typically not elicit-able and
require collaborative and
creative processes
Elicit Existing Requirements
Elicit already “known”
requirements from relevant
sources
15
Techniques For Elicitation
• Interviews
• Workshops
• Focus Groups
• Observation of stakeholders/users etc.,
• Questionnaires
• Perspective-based reading
Usually supported by “Assistance Techniques”
–
–
–
–
–
Brainstorming
Prototyping
Mind Mapping
KJ Analysis/Method
Elicitation Checklists
16
Framework For RE
Requirements Artifacts
(Documented Requirements)
Goals
Stakeholder intention with
regard to the objectives,
properties or use of the
system
Scenarios
Positive/Negative,
Misuse,
Exploratory,
Current-state/desired state,
Main, alternative or exception
Solution oriented
requirements
Data Model,
Functional Model,
Behavioral Model
17
Validation
Framework For RE
• Validation of context consideration
Check whether all relevant aspects in 4
contexts have been elicited, documented
within the RE process
• Validation of execution of activities
Check adherence of activities to process,
standards, guidelines etc.
• Validation of requirement artifacts
Check documented requirements w.r.t.
content, documentation and agreements
18
Validation Techniques
• Inspections
• Walkthroughs
• Desk-checking (checking programs with
pen-paper)
• Prototyping
Above are usually assisted by:
• Validation checklists
• Perspective-based reading
• Verbalization of models
• Creation of artifacts
19
• Observation of system context
Identification and management of context
changes
• Management of RE activities
Monitoring, controlling and adjustment of
planned workflow of elicitation, documentation,
negotiation and validation activities – standard
project management
• Management of requirements artifacts
– Establishing traceability between different artifacts
– Prioritizing requirements
– Managing changes via change management
processes
Management
Framework For RE
20
RE Framework == VBSE 4+1 
• RE Framework advocated by Klaus Pohl is in essence
isomorphic to VBSE’s 4+1
• VBSE brings value considerations to the foreground; RE
Framework doesn’t seem to make it explicit
• Each of the ‘steps’ of the RE framework is traceable in VBSE’s
4+1 structure  (and vice versa)
21
Part 2
Requirements Practices in 577ab
22
RE Framework and 577
System Context
QMP
Subject Facet
Maintain
information about
subjects in the real
world. (Subjects
subsume objects)
SSAD
Usage Facet
Desired workflows,
usage goals,
different user
groups, interaction
models, laws &
standards etc.,
OCD
IT System Facet
Existing hardware,
software,
communication
networks,
peripheral devices
etc.,
SSAD
Development Facet
Process guidelines
and constraints, QA
methods, maturity
models,
development
environments etc.,
LCP
23
RE Framework and 577
Core Activities
Documentation
Document & specify elicited
requirements as per defined
documentation and
specification rules. Also
capture rationale and other
relevant information
Winbook
Elicitation
Negotation
1.Detect conflicts and make
explicit
2. Resolve identified conflicts
WinWin
Sessions
24
RE Framework and 577
Elicitation
Identifying Requirement
Sources
Elicit Existing Requirements
Developing new &
innovative requirements
Stakeholders
Existing Documentation
Existing System(s)
Elicit already “known”
requirements from relevant
sources
Typically not elicit-able and
require collaborative and
creative processes
Result
Chains
On-site
Visits
WinWin
Sessions
25
RE Framework and 577
Requirements Artifacts
Goals
Stakeholder intention with
regard to the objectives,
properties or use of the
system
Result
Chains
OCD
Winbook
Scenarios
Positive/Negative,
Misuse,
Exploratory,
Current-state/desired state,
Main, alternative or exception
Solution oriented
requirements
Data Model,
Functional Model,
Behavioral Model
SSAD
26
RE Framework and 577
Project
Management
Lifecycle
Planning
Feasibility
Analysis
Validation
Prototyping
Bugzilla
(Winbook)
Prioritization
Management
IIV & V
Change
Management
ARBs
27
Requirements Capturing in 577
•
•
Previously captured in System and Software Requirements Document (SSRD)
Capability requirements (both nominal and off-nominal): i.e., the
fundamental subject matter of the system, measured by concrete means like
data values, decision-making logic and algorithms.
•
Level of Service Requirements (sometimes referred to as Non-functional
requirements): i.e., the behavioral properties that the specified functions must
have, such as performance, usability, etc.
•
Global constraints: requirements and constraints that apply to the system as a
whole e.g.: Interface Requirements, Budget and Schedule Requirements,
Implementation Requirements, and other Project Requirements
•
Evolution Requirements: not included in initial delivery, but need to be
supported by the System’s Architecture
•
Priorities on how the system must be implemented : MoSCoW( Must Have,
Should Have, Could Have, Want to Have)
•
Commitment: addressing WinWin agreements, policies, constraints
28
Main Kinds of Requirements
• Product Requirements
– Capability Requirements
• local to system, specific system functionality
– Level of Service Requirements
• local to system, may affect many system requirements
• System Interface Requirements
– varies, affects groups system requirements
• Project Requirements
– global to project, affects overall system requirements
• Evolutionary Requirements
– varies, effects design and implementation
29
Example of Nominal Requirement
Requirement:
CR-13
Description:
The Archive user subsystem allows the user to view the list of archive
items, select the item of interest, deselect if required and view the
overview on the selected archive items.
Priority:
Must Have
Input(s):
- Selected archive items
- The database with the overviews of the archive items.
Source(s):
Output(s):
User Input
Overview display of the archive items.
Destination(s):
User Display
Pre-condition(s):
The user has performed a search by keyword or has browsed the archive.
Post-condition(s):
The user either makes an advance request or starts another search or
exits from
the system.
WinWin Agreements:
[Agreement 1]
30
Examples of Levels of Service
• Dependability
– Reliability
– Availability
• Usability
– Ease of learning
– Ease of use
•
•
•
•
•
Performance
Maintainability
Portability
Inter-operability (or binary portability)
Reusability
31
Poor Examples of LOS
• M: The system should be as fast as possible
• R: The system should be available 24/ 7 (even if
organization does not support activities beyond
day time)
• S: The system shall be implemented as per the
standards laid out by USC
• A: The system shall be available 100% of the
time (for an unreliable network- based system)
32
SSRD in Practice
The true 3D view
Too much detail
and too much
to capture
In 2D
39
Change Management & SSRD?
40
Along came a
Story
User Stories
SSRD
What we thought…
What was actually intended…
41
The User Story – 3Cs
A promissory
note of intent
Discussion & clarification of
intent (a.k.a requirement)
Card
Conversation
Lightweight
Acceptance Tests
Confirmation
Ecstasy
42
User Stories
• Written on small index cards
• Usually of the form:
As a <role>, I can <activity>
so that <business value>
Ex.: As a Consumer I want to be able to see my
daily energy usage so that I can lower my energy
costs and usage
• Lacks details captured by traditional
requirements specifications
• Details conveyed primarily through conversations
43
INVEST-ing in User Stories
Commonly used acronym in the Agile World
to describe attributes of a good user story:
I
= Independent
N
V
E
= Negotiable
= Valuable
= Estimable
S
T
= Small
= Testable
44
Theory-W
Customer
Dr. Boehm
Developer
As a team discuss what will
make each of you “win”
(a.k.a. win conditions)
Think of requirements as
stakeholder negotiated win
conditions!!
Identify any issues and come up
with options to resolve them
Reach a mutual
consensus and move
forward
(WinWin Equilibrium)
45
Putting It All Together
Facebook
Winbook
Gmail
Theory - W
Requirement
Specifications
User Stories
46
Winbook
• A collaborative, social networking based tool
for requirements brainstorming similar to
facebook…
• …with requirements organization using colorcoded labels similar to Gmail…
• …to collaboratively converge on software
system requirements reaching win-win
equilibrium (based on Theory-W)…
• …by keeping it short and simple like XP’s user
stories!
47
48
49
Requirements in 577
• Requirements are treated as “Win Conditions”
• Win Conditions are captured in Winbook
• Win Conditions subsume user stories:
– Capability Requirements/Win Conditions can be
conveniently phrased as user stories
• Win Conditions are negotiated within Winbook
itself
• Win Conditions are linked to corresponding usecases facilitating “downstream value traceability”
50
Challenges in RE
• Things that can (and do) make life difficult
– Missing Requirements
– Ambiguous Requirements (major problem)
– Changing Requirements (changes in technology,
marketplace, political & legal changes, economic
changes etc.,)
– Non-identified Stakeholders
– Location/Time differences and communication
overhead
– IKIWISI (I’ll know it when I’ll see it)
– Implicit Assumptions
51
Key Takeaways
• Requirements are very critical to the field of Software
Engineering
• Almost everything documented information is a form
of requirement
• No single artifact to rule them all – content usually split
across various artifacts
• Very cooperative and iterative
• Assumptions/Conflicts must be made explicit and
validated/resolved
• SSRD is more commonly found in the wild
• 577 uses Winbook for documenting ‘requirements’
making the process ‘fun and lightweight’
52
References
• Requirements Engineering: Fundamentals,
Principles and Techniques – Klaus Pohl
• Agile Software Requirements – Dean
Leffingwell
• Exploring Requirements: Quality Before
Design – Gause & Weinberg
• User Stories Applied – Mike Cohn
• Software Engineering Economics – Barry
Boehm
53