Requirements and Winbook - University of Southern California

Report
Requirements and Winbook
Nupul Kukreja,
Barry Boehm
5th Sept, ‘14
Agenda
• What and Why of Requirements?
• Cost and Sources of Ambiguity
• Need for multiple requirements elicitation
techniques
• Requirements development, management and
documentation (Winbook)
• Requirements and 577
• Winbook and Requirements Capturing
• Challenges and Takeaways
“Requirement”
• IEEE definition:
1. A condition or capability needed by a user to
solve a problem or achieve an objective
2. A condition or capability that must be or
possessed by a system or system component to
satisfy a contract, standard, specification or
other formally imposed document
3. A documented representation of a condition or
capability as in (1) or (2)
“Requirements” – Cont’d
• Sommerville & Sawyer (1997):
– A specification of what should be implemented
– They are descriptions of how the system should
behave or of a system property or attribute
– They may be a constraint on the development
process of the system
“Why” Requirements?
• Incorrect requirements are a major cause of
project failure
• Exponential cost of fixing an incorrect
requirement after system in operation
• Cornerstone of project and product
management activities
• Basic currency to help estimate by “when will
you be done”
• Primary vehicle to go from “vision” to
“realization”
Project Success Rate
2010 Standish Group CHAOS Summary Report
60
50
53
51
49
46
44
40
35
34
30
29
28
20
Challenged
32
Failed
Succeded
24
23
18
19
15
10
0
2000
2002
2004
2006
2008
Challenged: Over budget/schedule or undelivered projects
Failed: Cancelled projects
7
CHAOS ’10 – Factors Influencing
Project Success
1. User Involvement
Lack of Stakeholder
2. Executive Support
involvement and
convergence
3. Clear Business Objectives
viewed as major
4. Emotional Maturity
causes of project
5. Scope Optimization
failure
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution Capability
10.Tools and Infrastructure
8
Two-Minute Exercise
Create a means for protecting a small group of
human beings from the hostile elements of their
environment
Ambiguity in Requirements
• A major source of headache and cost overruns
• Diverse interpretations of the same
requirement
• Cost of ambiguity
Phase in which found
Requirements
Cost Ratio
1
Design
3-6
Coding
10
Development/Testing
15-40
Acceptance Testing
30-70
Operation
40-1000
Removing Ambiguity
What we want that we don’t ask for
OR
What we ask for that we don’t want
The universe of everything that’s possible
Sources of Ambiguity
Test for Attentiveness
How many points were in the star that was
shown on the previous slide of this
presentation?
Sources of Ambiguity
• Observational & recall errors:
– (Not) seeing the same things or retaining what
you saw
• Interpretation errors
– What did “points” refer too?
• Mixtures of above
• Effects of human interaction
– Things lost in conversation
(Another) Test for Attentiveness
To the best of your recall ability what was the
question that you think you answered in the
previous test for attentiveness?
Problem Statement Ambiguity:
• Each variant of the problem does produce a
different way of looking at the problem which
in turn produces a different solution!!
• Subtle differences as these can cause the
project to be a success or a failure!
Removing Ambiguity
This is just a contrived example. I can always ask
the necessary questions to remove ambiguity!
True or False?
Game Time!
• You can ask me 20 Questions
(Hint: Order of questions matter so think
before asking)
• Problem: Design a transportation device
Multiple Elicitation Tools/Techniques
• A pure direct questioning approach would only
succeed with “perfect” human beings!
• Direct questioning needs to be supplemented
with other tools/techniques
–
–
–
–
–
–
Context Free Questions
Interviews/Workshops
Focus Groups/Observational studies
UI analysis
Mockups/Prototyping
Visual Representations: Activity diagrams, Data Flow
Diagrams, Decision Trees etc.,
–…
Three Dimensions & Goals
of Requirements Engineering
• Content:
All relevant requirements are explicitly known
and understood at the required level of detail
• Agreement:
A sufficient agreement about the system
requirements is achieved between the success
critical stakeholders
• Documentation:
All requirements are documented and
specified in compliance with the relevant
documentation/specification formats & rules
19
Visualizing The “Three Dimensions”
Content
Goal
complete
Agreement
consolidated views
vague
individual views
informal
compliant
with rules
Documentation
20
MOMMY, WHERE DO THE
REQUIREMENTS COME FROM?
Stakeholders
• Not any and every stakeholder but success
critical stakeholders
• Common mistake: Leaving an essential
stakeholder out of the software development
process (remember Win-Lose  Lose-Lose?)
• Critical to identify the right stakeholders
• How?
– Brainstorming/Pruning
– Checklist
– Benefits Chain
Other Sources
•
•
•
•
•
•
•
•
Existing systems & documentation
Legacy systems
External interfaces
Social media
Creative thinking
Competitive analysis
Customer survey
…many many more
Types of Requirements
• Business requirements: High-level statements of the goals,
objectives, or needs of an organization.
• User (stakeholder) requirements: Mid-level statements of the
needs of a particular stakeholder or group of stakeholders. They
usually describe how someone wants to interact with the intended
solution.
• Functional (solution) requirements: Usually detailed statements of
capabilities, behavior, and information that the solution will need.
• Quality-of-service (non-functional) requirements: “-ilities”
reliability, testability, maintainability, availability etc.
• Implementation (transition) requirements: Recruitment, role
changes, education, migration of data from one system to another
etc.
• Architectural requirements: what has to be done by identifying the
necessary systems structure and systems behavior, i.e., systems
architecture of a system.
• Project/Process requirements: Activities to be performed by
development organization
Where Are They Documented?
Requirement Type
Business Requirements (a,k.a., Epics,
Investment Themes etc.,)
Artifact
Project Vision, Charter; OCD in 577
User Requirements (may be referred to as User Requirements Document; Winbook
use-cases or user stories)
in 577
Functional Requirements (common
“shall” based form of requirements. The
system shall…)
System and Software Requirements
Specification/Document (SRS/SSRD)
(No longer applicable in 577)
Quality of Service (a.k.a., non-functional
or quality attributes or in 577: Levels of
Service)
Mostly part of SRS/SSRD; OCD and
Winbook in 577
Architectural Requirements
System and software architecture
document (SSAD); exists in 577
Project/Process Requirements
SRS/SSRD; OCD and Winbook in 577
Tools/Techniques for Capturing
Requirements in 577?
Activity
Tools/Techniques
Capturing Business Requirements
Program Model, Activity Diagrams,
Element-Relationship Diagrams etc.,
Capturing User Requirements
Top-down functional decomposition and
user stories
Capturing Functional Requirements
Shall-based statements. Eliminated for
577 like projects. Still done in the wild and
for large systems
Capturing Levels of Service/Quality
Requirements
Similar to user stories
Capturing Architectural Requirements
System Context, Deployment Diagrams,
Freeform text, Use-cases, Sequence
Diagrams etc.,
Capturing Project/Process Requirements
Similar to user stories
“HOW” ARE REQUIREMENTS
CAPTURED IN 577?
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
– Necessary to future proof the system
29
Levels of Service
Quality attributes of the system:
• Dependability
– Reliability
– Availability
• Usability
– Ease of learning
– Ease of use
•
•
•
•
•
Performance
Maintainability
Portability
Interoperability
Reusability
30
Example of Capability 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]
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>
“As a Consumer I can 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
• Formalized via acceptance tests
43
INVEST-ing in User Stories
Commonly used acronym in the Agile World
to describe attributes of a good user story:
I
N
= Independent
= Negotiable
V
E
S
T
=
=
=
=
Valuable
Estimable
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/Functional 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 with Requirements
• 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
• Software Requirements, 3rd Edition – Wiegers and
Beatty
• 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

similar documents