Software Requirements v10 Full

Software Requirements
Neil Potter
Mary Sakry
The Process Group
help@processgroup.com
www.processgroup.com
US 972-418-9541
© Copyright 2001-2014 The Process Group. [Based on K. Wiegers Software Requirements] www.processgroup.com Version 10.0 1
Have You Had Any of These Experiences?
❏  Customers are too busy to provide requirements.
❏  Project scope never clearly defined.
❏  Managers or marketing claim to speak for the users.
❏  Users claim that all requirements are critical.
❏  Developers encounter ambiguities and they guess.
❏  Requirements change continuously after approval.
❏  Changes are accepted with minimal evaluation.
❏  Requirements changes get lost.
❏  Functionality is requested and built, but never used.
❏  The specification is satisfied, but the customer is not.
Agenda - 1
Page
■  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
Agenda - 2
Page
■  Summary: Requirements Good Practices …..……………. 86
■  Improving Your Requirements Processes …..…………….89
■  Further Reading ……………………….……………………..91
Further resources at: http://www.processgroup.com/downloads.htm
Introduction to Software
Requirements Engineering
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)
Three Levels of Software Requirements
#1: Business
Requirements
Vision and Scope

Quality Business
Attributes Rules
#2: User
Requirements
Other Nonfunctional
Requirements
User Requirements
External
Interfaces
System #3:Functional
Requirements Requirements
Constraints
Benefits of Requirements Practices
Clarifying the target

– so you can arrive
there sooner with
less cost
■  Creating and reviewing multiple views of requirements helps

satisfy customer expectations.
■  Controlling requirements changes minimizes the adverse
impact of changes.
■  Emphasizing quality requirements reduces rework,
maintenance and wasted time implementing unnecessary
functions.
■  Enabling testing to be based on requirements.
Relative Cost of Fixing a Defect
Relative Cost to Correct a Defect 70
60
50
40
30
20
10
0
Requirements Design Code Development Acceptance Operation
Testing Testing
Development Phase
[Robert Grady, Applications of Software Measurement]
Requirements and a Software Life Cycle
High level definition of the Requirements changes are
requirements for the purposes of
estimation (Thin Spec., Backlog) processed here (ò)
Planning Prototype ò ò ò
!R!Requirements
equirements Architecture Build 1 Build 2 Build 3
Gathering
Gathering
ò ò ò
Reqs. Analysis
Design
Code
Test Reqs. Analysis
Prototype high-risk Integrate? Design
areas Release? Code Reqs. Analysis
Test Design
Iron out the Integrate Code
Release? Test
problems with the
life cycle on Build 1 Integrate
Release
Requirements and Scrum / Agile
Requirements changes are
processed here (ò)
Requirements (user stories)
Backlog Planning
ò ò ò
Sprint 1 Sprint 2 Sprint 3
Reqs. Analysis
Design
Code
Test
Integrate Reqs. Analysis Reqs. Analysis
Test Design Design
Release Code Code
Test Test
Integrate Integrate
Test Test
Release Release
Requirements and The V-Model
V-Model
From: en.wikipedia.org/wiki/V-
Model_(software_development)
An alternative
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
•  Elicitation
ambiguities. •  Analysis
■  Help establish requirements priorities. •  Specification
•  Verification
■  Clarify scope and context of solution with other •  Validation
systems. •  Requirements
Management
■  Educate users / customers on how to use / read
the requirements.
■  Assist in decisions regarding requirements
changes and tradeoffs.
■  Manage changes with stakeholders.
Your Class Expectations
•  Your job.
•  Requirements problems / issues?
•  Expectations for this class?
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.
Requirements Development
& Management Process
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Requirements User Needs
Derive
Functional
Requirements
Identify Users
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
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 e.g., doctor,
nurse, office
•  functions used manager
•  tasks to be accomplished
•  education and skill level
Your User
•  privilege or security level System System
■  Identify user classes and their characteristics
early.
■  Document user classes in the requirements.
■  Not all user classes are equally important to you.
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.
The Product Champion
■  Primary interface between development

and customer communities:
•  Represents a user class or system interface
■  Respected members of the user community.
Your User
■  A real user; not a manager, sponsor, System System
or simulated user.
■  Has a vision of what the product should be and do.
■  Reconciles incompatible customer requirements.
■  Must be empowered to make binding decisions.
Potential Product Champion Activities
Planning: ●  Define scope and limitations of system
●  Define external boundaries and interfaces
●  Plan migration pathway from current system to new one
Requirements: ●  Interview other users they represent

●  Resolve conflicting requirements
●  Set implementation priorities
●  Define quality attributes
●  Participate in requirements inspections (reviews)
Change
●  Evaluate / prioritize bug fixes and enhancements
Management:
Documentation: ●  Contribute to user manuals and on-line help

●  Help prepare classes and tutorial materials
Advocacy: ●  Help “sell” the system to customer communities
Product Champion Hierarchy for a Large Project
Project Manager
Analyst 1 Analyst 2 Analyst n
Product Champion 1 Product Champion 2 Product Champion n
Support Team 1 Support Team 2 Support Team n
user user user user user user user user user
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
Define Vision and Scope
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
#1: Business
Define
Requirements Vision
& Scope
Vision and Scope

Quality Business
Attributes Rules
#2: User
Requirements
Other Nonfunctional
Requirements
User Requirements
External
Interfaces
Constraints
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?
e.g.,
2. Business Requirements
•  Centralize all orders from world-
2.1. Background
wide customers.
2.2. Business Objectives (Success
Criteria) •  Provide a web system for order
Customer Needs management by 20XX.
2.3 Vision and Scope •  Reduce order management costs
2.4 Assumptions, Dependencies, Risks, 30% by 20YY.
Out of Scope
Simple example
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)  ……
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
Vision and Scope
Customer needs
2.  Business Requirements Internal & 1.  Make/track purchases
2.3 Vision and Scope Corporate 2.  Electronic payment
Clients 3.  Setup customer web access
4. Needs marketing
Context Diagram 5. Exec. Mgt. reporting
•  The system name 1+2. Make/ 1+2. Make/
goes in the circle track track
Response Request Auto Stock
•  Outside boxes Request
Buy/track
represent major Request
external entities Retail
Our Suppliers
System
•  Flows between Stores Auto Stock
externals and the Buy/track Response
Response
system comprehend
customer needs 3. New a/c Set up +
4. Needs Marketing
•  Diagram helps
Exec.
clarify/refine Mgt.
requirements Sales
Staff
Context Diagram Example - 1
Chemist
vendor chemical containers

vendor catalog
queries catalog requests
info for
chemicals
chemical order
Buyer status
Chemical inventory reports

requests for
new chemicals Tracking chemical containers Chemical
Stockroom
System information for
new containers
chemical usage
and disposal requests for records of
reports scanned hazardous chemical
barcode training
Health & requests for
Safety Dept. reports Training
records of
hazardous Database
Barcode chemical
Reader training
Context Diagram Example - 2
Graphics
designer
validation
validate design editable
design
design
issues
design
copy
edit
config
and d ure users
evices
Sys. Admin
config data
. repo Graphics
rt request parts list Production
Editor Coordinator
get component
specs
request status
Competitor status report
Data report
Component
Management Database
Assumptions (Facts you are assuming to be true or false)
2. Business 1 The OS will be Win vX only. Notes
Requirements 2 All data formats will remain unchanged (i.e., version X)
2.4 Assumptions, 3 Only systems 1-4 will be supported.
Dependencies,
Risks, Out of Scope 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.
Move risks to project risk 3 Analysis report from team B complete on mm/dd.
plan during planning
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.
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)
Understand User Needs
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
#1: Business
Requirements
! Define
Vision !
Vision and Scope ! & Scope
Quality Business
Attributes Rules
#2: User
Requirements
Other Nonfunctional
Requirements
User Requirements
External
Interfaces
Constraints
The Need for Customer Involvement
Customer involvement is a
critical factor in software quality.
Expectation Gap
Surprise!
Time
Incremental Requirements Definition
Don’t necessarily clarify
all user needs for the
whole system initially.
Consider focusing on
areas that are the:
■  Highest priority
■  Most frequently used
■  Highest revenue
■  Largest user class
■  Core features to support

architecture
■  Reqs. for regulatory
compliance
Sources of Software Requirements - 1
Documents Interviews
•  descriptions of current or competing •  focus groups of
products representative customers
•  standards or regulations •  use case workshops with
users + developers
•  help desk problem reports
•  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!
Sources of Software Requirements - 2
Watch users do their jobs Prototyping
•  create workflow diagrams •  useful for
•  “day in the life” studies requirements, design,
and implementation
•  look at what information the
user has when performing a
particular task
Task analysis Event-response tables

•  apply methods like use cases or •  identify external stimuli and
scenarios describe system responses
•  focus on user objectives, rather
than system functions
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?
Organizing Requirements Information
Quality Attribute Constraint
Business Rule Solution Idea
External
Interface Data Definition
Requirement
Use Case Functional

or Scenario Requirement
Business Requirement
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”
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”
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”
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.
Use Cases
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
Use Case in Context
Draft
User Reqs.
Verified
User Reqs.
Shared
User User Draft Test Vision
Workshops Reqs. Cases
v1.0
Verified
Models
Draft Models
Business
Rules
User Story vs. Use Case
1-liners can be
User Story ambiguous
and lead the
As an account owner, I want to withdraw cash developer to
As an account owner, I want to deposit cash guess
As an account owner, I want to deposit check(s)
As an account owner, I want to deposit foreign check(s)
Use Case Workshop Approach
Use Case Name:

Raw Interview Data View an order stored in the database.
Interview Data Category Interview User Classes: all
Source
Preconditions: database contains orders,
user identity is verified
Search a document Use Case Operator
collection for a specific Postconditions: order has been shown
template for a specific type
of project Actor Actions System Responses
A purchasing agent can Business Customer
modify an order only with Rule Manager user enters order order details
written permission from the number he wants are displayed
customer to view
user enters order error message:

number, but it order number
doesn’t exist not found
etc. for all normal

and exception
pathways
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.
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.
Graphical Option - Use Case Diagrams
Receive
Chemical
Obtain Training
Material Safety Database
Data Sheet Takes
Search Vendor
up lots
Catalogs of
Request a
Chemical
space!
Manage Chemical
Requester Inventory Stockroom
Staff
Check
Order
Status
Dispose of
a
Health & Chemical Buyer
Safety Dept.
Sample Use Case for an ATM - 1
[Elicitation questions]
Name: Withdraw Cash [What does the user want to do?]
Actor: Account Owner [Who?]
Description:
The user withdraws a specific amount of cash from a specified account.
Trigger: Account Owner selects Withdrawal action [What initiates it?]
Preconditions: [What state is the user / system before the event?]
1. The Account Owner is logged in to the ATM.
2. The Account Owner has at least 1 account with a positive balance.
3. The ATM contains cash.
Postconditions: [What state is the user / system after the event?]
1. The requested amount of cash has been dispensed.
2. The account balance is reduced by the amount withdrawn plus any fees.
3. The ATM cash balance is reduced by the amount withdrawn.
Priority: High
Sample Use Case for an ATM - 2
Normal flow: [What is the ideal flow?]
Actor Actions System Responses

1. Select Withdrawal action. 2. Display user’s accounts.
3. Select desired account. 4. Ask user to enter amount.
5. Enter desired amount. 6. If amount is okay, dispense
7. Remove cash from dispenser. cash and debit account.
Alternative Flow: [Any alternatives?]

• Step 4: display list of common amounts, let user select one
Exceptions: [Conditions the system needs to deal with?]
• Step 6: amount is not a multiple of $20.00
• Step 6: amount exceeds $400
• Step 6: amount exceeds account balance
• Step 6: amount exceeds cash available in ATM
Use Case Template
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
■  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
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.
Use Cases and Business Requirements - 2
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.
Obtain a list of use case names (actor

tasks) before expanding each use case.
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
Normal Flow 1. Select “New site admin” 2. Prompt for ID
3. Enter ID 3. Check ID + display
confirmation
4. Prompt for user info
5. Enter user info [record 1]
6. Select edit/save/submit
7.
8. Log out If edit do A
If save do B
If submit do C
Example Use Case #2 - 2
Alternative Flows 1. Select Auto fill/submit 2. Display confirmation

message
Exceptions 3a. ID wrong 3a. Display wrong error
3b. ID expired 3b. Prompt renew screen
3c. ID in use 3c. Prompt in use error
message
Business Rules 1. ID must be XYZ countries only - copyright laws.
Assumptions
Chinese characters? Test. Use standard text
processor for multi
languages.
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.
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
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.
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).
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.
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
Capturing Data Definitions - Data Dictionary
■  Store information about the system’s

data items, such as definitions, Quality Attribute Constraint
composition and allowed values:
Business Rule Solution Idea
•  Primitive: e.g., integer, text, special
character.
External
•  Enumerated primitive:
Interface
e.g., 1-99 Data Definition
(only these allowedRequirement
values).
•  Structure = e.g., record, group of
Functional
records, database. Use Case Requirement
or Scenario
Business Requirement
■  Keep separate from the requirements
(but linked).
•  Makes update simpler - does not Ref. Figure 13-4. Software

Requirements
need requirements to be changed.
Exercise: Use Cases
■  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:
User story
Description
Screen#
Trigger
Preconditions
Postconditions
Normal Flow
Alternative Flows
Exceptions
Business Rules
Assumptions
Event Tables
System Events as User Requirements
Sensor
Actor
Your control signal

Device
System
External Database
Event-Response Table: Windshield Wipers
Event System State System Response

set wiper control to low wiper off or wiper on high set wiper motor to low speed
speed speed or wiper on intermittent
set wiper control to high wiper off or wiper on low set wiper motor to high speed
speed speed or wiper on intermittent
set wiper control set to off wiper on high speed or wiper complete current wipe cycle;
on low speed or wiper on turn wiper motor off
intermittent
set wiper control to wiper off read wipe time interval setting;
intermittent initialize wipe timer
set wiper control to wiper on high speed or wiper read wipe time interval setting;
intermittent on low speed complete current wipe cycle;
initialize wipe timer
!
#1: Business
Requirements Understand
!
User Needs
Vision and Scope
#2: User
Requirements
! Quality
Attributes
Business
Rules
Other Nonfunctional
User Requirements
! Requirements
External
Interfaces
Constraints
Quality Attributes
!
#1: Business Understand
Vision and Scope !

#2: User
Requirements
! Quality
Attributes
Business
Rules
Other Nonfunctional
User Requirements
! Requirements
Software Quality Attributes
Examples Availability Flexibility

Efficiency Interoperability
Integrity Portability
Reliability Reusability
Robustness Maintainability
Usability Testability
Safety Security
■  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
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.
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.
Business Rules
!
!
Vision and Scope
!
#2: User
Requirements
! Quality
Attributes
Business
Rules
Other Nonfunctional
User Requirements
! Requirements
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
Typical Business Rules
Business Rules
Facts
true statements
Constraints
restrict actions Action

Enablers
trigger activity
Inferences
new facts
Computations
algorithms
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.
■  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.
■  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.
A Business Rules Catalog
ID Rule Definition Source
US-1 All software applications ADA-137B

must comply with Federal
regulations for usage by
visually impaired persons.
MK-1 If the customer ordered a marketing
book by an author who has policy,
written multiple books, then paragraph 4
offer the author’s other
books to the customer before
completing the order.
■  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.
Other Nonfunctional Requirements
!
!
Vision and Scope
! !
#2: User
Requirements
! Quality
Attributes
Business
Rules
Other Nonfunctional
User Requirements
! Requirements
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
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.
Derive Functional Requirements
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
!
#1: Business
Requirements Derive
Functional
! Requirements
! !
Vision and Scope
! Quality
Attributes
Business
Rules
!
#2: User
Requirements
Other Nonfunctional
User Requirements
! Requirements
External
Interfaces
Constraints
External Interfaces & Constraints
■  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)
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.
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.
!
#1: Business
Requirements Derive
Functional
! Requirements
! !
Vision and Scope
! Quality
Attributes
Business
Rules
!
#2: User
Requirements
Other Nonfunctional
! Requirements
User Requirements
External !
System
Requirements
! #3:Functional
Requirements
Interfaces
Constraints !
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
Functional Requirements Example - Style 2
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:
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.
Exercise: Writing Functional Requirements, System
Requirements, External Interfaces and Constraints
Defects found in test later are potential

functional requirements now.
■  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.
!
#1: Business
Requirements
!
! !
Vision and Scope
! Quality
Attributes
Business
Rules
!
#2: User
Requirements
Other Nonfunctional
! Requirements
!
User Requirements
External
System
Requirements
! #3:Functional
Requirements
! Interfaces
Constraints !
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
Where to Store Requirements?
Tool issues
Easy to use?
Baseline?
Cost?
Customizable?
Stuff Spreadsheet Export?
Separate out:
User requirement
Project task
Project issue
Bug
Document Tools (JIRA, Jama, Visure, ReqPro, DOORS, Cradle)
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!
Software Requirements Specification - 2
Requirements
■  Keep in mind the audience:
Audience: A
•  Customers, end users, marketing
•  Project management Audience: A+
B
•  Software development team Audience: A+
B+C
•  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.
Concise, No Repeat (Document or Tool)
Using IEEE? Trim It Down!
(adapted from IEEE Standard 830-1998 and EEE/ISO/IEC 29148-2011)
1. Introduction 4. System Features

1.1 Purpose 4.1 System Feature 1
1.2 Document Conventions 4.1.1 Description and Priority
1.3 Intended Audience and 4.1.2 Stimulus/Response Sequences
Reading Suggestions 4.1.3 Functional Requirements
1.4 Product Scope 4.x System Feature x
1.5 References 5. Other Nonfunctional Requirements
2. Overall Description 5.1 Performance Requirements
2.1 Product Perspective 5.2 Safety Requirements
2.2 Product Functions 5.3 Security Requirements
5.4 Software Quality Attributes
2.3 User Classes and Characteristics
5.5 Business Rules
2.4 Operating Environment
2.5 Design & Implementation Constraints 6. Other Requirements
2.6 User Documentation Appendix A: Glossary
2.7 Assumptions and Dependencies Appendix B: Analysis Models
3. External Interface Requirements Appendix C: To Be Determined List
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
Use Cases and the SRS
OPTION 1:
Use Cases Functional Spec.
■  Write a separate use case document Feature 1
Functional Reqs.
■  Organize section 4 of SRS by feature, Feature 2
with detailed functional requirements Functional Reqs.
■  Trace each functional requirement

back to a use case
OPTION 2: SRS
Use Case 1
■  Organize section 4 of SRS by use case, with Functional Reqs.
functional requirements as details Function 1
■  Cross-reference duplicate functional Use Case 2
Functional Reqs.
requirements, or <Function 1>
■  Consider defining common functions in SRS with
references in use cases (e.g., record locking)
Software Requirements Specification
Revised Layout with Use Cases
1. Introduction 4. Use Cases

1.1 Purpose 4.1 Use Case Name 1
1.2 Document Conventions 4.1.1 Use Case Details
1.3 Intended Audience and 4.1.2 Business Rules For Use Case 1
Reading Suggestions 4.1.3 Functional Requirements
1.4 Product Scope 4.x Use Case Name x
1.5 References 5. Other Nonfunctional Requirements
2. Overall Description 5.1 Performance Requirements
2.1 Product Perspective 5.2 Safety Requirements
2.2 Product Functions 5.3 Security Requirements
5.4 Software Quality Attributes
2.3 User Classes and Characteristics
5.5 Business Rules (Global)
2.4 Operating Environment
2.5 Design & Implementation Constraints 6. Other Requirements
2.6 User Documentation 7. Optional: Global Function Definitions
2.7 Assumptions and Dependencies Appendix A: Glossary
3. External Interface Requirements Appendix B: Analysis Models
3.1 User Interfaces Appendix C: To Be Determined List
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
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!
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
Analyze & Verify Requirements
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
Purpose: To find ambiguities and errors in the current

requirements definition.
■  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
Requirements Prioritization
Requirements Prioritization
■  Need to understand which requirements are most

important and most urgent
■  Not everything can be top priority!
■  Setting priorities will help you

value cost
•  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
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
Analytical Prioritization
Bus. Req. / Benefit Penalty Total Value Rel. Cost Rel. Risk Priority
Use Case / Value % Cost % Risk %
Feature
spell check
grammar
check
indexing
table of
contents
table border
wizard
Totals
Apply to ALL requirements OR just non-essential requirements
Estimating Relative Value of Features
Bus. Req. / Benefit If Penalty If

Use Case / Present Absent Total Value (Benefit Value
Feature
(1-9) (1-9) + Penalty) Percent
■  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 Feature Costs
Estimate the total effort to implement each feature:

❏  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)
Estimating Feature Priority
Bus. Req. / Value Cost Risk

Use Case /
Percentage Percentage Percentage Priority
Feature
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)
Prioritization Example: A Word Processor
Feature
spell check 6 8 14 35% 3 15% 2 13% 1.25
grammar 4 2 6 15% 7 35% 3 19% 0.28

check
indexing 4 3 7 18% 5 25% 3 19% 0.41
table of 5 4 9 22% 1 5% 1 7% 1.83
contents
table border 3 1 4 10% 4 20% 7 44% 0.16
wizard
Totals 22 18 40 100% 20 100% 16 100% --
■  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
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.
Feature
spell check 6 8 14 35% 3 15% 2 13% 1.25
grammar 4 2 6 15% 7 35% 3 19% 0.28

check
indexing 4 3 7 18% 5 25% 3 19% 0.41
table of 5 4 9 22% 1 5% 1 7% 1.83
contents
table border 3 1 4 10% 4 20% 7 44% 0.16
wizard
Totals 22 18 40 100% 20 100% 16 100% --

ARM: A Tool for Checking Requirements
■  Automated Requirement Measurement (ARM)

•  Tool no longer supported – but still a great idea!
•  Worth implementing.
Example: Spec 1 Spec 2

IMPERATIVE IMPERATIVE OCCURRENCE OCCURRENCE
-------------------- ----------
-------------------- ----------
shall shall 0 0
must must 5 1
Requirements
is required to is required to 0 0
are applicable are applicable 0 0
are to are to 0 0
responsible for responsible for 0 4
will will 138 81
should should 7 32
---------- ----------
TOTAL TOTAL150 118
ARM Example
(Continued)
Spec 1 Spec 2
CONTINUANCE CONTINUANCE OCCURRENCE OCCURRENCE
--------------------
-------------------- ---------- ----------
below: 1
Requirements
below: 0
as follows: as follows: 2 0
following: following: 1 1
listed: listed: 0 0
in particular: in particular: 0 0
support: support: 0 0
and and 23 25
: : 25 9
---------- ----------
TOTAL TOTAL51 36
ARM Example
(Continued)
Spec 1 Spec 2
DIRECTIVE DIRECTIVE OCCURRENCE OCCURRENCE
----------------------------------------
---------- ----------
e.g. e.g. 4 0
Clarification
i.e. i.e. 1 0
For example For example 0 0
Figure Figure 0 0
Table Table 0 0
Note: Note: 6 0
---------- ----------
TOTAL TOTAL
11 0
OPTION PHRASES OPTIONOCCURRENCE

PHRASES OCCURRENCE
--------------------
--------------------
---------- ----------
Ambiguity
can can 18 5
may may 1 2
Optionally Optionally 0 0
---------- ----------
TOTAL TOTAL19 7
ARM Example
(Continued)
WEAK WEAK PHRASE

PHRASE SpecOCCURRENCE
1
OCCURRENCE Spec 2
--------------------
-------------------- ---------- ----------
adequate adequate 0 0
as appropriate as appropriate 0 0
be able to be able to 2 6
Ambiguity
be capable of be capable of 0 0
capability of capability of 0 0
capability to capability to 0 0
effective effective 0 0
as required as required 0 0
normal normal 0 2
provide for provide for 0 0
timely timely 0 0
easy to easy to 1 0
---------- ----------
TOTAL TOTAL 3 8
ARM Example
(Continued)
Spec 1 Spec 2
INCOMPLETE INCOMPLETE OCCURRENCE OCCURRENCE
-------------------- ----------
-------------------- ----------
TBD TBD 0 0
TBS TBS 0 0
TBE TBE 0 0
Gaps
TBC TBC 0 0
TBR TBR 0 0
not defined not defined 0 0
not determined not determined 0 0
but not limited to but not limited to 0 0
as a minimum as a minimum 0 0
---------- ----------
TOTAL TOTAL 0 0
Total text strings = 771 920

Total requirements = 150+51=201 118+36=154
Text:Reqs = 3.8 : 1 6:1

Data Flow Diagram
Terminator data store
transformational read from

data flow process data store
■  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
State-Transition Diagrams
first system condition 3;

state outcome 3
condition 1;
outcome 1
condition 2;
second system outcome 2 third system
state state
condition 4;
outcome 4
■  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
User Interface Modeling Using a Dialog Map
enter system exit system
cancel
send note next menu

Send a Main Menu Main Menu
Feedback Note select Page 1 previous Page 2
feedback menu
select file
operations return to menu
rename file File Options delete file

Menu
cancel cancel
select
rename select
delete
Rename a Delete a
File Dialog File Dialog
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
A Possible, Partial ATM Dialog Map
try #3; retain card Welcome
Screen Common Commands
insert card cancel; eject card Exit Welcome
Exit or done;
Screen
eject card
Incorrect incorrect PIN
Prompt
PIN message for PIN
try #1 or #2
PIN okay
Transaction yes; print receipt

Prompt for
Options Receipt
no
select withdrawal cancel
standard amount;
cancel dispense cash
transaction Account
List amount ok;
dispense cash
different
select account account
invalid amount;
Amount custom amount Prompt for show error message
Options Amount
Dialog Map for Chemical Example
cancel cancel
DB40
select chemical
to order
chemical ID/OK; chemical ID/OK;

stockroom has no sample in
sample stockroom
DB50 DB60
order new bottle
stockroom list of vendors
sample list for chemical
sample selected/OK vendor selected/OK
DB70
current chemical
request list
A Possible Airline Reservation Dialog Map
exit system enter system
unsuccessful; give up
Main Menu
payment ok Screen select seat
select pay with choose chosen
credit card seat
select done
cancel select print printing
flight choose display function
selection flights available
seats
invalid city;
appropriate invalid date print
enter options
pay with error cities and menu
credit card message OK date
tickets print print itin.
valid city printed tickets itinerary printed
and date try
scan/bad; entered something
scan/invalid try again else
message: message:
printing printing
show tickets itinerary
available
unreadable flights
or invalid choose
credit card choose next
flight flight
done
display
current
itinerary
Exercise: Dialog Map
Draw a dialog map for one component of your

system.
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?
A Sample Decision Table
Requirement
Condition
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
A Sample Decision Tree
no reject no accept
request request
requester yes chemical yes accept

authorized? hazardous? request
yes chemical yes requester

available? trained?
no reject no reject
request request

Where They are Used
Inspection
of product
with peers
Technical review Technical review

Start or walkthrough of or walkthrough of End
activity ideas with peers ideas with peers activity
Develop Refine
idea idea
Rework Rework Rework
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.
Y N Complete Y N Necessary
Y N Consistent Y N Prioritized
Y N Correct Y N Traceable
Y N Feasible Y N Unambiguous
Y N Modifiable Y N Verifiable
An Imperfect Requirement - 1
“The product shall provide status messages at

regular intervals not less than every 60 seconds.”
■  Problems?
■  Try rewriting it:
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.”
“The system shall switch between displaying and

hiding non-printing characters instantaneously.”
■  Problems?
“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.”
“If condition X occurs, the LED display sign should

shut down.”
■  Problems?
“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.
Inspection (Peer Review)
Defect Logging Meeting Documents

■  High-level
■  Low-level
■  Standard
Document Owner/ Moderator & Scribe
Reviewer ■  Common-errors
Checklist
■  Reference
Material
Reviewers
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

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.

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!
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?

Why Do Prototyping?
To answer questions early in the development cycle.

Horizontal Prototype (mock-up)
■  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?
e.g., Pilot transactions, healthcare patient processing, migration from system A to B
Vertical Prototype (proof-of-concept)

■  Are the proposed architecture, database schema or algorithms
feasible?
e.g., Database performance, image stitching accuracy, server reliability
Reduce the Expectation Gap
Apply to high-risk components (difficult, critical)

Customer reviews of:
•  Requirements
wants •  Designs
me r
usto •  Screen mockups
a t the c •  End-to-end user / data
wh
flows
wha
t the
de velo Prototype user
per b interfaces:
uilds
•  Paper and/or electronic
•  Minimum programming
•  Use competitive
product, PowerPoint,
prototype prototype prototype Excel?
review review review
Apply to real customer
time need
Throwaway and Evolutionary Prototypes
Throwaway Evolutionary
Development Quick and dirty; No sloppiness; rigorous

Approach: no rigor
What to Build: Only difficult parts Build understood parts first;

Build on solid foundation
Ultimate Goal: Throw it away! Evolve it into the product
Risk!
Cut corners = software rust
(From Alan Davis, Software Requirements: Objects, Functions, & States)

Manage Requirements Changes
Identify
Start Users
Manage Define
Requirements Vision
Changes & Scope
Analyze &
Verify Understand
Derive
Functional
Requirements
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.
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”
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.
Example Change Control Processes
Originator submitted
a change request
Purpose: A checklist used to understand, confirm and
manage requirements changes.
Submitted q  Plan the requirements definition/review event:
Evaluator performed • Date:
impact analysis
CCB decided
• Time / resources needed:
not to make
the change
• Responsibility:
Evaluated Rejected
• Stakeholders:
CCB decided to make
the change, allocated
-  Name, Role
it to a release, and
assigned a Modifier q  Discuss new and changed requirements with
stakeholders to clarify understanding:
Approved change was canceled
•  Review current requirements and proposed
Modifier has made
changes to requirements
verification
failed the change and
requested verification
•  Resources needed to implement change
•  Current commitments and deadlines impacted
change was •  Added risks and mitigation actions
Change Made Canceled
canceled
•  Record stakeholder commitments
no verification Verifier has
required; Modifier
has installed
confirmed the q  Record major issues/actions
change
product
change was canceled
q  Update traceability mapping:
Verified •  Label requirement 1 thru N
Modifier has
•  List impacted work products (e.g., design, code,
installed product test plan, test cases)
Closed
q  Baseline requirements version in project folder:
project_N-requirements_vX
processgroup.com/change_control_process.doc
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
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
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
❏  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?
■  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.
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.
Tracking Requirements Volatility
16
Number of Req. Changes
14
12
10
8
6
4
2
0
0 5 10 15 20
Weeks After SRS was Baselined
Requirements Change Origin
30
Number of Req. Changes
25
Marketing
20 Management
Customer
15
SW Group
10 Other Eng.
Testing
5
0
Source
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
Requirements Status Tracking
100%
90%
Percent of Requirements
80%
70%
60% Proposed
Approved
50%
Implemented
40% Verified
30% Deleted
20%
10%
0%
1 2 3 4 5 6 7 8 9 10
Month
Requirements Traceability
System Requirement, Use Case, Business Rule
Software Requirement
Design Component Test Case
Each requirement must be

uniquely identified: 3.1.4.2,
PRINT.CONFIRM.COPIES,
Source Code File/Function FR-117
Requirements Traceability Matrix
Req. Design Element Source File Procedure Test Case

FR-117 DFD 8.8.7 progmgr.c execute_action, action.1,
select_manage action.3
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.
Commercial Requirements Management Tools
[Ref215]: seilevel.com/ wp-content/uploads/ 2011/09/ Seilevel-RequirementsManagementToolEvalResults2.xls
Weighted Total Weighted Total

Vendor and Tool name Score Vendor and Tool name Score
eDevTECH Kovair
inteGREAT™ ApplicaCon Lifecycle
Requirements Studio 5579 Management 4692
Blueprint® Orcanos
Requirements Center 5378 Qpack 4513
TechnoSoluCons Sparx Systems
TopTeam Analyst 5314 Enterprise Architect 4382
Micro Focus® Siemens Teamcenter® 4302
Caliber® RM 5171 Jama SoYware
MKS Contour 4222
Integrity 5171 HP
3SL Cradle® 5078 ApplicaCon Lifecycle
IBM RaConal Management 4147
Composer 4990 TraceCloud 4082
Polarion® MicrosoY
Requirements™ 4799 Team FoundaCon Server 3438
IBM® RaConal® DOORS 4718
www.toolsjournal.com/requirements-management-tools/
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
Summary
Requirements Good Practices
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
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
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
Verification and Validation
■  Formally inspect requirements documents
■  Write test cases from requirements
■  Write a user manual
■  Define acceptance criteria
■  Evaluate prototypes
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
Improving Your Requirements
Practices
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)
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)
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.

Software Requirements v10 Full

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Requirements v10 Full

Загружено:

Авторское право:

Доступные форматы

Software 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.

■ Introduction to Software Requirements Engineering…….. 3

■ Requirements Development and Management Process… 8

■ Summary: Requirements Good Practices …..……………. 86

■ Improving Your Requirements Processes …..…………….89

■ Further Reading ……………………….……………………..91

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

Vision and Scope

Clarifying the target

■ Creating and reviewing multiple views of requirements helps

[Robert Grady, Applications of Software Measurement]

• Write down your top 1-2 project deadlines/deliverables related to

• Write down your top 3-5 requirements problems (and/or risks)

■ Distinct groups of users for a product:

■ Scheduling / billing system User Classes and tasks:

A lack of understanding of your user classes can lead to major

■ Primary interface between development

Requirements: ● Interview other users they represent

Documentation: ● Contribute to user manuals and on-line help

Advocacy: ● Help “sell” the system to customer communities

Analyst 1 Analyst 2 Analyst n

Product Champion 1 Product Champion 2 Product Champion n

Support Team 1 Support Team 2 Support Team n

user user user user user user user user user

Vision and Scope

■ What business problem are you trying to solve?

vendor chemical containers

Chemical inventory reports

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

3 Integration with ABC toolkit.

■ Write 1-2 Business Objectives for one of your projects

■ Draw a context diagram (Vision Statement) for your current

■ Most frequently used

■ Largest user class

■ Core features to support

Questionnaires and marketing surveys

Task analysis Event-response tables

■ Keep asking “WHY?” to drill down to real needs.

■ Ask open-ended questions.

Quality Attribute Constraint

Business Rule Solution Idea

Use Case Functional

■ External Interface Requirement

Classify each of these requirements into the right category:

Use Case Name:

user enters order error message:

etc. for all normal

■ User-centric: user’s terminology is applied.

■ Order a bottle of chemical X from vendor A or B.

■ Search a document collection based on criteria A, B, C.

■ Output data every 3 milliseconds in JJU format.

■ Update interest rate based on loan database update.

Normal flow: [What is the ideal flow?]

Actor Actions System Responses

Alternative Flow: [Any alternatives?]

❏  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.

■  Introduction to Software Requirements Engineering…….. 3

■  Requirements Development and Management Process… 8

■  Summary: Requirements Good Practices …..……………. 86

■  Improving Your Requirements Processes …..…………….89

■  Further Reading ……………………….……………………..91

■  Creating and reviewing multiple views of requirements helps

•  Write down your top 1-2 project deadlines/deliverables related to

•  Write down your top 3-5 requirements problems (and/or risks)

■  Distinct groups of users for a product:

■  Scheduling / billing system User Classes and tasks:

■  Primary interface between development

Requirements: ●  Interview other users they represent

Documentation: ●  Contribute to user manuals and on-line help

Advocacy: ●  Help “sell” the system to customer communities

■  What business problem are you trying to solve?

■  Write 1-2 Business Objectives for one of your projects

■  Draw a context diagram (Vision Statement) for your current

■  Most frequently used

■  Largest user class

■  Core features to support

■  Keep asking “WHY?” to drill down to real needs.

■  Ask open-ended questions.

■  External Interface Requirement

■  User-centric: user’s terminology is applied.

■  Order a bottle of chemical X from vendor A or B.

■  Search a document collection based on criteria A, B, C.

■  Output data every 3 milliseconds in JJU format.

■  Update interest rate based on loan database update.

■  Actor: a human user or other system that provides the trigger

1.  Register a site admin.

■  Use cases work well for:

■  Use cases aren’t as valuable for:

■  Store information about the system’s

•  Makes update simpler - does not Ref. Figure 13-4. Software

■  Elicit several proposed use cases for your system.

■  Characteristics of software that are visible to users or

• The system shall be able to import chemical structures

• 90% of database queries shall be completed in no more

• All functions on the File menu shall have keyboard

■  “A business rule is a statement that defines or constrains

■  Write atomic business rules:

■  Some people define them as constraints,

■  These requirements may have been identified earlier in the

■  Two common styles of defining Functional Requirements:

•  2: Functional requirements = ADDITIONAL software characteristics that

■  Select one use case. Write several functional requirements

■  Trace each functional requirement

■  Evaluate from the developer’s perspective.

■  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

■  Need to understand which requirements are most

■  Setting priorities will help you

■  Estimate relative benefit and penalty for each feature

■  Risk: 1 = code while sleeping; 9 = very challenging

■  Priority = value% / (cost% + risk%)