1

®

Mastering Requirements Management with Use Cases Understand Stakeholder Needs

2

Objectives: Understand Stakeholder Needs Identify sources for stakeholder requests. Describe the Stakeholder Request Artifact. List techniques to elicit stakeholder

requests. Practice brainstorming techniques. Identify requirements from a customer-

generated specification.

3

Where Are We in the Requirements Discipline?

4

Understanding Needs: Activities and Artifacts

5

The process

6

What Are Sources for Requirements?

Analyst

Customer

Problem Domain

Users

Partners

Site Visits Domain Experts

Industry AnalystsCompetitive info

Initial RequestsBug ReportsChange Requests

Requirement SpecsBusiness Models

Business PlansPersonal Goals

7

What Does the Process Look Like?

Customer approved

Reworked specification

Rejected again

Reworked specification

Rejected by customer

Requirements specification

Customer

Ad-hoc requirements given to Project Team Project Team

8

What Problems Might Be Encountered? Stakeholders

Have a pre-conceived idea of the solution. Do not know what they really want. Are unable to articulate what they want. Think they know what they want, but do not recognize it

when it is delivered. Analysts

Think they understand user problems better than users.

Everybody Everyone sees things from

their own point of view. Believes everyone is

politically motivated.Stakeholder Analyst

??

9

Expressing Stakeholder RequestsSTRQ

STRQ STRQ

STRQ

STRQ

STRQ

“Students need to get grades

in a convenient manner”“Report cards can be printed”

“End of year results are automatically emailed to the student”

“Professors need to

know who is enrolled”

“Class lists are emailed at end of enrolment”

10

The Stakeholder Requests Artifact Is owned by the stakeholders. Contains all requests from the

stakeholders. Is consolidated from many sources.

E-mail, customer requirements specification, napkins, white boards, spreadsheets, and so on.

Used by project team to derive features and software requirements.

May contain references to any type of external source.

User Doc Specs

Design Specs

StakeholderRequests

Vision Document

SuplSpec

Use-Case Model

11

Techniques for Eliciting Stakeholder Requests

Review customer requirement specifications

Requirements workshop Use-case workshops Brainstorming and idea reduction

Interviews Questionnaires Role playing Prototypes Storyboards

12

Review Customer Requirement Specifications

Identify requirements. Recognize and label:

• Application behaviors• Behavioral attributes• Issues and assumptions

Ask the customer.

Requirements review

13

Review Customer Requirements Spec

Part 1 Review the customer requirements

specification. Look for possible requirements in the spec.

Part 2 Review the list of sample stakeholder requests. Refine the Vision document.

• Define the system boundary.• Revise the list of actors.

14

Feature in relation to need or requirement Needs

A reflection of the business, personal or operational problem/opportunity that must be addressed

Features A service which fulfills one or more stakeholder needs Expressed in short sentences or phrases Usually try to limit number Are not yet requirements Must be tracked

Attributes Describe feature Status,priority, level of effort,risk, stability, assigned to, release target,

reason

15

UserDocs

UserDocs

DesignDesign

Map of the Territory (Requirements Management)

Test Procedures

Needs

Features

Use cases and Software

requirementsTraceability

Problem

Problem

The Problem space

Solution space

The Product To be built

The Product To be built

Traceability

16

Requirements Workshops

Perhaps the most powerful method of elicitation (and validation) Many opinions at once

Feed on each other Improve and clarify each other Bring total knowledge to bear

Benefits Team spirit – involvement All stakeholders get to input

• Challenge

• Defend

• Compromise Preliminary system features available at the end ??

17

Requirements Workshops

Create consensus on the scope, risks, and key features of the software system.

Are directed by a facilitator. Duration: three to five days

Produce artifacts, such as: Problem statement Stakeholder Requests Key features Initial business object model Use-case diagram Prioritized risk list

18

Requirements Workshop Benefits

Provides a framework for applying other elicitation

techniques. Use-case workshops, brainstorming, storyboarding

Accelerates the elicitation process. Gathers all stakeholders together for an intense,

focused period. Promotes participation by everyone.

Results available immediatelyRequirements

19

Workshops: Plan and Execute

Sell the workshop

Establish team

Handle logistics

Send material

Prepare agenda

Facilitate

Keep on track

Record findings

Summarize conclusions

Synthesize findings

Condense info

Present to customer

Plan next steps

Pre-Workshop Production Follow-upSession

20

Requirements workshops

Preparing Selling concept Right stakeholders Logistics

• Room

• Lighting

• Equipment and facilities

• Travel

• Refreshments Pre meeting materials

• Project specific

• Out of the box

• 1 to 2 weeks early

21

Requirements workshops

Facilitator Should be outsider (trained in the role) Team only if:

• Trained in the process• Has team/consensus building skills• STRONG to control a meeting that can get heated• Is well respected

Has no input into the workshop A facilitator of a requirements workshop needs to be prepared for the following difficulties:

• Stakeholders know what they want but may not be able to articulate it. • Stakeholders may not know what they want. • Stakeholders think they know what they want until you give them what they said they wanted. • Analysts think they understand user problems better than users. • Everybody believes everybody else is politically motivated.

Responsibilities Set the tone Start and stop on time Establish and enforce the rules Introduce goals and agenda Manage the meeting Facilitate decision/consensus process Manage logistics Be sure all input Handle disruptive behavior

22

Preparation for the Workshop

Before the Workshop The facilitator needs to "sell" the workshop to stakeholders that should

attend, and to establish the group that will participate in the workshop. The attendees should be given "warm-up" material to review before they arrive. The facilitator is responsible for the logistics surrounding the workshop, such as sending out invitations, finding an appropriate room with the equipment needed for the session, as well as distributing an agenda for the workshop

Conduct the Session The facilitator leads the session, which includes:

• Giving everyone an opportunity to speak. • Keeping the session on track. • Gathering input for applicable Requirement Attributes • Recording the findings. • Summarizing the session and working out conclusions.

Consolidate Results After the requirements workshop, the facilitator (together with fellow system

analysts) need to spend some time to synthesize the findings and condense the information into a presentable format.

23

Tricks of the Trade

The table below lists a collection of problems and suggested solutions that could come in handy for the facilitator. The solutions are referring to a set of "tickets" that may sound unnecessary to have, but in most cases turn out to be very effective:

Problem Solution

Hard to get restarted after breaks. Anyone who is late gets a "Late From Break" ticket, use a kitchen timer to catch peoples attention, use a charitable contribution box (say $1 for each ticket used).

Pointed criticism - petty biases, turf wars, politics and cheap shots.

"1 Free Cheap Shot" ticket, "That’s a Great Idea!!" ticket.

Grandstanding, domineering positions, uneven input from participants.

Use a trained facilitator, limit speaking time to a "Five Minute Position Statement".

Energy low after lunch. Light lunches, breaks, coffee, soda, candies, cookies, rearrange room, change temperature.

24

Requirements workshops

Conducting the workshop Follow the agenda Problems

• Gimmicks Follow up

Documented• Approval

• Further clarification

25

Brainstorming

Helps find hidden “undiscovered” features/ needs Usually part of a workshop – may start with a brainstorming session Benefits

Encourages participation by all Expand on ideas of others No constraints Broad set of possible solutions

26

Brainstorming rules

Rules•No debate or criticism•No bad ideas•Use imagination•Generate as many ideas as possible•Build on others

27

Brainstorming Getting started

Facilitator states the objective of the session As soon as the objective is met and there are no new ideas your done Speak your idea, write it down No criticism/ or comments on the ideas other than expansions

End When your done 1 to 3 hours Never force close

28

Brainstorming Generates as many ideas as possible.

Rules for Brainstorming Clearly state the objective of the

session. Generate as many ideas as

possible. Let your imagination soar. Do not allow criticism or debate. Combine ideas.

29

Brainstorming Advantages and Disadvantages

Advantages Used anytime, anywhere. Good for groups. Good for high-level entities and assumptions. Amenable to some automation.

Disadvantages Susceptible to group processes. Unsystematic in “classic” form.

Takeda et al. 1993

30

Brainstorming

Prune Ideas down Concurrence on validity Further consideration yes/no

Group ideas Related ideas are grouped into categories

• Pick your classes• Reopen if grouping causes participants to want to add more

Feature definition A definition agreed to by all is created to be sure everyone

understands

Prioritize Money or marbles Critical/important/useful

31

Idea Reduction: Prune and Organize

Affinity Diagrams

32

Idea Reduction: Prioritize Ideas

Prioritize remaining ideas. Vote

• Cumulative votesBuy ideas

• Single vote Apply evaluation criteria

• Non-weighted• Weighted

33

Exercise Brainstorming

Gather ideas for stakeholder requests/needs.

Clarify and organize the ideas. Condense ideas. Prioritize remaining ideas.

34

Considerations for Selecting Elicitation Techniques

Requirements Purpose Specification for design and implementation. Selecting off-the-shelf packages. Legal contract for system procurement.

Knowledge Types Different methods acquire different types of knowledge.

Internal Knowledge Filtering Some knowledge can be retrieved from memory;

whereas, other knowledge cannot. Acquisition Context

Environment can influence elicitation techniques.

WP6:ACRE: Selecting Methods for Requirements AcquisitionMaiden N.A.M. & Rugg G., 1996

35

Purpose

Known COTS -

Unknown COTS -

System Procurement

System Development

Knowledge TypeBehavior

Process

Data -

Effectiveness of brainstorming for acquiring knowledge with different internal representations

Future System

Non-Tacit

Recognized

Taken-for-granted -

Working memory X

Compiled

Implicit -

Observable X

Conditions for Method Use

Meeting Needed

Time to Prepare

Time for Session

Time to Obtain

Number of Stakeholders

Friendliness

No Technologies

LEGEND

Good fit

Very good fit

X Weak fit

- Poor fit

Brainstorming Classification Example

36

Requirements allocation

Complex systems Divide and conquer rule

• Decompose into smaller more manageable sub-systems

• Done (divided small enough) when Distribution and functionality are optimized/ min cost- max flexibility Each sub-system lends itself to small team development Can test the piece stand alone

Derived requirements As we sub divide new “requirements” are generated Usually “smell” different than user requirements

Interface Requirements As we break apart we generate new “requirements” for communication

37

Requirements Issues and recommendations

Issues More “derived” requirements than original Can lead to inflexible systems Contracting services and sub contractors

Recommendations Traceability

• Need

• Feature

• Sub system requirement Partition and isolate

• Encapsulation

• Messaging vs data sharing

38

Interviews

Provide a simple and direct technique. Gain understanding of problems and

solutions. Consider all perspectives.

Users Customers Other stakeholders

39

Interview Tips

Avoid asking people to describe things they don’t usually describe. Example: Describe how to tie your shoes.

Avoid “Why…?” questions. Ask open-ended questions. Listen, listen, listen!

40

Gause & Weinberg, 1989

Context-Free Questions

Are high-level, abstract questions. Explore needs from stakeholder

perspective. User’s problems. Potential solutions.

Are always appropriate. Unbiased with application or solutions

knowledge. Are typically posed early in a project.

41

Gause & Weinberg, 1989

Types of Context-Free Questions

User questions Who are the users? What the key responsibilities of each user? What is the user’s background, capabilities,

environment? Process questions

What is the problem? How do you currently solve the problem? How would you like to solve the problem? Where else can the solution to this problem be

found?

42

Gause & Weinberg, 1989

Types of Context-Free Questions (cont.)

Product questions What environment will the product encounter? What business problems could this product create? What are your expectations for usability? reliability?

Meta-questions Do my questions seem relevant? Are you the right person to answer these questions? Are your answers requirements? Is there anything else I should be asking you?

43

Non-Context-Free Examples

Leading questions You need a larger screen, don’t you?

Self answering questions Are fifty items about right?

Controlling statements Can we get back to my questions?

Too long and too complex I have a three part question, ...

What are better questions to ask?

44

Typical Interview result

45

1994 by Alan M. Davis

Questionnaires

Give access to a wide audience. Appear scientific because of statistical

analysis. Apply to broad markets where questions

are well-defined. Are powerful, but not a substitute for an

interview. Assumptions:

Relevant questions can be decided in advance. Questions phrased so reader hears as

intended.

46

Observation/Contextual Interviews

Definition Observe real user in the field. Master-apprentice model: User explains his activities

and answers questions. Use real data in real situations.

Advantages Deliver requirements from situated activities. Probe inherent/tacit knowledge.

Issues Experienced interviewer needs to keep focused on

interview goals. Expensive and time-consuming to analyse data. Not always applicable to do in real situations.

Beyer & Holtzblatt, 1997

47

Shurtleff ‘94

Storyboard Benefits

Gathers and refines customer requirements in a user-friendly way.

Encourages creative and innovative solutions. Encourages team review. Prevents features that no one wants. Implements features in an accessible and

intuitive way. Eases the interview process. Avoids blank-page syndrome.

48

Prototypes

Demonstrate some or all of the externally observable behaviors of a system.

Are used to: Demonstrate understanding of the problem

domain. Gain feedback on proposed solution. Validate known requirements. Discover unknown requirements. Create simulations.

49

Why Use Prototypes?

Elicit and understand requirements. Prove and understand technology. Reduce risk. Enhance shared understanding. Improve

Cost and schedule estimates Feature definition

50

Eliciting Stakeholder Requests: Which Techniques to Use?

Developer Experience

Cu

sto

me

r/U

ser

Exp

eri

ence

Low Hi

Low

Hi

“Fuzzy problem”

“Catch Up” “Mature”

“Selling/Teaching”

Adapted from Alan Davis

1. Requirements Workshops

2. Brainstorming3. Use Cases4. Interviews5. Questionnaires6. Role Playing7. Storyboarding8. Prototyping9. Requirement

Reviews

Which of these tools might you use for each quadrant of the graph?

51

Eliciting Stakeholder Requests: Which Techniques to Use?

Developer Experience

Cu

sto

me

r/U

ser

Exp

eri

ence

Low Hi

Low

Hi

“Fuzzy problem”1, 2, 7

“Catch Up”1, 3, 4, 7, 8, 9

“Mature”1, 3, 4, 5, 6, 7, 8, 9

“Selling/Teaching”1, 2, 3, 4, 5, 6, 7, 8.

Adapted from Alan Davis

1. Requirements Workshops

2. Brainstorming3. Use Cases4. Interviews5. Questionnaires6. Role Playing7. Storyboarding8. Prototyping9. Requirement

Reviews

Which of these tools might you use for each quadrant of the graph?

52

Review: Understand Stakeholder Needs

1. What are some elicitation techniques for understanding user needs?

2. What is the relationship between a need and a feature when expressed by a stakeholder during Understand Stakeholder Needs?

3. What should you do with a need that is expressed as a feature?

4. What does the ACRE Framework say about requirements elicitation?

5300

ISC = BlueIPD = RedCRM = Green

Marketing/Sales

ProductionDistribute Product

Order MgmtSales Adm

ChannelEnd-UserCustomer

Direct ShipDrop ShipSpare Parts MgmtCI144Product Parts Support PlanSAP - P

Replenishment

Weekly CollaborationCustomer Profile Data base

PC Sales TrackingTechnical Info AAPRosetta Net

ConfiguratorAdvertisingCustomer RegistrationTechnical SupportStandard Help Center

PartnerInfoMarketing Deliverables

Market PlanningProduct Info (OPIC/M), Prod AssumAnnounce, CTPLife Cycle/Transition ManagementPricing: BB, Entitled,WW, Realtime Software RoyaltiesConfigurationIndustry naming: Rosetta Net PIPSPlanning: Demand, Supply, Souring...

ConfiguratorSAP - F

Central PlanningWeekly PRGWeekly Executioni2Weekly Remix

Procure Parts

Plan Demand/Supply

MTM/PN/BB MgmtProductManager

BoM StructureRules

EC Release & MgmtTesting BB and AVLAspectTechnology Planning / Cost Takedown Projection

ReplenishmentParts Mgmt

Aspect

DevelopProduct

Building Block Transition Management

MTMProduct Family

andBuilding Blocks

-- Dynamic Configure to Order

-- Pre-Planned Standard Offerings

Today Tomorrow

e-Commerce

e-Commerce

System perspective

54

Credit CheckCustomer eligibilityPricingInvoicing/BillingReportingOrder RoutingDelivery SpecsReturns

MKTG/SALES FULFILLMENT

Customer

Customer Driven Navigation

Config Rules & Choice

Place an order

A

C

ORDER(Config & Order

Instructions) Demand PlanningLTST - Cust Collaboration

Supply PlanningS/D MatchScheduling (order)REMIX (Component)Logical Reservation SupplySourcing/ BalancingProfit OptimizationProduction Optimization

Capacity /SchedulingAllocation MethodologyDATA

Customer Config / OrderRequest date

Supply info - componentProduction CapacityBBs? / PNs

PLANNING ENGINE (ACTIVITIES)

Orders:What,When,How Many

Permissible Builds &Rules & Structures

(What, How)

Offering DefinitionPF / BBs

Product FamilyBB FamiliesRulesBB Names -> P/Ns

PF = Unique Super BOM = MT

Contract DBEntitlement, T/Cs

DEVELOPMENT PRODUCTION

WE

B IN

TE

RF

AC

E

B

One Configurator

A, B, C, D = Order, Fulfillment Information Flow

1, 2 = Development, Production Information flow

1

Engineering & Materials Planning

Items(P/Ns)ComponentsAssemblers

Structure Placement & Connection Selection RulesUsers

Floor control systemsMaterials PlanningScheduling

2

D

?

Availability to Promise (ATP)

Permissible Sales & Rules (What)