1
Requirements Engineering
Nupul Kukreja,Barry Boehm
9th September 2013
3
Agenda• Part 1– Pervasiveness of Software– Motivation for Requirements Engineering– Interrelationships: Requirements Engineering, Enterprise &
Software Development– Types of Requirements– Goals of Requirements Engineering– Framework for Requirements Engineering
• Part 2– Requirements Practice in 577– System and Software Requirements Document– User Stories– Documenting Requirements in 577
Team Mixer after class in
Engineering Quad (outside OHE)
4
Pervasiveness of Software• Software-intensive systems prevalent across
industries/domains – E.g.: automotive, finance, consumer electronics, medical devices etc.,
• Information systems: – Collects, stores, transforms, transmits, and/or processes information
or data– Goal: Provide information at right place/time– Ex.: Accounting system
• Embedded software-intensive systems:– Software only ONE (important) part of overall system– Often closely integrated with hardware– Ex.: Anti-lock braking system of a car
5
Challenges in Software Development• Software-based innovations
– Customers demanding innovative features software is key for realizing innovation
• Increasing Complexity– Greater number of functions realized by software increasing complexity
i.e., increased integration with external systems, customizability etc.,• Higher quality demands
– Pervasiveness of software higher level of quality• Shorter development times
– Increasing competition faster time to market• Pressure to reduce costs
– Increasing market pressure software systems must be developed at lower costs
6
Project Success Rate
2000 2002 2004 2006 20080
10
20
30
40
50
60
4951
53
4644
23
1518 19
24
28
34
29
3532
2010 Standish Group CHAOS Summary Report
ChallengedFailedSucceded
Challenged: Over budget/schedule or undelivered projectsFailed: Cancelled projects
7
Lack of Stakeholder involvement and convergence viewed as major causes of project failure
1. User Involvement2. Executive Support3. Clear Business Objectives4. Emotional Maturity5. Scope Optimization6. Agile Process7. Project Management Expertise8. Skilled Resources9. Execution Capability10.Tools and Infrastructure
CHAOS ’10 – Factors Influencing Project Success
9
2 Minutes
In-class• Create a means for protecting a small group of
human beings from the hostile elements of their environment– List or draw or describe the “creation” in a couple
of lines• Note down questions you may have
10
Why Is RE Important?• Flawed requirements a major cause of project
failure • 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”
11
RE and the Enterprise
Requirements Engineering
Marketing
Customer Relationship Management
Product Management
Product roadmap/ strategy, key
requirements
New and revised
requirements
Customer wishes, Reported problems
Realized changes and
enhancements
Market needs and trends,Price range
New Features
12
RE and Software Development
Requirements Engineering
Project Management
System Maintenance
Quality Assurance
Requests for clarification and
improvement
Requirement Artifacts Change requests
Status of change requests
Project plan, Approved goals
Requirements & constraints Design &
Development
Solutions, New technologies
Monitoring data, Elicited goals
13
Defining “Requirement”IEEE 610.12-1990:1. A condition or capability needed by a user to
solve a problem or achieve an objective2. A condition or capability that must be met or
possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents
3. A documented representation of a condition or capability as in (1) or (2)
14
Types of Requirements• Functional Requirements: specify the functionality the system shall
provide to its users– Ex.: The system shall allow the users to access their profile page after they
provide valid credentials• Quality Requirements (a.k.a., Levels of Service): define the quality
properties of the entire system or of a system component, service or function– Ex.: Reliability, performance under high loads etc.,– “-ilities”: Availability, flexibility, scalability, usability, robustness,
interoperability etc.,• Constraints: Organization or technological requirement that
restricts a way in which the system shall be developed– Ex.: Legal constraints (Sarbanes-Oxley), Project/Budget/ Schedule
constraints, Physical constraints etc.,
15
Goal of RE: Establishing a Vision in Context
• 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
16
Goal of RE: Establishing a Vision in Context
• Each system is embedded within a given context
• Context (a.k.a. “system context”): Part of the system environment relevant for– Defining, understanding & interpreting system
requirements
17
Visualizing “Vision” in “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
18
Framework For RE
System Context
Core Activities
Requirements Artifacts
Valid
ation
Man
agem
ent
19
Framework For RE
System Context
Subject FacetMaintain
information about objects/events in
the real world.
Usage Facet Desired workflows,
usage goals, different user
groups, interaction models, laws & standards etc.,
IT System FacetExisting hardware,
software, communication
networks, peripheral devices
etc.,
Development FacetProcess guidelines
and constraints, QA methods, maturity
models, development
environments etc.,
20
Relationship Between Facets
Subject Facet
Representation
PresentationApplication
Usage Facet Development Facet
IT System Facet
RE happens here!!
21
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
22
Visualizing The “Three Dimensions” Content
Documentation
Agreement
complete
vague
informal compliant with rules
individual views
consolidated views
Goal
23
Framework For RE
Core Activities
Documentation Document & specify elicited requirements as per defined
documentation and specification rules. Also
capture rationale and other relevant information
Elicitation
Negotiation1.Detect conflicts and make them explicit2. Resolve identified conflicts
24
Framework For RE
Elicitation
Identifying Requirement Sources
StakeholdersExisting Documentation
Existing System(s)Elicit Existing Requirements
Elicit already “known” requirements from relevant
sources
Developing new & innovative requirements
Typically not elicit-able and require collaborative and
creative processes
25
Techniques For Elicitation• Interviews• Workshops• Focus Groups• Observation of stakeholders/users etc.,• Questionnaires • Perspective-based readingUsually supported by “Assistance Techniques”– Brainstorming– Prototyping– Mind Mapping– KJ Analysis/Method– Elicitation Checklists
26
Framework For RE
Goals Stakeholder intention with
regard to the objectives, properties or use of the
system
ScenariosPositive/Negative,
Misuse,Exploratory,
Current-state/desired state,Main, alternative or exception
Solution oriented requirementsData Model,
Functional Model,Behavioral Model
Requirements Artifacts(Documented Requirements)
27
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 activitiesCheck adherence of activities to process, standards, guidelines etc.
• Validation of requirement artifactsCheck documented requirements w.r.t. content, documentation and agreements
Valid
ation
28
Validation Techniques• Inspections• Walkthroughs• Desk-checking (checking programs with
pen-paper)• PrototypingAbove are usually assisted by:• Validation checklists• Perspective-based reading• Verbalization of models• Creation of artifacts
29
Framework For RE• 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
Man
agem
ent
30
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)
31
Part 2
Requirements Practices in 577ab
37
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
38
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
39
Example of Capability RequirementRequirement: 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): User InputOutput(s): 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 fromthe system.
WinWin Agreements: [Agreement 1]
40
Levels of ServiceQuality attributes of the system:• Dependability– Reliability– Availability
• Usability– Ease of learning– Ease of use
• Performance• Maintainability• Portability• Interoperability• Reusability
41
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)
48
SSRD in Practice
In 2D
The true 3D view
Too much detail and too much
to capture
49
Change Management & SSRD?
50
Along came a
User Stories
SSRD
Story
What we thought… What was actually intended…
51
The User Story – 3Cs
Lightweight Ecstasy
Card
A promissory note of intent
Conversation
Discussion & clarification of intent (a.k.a requirement)
Confirmation
Acceptance Tests
52
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• Formalized via acceptance tests
53
INVEST-ing in User Stories
I = IndependentN = NegotiableV = ValuableE = EstimableS = SmallT = Testable
Commonly used acronym in the Agile World to describe attributes of a good user story:
54
Theory-WCustomer
Developer
STOP THIS MADNESS!
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)
Dr. Boehm
55
WinbookTheory - W
Requirement Specifications
Putting It All Together
User Stories
Facebook Gmail
56
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!
57
58
59
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”
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
60
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’
61
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
Boehm62