clearer software requirements using a concise template · pdf fileclearer software...
TRANSCRIPT
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 1
Clearer Software RequirementsUsing a Concise Template
Neil Potter, Mary SakryThe Process Group
Selected material licensed from Karl E. Wiegers
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 2
Agenda
Introduction
Business Requirements
User Requirements
Use Case Names
Functional Requirements
Further resources at: http://www.processgroup.com/downloads.htm
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 3
Have You Had Any of These Experiences?
The project’s vision and scope are never clearlydefined.
Developers encounter ambiguities and missinginformation resulting in guesswork.
Requirements hide in long paragraphs. Difficult to understand Multiple requirements Conflicts Difficult to trace to/from Difficult to edit/remove/add
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 4
Three Levels of Software Requirements
#2: UserRequirements
Software Requirements Specification (SRS)
Constraints
BusinessRules
QualityAttributes
SystemRequirements
Vision and Scope Document
Use Case Document
Other NonfunctionalRequirements
External Interfaces
#3:FunctionalRequirements
#1: BusinessRequirements
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 5
Define Vision and Scope
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 6
Three Levels of Software Requirements
Define Vision
& Scope
#1: BusinessRequirements
#2: UserRequirements
Software Requirements Specification (SRS)
Constraints
BusinessRules
QualityAttributes
SystemRequirements
Vision and Scope Document
Use Case Document
Other NonfunctionalRequirements
External Interfaces
#3:FunctionalRequirements
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 7
Some Elicitation Questions: Business Reqs.
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 includedin the solution? Which should not?
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 8
Vision and Scope Document
1. Business Requirements1.1. Background1.2. Business Opportunity1.3. Business Objectives and
Success Criteria1.4. Customer or Market Needs1.5. Business Risks
1. Allow customers world wide to make and track purchases for allconsumable products using a web browser.
2. Allow payment to be made electronically using existing or new accounts.3. Provide customer with Internet access to accounts payable and receivable
functions on existing accounts.4. Capture needs profile of each customer for future marketing use.5. …
• Eliminate paper-based orders fromworld-wide customers byproviding a web system for ordermanagement.
• Replace all paper transactions by200X.
• Reduce order management costs30% by 200Y.
e.g.,
e.g.,
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 9
Another Example - Customer NeedsReq # CURRENT ACCOUNTS
CA 1.1 A/C to A/C transfer (XXX accounts)
CA 1.2 A/C to A/C transfer (to other local banks)
CA 1.3 Transfer from XXX A/C to a Beneficiary through a XXX Branch
CA 1.4 A/C to A/C transfer (to international banks thru pre-defined transfer)
CA 1.5 Utility bill payments
CA 1.6 Request additional XXX ATM card
CA 1.7 Report lost/stolen XXX ATM card with option to request a replacement
CREDIT CARD
CC 1.1 Apply for a XXX VISA / MasterCard
CC 1.2 XXX VISA/MasterCard credit card payment with the option to pay for another XXX credit card
CC 1.3 Transfer from XXX VISA / MasterCard to Current A/C
CC 1.4 Change of XXX VISA / MasterCard address
TIME DEPOSIT
TD 1.1 Book a Time Deposit from a current account
TD 1.2 Commission Rate Inquiry/Display Rates
TD 1.3 Change interest account assignment
PERSONAL FINANCE
PF 1.1 Apply for Consumer Loan
PF 1.2 Inquiry on loan outstanding amount, installment amount, due amount
PF 1.3 View loan statement
FINANCIAL PLANNING
FP 1.1 Plan Details
FP 1.2 Payment Details
FP 1.3 Investment Details
FP 1.4 Benefit Details
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 10
Understand User Needs
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 11
Three Levels of Software Requirements
#1: BusinessRequirements
#2: UserRequirements
Software Requirements Specification (SRS)
Constraints
BusinessRules
QualityAttributes
SystemRequirements
Vision and Scope Document
Use Case Document
Other NonfunctionalRequirements
External Interfaces
#3:FunctionalRequirements
Define Vision
& Scope
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 12
The Need for Customer Involvement
Customer involvement is acritical factor in software quality.
What the customer wants
What the developer builds
Expectation Gap
Surprise!
Time
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 13
Classifying the Voice of the Customer
ExternalInterface
Requirement
FunctionalRequirement
Solution IdeaBusiness Rule
ConstraintQuality Attribute
Business Requirement
Use Caseor Scenario
Data Definition
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 14
Use Cases
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 15
Gathering Requirements Through Use Cases
Use cases came from object-oriented world, extended for systemanalysis and user interface design
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.”
not:“What do you want this system to do?”
Explore sequences of user actions and system responses
Derive functional requirements and test cases from use cases
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 16
Use Case Workshop Approach
Preconditions: database contains orders,user identity is verified
Postconditions: order has been shown
Use Case Name:
User Classes: allView an order stored in the database.
Actor Actions System Responses
user enters ordernumber he wantsto view
user enters ordernumber, but itdoesn’t exist
error message:order numbernot found
order details are displayed
etc. for all normaland exceptionpathways
Raw Interview Data
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 17
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 thecustomer
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 18
Examples of Use Case Statements
Order a bottle of a specific chemical from a specificvendor.
Search a document collection for a specific template.
See which flight has the lowest fare from city A to city Bon a specified date. with an advance ticket purchase without an advance ticket purchase
Pay for a purchase made at a commercial website.
Output data every 3 milliseconds in JJU format.
Update interest rate based on loan database update.
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 19
Sample Use Case for an ATM - 1
Name: Withdraw CashActor: Account OwnerDescription:
The user withdraws a specific amount of cash from a specified account.
Trigger: Account Owner selects Withdrawal action.
Preconditions: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: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
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 20
Sample Use Case for an ATM - 2
Actor Actions System Responses
1. Select Withdrawal action.3. Select desired account.5. Enter desired amount.7. Remove cash from dispenser.
2. Display user’s accounts.4. Ask user to enter amount.6. If amount is okay, dispense
cash and debit account.
Alternative Flow: Step 4: display list of common amounts, let user select one
Exceptions: 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
Normal flow:
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 21
Derive Functional Requirements
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 22
Three Levels of Software Requirements
DeriveFunctional
Requirements
#1: BusinessRequirements
#2: UserRequirements
Software Requirements Specification (SRS)
Constraints
BusinessRules
QualityAttributes
SystemRequirements
Vision and Scope Document
Use Case Document
Other NonfunctionalRequirements
External Interfaces
#3:FunctionalRequirements
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 23
Deriving Functional Requirements
Two common styles of defining Functional Requirements: 1: Functional requirements = complete rewrite of the user requirements
from a system / developer perspective, e.g., Feature A: <description, use case(s) it implements, characteristics> Feature B: <description, use case(s) it implements, characteristics>
2: Functional requirements = ADDITIONAL software characteristics thatmore completely define system behavior, at the level that designers candesign without causing significant rework and defects, e.g., Ensure record locking for database X Don’t allow control characters in the password Process empty records by flagging them as null
You might decide that some of the functional requirements aremore appropriately recorded as user requirements
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 24
Q&A
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 25
For Further Reading - 1
Beyer, Hugh, and Karen Holtzblatt. Contextual Design: Defining Customer-CenteredSystems. San Francisco: Morgan Kaufmann Publishers, 1998.
CMMI Product Development Team. CMMI for Development. Version 1.2 (CMMI-DEV,v1.2). CMU/SEI-2006-TR-008CMU/SEI-2006-TR-008, ESC-TR-2006-008. August 2006.
Collard, Ross. “Test Design”, Software Testing & Quality Engineering, vol. 1, no. 4(July/August 1999), pp. 30-37.
Gause, Donald C., and Brian Lawrence. “User-Driven Design,” Software Testing &Quality Engineering, vol. 1, no. 1 (January/February 1999), pp. 22-28.
Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs.Boston: Addison-Wesley, 2002.
Gottesdiener, Ellen. The Software Requirements Memory Jogger. Salem, NH:Goal/QPC, 2005.
IEEE Std. 830-1998, "Recommended Practice for Software RequirementsSpecifications." Los Alamitos, Calif.: IEEE Computer Society Press, 1998.
Kulak, Daryl, and Eamonn Guiney. Use Cases: Requirements in Context, 2nd Ed.Boston: Addison-Wesley, 2003.
Based on In Search of Excellent Requirements, Copyright © 2007 by Karl E. Wiegers. Modifications & additions Copyright © 2007 The Process Group. www.processgroup.com Version 9.8L-2 PGv9 26
For Further Reading - 2
Lauesen, Soren. Software Requirements: Styles and Techniques. London: Addison-Wesley, 2002.
Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use CaseApproach, 2nd Ed. Reading, Mass.: Addison Wesley, 2003.
Robertson, James and Suzanne Robertson. Complete Systems Analysis: The Workbook,the Textbook, the Answers. New York: Dorset House, 1994.
Sommerville, Ian, and Pete Sawyer. Requirements Engineering: A Good Practice Guide.New York: John Wiley & Sons, 1997.
Wiegers, Karl E. Creating a Software Engineering Culture. New York: Dorset House, 1996.
Wiegers, Karl E. Peer Reviews in Software: A Practical Guide. Boston: Addison-Wesley,2002.
Wiegers, Karl E. Software Requirements, 2d Ed. Redmond, Wash.: Microsoft Press, 2003.
Wiegers, Karl E. More About Software Requirements: Thorny Issues and Practical Advice.Redmond, Wash.: Microsoft Press, 2006.
Wiegers, Karl. “Karl Wiegers Describes 10 Requirements Traps to Avoid,” Software Testing& Quality Engineering, vol. 2, no. 1 (January/February 2000), pp. 34-40.