Software Requirements v10 Full [PDF]

Zitiervorschau

Software Requirements

Neil Potter Mary Sakry The Process Group [email protected] www.processgroup.com US 972-418-9541

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

1

Have You Had Any of These Experiences? ❏  Customers are too busy to provide requirements. ❏  Project scope never clearly defined. ❏  Managers or marketing claim to speak for the users. ❏  Users claim that all requirements are critical. ❏  Developers encounter ambiguities and they guess. ❏  Requirements change continuously after approval. ❏  Changes are accepted with minimal evaluation. ❏  Requirements changes get lost. ❏  Functionality is requested and built, but never used. ❏  The specification is satisfied, but the customer is not.

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

2

Agenda - 1 Page

■  Introduction to Software Requirements Engineering…….. 3 ■  Requirements Development and Management Process… 8

•  Identify users……………………………………………………... •  Define vision and scope……………………...…………………. •  Understand user needs.………………………….……………... •  Define quality attributes………………………….……………… •  Define business rules………………………….………………… •  Derive functional requirements………………..….………..…... •  Analyze and verify requirements……………...….……………. •  Manage requirements changes …..…………..….……………. •  Requirements specification approaches……………………….

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

9 12 17 36 38 43 53 77 48

3

Agenda - 2 Page

■  Summary: Requirements Good Practices …..……………. 86 ■  Improving Your Requirements Processes …..…………….89 ■  Further Reading ……………………….……………………..91

Further resources at: http://www.processgroup.com/downloads.htm

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

4

Introduction to Software Requirements Engineering

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

5

What is a Software Requirement? A condition or capability needed by a user to solve a problem or achieve an objective*.

© Copyright 2001-2014 The Process Group.

*(IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology”, computer.org) www.processgroup.com Version 10.0 6

[Based on K. Wiegers Software Requirements]

Three Levels of Software Requirements #1: Business Requirements

Vision and Scope #2: User Requirements

Quality Attributes

Business Rules Other Nonfunctional Requirements

User Requirements External Interfaces System Requirements

#3:Functional Requirements

Constraints

Software Requirements © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

7

Benefits of Requirements Practices Clarifying the target – so you can arrive there sooner with less cost ■  Creating and reviewing multiple views of requirements helps

satisfy customer expectations. ■  Controlling requirements changes minimizes the adverse

impact of changes. ■  Emphasizing quality requirements reduces rework,

maintenance and wasted time implementing unnecessary functions. ■  Enabling testing to be based on requirements. © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

8

Relative Cost to Correct a Defect

Relative Cost of Fixing a Defect 70 60 50 40 30 20 10 0 Requirements Design

Code

Development Acceptance Testing Testing

Operation

Development Phase [Robert Grady, Applications of Software Measurement] © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

9

Requirements and a Software Life Cycle High level definition of the requirements for the purposes of estimation (Thin Spec., Backlog)

Planning

Requirements changes are processed here (ò)

ò

Prototype Architecture Build 1

!R!Requirements equirements Gathering Gathering

ò

ò

ò

Prototype high-risk areas Iron out the problems with the life cycle on Build 1 © Copyright 2001-2014 The Process Group.

ò Build 2

ò Build 3

Reqs. Analysis Design Code Reqs. Analysis Test Design Integrate? Code Release? Reqs. Analysis Test Design Integrate Code Release? Test Integrate Release [Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

10

Requirements and Scrum / Agile Requirements changes are processed here (ò) Requirements (user stories)

Backlog

Planning

Sprint 1

ò

Reqs. Analysis Design Code Test Integrate Test Release

© Copyright 2001-2014 The Process Group.

Sprint 2

ò

Sprint 3

Reqs. Analysis Design Code Test Integrate Test Release

[Based on K. Wiegers Software Requirements]

ò

Reqs. Analysis Design Code Test Integrate Test Release

www.processgroup.com

Version 10.0

11

Requirements and The V-Model V-Model

From: en.wikipedia.org/wiki/VModel_(software_development)

An alternative

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

12

The Requirements Job ■  Learn about the business, its language, and

the objectives of the solution.

■  Sort out requirements information and

structure into set of usable requirements.

■  Help identify and remove requirements

ambiguities.

■  Help establish requirements priorities. ■  Clarify scope and context of solution with other

systems.

■  Educate users / customers on how to use / read

•  Elicitation •  Analysis •  Specification •  Verification •  Validation •  Requirements Management

the requirements.

■  Assist in decisions regarding requirements

changes and tradeoffs.

■  Manage changes with stakeholders. © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

13

Your Class Expectations

•  Your job. •  Requirements problems / issues? •  Expectations for this class?

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

14

Exercise: Pick a Project to Work On •  Write down your top 1-2 project deadlines/deliverables related to your current work (e.g., the delivery of a current product, changes to an existing product, or improvement goal). For example: –  HUT system v1.6, August 23rd, 20YY. –  System X moved to platform Y with web access. •  Write down your top 3-5 requirements problems (and/or risks) related to each project. For example: –  No customers defined. –  Multiple current versions of the requirements. –  Customers change requirements too fast, too late - little team evaluation. –  Requirements document contains mostly design and implementation suggestions.

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

15

Requirements Development & Management Process Identify Users

Start Manage Requirements Changes

Define Vision & Scope

Analyze & Verify Requirements

Understand User Needs

Derive Functional Requirements

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

16

Identify Users Identify Users

Start Manage Requirements Changes

Define Vision & Scope

Analyze & Verify Requirements

Understand User Needs

Derive Functional Requirements

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

17

User Classes ■  Distinct groups of users for a product:

•  Could include other systems as users of your system ■  May differ in: e.g., doctor, nurse, office manager

•  frequency of use of application •  functions used •  tasks to be accomplished •  education and skill level •  privilege or security level

Your User System System

■  Identify user classes and their characteristics

early.

■  Document user classes in the requirements. ■  Not all user classes are equally important to you. © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

18

User Class Example ■  Scheduling / billing system User Classes and tasks:

•  Office assistant: Ø  Daily patient scheduling, patient billing •  Office manager: Ø  Monthly reporting, complaint management •  System administrator: Ø  Database maintenance and recovery •  Doctor: Ø  Schedule summary, scheduling strategy changes (#minutes per patient, blackout days, on-call doctor availability, emergency patient information access, remote data access) A lack of understanding of your user classes can lead to major omissions in functionality and reduced customer satisfaction. © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

19

The Product Champion ■  Primary interface between development

and customer communities:

•  Represents a user class or system interface ■  Respected members of the user community. ■  A real user; not a manager, sponsor,

Your User System System

or simulated user.

■  Has a vision of what the product should be and do. ■  Reconciles incompatible customer requirements. ■  Must be empowered to make binding decisions.

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

20

Potential Product Champion Activities Planning:

●  Define scope and limitations of system ●  Define external boundaries and interfaces ●  Plan migration pathway from current system to new one

Requirements:

●  Interview other users they represent ●  Resolve conflicting requirements ●  Set implementation priorities ●  Define quality attributes ●  Participate in requirements inspections (reviews)

Change Management:

●  Evaluate / prioritize bug fixes and enhancements

Documentation: ●  Contribute to user manuals and on-line help ●  Help prepare classes and tutorial materials Advocacy:

●  Help “sell” the system to customer communities

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

21

Product Champion Hierarchy for a Large Project Project Manager

Analyst 1

Analyst 2

Analyst n

Product Champion 1

Product Champion 2

Product Champion n

Support Team 1

Support Team 2

Support Team n

user

user

user

© Copyright 2001-2014 The Process Group.

user

user

user

[Based on K. Wiegers Software Requirements]

user

user

www.processgroup.com

user Version 10.0

22

Exercise: User Classes & Product Champions ■  Select a project ■  Determine user classes

•  May differ in: Ø  frequency of use of application Ø  functions used Ø  tasks to be accomplished Ø  education and skill level Ø  privilege or security level ■  Determine at least one product champion for each user class ■  Determine activities you need the Product Champions to do User Class Name

Champion Name

Champion Activities

Uclass#1 Uclass#2

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

23

Define Vision and Scope Identify Users

Start Manage Requirements Changes

Define Vision & Scope

Analyze & Verify Requirements

Understand User Needs

Derive Functional Requirements

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

24

Three Levels of Software Requirements #1: Business Requirements

Define Vision & Scope

Vision and Scope #2: User Requirements

Quality Attributes

Business Rules Other Nonfunctional Requirements

User Requirements External Interfaces System Requirements

#3:Functional Requirements

Constraints

Software Requirements © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

25

Vision and Scope Document 2. Business Requirements 2.1. Background 2.2. Business Objectives (Success Criteria) Customer Needs

2.3 2.4

Vision and Scope Assumptions, Dependencies, Risks, Out of Scope

■  What business problem are you trying to solve? ■  What’s the motivation for solving this problem? ■  What would a highly successful solution do for you? ■  How can we judge the success of the solution? ■  What’s a successful solution worth? ■  Which business activities and events should be included in

the solution? Which should not?

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

26

Vision and Scope Document 2. Business Requirements

e.g.,

2.1. Background 2.2. Business Objectives (Success Criteria) Customer Needs

2.3 2.4

Vision and Scope Assumptions, Dependencies, Risks, Out of Scope

•  Centralize all orders from worldwide customers. •  Provide a web system for order management by 20XX. •  Reduce order management costs 30% by 20YY.

Simple example

1)  Allow customers world wide to make and track purchases for all consumable 2)  3)  4)  5)  6) 

products using a web browser. Allow payment to be made electronically using existing or new accounts. Provide customer with web access to accounts payable and receivable functions on existing accounts. Capture needs profile of each customer for future marketing use. Provide customizable reporting of system use to executive management (reporting to be defined). ……

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

27

Another Example - Customer Needs Req # CA 1.1 CA 1.2 CA 1.3 CA 1.4 CA 1.5 CA 1.6 CA 1.7 CC CC CC CC

1.1 1.2 1.3 1.4

TD 1.1 TD 1.2 TD 1.3 PF 1.1 PF 1.2 PF 1.3 FP FP FP FP

1.1 1.2 1.3 1.4

CURRENT ACCOUNTS A/C to A/C transfer (XXX accounts) A/C to A/C transfer (to other local banks) Transfer from XXX A/C to a Beneficiary through a XXX Branch A/C to A/C transfer (to international banks thru pre-defined transfer) Utility bill payments Request additional XXX ATM card Report lost/stolen XXX ATM card with option to request a replacement CREDIT CARD Apply for a XXX VISA / MasterCard XXX VISA/MasterCard credit card payment with the option to pay for another XXX credit card Transfer from XXX VISA / MasterCard to Current A/C Change of XXX VISA / MasterCard address TIME DEPOSIT Book a Time Deposit from a current account Commission Rate Inquiry/Display Rates Change interest account assignment PERSONAL FINANCE Apply for Consumer Loan Inquiry on loan outstanding amount, installment amount, due amount View loan statement FINANCIAL PLANNING Plan Details Payment Details Investment Details Benefit Details

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

28

Vision and Scope 2.  Business Requirements 2.3

Internal & Corporate Clients

Vision and Scope

Context Diagram •  The system name goes in the circle •  Outside boxes represent major external entities •  Flows between externals and the system comprehend customer needs •  Diagram helps clarify/refine requirements © Copyright 2001-2014 The Process Group.

Customer needs 1.  Make/track purchases 2.  Electronic payment 3.  Setup customer web access 4. Needs marketing 5. Exec. Mgt. reporting

1+2. Make/ track Response

1+2. Make/ track Request

Buy/track Request

Auto Stock Request

Suppliers

Our System

Retail Stores Buy/track Response

Auto Stock Response

3. New a/c Set up + 4. Needs Marketing

Exec. Mgt.

[Based on K. Wiegers Software Requirements]

Sales Staff www.processgroup.com

Version 10.0

29

Context Diagram Example - 1 Chemist vendor catalog info

vendor catalog queries

Buyer

requests for chemicals

chemical order status requests for new chemicals

chemical usage and disposal reports

Health & Safety Dept.

chemical containers

requests for reports

Chemical Tracking System

information for new containers

[Based on K. Wiegers Software Requirements]

Chemical Stockroom

requests for records of hazardous chemical training

scanned barcode

Barcode Reader

© Copyright 2001-2014 The Process Group.

inventory reports chemical containers

records of hazardous chemical training

Training Database

www.processgroup.com

Version 10.0

30

Context Diagram Example - 2

Sys. Admin

config and d ure users evices

config

Competitor Data

. repo

rt

edit design

validate design

design validation issues

Graphics designer

Graphics Editor

request status report

data request parts list get component specs

Production Coordinator

status report

Management

© Copyright 2001-2014 The Process Group.

editable design copy

[Based on K. Wiegers Software Requirements]

Component Database

www.processgroup.com

Version 10.0

31

Vision and Scope Document Assumptions (Facts you are assuming to be true or false)

2. Business Requirements 2.4 Assumptions, Dependencies, Risks, Out of Scope

Move risks to project risk plan during planning

1

The OS will be Win vX only.

Notes

2

All data formats will remain unchanged (i.e., version X)

3

Only systems 1-4 will be supported.

Dependencies (Tasks or deliverables your team needs from others) 1

Installation of Win vX at the client site complete on mm/dd.

2

Database update from supplier A complete on mm/dd.

3

Analysis report from team B complete on mm/dd.

Risks (Potential problems) 1

Installation of Win vX at the client site is >1 week late.

2

Database update from supplier A is unstable / unusable.

3

Installation of Win vX at the client site is >1 week late.

Out of Scope

© Copyright 2001-2014 The Process Group.

1

Win vY support.

2

Cloud support.

3

Integration with ABC toolkit.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

32

Exercise: Business Requirements and Context Diagram ■  Write 1-2 Business Objectives for one of your projects ■  Write several Customer Needs: •  Include the needs of a typical customer and the needs that are not being met •  Include problems that customers are currently having that the product will address ■  Draw a context diagram (Vision Statement) for your current

project:

•  The system name goes in the circle •  Identify major external entities (can include user classes) •  Define the flows between externals and the system (summarizes customer needs)

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

33

Understand User Needs Identify Users

Start Manage Requirements Changes

Define Vision & Scope

Analyze & Verify Requirements

Understand User Needs

Derive Functional Requirements

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

34

Three Levels of Software Requirements #1: Business Requirements

!

Vision and Scope #2: User Requirements

Define Vision & Scope

! Quality Attributes

!

Business Rules Other Nonfunctional Requirements

User Requirements External Interfaces System Requirements

#3:Functional Requirements

Constraints

Software Requirements © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

35

The Need for Customer Involvement Customer involvement is a critical factor in software quality.

Expectation Gap Surprise!

Time

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

36

Incremental Requirements Definition Don’t necessarily clarify all user needs for the whole system initially. Consider focusing on areas that are the: ■  Highest priority ■  Most frequently used ■  Highest revenue ■  Largest user class ■  Core features to support

architecture ■  Reqs. for regulatory

compliance

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

37

Sources of Software Requirements - 1 Interviews

Documents •  descriptions of current or competing

products

•  focus groups of

representative customers •  use case workshops with

•  standards or regulations •  help desk problem reports

users + developers •  product champions as key

customer representatives

Questionnaires and marketing surveys •  good for large number of responses •  ask the right people the right questions! •  run a pilot first – difficult to ask clear questions! © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

38

Sources of Software Requirements - 2 Watch users do their jobs •  create workflow diagrams •  “day in the life” studies •  look at what information the

Prototyping •  useful for

requirements, design, and implementation

user has when performing a particular task

Task analysis

Event-response tables

•  apply methods like use cases or

scenarios •  focus on user objectives, rather than system functions © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

•  identify external stimuli and

describe system responses

www.processgroup.com

Version 10.0

39

Some Requirements Elicitation Tips ■  Keep asking “WHY?” to drill down to real needs.

•  •  •  • 

Look for hidden details that might be important. Try to surface assumptions. Ask about the rationale behind requirements. Clarify points you don’t understand.

■  Ask for examples and for specific details. ■  Ask open-ended questions.

•  “What else could...?”, “Would anyone ever...?” ■  Probe around the exceptions.

•  “What happens when...?” ■  Are there any constraints or rules

to which the product must conform? © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

40

Organizing Requirements Information Quality Attribute

Constraint

Business Rule

Solution Idea

External Interface Requirement

Data Definition

Functional Requirement

Use Case or Scenario Business Requirement © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

41

Requirements Classification Cues - 1 ■  Business Requirement •  statement of a customer or business benefit Ø  “increase market share by X%” Ø  “save $Y per year on electricity by replacing inefficient units” Ø  “save $Z in maintenance costs by retiring legacy systems” ■  Use Case •  describes a task a user would need to do Ø  “print a mailing label for a package” Ø  “manage a queue of samples to be analyzed” Ø  “calibrate the pump controller” ■  Business Rule •  describes a policy, standard, or regulation Ø  “only the lead site operator can override the safety alert” Ø  “must comply with FDA standard 137-B” Ø  “only system admin can modify system files” Ø  “only animators can modify a character file” © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

42

Requirements Classification Cues - 2 ■  External Interface Requirement •  describes connections between your system and outside world Ø  “must read signals from all Nixdorf 3XXX pressure sensors” Ø  “must import files in comma-separated value format” Ø  “GUI button labels must conform to product family style guide” ■  Quality Attribute •  describes how well the system performs some function Ø  “mean time between failure >= 100 hours” Ø  “noise level cannot exceed 78 dB at 20 meters” ■  Constraint •  states a limitation on design or implementation choices Ø  “must run in 4 XX of memory” Ø  “must be backwards compatible with 3.X versions” Ø  “must use Oracle N.1 or later run-time engine” © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

43

Requirements Classification Cues

-3

■  Data Definition •  describes a data item or structure Ø  “format of a charge number is a 3-character department prefix, a hyphen, and a 6-digit project code” Ø  “default value for the control temperature is 75.0 ºF” ■  Solution Idea •  suggests one possible way to solve the problem Ø  “user selects the desired value from a dropdown list” Ø  “program must be written in Java” Ø  “got to be on the cloud” ■  Functional Requirement •  states how system behaves under certain conditions Ø  “if the pressure exceeds 40.0 psi, the amber pressure warning light must come on” Ø  “user must be able to sort the project list alphabetically” © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

44

Practice Session: Classifying Requirements Classify each of these requirements into the right category: 1. Each case status record will indicate the status code, date of status change, and user ID of the updater. 2. A person younger than 16 may be issued a driver’s license only if he or she has passed an approved driver training class. 3. The user must be able to print a boarding pass for a flight. 4. The system table shall be synchronized daily with the desktop phone system. 5. Permit the use of LU6.2 peer-to-peer network protocol. 6. The system must reduce cafeteria operating costs by 15% within 12 months following initial release. 7. All code must conform to the 4.0 standard. 8. The system shall use duplicated (RAID) disks to prevent data loss. 9. A trained clerk shall be able to check in a guest in 2 minutes or less. © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

45

Use Cases

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

46

Gathering Requirements Through Use Cases ■  Provides a method to capture user requirements ■  Focus on actual, but abstracted (“essential”) usage scenarios ■  Ask users:

“Describe a task (or goal) you need to perform” -  Spell check all database fields with 1 click and output result on screen or file -  Save data in formats A, B and C on local machine and/or cloud -  Import from formats A, B, C – single file or batch

not: “What features would you like?” -  Spelling check -  Save -  Import ■  Explore sequences of user actions and system responses ■  Derive functional requirements and test cases from use cases © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

47

Use Case in Context Draft User Reqs. Verified User Reqs. User Workshops

User Reqs.

Draft Test Cases

Shared Vision v1.0

Verified Models Draft Models

Business Rules

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

48

User Story vs. Use Case User Story

As an account owner, I want to withdraw cash As an account owner, I want to deposit cash

1-liners can be ambiguous and lead the developer to guess

As an account owner, I want to deposit check(s) As an account owner, I want to deposit foreign check(s)

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

49

Use Case Workshop Approach Use Case Name:

Raw Interview Data Interview Data

Category

Search a document collection for a specific template for a specific type of project

Use Case

A purchasing agent can modify an order only with written permission from the customer

Business Rule

View an order stored in the database. Interview Source Operator

User Classes: all Preconditions: database contains orders, user identity is verified Postconditions: order has been shown Actor Actions

Customer Manager

user enters order number he wants to view

System Responses order details are displayed

user enters order number, but it doesn’t exist

error message: order number not found

etc. for all normal and exception pathways

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

50

Benefits from the Use Case Approach ■  User-centric: user’s terminology is applied. ■  Task-centric: reveals requirements to get

work done.

■  Helps analysts understand application domain. ■  Avoids building unnecessary functionality. ■  Permits early drafting of functional test cases. ■  Helps set implementation priorities on functional

requirements (i.e., which is the most important user task?)

■  Permits tracing requirements back to voice of the

customer.

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

51

Examples of Use Case Statements (also called User Stories, “As user X, I want to…”)

■  Order a bottle of chemical X from vendor A or B. ■  Search a document collection based on criteria A, B, C. ■  See which flight has the lowest fare from city A to city B

on a specified date. •  with an advance ticket purchase •  without an advance ticket purchase ■  Pay for a purchase with payment options A, B, C. ■  Output data every 3 milliseconds in JJU format. ■  Update interest rate based on loan database update.

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

52

Graphical Option - Use Case Diagrams Receive Chemical

Training Database

Obtain Material Safety Data Sheet Search Vendor Catalogs Request a Chemical Manage Inventory

Requester

Takes up lots of space!

Chemical Stockroom Staff

Check Order Status

Health & Safety Dept.

Dispose of a Chemical

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

Buyer

www.processgroup.com

Version 10.0

53

Sample Use Case for an ATM - 1 [Elicitation questions] Name: Withdraw Cash [What does the user want to do?] Actor: Account Owner [Who?] Description: The user withdraws a specific amount of cash from a specified account.

Trigger: Account Owner selects Withdrawal action [What initiates it?] Preconditions: [What state is the user / system before the event?] 1. The Account Owner is logged in to the ATM. 2. The Account Owner has at least 1 account with a positive balance. 3. The ATM contains cash.

Postconditions: [What state is the user / system after the event?] 1. The requested amount of cash has been dispensed. 2. The account balance is reduced by the amount withdrawn plus any fees. 3. The ATM cash balance is reduced by the amount withdrawn.

Priority: High © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

54

Sample Use Case for an ATM - 2 Normal flow: [What is the ideal flow?]

Actor Actions 1. 3. 5. 7.

System Responses

Select Withdrawal action. 2. Display user’s accounts. Select desired account. 4. Ask user to enter amount. Enter desired amount. 6. If amount is okay, dispense Remove cash from dispenser. cash and debit account.

Alternative Flow: [Any alternatives?] • Step 4: display list of common amounts, let user select one Exceptions: [Conditions the system needs to deal with?] • Step 6: amount is not a multiple of $20.00 • Step 6: amount exceeds $400 • Step 6: amount exceeds account balance • Step 6: amount exceeds cash available in ATM © Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

55

Use Case Template User story Description Screen# Trigger Preconditions Postconditions Normal Flow Alternative Flows Exceptions Business Rules Assumptions Notes and Issues

■  ■  ■  ■  ■ 

User / Actor

System Response

Note / Issue

Resolution

Actor: a human user or other system that provides the trigger Trigger: event that causes your system to respond Pre/post conditions: bounds the use case to avoid major design flaws Alternative flow: alternative route to accomplish Use Case Exceptions: describes how the system reacts to bad input

© Copyright 2001-2014 The Process Group.

[Based on K. Wiegers Software Requirements]

www.processgroup.com

Version 10.0

56

Use Cases and Business Requirements - 1 Business Requirements Centralized system for managing all photo images: • Storage cost