1

Requirements Engineering

Nupul Kukreja,Barry Boehm

7th September 2012

2

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

3

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.,

4

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

5

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 detail2. 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

6

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”

7

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

8

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

9

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

10

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

11

Visualizing The “Three Dimensions” Content

Documentation

Agreement

complete

vague

informal compliant with rules

individual views

consolidated views

Goal

12

Framework For RE

System Context

Core Activities

Requirements Artifacts

Valid

ation

Man

agem

ent

13

Framework For RE

System Context

Subject FacetMaintain

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 FacetExisting hardware,

software, communication

networks, peripheral devices

etc.,

Development FacetProcess guidelines

and constraints, QA methods, maturity

models, development

environments etc.,

14

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

Negotation1.Detect conflicts and make them explicit2. Resolve identified conflicts

15

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

16

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

17

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)

18

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

19

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

20

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

21

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)

22

Part 2

Requirements Practices in 577ab

23

RE Framework and 577

System Context

Subject FacetMaintain

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 FacetExisting hardware,

software, communication

networks, peripheral devices

etc.,

Development FacetProcess guidelines

and constraints, QA methods, maturity

models, development

environments etc.,

SSAD OCD SSAD LCP

QMP

24

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

Elicitation

Negotation1.Detect conflicts and make explicit2. Resolve identified conflicts

WinWinSessions

Winbook

25

RE Framework and 577

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

Result Chains

On-site Visits

WinWin Sessions

26

RE Framework and 577

Requirements Artifacts

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

Result Chains

OCD

WinbookSSAD

27

RE Framework and 577

Valid

ation

Man

agem

ent

IIV & V

PrototypingLifecycle Planning

Project Management

(Winbook)Prioritization

Feasibility Analysis

ARBs

Bugzilla Change Management

28

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

29

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

30

Example of Nominal 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]

31

Examples of Levels of Service• Dependability– Reliability– Availability

• Usability– Ease of learning– Ease of use

• Performance• Maintainability• Portability• Inter-operability (or binary portability)• Reusability

32

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)

39

SSRD in Practice

In 2D

The true 3D view

Too much detail and too much

to capture

40

Change Management & SSRD?

41

Along came a

User Stories

SSRD

Story

What we thought… What was actually intended…

42

The User Story – 3Cs

Lightweight Ecstasy

Card

A promissory note of intent

Conversation

Discussion & clarification of intent (a.k.a requirement)

Confirmation

Acceptance Tests

43

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

44

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:

45

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

46

WinbookTheory - W

Requirement Specifications

Putting It All Together

User Stories

Facebook Gmail

47

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!

48

49

50

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 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

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

Boehm53