Upload
hakiet
View
242
Download
0
Embed Size (px)
Citation preview
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 1
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] Version 10.0www.processgroup.com 2
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] Version 10.0www.processgroup.com 3
Agenda - 1
■ Introduction to Software Requirements Engineering…….. 3
■ Requirements Development and Management Process… 8 • Identify users……………………………………………………... 9 • Define vision and scope……………………...…………………. 12 • Understand user needs.………………………….……………... 17 • Define quality attributes………………………….……………… 36 • Define business rules………………………….………………… 38 • Derive functional requirements………………..….………..…... 43 • Analyze and verify requirements……………...….……………. 53 • Manage requirements changes …..…………..….……………. 77 • Requirements specification approaches………………………. 48
Page
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 4
Agenda - 2
■ Summary: Requirements Good Practices …..……………. 86
■ Improving Your Requirements Processes …..……………. 89
■ Further Reading ……………………….…………………….. 91
Further resources at: http://www.processgroup.com/downloads.htm
Page
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 5
Introduction to Software Requirements Engineering
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 6
What is a Software Requirement?
A condition or capability needed by a user to solve a problem or achieve an objective*.
*(IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology”, computer.org)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 7
Three Levels of Software Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
#1: Business Requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 8
Benefits of Requirements Practices
■ 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.
Clarifying the target – so you can arrive there sooner with less cost
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 9
Relative Cost of Fixing a Defect
[Robert Grady, Applications of Software Measurement]
0
10
20
30
40
50
60
70
Requirements Design Code Development Testing
Acceptance Testing
Operation
Development Phase
Rel
ativ
e C
ost t
o C
orre
ct a
Def
ect
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 10
Requirements and a Software Life Cycle
Reqs. Analysis Design Code Test Integrate? Release?
Architecture Build 1 Build 2 Build 3
Requirements changes are processed here (ò)
Reqs. Analysis Design Code Test Integrate Release?
Reqs. Analysis Design Code Test Integrate Release
Prototype Planning
Prototype high-risk areas
Iron out the problems with the life cycle on Build 1
ò ò ò
ò ò ò
High level definition of the requirements for the purposes of estimation (Thin Spec., Backlog)
!RequirementsGathering!RequirementsGathering
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 11
Requirements and Scrum / Agile
Requirements changes are processed here (ò)
Requirements (user stories)
ò ò ò Sprint 1 Sprint 2 Sprint 3
Planning Backlog
Reqs. Analysis Design Code Test Integrate Test Release
Reqs. Analysis Design Code Test Integrate Test Release
Reqs. Analysis Design Code Test Integrate Test Release
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 12
Requirements and The V-Model
From: en.wikipedia.org/wiki/V-Model_(software_development)
V-Model
An alternative
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 13
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 the requirements.
■ Assist in decisions regarding requirements changes and tradeoffs.
■ Manage changes with stakeholders.
• Elicitation • Analysis • Specification • Verification • Validation • Requirements
Management
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 14
• Your job. • Requirements problems / issues? • Expectations for this class?
Your Class Expectations
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 15
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] Version 10.0www.processgroup.com 16
Requirements Development & Management Process
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 17
Identify Users
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 18
User Classes
■ Distinct groups of users for a product: • Could include other systems as users of your system
■ May differ in: • frequency of use of application • functions used • tasks to be accomplished • education and skill level • privilege or security level
■ Identify user classes and their characteristics early.
■ Document user classes in the requirements. ■ Not all user classes are equally important to you.
e.g., doctor, nurse, office
manager
Your System
User System
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 19
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] Version 10.0www.processgroup.com 20
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, 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.
Your System
User System
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 21
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
● Interview other users they represent ● Resolve conflicting requirements ● Set implementation priorities ● Define quality attributes ● Participate in requirements inspections (reviews) ● Evaluate / prioritize bug fixes and enhancements
● Contribute to user manuals and on-line help ● Help prepare classes and tutorial materials
● Help “sell” the system to customer communities
Requirements:
Change Management:
Documentation:
Advocacy:
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 22
Product Champion Hierarchy for a Large Project
Project Manager
Analyst 1 Analyst n Analyst 2
Support Team 1 Support Team n Support Team 2
user user user user user user user user user
Product Champion n Product Champion 2 Product Champion 1
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 23
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] Version 10.0www.processgroup.com 24
Define Vision and Scope
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 25
Three Levels of Software Requirements
Define Vision
& Scope
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 26
Vision and Scope Document
2. Business Requirements 2.1. Background 2.2. Business Objectives (Success
Criteria) Customer Needs
2.3 Vision and Scope 2.4 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] Version 10.0www.processgroup.com 27
Vision and Scope Document
1) Allow customers world wide to make and track purchases for all consumable products using a web browser.
2) Allow payment to be made electronically using existing or new accounts.3) Provide customer with web access to accounts payable and receivable
functions on existing accounts.4) Capture needs profile of each customer for future marketing use.5) Provide customizable reporting of system use to executive management
(reporting to be defined).6) ……
• Centralize all orders from world-wide customers.
• Provide a web system for order management by 20XX.
• Reduce order management costs 30% by 20YY.
e.g.,
Simple example
2. Business Requirements 2.1. Background 2.2. Business Objectives (Success
Criteria) Customer Needs
2.3 Vision and Scope 2.4 Assumptions, Dependencies, Risks,
Out of Scope
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 28
Another Example - Customer Needs Req # 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
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 29
Vision and Scope
OurSystem
Internal & Corporate Clients
Sales Staff
Suppliers
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
1+2. Make/trackResponse
1+2. Make/trackRequest
Buy/trackRequest
Buy/trackResponse
Auto StockRequest
Auto StockResponse
3. New a/c Set up +4. Needs Marketing
Exec.Mgt.
Retail Stores
2. Business Requirements 2.3 Vision and Scope
Customer needs 1. Make/track purchases2. Electronic payment3. Setup customer web access4. Needs marketing5. Exec. Mgt. reporting
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 30
Context Diagram Example - 1
Chemical Tracking System
Health & Safety Dept.
Buyer
Training Database
Chemical Stockroom
Chemist
inventory reports chemical containers
information for new containers
requests for records of hazardous chemical training
records of hazardous
chemical training
chemical usage and disposal reports
requests for reports
requests for new chemicals
chemical order status
requests for chemicals
vendor catalog queries
chemical containers vendor catalog
info
Barcode Reader
scanned barcode
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 31
Context Diagram Example - 2
Graphics Editor
Competitor Data
Sys. Admin
ComponentDatabase
Production Coordinator
Graphics designer
data request parts list
get component specs
config. report
configure users and devices
edit
desi
gn validate design
desi
gn
valid
atio
n is
sues
editable design
copy
Management
request status report
status report
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 32
Vision and Scope Document
2. Business Requirements 2.4 Assumptions,
Dependencies, Risks, Out of Scope
Assumptions (Facts you are assuming to be true or false)
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
1 Win vY support.
2 Cloud support.
3 Integration with ABC toolkit.
Move risks to project risk plan during planning
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 33
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] Version 10.0www.processgroup.com 34
Understand User Needs
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 35
Three Levels of Software Requirements
!!
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
Define Vision
& Scope!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 36
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] Version 10.0www.processgroup.com 37
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
Incremental Requirements Definition
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 38
Sources of Software Requirements - 1
Documents • descriptions of current or competing
products • standards or regulations
• help desk problem reports
Interviews • focus groups of
representative customers • use case workshops with
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] Version 10.0www.processgroup.com 39
Sources of Software Requirements - 2
Watch users do their jobs • create workflow diagrams • “day in the life” studies • look at what information the
user has when performing a particular task
Event-response tables • identify external stimuli and
describe system responses
Task analysis • apply methods like use cases or
scenarios • focus on user objectives, rather
than system functions
Prototyping • useful for
requirements, design, and implementation
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 40
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] Version 10.0www.processgroup.com 41
Organizing Requirements Information
External Interface
Requirement
Functional Requirement
Solution Idea Business Rule
Constraint Quality Attribute
Business Requirement
Use Case or Scenario
Data Definition
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 42
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] Version 10.0www.processgroup.com 43
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] Version 10.0www.processgroup.com 44
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] Version 10.0www.processgroup.com 45
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] Version 10.0www.processgroup.com 46
Use Cases
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 47
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] Version 10.0www.processgroup.com 48
Use Case in Context
User Workshops
User Reqs.
Draft Test Cases
Verified User Reqs.
Draft Models
Draft User Reqs.
Business Rules
Verified Models
Shared Vision v1.0
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 49
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 As an account owner, I want to deposit check(s) As an account owner, I want to deposit foreign check(s)
1-liners can be ambiguous and lead the developer to guess
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 50
Use Case Workshop Approach
Preconditions: database contains orders, user identity is verified
Postconditions: order has been shown
Use Case Name:
User Classes: all View an order stored in the database.
Actor Actions System Responses
user enters order number he wants to view
user enters order number, but it doesn’t exist
error message: order number not found
order details are displayed
etc. for all normal and exception pathways
Interview Data Category InterviewSource
Search a documentcollection for a specifictemplate for a specific typeof project
Use Case Operator
A purchasing agent canmodify an order only withwritten permission from thecustomer
BusinessRule
CustomerManager
Raw Interview Data
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 51
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] Version 10.0www.processgroup.com 52
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] Version 10.0www.processgroup.com 53
Graphical Option - Use Case Diagrams
Obtain Material Safety
Data Sheet
Search Vendor Catalogs
Request a Chemical
Receive Chemical
Manage Inventory
Check Order Status
Dispose of a
Chemical Health & Safety Dept.
Training Database
Chemical Stockroom
Staff Requester
Buyer
Takes up lots
of space!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 54
Sample Use Case for an ATM - 1
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
[Elicitation questions]
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 55
Sample Use Case for an ATM - 2
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
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.
Normal flow: [What is the ideal flow?]
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 56
Use Case Template
■ 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
User story Description
Screen# Trigger
Preconditions Postconditions
User / Actor System Response Normal Flow
Alternative Flows Exceptions
Business Rules Assumptions
Notes and Issues Note / Issue Resolution
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 57
Use Cases and Business Requirements - 1
Business Requirements Centralized system for managing all photo images: • Storage cost <=$X/year/10K photos. • Import-to-publish processing time <=2 mins per photo (with no edits).
Notes
BO#1 One storage location for all photos.
CN#1.1 Imports from photo sources to complete in 5 minutes (total).
CN#1.2 Customized master storage location.
CN#1.3 Customized list of allowed sharing devices.
BO#2 Viewing, editing, printing from any portable device and browser.
CN#2.1 1-click printing from any device.
CN#2.2 Labeling /version control.
BO#3 Creating and managing accounts.
CN#3.1 Ability to add friends, suppliers, co-managers to account.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 58
Use Cases and Business Requirements - 2
Obtain a list of use case names (actor tasks) before expanding each use case.
Example Use Cases for Requirement #3.
1. Register a site admin. 2. Create a new site admin profile. 3. Modify site admin profile. 4. Remove the site admin profile. 5. Register a new user. 6. Remove an existing user. 7. View own profile. 8. Modify own profile.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 59
Example Use Case #2 - 1
User story1 Create a new site admin profile. Description Create a site admin profile for a customer. The site admin can
then create users. Screen# TBD Trigger Select “New site admin”
Preconditions Site admin has a valid software license ID to enter Postconditions Screen confirmation
Profile created in database Email confirmation
User / Actor System Response Normal Flow 1. Select “New site admin”
3. Enter ID 5. Enter user info 6. Select edit/save/submit 8. Log out
2. Prompt for ID 3. Check ID + display confirmation 4. Prompt for user info [record 1] 7. If edit do A If save do B If submit do C
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 60
Example Use Case #2 - 2
Alternative Flows 1. Select Auto fill/submit 2. Display confirmation message
Exceptions 3a. ID wrong 3b. ID expired 3c. ID in use
3a. Display wrong error 3b. Prompt renew screen 3c. Prompt in use error message
Business Rules 1. ID must be XYZ countries only - copyright laws. Assumptions
Notes and Issues Note / Issue Resolution Chinese characters? Test. Use standard text
processor for multi languages.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 61
Example Use Case - Another Format - 1
Use Case: New Subscription Brief Description This describes the process for subscribing to a XXX mutual fund for the first time by debiting a XXX account. Preconditions 1. The customer has logged in. 2. The customer decides to “Make a new Subscription”. 3. The customer is an existing XXX a/c holder.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 62
Example Use Case - 2
Basic Flow
1 A disclaimer language that the customer has read, understood and accepted the Terms & Conditions.
2 The customer will be able to apply for multiple funds at the same time. For this the shopping cart mechanism will be adopted. As the customer decides to exercise this option all the existing accounts of the customer, with their outstanding balances will be fetched from the STAR system. Support will be provided only for SAR & USD accounts and funds.
3 Every cart module, will allow user to subscribe to one fund. The components of the module are:
a. Fund Name: This will get all the existing fund names from IMFS. b. Fund Currency: Each Fund will have a currency associated with it. c. A/C balance: The value for this field before the customer makes the first subscription,
once in a session, will be the balance fetched from STAR, on logging in. The rule for the reduction in balance will be as follows:
i. Case 1: For SAR Mutual Funds from SAR accounts New Balance= (Balance carried over from the previous cart, where this account was used (if not used in the session, then the STAR balance at log on)-(Amount of SAR Funds Subscribed to+ Subscription Fee)
ii. Case 2: For SAR Mutual Funds from USD accounts
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 63
Example Use Case - 3
Alternative Flow 1. Exception to 5: The use case terminates in case of 4(b) 2. Exception to 6: The transaction set flows into the IMFS when 5 is True but gets rejected
by IMFS. Show the rejection messages for the failed transaction(s).
4 Once the customer has finished adding a set of transactions to the shopping cart, a summary of the transactions for the session will be displayed. The user can select the following:
a. I Agree: User agrees to the transactions. b. Cancel: User will cancel the entire transaction set. c. Modify: If the customer decides to modify, the entire transaction set will be displayed and
the customer can change the values and funds selected. 5 The customer selects 4(a). The transaction set then flows to the STAR system for validation for
Initial Balance = Balance at the end of transaction session. This will be to check if there was any transaction on the customer account(s), while user was in session. Note: The transaction set flows into the IMFS system, one subscription at a time.
6 5 is TRUE. The transaction(s) gets verified by IMFS also.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 64
Example Use Case - 4
Association Screen # 3.1 – USER INTERFACE Verification Screen- Subscription to XXX Funds
Post Condition The customer has been able to subscribe to XXX mutual funds.
Business Rules 1. Minimum subscription amount for XXX Mutual Funds will be available as fund parameters. 2. To identify customers subscribing to XXX Mutual Funds for the first time, system will check
if user has holdings on any XXX Fund. If user doesn’t this will be considered as a new subscription. Else this will be considered as an additional subscription. Note for customers which don’t have any holdings at present, in any fund, will be treated as a new customer.
3. Default values will be used (e.g. mid rate will be used for cross-currency, subscription fee as per fund parameters)
4. There will be no limit for this transaction - the customer can subscribe as much as user wants to as long as there are sufficient funds in user's account.
5. Confirmation to customers once the transaction is executed will be sent by internal mailbox. The existing IMFS advices sent to the customers through mail will continue without any change to meet this requirement.
6. The transaction will be created with “Verified Status” immediately - immaterial of the amount of the transaction. Predefined ID’s will be used while creating the transaction.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 65
Appropriate Use Case Applications
■ Use cases work well for: • end-user applications • web sites • devices with which users must interact • services provided by one system to another
■ Use cases aren’t as valuable for: • batch processes • computationally-intensive systems • data warehousing projects • event-controlled real-time systems
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 66
Capturing Data Definitions - Data Dictionary
■ Store information about the system’s data items, such as definitions, composition and allowed values:
• Primitive: e.g., integer, text, special character.
• Enumerated primitive: e.g., 1-99 (only these allowed values).
• Structure = e.g., record, group of records, database.
■ Keep separate from the requirements (but linked).
• Makes update simpler - does not need requirements to be changed.
ExternalInterface
Requirement
FunctionalRequirement
Solution IdeaBusiness Rule
ConstraintQuality Attribute
Business Requirement
Use Caseor Scenario
Data Definition
Ref. Figure 13-4. Software Requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 67
■ Elicit several proposed use cases for your system. ■ Select 1-3 of the use cases and explore in more depth, focusing
on items in template below:
Exercise: Use Cases
User story Description
Screen# Trigger
Preconditions Postconditions
User / Actor System Response Normal Flow
Alternative Flows Exceptions
Business Rules Assumptions
Notes and Issues Note / Issue Resolution
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 68
Event Tables
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 69
System Events as User Requirements
Sensor
Device control signal
Actor
External Database
Your System
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 70
Event-Response Table: Windshield Wipers
Event System State System Response set wiper control to low speed
wiper off or wiper on high speed or wiper on intermittent
set wiper motor to low speed
set wiper control to high speed
wiper off or wiper on low speed or wiper on intermittent
set wiper motor to high speed
set wiper control set to off wiper on high speed or wiper on low speed or wiper on intermittent
complete current wipe cycle; turn wiper motor off
set wiper control to intermittent
wiper off read wipe time interval setting; initialize wipe timer
set wiper control to intermittent
wiper on high speed or wiper on low speed
read wipe time interval setting; complete current wipe cycle; initialize wipe timer
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 71
Three Levels of Software Requirements
UnderstandUser Needs
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
!!!
!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 72
Quality Attributes
UnderstandUser Needs
#1: Business Requirements
#2: User Requirements
Business Rules
Quality Attributes
Vision and Scope
User Requirements
Other Nonfunctional Requirements
!!!
!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 73
Software Quality Attributes
■ Characteristics of software that are visible to users or important to developers
■ Write them to be quantitative and verifiable ■ Document these in the SRS ■ Cannot be simultaneously optimized; there are tradeoffs
Availability Flexibility Efficiency Interoperability Integrity Portability Reliability Reusability Robustness Maintainability Usability Testability Safety Security
Examples
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 74
Documenting Quality Attributes - 1
Interoperability: Exchange data or services with other programs.
• The system shall be able to import chemical structures directly from the ChemDraw and ChemiStruct tools.
Performance: Speed.
• 90% of database queries shall be completed in no more than 2 seconds on a XXX target machine.
Usability: Ease of use, user-friendliness, learning curve.
• All functions on the File menu shall have keyboard equivalents defined that use the Control key pressed simultaneously with one other key.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 75
Documenting Quality Attributes - 2
Robustness: Product still functions with bad input & user error.
• All inputs shall have default values specified, to be used if the input data is not supplied or is invalid.
Maintainability: How easy it is to maintain the software.
• Support costs are 1 person / year or less.
• The ratio of comments to source statements shall be at least 0.5.
Testability: Ease with which each feature can be tested.
• A test case can be written for each requirement.
• The user interface can be tested with playback scripts.
Flexibility: Effort needed to add new product capabilities.
• It shall be possible to add a new supported hardcopy output device in two hours or less.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 76
Business Rules
UnderstandUser Needs
#1: Business Requirements
#2: User Requirements
Business Rules
Quality Attributes
Vision and Scope
User Requirements
Other Nonfunctional Requirements
!!!
!
!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 77
What Are Business Rules?
■ “A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.” (The Business Rules Group)
■ Common sources of business rules: • corporate policies • government laws and regulations • industry standards • imposed computational algorithms
YIELD ONE WAY
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 78
Typical Business Rules
Business Rules
Facts
true statements
Constraints
restrict actions Action Enablers
trigger activity Inferences
new facts Computations
algorithms
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 79
Examples of Business Rules - 1
■ Facts • Every chemical container has a unique bar code identifier. • Every order must have a shipping charge. • Sales tax is not computed on shipping charges.
■ Constraints • A user may request a chemical on the Level 1 hazard list only
if he has had hazardous-chemical training within the past 12 months.
• A library patron may place up to 10 items on hold. • Correspondence may not display more than four digits of the
policyholder’s Social Security number. • Commercial airline flight crews must receive at least eight
hours of continuous rest in every 24-hour period.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 80
Examples of Business Rules - 2
■ Action Enablers • If the chemical stockroom has containers of a requested
chemical in stock, then offer existing containers to the requester.
• If the expiration date for a chemical container has been reached, then notify the person who currently possesses that container.
• On the last day of a calendar quarter, generate the mandated government reports on chemical handling and disposal for that quarter.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 81
Examples of Business Rules - 3
■ Inferences • A container of a chemical that can spontaneously form
explosive peroxides is considered expired one year after its date of manufacture.
• If the vendor cannot ship an ordered item within five days of receiving the order, then the item is backordered.
■ Imposed Computations • The domestic ground shipping charge for an order that weighs
more than 2 pounds is $4.75 plus 12 cents per ounce. • The total price for an order is computed as the sum of the
price of the items ordered, less any volume discounts, plus state and county sales tax for the location to which the order is being shipped, plus the shipping charge.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 82
A Business Rules Catalog
All software applications must comply with Federal regulations for usage by visually impaired persons.
US-1 ADA-137B
If the customer ordered a book by an author who has written multiple books, then offer the author’s other books to the customer before completing the order.
MK-1 marketing policy, paragraph 4
■ Write atomic business rules: • no “ors” on the left of an if/then clause, no “ands” on the right. • easier to change, apply, understand, and combine.
Source Rule Definition ID
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 83
Other Nonfunctional Requirements
UnderstandUser Needs
#1: Business Requirements
#2: User Requirements
Business Rules
Quality Attributes
Vision and Scope
User Requirements
Other Nonfunctional Requirements
!!!
!
! !
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 84
Nonfunctional Requirements
Nonfunctional Requirements: ■ An term commonly used in industry. IEEE
defines them as: • Performance Requirements • Safety Requirements • Security Requirements • Software Quality Attributes • Business Rules
■ Some people define them as constraints, others as product look-and-feel.
Keep your spec. simple by defining these type of requirements under “Quality Attributes” or in unique sections of the SRS
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 85
Exercise: Writing Quality Attributes and Business Rules
1. Identify 2 or 3 Quality Attributes likely to be important for your project. Consider these: Availability Efficiency
Robustness Maintainability Portability Reliability Integrity Usability Performance Flexibility Safety Security
For each attribute, write 1 or 2 quantitative and verifiable statements of appropriate goals for your project.
2. Identify 3-5 Business Rules for a section of your project.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 86
Derive Functional Requirements
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 87
Three Levels of Software Requirements
DeriveFunctional
Requirements
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
!!! !
!
!!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 88
External Interfaces & Constraints
External Interfaces: describes connections to the outside world ■ Must connect via Ethernet and receive Y22 standard signals. ■ Must communicate with wireless router models A-C. ■ Must read raw photo data files.
Constraints: Issues we must live with ■ Memory use cannot exceed 50%. ■ Database must be less than 20GB to allow it to be transferred
across the network. ■ Data fields cannot change in version 6.0.
■ These requirements may have been identified earlier in the requirements phase - complete them here
■ Only record them in one place: ✔ For larger systems it is common to have an interface spec.
(Interface Control Document)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 89
System Requirements
System Requirements are hardware or software issues: ■ The product must work on an isolated PC Vx machine with a
maximum of N bytes of memory. ■ The system must recognize USB N and N+1 ports. ■ The invoice system must share data with the purchase order
system. ■ The system must use J-type middleware and K-type firewall. ■ Safari and IE browsers must be supported.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 90
Three Levels of Software Requirements
DeriveFunctional
Requirements
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
!!! !
!
!!
!!!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 91
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 that more completely define system behavior, at the level that designers can design 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 are more appropriately recorded as user requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 92
Functional Requirements Example - Style 2
No system use will be possible if the license is invalid. The site admin will be asked for a license renewal number annually. The system will remember partial profile creations, should the site admin not complete the profile creation process at one time. The site admin will be able to continue where he/she left off. The admin tool will not provide any record locking and will depend on the default record locking provided by the database. There will be only one site admin per user. Control characters (defined in X standard) will be rejected with warning code 16.
Business Requirement 7: Support sales force in creating and managing Internet accounts for customers.
Use Case 2: Create a new site admin profile.
Functional Requirements for Use Case 2:
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 93
Exercise: Writing Functional Requirements, System Requirements, External Interfaces and Constraints
■ Select one use case. Write several functional requirements that, if implemented, would allow the user to perform that use case. • Assume: Functional requirements = ADDITIONAL software
characteristics that more completely define system behavior.
■ Identify System Requirements, External Interfaces and Constraints for a section of your project.
Defects found in test later are potential functional requirements now.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 94
Three Levels of Software Requirements
#1: Business Requirements
#2: User Requirements
Software Requirements
Constraints
Business Rules
Quality Attributes
System Requirements
Vision and Scope
User Requirements
Other Nonfunctional Requirements
External Interfaces
#3:Functional Requirements
!!! !
!
!!
!!! !
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 95
Requirements Specification Approaches
Textual • Vision and Scope Document • Use Case Document • Software Requirements Specification
Graphical • Structured analysis models (such as data
flow diagram, entity-relationship diagram, state-transition diagram, dialog map)
• Object-oriented analysis models
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 96
Where to Store Requirements?
Document
Stuff Spreadsheet
Tools (JIRA, Jama, Visure, ReqPro, DOORS, Cradle)
Tool issues Easy to use? Baseline? Cost? Customizable? Export?
Separate out: User requirement Project task Project issue Bug
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 97
Software Requirements Specification (SRS) - 1
■ Definition • A set of precisely stated properties and constraints that a
software system must satisfy. • A complete description of the behavior of a software system.
■ Objectives • To achieve agreement regarding the requirements among
developers, customers, and other stakeholders. • To provide the basis for software design. • To support verification and validation of the software.
These objectives require the SRS to be written!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 98
Software Requirements Specification - 2
■ Keep in mind the audience: • Customers, end users, marketing • Project management • Software development team • Testing group • Software maintenance and support • Quality assurance, configuration management, training, legal,
publications
■ Consider one document, incrementally completed by different roles: • Work together to speed up communication.
■ Keep it up-to-date so that it always reflects the goal: • People will ignore a bad / out-of-date spec.
Requirements Audience: A Audience: A+B Audience: A+B+C
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 99
Concise, No Repeat (Document or Tool)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 100
Using IEEE? Trim It Down! (adapted from IEEE Standard 830-1998 and EEE/ISO/IEC 29148-2011)
1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended Audience and
Reading Suggestions 1.4 Product Scope 1.5 References
2. Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Classes and Characteristics 2.4 Operating Environment 2.5 Design & Implementation Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies
3. External Interface Requirements 3.1 User Interfaces 3.2 Hardware Interfaces 3.3 Software Interfaces 3.4 Communications Interfaces
4. System Features 4.1 System Feature 1 4.1.1 Description and Priority 4.1.2 Stimulus/Response Sequences 4.1.3 Functional Requirements 4.x System Feature x
5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 5.5 Business Rules
6. Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 101
Use Cases and the SRS
OPTION 1: ■ Write a separate use case document ■ Organize section 4 of SRS by feature,
with detailed functional requirements ■ Trace each functional requirement
back to a use case
Use Cases Functional Spec. Feature 1
Functional Reqs. Feature 2
Functional Reqs.
SRS Use Case 1
Functional Reqs. Function 1
Use Case 2 Functional Reqs.
<Function 1>
OPTION 2: ■ Organize section 4 of SRS by use case, with
functional requirements as details ■ Cross-reference duplicate functional
requirements, or ■ Consider defining common functions in SRS with
references in use cases (e.g., record locking)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 102
Software Requirements Specification Revised Layout with Use Cases
1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended Audience and
Reading Suggestions 1.4 Product Scope 1.5 References
2. Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Classes and Characteristics 2.4 Operating Environment 2.5 Design & Implementation Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies
3. External Interface Requirements 3.1 User Interfaces 3.2 Hardware Interfaces 3.3 Software Interfaces 3.4 Communications Interfaces
4. Use Cases 4.1 Use Case Name 1 4.1.1 Use Case Details 4.1.2 Business Rules For Use Case 1 4.1.3 Functional Requirements 4.x Use Case Name x
5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 5.5 Business Rules (Global)
6. Other Requirements 7. Optional: Global Function Definitions Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 103
Writing Quality Requirements
■ Evaluate from the developer’s perspective.
■ Document in hierarchical, structured form.
■ Short: • Discretely testable. • No “and” and “or” - suggests multiple requirements. • Use “shall,” “must,” or “will,” not “should,” “might,” or “may.” • Avoid ambiguous words: minimize, maximize, optimize, rapid. • Label each requirement. • Organize similar requirements into tables. • Avoid redundancies.
■ Don’t over constrain with design information: • One project reduced 800 requirements to 80 when they removed design
suggestions!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 104
Characteristics of Quality Requirement Specifications
Complete nothing is missing; no “To Be Determineds”
Consistent does not conflict with other requirements
Correct accurately states a customer or external need
Feasible can be implemented within known constraints
Modifiable can be easily changed, with history, when necessary
Necessary documents something customers really need
Prioritized ranked as to importance of inclusion in product
Traceable linked to system requirements, and to designs, code, and tests
Unambiguous has only one possible meaning
Verifiable correct implementation can be determined by testing, inspection, analysis, or demonstration
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 105
Analyze & Verify Requirements
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 106
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 107
Requirements Prioritization
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 108
Requirements Prioritization
■ Need to understand which requirements are most important and most urgent
■ Not everything can be top priority!
■ Setting priorities will help you • work on the right things first • make tradeoff decisions • deal with added and changed requirements
■ Need to bypass politics and emotion • favorable indicator: customer value (benefit + penalty) • unfavorable indicators: cost and risk
cost value
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 109
Requirements Prioritization Scales
■ One scale: High = must be included in this release Medium = must be included, but can wait for later release Low = would be nice to have if we can fit it in
■ Another scale: Necessary = mission critical Important = supports necessary system operations Desirable = a functional, quality, or usability enhancement
■ A third scale Essential = product is not acceptable without this Conditional = enhances product, but it’s not unacceptable if absent Optional = functions that might or might not be worthwhile
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 110
Bus. Req. / Use Case /
Feature
Benefit Penalty Total Value
Value %
Rel. Cost
Cost %
Rel. Risk
Risk %
Priority
spell check
grammar check
indexing
table of contents
table border wizard
Totals
Analytical Prioritization
Apply to ALL requirements OR just non-essential requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 111
Bus. Req. /Use Case /
Feature
Benefit IfPresent
(1-9)
Penalty IfAbsent
(1-9)Total Value (Benefit
+ Penalty)Value
Percent
1
2
3
■ Estimate relative benefit and penalty for each feature ■ Sum of benefit and penalty reveals relative value ■ Calculate the percent of total value coming from each feature
Estimating Relative Value of Features
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 112
Estimating Feature Costs
❏ Fully refine requirements and review them
❏ Design and review user interface, architecture, algorithms
❏ Build and evaluate a prototype
❏ Code, review code, rework, unit test, rework, document
❏ Integrate with rest of product, test, rework
❏ Develop and execute system tests, rework
❏ Program documentation
❏ Support activities (configuration management, QA, publications)
Estimate the total effort to implement each feature:
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 113
Bus. Req. /Use Case /
Feature
ValuePercentage
CostPercentage
RiskPercentage Priority
1 A L X A/(L+X)
2 B M Y B/(M+Y)
3 C N Z C/(N+Z)
-- 100% 100% 100% --
■ Risk: 1 = code while sleeping; 9 = very challenging ■ Value, Cost, and Risk percentages must total 100 ■ Consider weighting risk by 1/2; e.g., A/(L+X/2)
Estimating Feature Priority
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 114
Bus. Req. /Use Case /
Feature
Benefit Penalty TotalValue
Value%
Rel.Cost
Cost%
Rel.Risk
Risk%
Priority
spell check 6 8 14 35% 3 15% 2 13% 1.25
grammarcheck
4 2 6 15% 7 35% 3 19% 0.28
indexing 4 3 7 18% 5 25% 3 19% 0.41
table ofcontents
5 4 9 22% 1 5% 1 7% 1.83
table borderwizard
3 1 4 10% 4 20% 7 44% 0.16
Totals 22 18 40 100% 20 100% 16 100% --
Prioritization Example: A Word Processor
■ Priority = value% / (cost% + risk%) ■ Could weight benefit, penalty, risk, and cost differently ■ Sort by descending Priority to see top priorities
Ref: Table 16-1. Software Requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 115
Optional: Exercise: Using a Prioritization Scheme
■ If you have many requirements, use the 3-bin scheme to organize them into 3 categories.
■ Set requirements priorities using the numeric value/cost/risk scheme.
Bus. Req. /Use Case /
Feature
Benefit Penalty TotalValue
Value%
Rel.Cost
Cost%
Rel.Risk
Risk%
Priority
spell check 6 8 14 35% 3 15% 2 13% 1.25
grammarcheck
4 2 6 15% 7 35% 3 19% 0.28
indexing 4 3 7 18% 5 25% 3 19% 0.41
table ofcontents
5 4 9 22% 1 5% 1 7% 1.83
table borderwizard
3 1 4 10% 4 20% 7 44% 0.16
Totals 22 18 40 100% 20 100% 16 100% --
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 116
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 117
ARM: A Tool for Checking Requirements
■ Automated Requirement Measurement (ARM) • Tool no longer supported – but still a great idea! • Worth implementing.
IMPERATIVE OCCURRENCE-------------------- ----------shall 0must 5is required to 0are applicable 0are to 0responsible for 0will 138should 7----------TOTAL 150
IMPERATIVE OCCURRENCE -------------------- ---------- shall 0 must 1 is required to 0 are applicable 0 are to 0 responsible for 4 will 81 should 32 ---------- TOTAL 118
Spec 1 Spec 2Example:
Req
uire
men
ts
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 118
CONTINUANCE OCCURRENCE -------------------- ---------- below: 0 as follows: 2 following: 1 listed: 0 in particular: 0 support: 0 and 23 : 25 ---------- TOTAL 51
CONTINUANCE OCCURRENCE -------------------- ---------- below: 1 as follows: 0 following: 1 listed: 0 in particular: 0 support: 0 and 25 : 9 ---------- TOTAL 36
Spec 1 Spec 2
ARM Example (Continued)
Req
uire
men
ts
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 119
DIRECTIVE OCCURRENCE -------------------- ---------- e.g. 4 i.e. 1 For example 0 Figure 0 Table 0 Note: 6 ---------- TOTAL 11
DIRECTIVE OCCURRENCE -------------------- ---------- e.g. 0 i.e. 0 For example 0 Figure 0 Table 0 Note: 0 ---------- TOTAL 0
Spec 1 Spec 2
ARM Example (Continued)
OPTION PHRASES OCCURRENCE -------------------- ---------- can 18 may 1 Optionally 0 ---------- TOTAL 19
OPTION PHRASES OCCURRENCE -------------------- ---------- can 5 may 2 Optionally 0 ---------- TOTAL 7
Cla
rific
atio
n A
mbi
guity
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 120
WEAK PHRASE OCCURRENCE -------------------- ---------- adequate 0 as appropriate 0 be able to 2 be capable of 0 capability of 0 capability to 0 effective 0 as required 0 normal 0 provide for 0 timely 0 easy to 1 ---------- TOTAL 3
WEAK PHRASE OCCURRENCE -------------------- ---------- adequate 0 as appropriate 0 be able to 6 be capable of 0 capability of 0 capability to 0 effective 0 as required 0 normal 2 provide for 0 timely 0 easy to 0 ---------- TOTAL 8
Spec 1 Spec 2
ARM Example (Continued)
Am
bigu
ity
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 121
INCOMPLETE OCCURRENCE -------------------- ---------- TBD 0 TBS 0 TBE 0 TBC 0 TBR 0 not defined 0 not determined 0 but not limited to 0 as a minimum 0 ---------- TOTAL 0
INCOMPLETE OCCURRENCE -------------------- ---------- TBD 0 TBS 0 TBE 0 TBC 0 TBR 0 not defined 0 not determined 0 but not limited to 0 as a minimum 0 ---------- TOTAL 0
Total text strings = 771 920Total requirements = 150+51=201 118+36=154Text:Reqs = 3.8 : 1 6 : 1
Spec 1 Spec 2
ARM Example (Continued)
Gap
s
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 122
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 123
Data Flow Diagram
■ DFD is the child of the context diagram ■ Can expand DFDs to multiple levels of detail ■ Permits top-down hierarchical decomposition of a system ■ Suitable for analyzing process-focused applications
Terminator
transformational process
data store
data flow read from data store
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 124
State-Transition Diagrams
■ Models the discrete states a system can be in ■ Transitions show the only permitted state changes ■ Can also model possible statuses of an object in the system
first system state
second system state
third system state
condition 3; outcome 3
condition 2; outcome 2
condition 1; outcome 1
condition 4; outcome 4
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 125
User Interface Modeling Using a Dialog Map
Send a Feedback Note
Main Menu Page 1
Main Menu Page 2
File Options Menu
Delete a File Dialog
Rename a File Dialog
send note
cancel
previous menu
next menu
delete file
cancel
rename file
cancel
select delete
select rename
select feedback
exit system enter system
select file operations return to menu
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 126
Benefits of a Dialog Map
■ Find incorrect or missing transitions early
■ Find missing or incorrect requirements early
■ Define user back-out and cancellation routes
■ Spot opportunities for reuse
■ Spot redundancies in user interface design
■ Can partition the user interface into sub-components
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 127
A Possible, Partial ATM Dialog Map
Welcome Screen
Prompt for PIN
Transaction Options
Incorrect PIN message
Account List
Amount Options
Prompt for Amount
Prompt for Receipt
cancel; eject card
different account select account
cancel select withdrawal
PIN okay
try #3; retain card
try #1 or #2
incorrect PIN
insert card
yes; print receipt
custom amount
cancel transaction
amount ok; dispense cash
standard amount; dispense cash
no
Exit or done; eject card
invalid amount; show error message
Common Commands
Exit Welcome Screen
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 128
cancel
select chemicalto order
DB40
chemical ID/OK;stockroom hassample
order new bottlestockroomsample list
DB50 DB60list of vendorsfor chemical
vendor selected/OK sample selected/OK
current chemicalrequest list
DB70
cancel
chemical ID/OK;no sample instockroom
Dialog Map for Chemical Example
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 129
Main MenuScreen
enter systemexit system
entercities and
date
showavailableflights
appropriateerror
message
displaycurrentitinerary
invalid city;invalid date
OK
valid cityand dateentered
trysomethingelse
choosenext
flight done
selectchooseflights
cancelflight
selectiondisplayavailableseats
selectchoose
seat seat chosen
pay withcredit card
unreadableor invalid
credit card
try againscan/bad;
scan/invalid
unsuccessful; give up
payment ok
select pay withcredit card select
printfunction
doneprinting
printoptionsmenu
message:printingtickets
message:printingitinerary
printtickets
ticketsprinted
printitinerary
itin.printed
chooseflight
A Possible Airline Reservation Dialog Map
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 130
Exercise: Dialog Map
Draw a dialog map for one component of your system.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 131
Decision Tables and Decision Trees
■ How does the Chemical Tracking System decide whether to approve or reject a request?
4 conditions to check for (business rules):
• Is the requester authorized to request chemicals?
• Is the chemical available either in the chemical stockroom or from a vendor?
• Is the chemical on the list of hazardous chemicals?
• Is the requester trained in handling hazardous chemicals?
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 132
A Sample Decision Table
Condition Requirement 1 2 3 4 5
Requester is authorized F T T T T Chemical is available — F T T T Chemical is hazardous — — F T T Requester is trained — — — F T
Action
Accept request X X Reject request X X X
Five distinct functional requirements arise from 16 possible combinations (24).
Ref: Table 12-6. Software Requirements
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 133
A Sample Decision Tree
requester authorized?
yes chemical available?
reject request
no reject request
no
reject request
no accept request
no
requester trained?
yes
accept request
yes chemical hazardous?
yes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 134
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 135
Where They are Used
Start activity
End activity
Develop idea
Technical review or walkthrough of ideas with peers
Rework Rework Rework
Inspection of product with peers
Refine idea
Technical review or walkthrough of ideas with peers
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 136
Informal Requirements Review
2.1.4 A charge number shall be entered for each chemical ordered. [Priority 1]
2.1.4.1 Charge numbers shall be validated on-line against the master corporate charge number list, if possible. The order shall be accepted even if the charge number cannot be validated.
2.1.4.2 The charge number entered shall apply to an entire order, not to individual line items in the order.
2.1.4.3 Each order shall have space for the user to enter several lines of free-form text (a comment) along with the order details.
2.1.4.4 If the charge number is invalid, the order shall not be accepted. The user can either postpone the order for future completion, or exit from the application.
Complete Necessary Consistent Prioritized Correct Traceable Feasible Unambiguous Modifiable Verifiable
Y N
Y N Y N Y N Y N
Y N
Y N Y N Y N Y N
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 137
An Imperfect Requirement - 1
“The product shall provide status messages at regular intervals not less than every 60 seconds.”
■ Problems?
■ Try rewriting it:
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 138
A Better Requirement - 1
“1. The Background Task Manager (BTM) shall display status messages in a designated area of the user interface.
1.1. The messages shall be updated every 60 plus or minus 10 seconds after background task processing begins and shall remain visible continuously.
1.2. If background task processing is progressing normally, the BTM shall display the percentage of the background task processing that has been completed.
1.3. The BTM shall display a “done” message when the background task is completed.
1.4. The BTM shall display an error message if the background task has stalled.”
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 139
An Imperfect Requirement - 2
“The system shall switch between displaying and hiding non-printing characters instantaneously.”
■ Problems?
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 140
A Better Requirement - 2
“The user shall be able to toggle between displaying and hiding all XML tags in the document being edited with the activation of a specific triggering condition.
The display shall change in 0.1 second or less.”
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 141
An Imperfect Requirement - 3
“If condition X occurs, the LED display sign should shut down.”
■ Problems?
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 142
A Better Requirement - 3
“If condition X occurs: 1. Sign displays “Maint.” 2. Sign can be rebooted by turning main switch off, then
on. 3. Time and condition code are written into the error log.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 143
Defect Logging Meeting
Moderator & Scribe
Documents
■ High-level
■ Low-level
■ Standard
■ Common-errors Checklist
■ Reference Material
Document Owner/Reviewer
Reviewers
Inspection (Peer Review)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 144
Reviewing Requirements
■ Review formally and informally, early and often. ■ Use checklists to help find typical requirements
defects. ■ Ensure that all requirements are within scope. ■ Ensure all high-level requirements have been addressed via:
• Business requirements, business rules, use cases and interfaces ■ Ensure that requirements can serve as a basis for design.
• But free from design and implementation (except constraints) ■ Check for exception conditions and error handling. ■ Participants: analyst, customer reps, designer, tester, project
leader, user documentation author.
Further checklists at: http://www.processgroup.com/downloads.html
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 145
Exercise: Inspection of a Sample SRS
Conduct an inspection: ■ Select 3 pages of an example SRS.
■ 10 minutes individual preparation: • Note the defects, severity (major, minor), location (line/page/
paragraph)
■ 15 minutes defect logging.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 146
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 147
Test Case Generation
■ Write test cases from requirements: • develop test cases from use cases. • trace test cases to requirements. • verify models (state transition, dialogue, data flow) with
test cases. • Develop acceptance criteria using domain experts (and / or
customers).
If you can’t generate a test case from a requirement, you might have an ambiguous requirement!
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 148
Test Case Generation Exercise
Write some test cases: ■ Select 2-3 requirements (e.g., use case, dialogue map).
■ Write 1-5 test cases for each one.
■ What did you learn about your requirements? • Clear, complete, needs work?
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 149
Analyze & Verify Requirements
■ Determining Requirements Priorities
■ ARM: A Tool for Checking Requirements
■ Using Models to Clarify Requirements
■ Reviewing and Inspecting Requirements Documents
■ Generating Test Cases
■ Reducing the Expectation Gap Through Prototyping
Purpose: To find ambiguities and errors in the current requirements definition.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 150
Why Do Prototyping?
■ Does this program do the right thing for you? ■ Do you find any defects or omissions in the user interface? ■ Preference among several example interaction techniques? ■ Do parts of the interface feel clumsy or inefficient?
To answer questions early in the development cycle.
■ Are the proposed architecture, database schema or algorithms feasible?
Horizontal Prototype (mock-up)
Vertical Prototype (proof-of-concept)
e.g., Pilot transactions, healthcare patient processing, migration from system A to B
e.g., Database performance, image stitching accuracy, server reliability
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 151
Reduce the Expectation Gap
Customer reviews of: • Requirements • Designs • Screen mockups • End-to-end user / data
flows Prototype user interfaces:
• Paper and/or electronic • Minimum programming • Use competitive
product, PowerPoint, Excel?
Apply to real customer need
Apply to high-risk components (difficult, critical)
t i m e
prototype review
prototype review
prototype review
what the customer wants
what the developer builds
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 152
Throwaway and Evolutionary Prototypes
(From Alan Davis, Software Requirements: Objects, Functions, & States)
Development Approach:
What to Build:
Ultimate Goal:
Quick and dirty; no rigor
Only difficult parts
Throw it away!
No sloppiness; rigorous
Build understood parts first; Build on solid foundation
Evolve it into the product
Throwaway Evolutionary
Risk!
Cut corners = software rust
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 153
Manage Requirements Changes
Start IdentifyUsers
Define Vision
& Scope
UnderstandUser Needs
DeriveFunctional
Requirements
Analyze &Verify
Requirements
Manage Requirements
Changes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 154
Key Requirements Management Practices
■ Requirements Management involves establishing an agreement with the stakeholders on the project’s requirements.
• agreements are written • technical and non-technical requirements • project work is based on the agreement
■ Manage versions of requirements documents.
■ Adopt and enforce a change control process.
■ Perform requirements change impact analysis. • Consider other related documents (plan, design, code, test)
■ Store requirement attributes.
■ Track the status of each requirement.
■ Trace requirements into designs, code, and tests.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 155
Requirements Version Management
■ Place requirements documents under version control. • keep requirements documentation up to date • everyone must have access to current versions • maintain history of changes made, when and why
■ Restrict document update access to authorized individuals.
■ Store requirements in a database or use a configuration management system for requirements documents.
■ Or, define a document version identification scheme. #1 = “version 1.0 draft 1” #2 = “version 1.0 draft 2” #n = “version 1.0 approved” #n+1 = “version 1.1 draft 1” or “version 2.0 draft 1”
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 156
Requirements Change Control
■ Uncontrolled changes cause problems: • rework, degraded quality, unpredictable schedules
■ Define a requirements change process. • propose, review, approve, and incorporate changes • define state-transition model for allowed change states • include impact analysis • support with a tool, but a Tool is Not a Process!
■ All change requests must follow the process.
■ Requirements changes may require renegotiating project commitments.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 157
Example Change Control Processes
Submitted
Evaluated Rejected
Approved
Change Made
Verified
Closed
Verifier hasconfirmed thechange
Modifier hasinstalled product
verificationfailed
Modifier has madethe change andrequested verification
no verificationrequired; Modifierhas installedproduct
CCB decided to makethe change, allocatedit to a release, andassigned a Modifier
CCB decidednot to makethe change
Evaluator performedimpact analysis
Originator submitteda change request
Canceled
change was canceled
change was canceled
change wascanceled
processgroup.com/change_control_process.doc
Purpose: A checklist used to understand, confirm and manage requirements changes.
q Plan the requirements definition/review event: • Date: • Time / resources needed: • Responsibility: • Stakeholders: - Name, Role
q Discuss new and changed requirements with stakeholders to clarify understanding: • Review current requirements and proposed
changes to requirements • Resources needed to implement change • Current commitments and deadlines impacted • Added risks and mitigation actions • Record stakeholder commitments
q Record major issues/actions q Update traceability mapping:
• Label requirement 1 thru N • List impacted work products (e.g., design, code,
test plan, test cases)
q Baseline requirements version in project folder: project_N-requirements_vX
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 158
Change Control Board (or Scrum Team)
■ Diverse individuals: • development • project management • customer • testing • documentation
■ Authorized to make binding decisions: • Define charter and process to be followed
■ Consider change requests periodically: • request impact analysis • make accept/reject decisions • set priorities or targeted releases • communicate decisions and impacts to stakeholders
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 159
Ways to Document Requirements Changes
■ Use strikethrough, underscore, revision bars. • feature of word processors • can selectively accept or reject text changes later • maintain revision history of what changes were made when
■ Use version control tools to maintain historical versions. • configuration management tools can store binary files • can access previous versions if necessary
■ Use database of requirements and changes to them. • commercial requirements management tools • record why changes were made • store additional information about each requirement
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 160
Impact Analysis for Requirements Changes - 1
❏ Identify conflicts with existing requirements.
❏ Identify affected design, code, test components.
❏ Assess impact on user interface, database, reports, files, help screens, publications.
❏ Identify other systems, libraries, or hardware affected.
❏ Determine which work products will require reviewing.
❏ Identify plans* to update (SPMP, SCMP, SQAP, etc.).
*Software Project Management Plan, Software Configuration Management Plan, Software Quality Assurance Plan
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 161
Impact Analysis for Requirements Changes - 2
❏ Will the change affect performance or other quality attributes?
❏ Is the change technically feasible?
❏ Will prototyping be required?
❏ Will the change overload computer resources for development, test, or host environment?
❏ Does the change affect any other current tasks?
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 162
Impact Analysis for Requirements Changes - 3
■ Estimate total labor hours for all tasks to be performed: • create new designs, code, tests, UI, database, files, reports • modify existing designs, code, tests, UI, database, files, reports • develop and evaluate prototype • retesting • reviews and rework
■ Allocate resources to tasks.
■ Sequence tasks and identify predecessors.
■ Determine if change is on critical path.
■ Estimate schedule and cost impact from effort.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 163
Requirement Attributes
■ Store additional information about each requirement. • status • date created and version number • author and person responsible for the requirement • origin or rationale behind the requirement • allocated subsystem, product release, and build • priority • verification method
■ Notify those affected by change requests.
■ Track project status through requirements status.
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 164
Tracking Requirements Volatility
Weeks After SRS was Baselined
Num
ber o
f Req
. Cha
nges
0 2 4 6 8
10 12 14 16
0 5 10 15 20
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 165
Requirements Change Origin
0
5
10
15
20
25
30
Nu
mb
er
of
Req
. C
ha
ng
es
Source
Marketing
Management
Customer
SW Group
Other Eng.
Testing
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 166
Example Requirements Status Tracking
Proposed requirement was requested by a legitimate source
Approved requirement was analyzed, impact assessed, and agreed to by all affected parties
Baselined requirement became allocated as part of a fixed group of requirements for implementation
Implemented code was designed, written, and tested
Verified requirement was shown to be implemented correctly in the product
Deleted planned requirement was deleted from the baseline
Rejected requirement was requested, not approved
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 167
Requirements Status Tracking
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1 2 3 4 5 6 7 8 9 10
Month
Pe
rce
nt
of
Re
qu
ire
me
nts
Proposed
Approved
Implemented
Verified
Deleted
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 168
Requirements Traceability
Software Requirement
System Requirement, Use Case, Business Rule
Design Component
Source Code File/Function
Test Case
Each requirement must be uniquely identified: 3.1.4.2, PRINT.CONFIRM.COPIES, FR-117
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 169
Requirements Traceability Matrix
Benefits: 1. No requirements are overlooked during design and
implementation.
2. You can see at a glance what work has been completed.
3. If a test fails, it points to the code to search for the problem.
4. A requirement change points to the affected design, code, and test elements.
Req. Design Element Source File Procedure Test Case
FR-117 DFD 8.8.7 progmgr.c execute_action,select_manage
action.1,action.3
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 170
Commercial Requirements Management Tools
www.toolsjournal.com/requirements-management-tools/
Vendor and Tool name Weighted Total
Score eDevTECH inteGREAT™ Requirements Studio 5579 Blueprint® Requirements Center 5378 TechnoSoluCons TopTeam Analyst 5314 Micro Focus® Caliber® RM 5171 MKS Integrity 5171 3SL Cradle® 5078 IBM RaConal Composer 4990 Polarion® Requirements™ 4799 IBM® RaConal® DOORS 4718
Vendor and Tool name Weighted Total
Score Kovair ApplicaCon Lifecycle Management 4692 Orcanos Qpack 4513 Sparx Systems Enterprise Architect 4382 Siemens Teamcenter® 4302 Jama SoYware Contour 4222 HP ApplicaCon Lifecycle Management 4147 TraceCloud 4082 MicrosoY Team FoundaCon Server 3438
[Ref215]: seilevel.com/ wp-content/uploads/ 2011/09/ Seilevel-RequirementsManagementToolEvalResults2.xls
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 171
Requirements Management Tool Capabilities
■ Manage versions and changes • version history of every requirement • baselining capability
■ Store requirements attributes • system and user-defined • filter to view requirements with specific attribute values
■ Define traceability links • requirements to other requirements, designs, tests, etc. • assist with change impact analysis
■ Control access • group and individual permissions • web access to requirements database
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 172
Summary Requirements Good Practices
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 173
Elicitation
■ Write project vision and scope ■ Define requirements development process ■ Identify user classes and characteristics ■ Select product champions ■ Establish focus groups ■ Identify use cases ■ Analyze user workflow ■ Define quality attributes ■ Examine problem reports ■ Reuse requirements across projects
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 174
Analysis
■ Draw a context diagram to clarify project scope
■ Create user interface prototypes
■ Analyzing requirements feasibility
■ Prioritize the requirements
■ Model the requirements
■ Create a data dictionary
■ Use a tool to search for defects common defects
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 175
Specification
■ Adopt a software requirements specification template / tool
■ Identify the source of each requirement
■ Uniquely label each requirement
■ Record business rules
■ Create requirements traceability matrix
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 176
Verification and Validation
■ Formally inspect requirements documents
■ Write test cases from requirements
■ Write a user manual
■ Define acceptance criteria
■ Evaluate prototypes
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 177
Requirements Management
■ Define requirements change control process
■ Establish change control board
■ Perform requirements change impact analysis
■ Trace each change to all affected work products
■ Baseline and control versions of requirements documents
■ Maintain history of requirements changes
■ Track requirements status
■ Measure requirements stability
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 178
Improving Your Requirements Practices
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 179
Exercise: Requirements Improvement Plan
■ Consider 3 timeframes: • next week, next month, in six months
■ For each timeframe, identify: • new requirements practices you want to try • what situation you might apply them to • what benefits you hope to gain (or problems you want to fix)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 180
Improving Your Requirements Processes
Next Week Next Month In 6 Months
New practices to try
Situation you might apply them to
Motivation to take action (e.g., benefits you hope to gain)
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] Version 10.0www.processgroup.com 181
For Further Reading
1. Wiegers, Karl E; Beatty, Joy. Software Requirements, 3rd Ed. Redmond, Wash.: Microsoft Press, 2013.
2. CMMI for Development. Version 1.3. November 2011. 1. http://cmmiinstitute.com/cmmi-solutions/cmmi-for-development/
3. Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs. Boston: Addison-Wesley, 2002.
4. Gottesdiener, Ellen. The Software Requirements Memory Jogger. Salem, NH: Goal/QPC, 2005.
5. IEEE Std. 830-1998, "Recommended Practice for Software Requirements Specifications." Los Alamitos, Calif.: IEEE Computer Society Press, 1998.
6. Kulak, Daryl, and Eamonn Guiney. Use Cases: Requirements in Context, 2nd Ed. Boston: Addison-Wesley, 2003.
7. Robertson, James and Suzanne Robertson. Complete Systems Analysis: The Workbook, the Textbook, the Answers. New York: Dorset House, 1994.
8. Sommerville, Ian, and Pete Sawyer. Requirements Engineering: A Good Practice Guide. New York: John Wiley & Sons, 1997.
9. Wiegers, Karl E. More About Software Requirements: Thorny Issues and Practical Advice. Redmond, Wash.: Microsoft Press, 2006.