Software Requirements - The Process Groupprocessgroup.com/software-requirements-v10-full.pdf · What is a Software Requirement? ... [Based on K. Wiegers Software Requirements] ...

© 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


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

■  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


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


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

#2: User Requirements


Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements

Other Nonfunctional Requirements

External Interfaces

#3:Functional Requirements

#1: Business Requirements


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


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


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


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




Requirements and The V-Model

From: en.wikipedia.org/wiki/V-Model_(software_development)

V-Model

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


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

Your Class Expectations


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

Start IdentifyUsers

Define Vision

& Scope

UnderstandUser Needs

DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes


Identify Users

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes


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


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.

■  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


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:


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


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

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes



Define Vision

& Scope




Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces



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?



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


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

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


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


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



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


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

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes



!!




Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces


Define Vision

& Scope!


The Need for Customer Involvement

Customer involvement is a critical factor in software quality.

Expectation Gap Surprise!

Time


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


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!


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


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

External Interface

Requirement

Functional Requirement

Solution Idea Business Rule

Constraint Quality Attribute

Business Requirement

Use Case or Scenario

Data Definition


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”



■  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”



■  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

User Workshops

User Reqs.

Draft Test Cases

Verified User Reqs.

Draft Models

Draft User Reqs.

Business Rules

Verified Models

Shared Vision v1.0


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


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


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

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!


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]


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


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


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

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.


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


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.


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



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.



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, 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


■  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


Event Tables


System Events as User Requirements

Sensor

Device control signal

Actor

External Database

Your System


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







Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces


!!!

!


Quality Attributes




Business Rules

Quality Attributes

Vision and Scope

User Requirements


!!!

!


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


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




Business Rules

Quality Attributes

Vision and Scope

User 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

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






Business Rules

Quality Attributes

Vision and Scope

User 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

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes



DeriveFunctional

Requirements




Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces


!!! !

!

!!


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)


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.



DeriveFunctional

Requirements




Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces


!!! !

!

!!

!!!


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

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:


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.






Constraints

Business Rules

Quality Attributes

System Requirements

Vision and Scope

User Requirements


External Interfaces


!!! !

!

!!

!!! !


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?

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


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

■  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


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


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)


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


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

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes



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


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 •  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


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


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


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


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:



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



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


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

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% --











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


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


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


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


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


Am

bigu

ity


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


Gap

s











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


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





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


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

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


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


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


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

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


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











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


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


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.


Defect Logging Meeting

Moderator & Scribe

Documents

■  High-level

■  Low-level

■  Standard

■  Common-errors Checklist

■  Reference Material

Document Owner/Reviewer

Reviewers

Inspection (Peer Review)


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?

■  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


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


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


Manage Requirements Changes

Start IdentifyUsers

Define Vision

& Scope


DeriveFunctional

Requirements

Analyze &Verify

Requirements

Manage Requirements

Changes


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

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


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

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


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


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

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


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


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


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


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.