Transcript Requirements and Winbook - University of Southern California
Requirements and Winbook
Nupul Kukreja, Barry Boehm 5
th
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
30 20 10 0 60 50
49
40
23 28 51 15 34 53 18 29 46 19 35 44 24
2000 2002 2004 2006 2008 Challenged: Over budget/schedule or undelivered projects Failed: Cancelled projects
32
Challenged Failed Succeded 7
CHAOS ’10 – Factors Influencing Project Success
1. User Involvement
Lack of Stakeholder
2. Executive Support
involvement and
3. Clear Business Objectives
convergence
4. Emotional Maturity
viewed as major
5. Scope Optimization
causes of project
6. Agile Process
failure
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 Design Coding Development/Testing Acceptance Testing Operation
Cost Ratio
1 3-6 10 15-40 30-70 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 use-cases or user stories) Functional Requirements (common “shall” based form of requirements. The system shall…) Quality of Service (a.k.a., non-functional or quality attributes or in 577: Levels of Service)
Architectural Requirements Project/Process Requirements
User Requirements Document; Winbook in 577 System and Software Requirements Specification/Document (SRS/SSRD) (No longer applicable in 577) Mostly part of SRS/SSRD; OCD and Winbook in 577 System and software architecture document (SSAD); exists in 577 SRS/SSRD; OCD and Winbook in 577
Tools/Techniques for Capturing Requirements in 577?
Activity
Capturing Business Requirements Capturing User Requirements Capturing Functional Requirements
Tools/Techniques
Program Model, Activity Diagrams, Element-Relationship Diagrams etc., Top-down functional decomposition and user stories Shall-based statements. Eliminated for 577 like projects. Still done in the wild and for large systems Similar to user stories Capturing Levels of Service/Quality Requirements Capturing Architectural Requirements Capturing Project/Process Requirements System Context, Deployment Diagrams, Freeform text, Use-cases, Sequence Diagrams etc., 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: Description: Priority: Input(s): Source(s): Output(s): Destination(s): Pre-condition(s): Post-condition(s): WinWin Agreements:
CR-13 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.
Must Have - Selected archive items - The database with the overviews of the archive items.
User Input Overview display of the archive items.
User Display The user has performed a search by keyword or has browsed the archive.
The user either makes an advance request or starts another search or exits from the system.
[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
In 2D The true 3D view Too much detail and too much to capture 39
Change Management & SSRD?
40
Along came a Story
What we thought…
User Stories
What was actually intended…
SSRD
41
A promissory note of intent The User Story – 3Cs Discussion & clarification of intent (a.k.a requirement) Acceptance Tests Confirmation Card Conversation Lightweight Ecstasy 42
User Stories
• • • • • Written on small index cards Usually of the form: As a
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 V E S T
= Independent = Negotiable = Valuable = Estimable = Small = Testable 44
Dr. Boehm Customer
Theory-W
Developer Think of requirements as stakeholder negotiated win conditions!!
As a team discuss what will make each of you “win” (a.k.a. win conditions) Identify any issues and come up with options to resolve them Reach a mutual consensus and move forward (WinWin Equilibrium) 45
Facebook Putting It All Together
Winbook
Theory - W Requirement Specifications User Stories Gmail 46
• • • •
Winbook
A collaborative, social networking based tool for requirements brainstorming similar to facebook… …with requirements organization using color coded 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 use cases 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, 3 rd Beatty Edition – Wiegers and 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