requirements management with use cases module 5: understand stakeholder needs requirements...

Requirements Management with Use Cases

Module 5: Understand Stakeholder Needs

Requirements Management with Use Cases

Module 5: Understand Stakeholder Needs

Requirements Management with Use CasesCopyright © 1998-2001 Rational Software, all rights reserved 2

Where Are We in the Requirements Discipline?


Objectives: Understand Stakeholder Needs

Identify sources for needs/requirements List problems in eliciting needs Identify techniques to elicit needs/

requirements Explain context-free questions Describe a requirements workshop Practice brainstorming techniques Identify requirements from a customer-

generated specification Describe business modeling


Understanding Needs: Activities and Artifacts


What Are Sources for Our Requirements?

Customer

Users Problem DomainDomain ExpertsIndustry AnalystsSite VisitsCompetitive info

Bug ReportsChange Requests

Requirement SpecsBusiness PlansPersonal GoalsBusiness Models

Analyst

Partners


Moore, 1991

TimeINNOVATORS• Technical Influence• No Money• Discontinuous innovation• Company specific

EARLY ADOPTERS• Have money• Strong Influence• Specific features

EARLY MAJORITY• Pragmatists• Mission critical systems• Reliability• Whole product solutions

LATE MAJORITY• Conservatives• Price sensitive• Simplify• Commodity• Demanding

LAGGARDS• Skeptics• Price

0%

5%

10%

15%

20%

25%

30%

35%CHASM”“Crossing the

What Are the Characteristics of Our Customers?%

of

Tar

get

Do

mai

n C

ust

om

ers

Technology AdoptionProfile

(the lifecycle of the technology)


What Problems Might Be Encountered?

Stakeholders Do not know what they really want Are unable to articulate what they want Think they know what they want, but don’t

recognize it when delivered Analysts think they understand user

problems better than users Everybody believes everyone else is

politically motivated


What Does this Process Look Like?

CustomerDevelopment

Requirements Spec

Approved !

Rejected

Reworked Spec

Rejected

Reworked again

Ad hoc requirements


Techniques for Eliciting Stakeholder Needs

Interviews Questionnaires Role playing Requirements workshop Use cases Brainstorming and idea reduction Storyboards Prototypes Review of customer requirement specifications Business models


Interviews

Provide a simple and direct technique Gain understanding of problems and solutions Consider all perspectives

Users Customers Other stakeholders


Gause & Weinberg, 1989

Context-Free Questions

High-level, abstract questions Explore needs from stakeholder perspective

User’s problems Potential solutions

Always appropriate Unbiased with application or solutions

knowledge Typically posed early in a project



Types of Context-Free Questions

User questions Who are the users? What are their key responsibilities? What are their 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?



Types of Context-Free Questions

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?


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?


Interview Tips

Don't ask people to describe things they don’t usually describeExample: Describe how to tie your shoes.

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

TP3: Stakeholder Requests: Interview Template


1994 by Alan M. Davis

Questionnaires

Give access to a wide audience Appear scientific because of statistical

analysis Are applicable to broad markets where

questions are well-defined Can be powerful, but not a substitute for an

interview

Assumptions: Relevant questions can be decided in advance Questions phrased so reader hears as intended


Tools and techniques Analyst learns and performs user’s job Analyst performs a scripted walkthrough

Advantages Gain real insights into the problem domain Understand problems users may face

Role Playing


A Requirements Workshop

Accelerates the elicitation process Gathers all stakeholders together for an intensive,

focused period Is guided by a facilitator Provides opportunity for all stakeholder feedback Presents results immediately Provides a framework for applying

other elicitation techniques


Workshops: Planning and Executing

• Sell the workshop

• Establish team• Handle logistics• Issue warm-up

material• Prepare agenda

• Facilitate• Keep on track• Record findings• Summarize

conclusions

• Synthesize findings

• Condense info

• Present to customer

• Determine next steps

PREWORKSHOP SESSION PRODUCTION FOLLOW-UP


Use-Case Model

How Do Use Cases Help Elicit Needs?

Provide stakeholders’ point of view Promote discussion: Why is the system needed?

Who will interact with the system (actors)? What do users want to achieve by using the system

(use cases)? What interfaces should the system have?


Rules for Brainstorming

Brainstorming

Clearly state the objective of the session

Generate as many ideas as possible Let your imagination soar Do not allow criticism or debate Mutate and combine ideas


Exercise 5.1: Utilize Brainstorming Techniques

Gather ideas for features Clarify and organize the ideas Condense ideas Prioritize remaining ideas


Shurtleff ‘94

Storyboards

Movies, cartoons, and animated features all begin with storyboards that tell: Who the players are (actors) What happens to them When it happens


Shurtleff ‘94

Storyboard Benefits

Help gather and refine customer requirements in a user friendly way

Encourage creative and innovative solutions Encourage team review Prevent features no one wants Ensure that features are

implemented in an accessible and intuitive way

Ease the interviewing process Avoid the blank-page syndrome


Prototypes

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

Used to: Gain feedback on proposed solution Demo the problem domain Validate known requirements Discover unknown requirements

Prototyping tools Demo programs Simulations


Why are Prototypes Dangerous?


Why Use Prototypes?

Elicit and understand requirements Prove and understand technology Reduce risk Enhance shared understanding Improve cost and schedule estimates Improve feature definition


Review Customer Requirement Specs

Identify requirements Look for and label:

• Application behaviors• Behavioral attributes• Issues and assumptions

Ask the customer!

requirements review


Exercise 5.2: Review System Specifications

Review the 2001 Elevator System Specifications

Look for possible requirements Mark and number each requirement


Business Models

Model organization structure and dynamics Business processes Organizational structure Roles and responsibilities

Visualize the organization and its processes Help understand current problems Identify potential improvements Derive system requirements needed to

support the organization

Products Deliveries Events


Business Models Are Input to System Requirements

Responsibilities of actors supported by the system Business processes to automate in the system Types of information to manage Traceability between business and system model

Traceability


Business Use-Case Model

Support Customer

Customer

VendorDevelop Product

Market and Sell ProductRegulatory

Body

Business actor: Someone or something outside the business that interacts with the business.

Business use case: A sequence of actions a business performs that yields an observable result of value to a particular business actor.

Example: Business Use-Case Model for a Generic Software Solution Vendor


Mapping Guidelines: Business to System Use-Case Model

Business actor system actor Business worker system actor or use case

System actor (if the worker interacts with the system) System use case (if the worker is automated by system)

Business use case subsystem or use case

Application System or Subsystem

Business Workers

Business Use Cases

Business Actor

System Actor


Business Object Model

Shows structural elements Business entities Business workers Responsibilities Relationships

Is visualized by Static views–the class diagram Dynamic views–sequence diagram,

collaboration diagram, and state chart diagram Behavioral views–the activity diagram


Capture Vocabulary: Make a Domain Model

Subset of Business Object Model Visual model of business objects Benefits:

Formalizes the vocabulary for the project Simplifies reasoning about different terms Describes relationships between terms Provides visual representation of relationships


Domain Model Example: RU e-st

Market transaction Transfer

Trade Customer Trading Acct. Transaction1..2 11..* *

Limit Transaction


Eliciting Needs: Which Tools to Use?

Developer Experience

Cu

sto

mer

/Use

rE

xper

ien

ce

Low Hi

Low

Hi

“Fuzzy problem”

“Catch Up” “Mature”

“Selling/Teaching”

Adapted from Alan Davis

Requirements Workshop

Brainstorming

Use Cases

Interviews

Questionnaires

Role Playing

Business Modeling

Storyboarding

Prototyping

Requirement Reviews

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


Review: Understand Stakeholder Needs

1. What are some problems encountered in trying to understand user needs?

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

3. What is the basis of the “context-free” question?4. How can a requirements workshop accelerate

the elicitation process?5. How are use cases helpful in eliciting user

needs?6. What would you look for in a customer-generated

requirement specification?7. What is business modeling?

requirements management with use cases module 5: understand stakeholder needs requirements...

Documents