Understanding Requirements

Understanding Requirements
2
Objectives
Objectives
 What are requirements
 Types of requirements
3
Requirements
Business Modeling
Requirements
Analysis & Design
Workflows
W o r k f l o w s
Inception
Elaboration
Phases
Construction
Transition
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
Iterations
Initial
E
#
1
E
#
2
C
#
1
C
#
2
C
#
n
T
#1
T
#2
Content
Time
4
Relevant Requirements Artifacts
Supplementary
Specification
Glossary
Use-Case Specifications
...
Use-Case Model
Actors
Use Cases
5
UP artifact influence
Operation :
enterItem (…)
Post-conditions :
- . . .
Operation Contracts
S a le
d a te
. . .
S a le s
L in e Ite m
quantity
1 1. . * . . .
. . .
Domain Model
U s e
-
Case Model
Design Model
: Register
enterItem
(ite m ID , quantity )
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem ( sp e c , quantity )
: S a le
objects, attributes,
associations
Req u ire
-
men ts
Business
Modeling
D esig n
Sample UP Artifact Relationships
: S yste m
enterItem
(i d , quantity)
Use Case Text
System Sequence Diagrams
m a ke
N ew Sale ( )
system
events
Cashier
Process
S a le
: C ashier
use
case
nam es
system
operations
Use Case Diagram
V isio n
Supplementary
Specification
Glossary
sco p e , g o a ls ,
actors, features
term s, attributes,
validation
n o n -functional reqs,
quality attributes
requirements
Process Sale
1. Customer
arrives ...
2. Cashier
makes new
s a le .
3. ...
6
What are requirements?
 Requirements
are capabilities and conditions
to which the system must conform
 FURPS
 F unctionality
 U sability
 R eliability
 P erformance
 S upportability
7
What Requirements Are Not
 Design or implementation details
 Project planning information
 Testing strategies or details
 Other project requirements like
 Development environment
 Budget limitations
 Training
8
Purpose
 Establish and maintain agreement with customers
and other stakeholders on what the system should
do.
 Provide system developers with better
understanding of the system requirements
 Define the boundaries of the system
 Provide a basis for planning the technical contents
of iterations
 Provide a basis of estimating cost & schedule
 Define a user interface for the system
9
Process
 Define a vision of the system
 Translate the vision into a use case model
 Generate supplementary specifications
10
Requirements Changes
 A prime challenge of requirements work is to find,
communicate, and remember (that usually means
record) what is really needed, in a form that clearly
speaks to the client and development team
members.
 Requirements are changing
itracesgnuR , a development
team needs to:
 Use a systematic approach to finding,
documenting, organizing,
and tracking
tragncki
the
changing requirements of a system
11
Impact Factors on a project
Poor user input
13%
Changing requirements
12%
Poor technical skills
7%
Poor staffing
6%
Other
50%
Incomplete requirements
12%
12
Types of Requirements
 Functional
—features, capabilities, security.
 Nonfunctional
 Usability
—human factors, help, documentation.
 Reliability
—frequency of failure, recoverability, predictability.
 Performance
—response times, throughput, accuracy, availability,
resource usage.
 Supportability
—adaptability, maintainability, internationalization,
configurability.
 Other Requirements
 Implementation
—resource limitations, languages and tools,
hardware, ...
 Interface
—constraints imposed by interfacing with external
systems.
 Operations
—system management in its operational setting.
 Packaging
 Legal
—licensing and so forth.
13
Functional requirements
 Functional == "What the system does."
 A functional requirement is typically something
that a non-techie domain expert can identify.
 In the Unified Process, functional requirements
are captured in:
 Vision Statement
 Use Cases
 Supplementary Specification
14
Non-functional requirements
 Every requirement that isn't a functional
requirement is a (duh!) non-functional requirement.
 Examples:
 Reliability
 Response time
 Maximum backup time
 Implementation language
 Non-functional requirements are still
requirements — they must be testable.
15
Features
 Features – higher-level expressions of system
behavior
raebovhi
 Representation of real needs
 Provide context to the requirements workflow
 Adding attributes enhances comprehension
• Risk
• Priority
• Level of effort
16
Example of System Features
For example, System Features of POS:
 sales capture
 payment authorization (credit, debit, check)
 system administration for users, security, code
and constants tables, and so on
 automatic offline sales processing when external
components fail
17
System Features in POS
 R1.1 – Record the current sale – the items purchased
 R1.2 – Calculate current sale total, including tax and
coupon calculations
 R1.4 – Reduce inventory quantities when sale is
committed
 R1.5 – Log completed sale
 R1.6 – Cashier must login with an ID and password to use
system
 R1.7 – Provide a persistent storage mechanism
 R1.8 – Provide inter-process and inter-system
communication mechanism
 R1.9 – Display description and price of item recorded
18
Features vs. Requirements
 A “feature” is a set of logically related functional
requirements
 It provides capability to a user and enables
satisfaction of a business objective
 Examples:
 It’s easy to add clip art to your presentation!
 All of last year’s messages from XXX can be
displayed instantly!
 Our “Web-Link” technology discovers the
identity of selected clients in your database!
19
Another View of Requirements
Vision and Scope Document
Use Case Document
Business Requirements
User Requirements
Business Rules
Quality Attributes
Systems Requirements
Functional Requirements
External Interfaces
Constraints
Software Requirements
Specification
Functional Nonfunctional
20
Business Requirements
 High-level objectives of the organization
 These are at the top-most level of the
“requirements chain”
 These come from
 the funding sponsor, or
 the customer, or
 marketing
21
Business Requirements (Continue)
 We must have these before any other (e.g., user
and functional) requirements
 These must show how the project will achieve
business objectives
 These are the basis for determining product
features and proposed releases
 These should be very public
 Record these in a “Vision and Scope” document
22
The Vision Thing
 RUP provides a standard vision template
 Sections of greatest interest (to us):
 Stakeholder and user descriptions
 Features
 Other product requirements
 Following is the table of contents from the
standard RUP Vision document template – we
won’t do this for all the RUP documents …
23
Vision Document Table of Contents
1. Introduction
2. Positioning
3. Stakeholder and User Descriptions
4. Product Overview
5. Product Features
6. Constraints
7. Quality Ranges
8. Precedence and Priority
9. Other Product Requirements
10. Documentation Requirements
11. Appendix 1 - Feature Attributes
24
User Requirements
 User tasks that the user must be able to
perform
 These can be described by
 use cases, or
 scenario descriptions, or
 event-response tables or…
 Record these in a “Use Case” document
25
System Requirements
 These are for “systems,” i.e., things that contain
subsystems
 Subsystems may be hardware or software or both
 People are part of a system, too
 Example: Airline reservation system
 Software subsystems: dbase manager, graphical UI,
communication system, etc.
 Hardware subsystems: Mainframes, access
terminals, communication infrastructure, etc.
 People: Travel agents, etc.
26
Who Are The Stakeholders in a Software Project?
 Customers who fund or buy a product
 Users who use the product
 Requirements analysts
 Developers and testers
 Project managers
 Legal staff
 Manufacturing people
 Sales, marketing, field support, help desk, etc.
27
Stakeholders
Stakeholders
Customers Others
Procurers Users
Managers
Favored
User Classes
Disfavored
User Classes
Ignored
User Classes
Other
User Classes
28
Stakeholder Description
[Name: Stakeholder name, e.g. system administration]
Date Identified:
09 / 07 / 2003
Representative
[Names of individuals who represent this stakholder.]
Description:
[Brief description of the stakeholder type.]
Type
[Qualify the stakeholder’s expertise, technical background, and degree of sophistication —that is, guru, business, expert, casual user,
etc.]
Responsibilities:
[List the stakeholder’s key responsibilities with regards to the system being developed —that is, their interest as a stakeholder.]
Success Criteria:
[How does the stakeholder define success? How is the stakeholder rewarded?]
Involvement
[How the stakeholder is involved in the project? Relate where possible to RUP workers —that is, Requirements Reviewer etc.]
Deliverables:
[Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system
under development.]
Comments/Issues
[Problems that interfere with success and any other relevant information go here.]
29
Requirements Workflow
 Analyze the Problem
 Understand Stakeholder Needs
 Define the System
 Manage the Scope of the System
 Refine the System Definition
 Manage Changing Requirements
30
Requirements Workflow Activity Diagram
[New
System]
Manage
Changing
Requirements
Define the
System
Understand
Stakeholder
Needs
[Existing
System]
Analyze the
Problem
[Incorrect
Problem]
[Correct
Problem]
Manage
Scope of
System
[Work in
Scope]
Refine
System
Definition
[More
Iterations]
[Requirements
Definition
Complete]
[New Input]
[Work not
in Scope]
31
Workers in Requirements
 System Analyst
 Use-Case Specifier
 User-Interface Designer
 Architect
 Requirements Reviewer
32
System Analyst
 Leads and coordinates requirements elicitation
and use-case modeling
 Analyzes the problem
 Works with stakeholders of the project to
determine their needs
 Identifies non-functional requirements, if any
 Develops a vision from stakeholder’s point of view
33
Use-Case Specifier
 Details all or part of a system’s functionality by
describing the requirements aspect of one or
several cases
 Makes the requirements consistent with other
requirements workflow artifacts
 Works with other individual Use-Case Specifiers
and with System Analyst
34
User-Interface Designer
 Responsible for selecting the set of use cases to
demonstrate the essential interactions of the users
with the system
 Develops Use-Case Storyboards and User-
Interface Prototype
 Works in parallel with the Use-Case Specifier to
design the system’s user interface
35
Architect
 Involved in early iterations
 Works with System Analyst and Use-Case
Specifier
 Ensures integrity of those use cases which are
architecturally significant
36
Requirements Reviewer
 Any individual brought in to verify that :
 Requirements are perceived correctly
 Requirements are interpreted correctly
 May review requirements several different times
during the execution of the requirements workflow
37
Artifacts in Requirements (1 of 4)
 Stakeholder Requests:
 actively elicited
 different stakeholders may have different expectations
about what system includes
 Vision Document:
 complete vision for software system being developed
 supports the “contract” between funding authority and
development organization
38
Artifacts in Requirements (2 of 4)
 Use-Case Model:
 communication medium
 “contract” among customer, users, and developers on
functionality of system:
• customers and users validate that system will
meet their expectations
• system developers build what is expected
 consists of Use Cases and Actors
 shows each Use Case in detail
39
Artifacts in Requirements (3 of 4)
 Supplementary Specifications:
 complement to the Use-Case Model
• together capture all software requirements
• functional (behavioral) and nonfunctional
 primarily nonfunctional requirements – cannot associate
with a particular use case
 capture as a list of requirements
40
Supplementary Specification
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Design constraints
Supplementary
Specification
41
Example: Supplementary Specification
 Review the
Supplementary
Specification provided
in the Course
Registration
Requirements
Document.
Course
Registration
Requirements
Document
Supplementary
Specification
42
Artifacts in Requirements (4 of 4)
 Software Requirements Specifications
 packages complete definition of software requirements
 based on use cases and Supplementary Specifications
 can be used for “full product”, a particular “feature”, or
some other sub-system grouping
• E.g. a “component” specified in a SOW
43
Miscellaneous Artifacts
 Glossary
 defines a common terminology used throughout
project or organization
 User-Interface Prototype
44
Glossary
Glossary
Course Registration System Glossary
1.
Introduction
This document is used to define terminology specific to the problem
domain, explaining terms, which may be unfamiliar to the reader of the
use-case descriptions or other project documents. Often, this document
can be used as an informal data dictionary, capturing data definitions so
that use-case descriptions and other project documents can focus on
what the system must do with the information.
2.
Definitions
The glossary contains the working definitions for the key concepts in the
Course Registration System.
2.1
Course:
A class offered by the university.
2.2
Course Offering:
A specific delivery of the course for a specific
semester – you could run the same course in parallel sessions in the
semester. Includes the days of the week and times it is offered.
2.3
Course Catalog:
The unabridged catalog of all courses offered by
the university.
45
Case Study: Glossary
 Review the Glossary
provided in the Course
Registration
Requirements Document
Glossary
46
Case Study: Supplementary Specification of the POS system (1/5)
Supplementary Specification
 Logging and Error Handling:
L o g i n g a n d E r o r H a n d l i n g :
Log all errors to persistent storage.
 Pluggable Business Rules:
P l u g a b l e B u s i n e s R u l e s :
At various scenario points of several use cases
(to be defined) support the ability to customize the functionality of the system
with a set of arbitrary rules that execute at that point or event.
 Security:
S e c u r i t y :
All usage requires user authentication.
 Usability (
Human Factors)
H u m a n F a c t o r s )
The customer will be able to see a large-monitor display of the POS.Therefore:
Text should be easily visible from 1 meter.
Avoid colors associated with common forms of color blindness.
 Speed, ease, and error-free processing are paramount in sales processing,
as the buyer wishes to leave quickly
 The cashier is often looking at the customer or items, not the computer
display. Therefore, signals and warnings should be conveyed with sound
rather than only via graphics.
 Reliability
 Recoverability
R e c o v e r a b i l i t y
No failure should be allowed (payment authorizer, accounting system, ...)
Much more analysis is needed
47
Continue (2/5)
 Performance
Buyers want to complete sales processing very quickly. One potential
bottleneck is external payment authorization. It is required to achieve
authorization in less than 1 minute, 90% of the time.
 Supportability
Adaptability
A d a p t a b i l i t y
To support different business rules
 Configurability
C o n f i g u r a b i l i t y
The ability to modify network configurations, to reflect their changing business
and performance needs. The system should be configurable to reflect these
needs. Much more analysis is needed in this area.
 Implementation Constraints
(Constraints
are not behaviors, but some other kind of restriction on
the design or project)
Customer insists on a Java technologies solution, predicting this will improve
long-term porting and supportability, in addition to ease of development.
 Purchased Components
Tax calculator. Must support pluggable calculators for different countries.
48
Continue
(3/5)
 Interfaces
 Hardware Interfaces
H a r d w a r e I n t e r f a c e s
Touch screen monitor
Barcode laser scanner
Receipt printer
Credit/debit card reader
 Software Interfaces
S o f t w a r e I n t e r f a c e s
For most external collaborating systems (tax calculator,
accounting, inventory, ...) we need to be able to plug in
varying systems and thus varying interfaces.
 Legal Issues
All tax rules must, by law, be applied during sales. Note
that these can change frequently.
49
Continue (4/5)
Purchaser discount rules. High Retailer policy.
Examples:
Employee. 20% off. Preferred
Customer. 1 0% off. Senior. 15%
Rule 3
Credit authorization
companies.
High. Tax laws
Change annually
Rule 1 Signature required for credit payments.
Tax rules. See government statutes High
for current details
Rule 2
Product (line item level) discount High Retailer policy.
rules.
Examples:
10% off small elec this week. Buy 2
burgers, get 1 free.
Rule 4
Source
Changeability
Rule
ID
Business Rules
are not application requirements
. Do not record system features as
rules. They describe the constraints and behaviors of how the domain works,
not the application.
50
Continue (5/5)
Information in Domains of Interest
 Credit and Debit Payment Handling
C r e d i t a n d D e b i t P a y m e n t H a n d l i n g
When an electronic credit or debit payment is approved by a payment
authorization service, they are responsible for paying the seller, not the
buyer. Consequently, for each payment, the seller needs to record
monies owing in their accounts receivable, from the authorization
service. Usually on a nightly basis, the authorization service will
perform an electronic funds transfer to the seller’s account for the daily
total owing, less a (small) per transaction fee that the service charges.
 Sales Tax
S a l e s T a x
Sales tax calculations can be very complex, and regularly change in
response to legislation at all levels of government. Therefore,
delegating tax calculations to third-party calculator software is
advisable. Tax may be owing to city, region, state, and national bodies.
Some items may be tax exempt without qualification, or exempt
depending on the buyer or target recipient (for example, a farmer or a
child).
51
Case Study: Write the vision of POS (1/5)
 Problem Statement
P r o b l e m S t a t e m e n t
Traditional POS systems are inflexible, fault intolerant, and difficult
to integrate with third-party systems
. This leads to problems in
timely sales processing, instituting improved processes that don’t
match the software, and accurate and timely accounting and inventory
data to support measurement and planning, among other concerns.
This affects cashiers, store managers, system administrators, and
corporate management.
 Stakeholder Descriptions
Understand who the players are, and their problems.
The Accounting Department use system for accounting purpose
PriceMart Customer (user)
Stakeholder Reason (or Description)
52
Continue (2/5)
 Identify key goals and problems
 How should we do it?
A one day requirements workshop with subject matter experts and
other stakeholders, and surveys at several retail outlets led to
identification of the key goals and problems of POS:
Existing POS
products
provide basic sales
processing, but do
not
address these
problems.
Reduced speed as load increases.
Loss of sales processing capability if
components fail.
Lack of up-to-date and accurate information
from accounting and other systems due to
non-integration with existing accounting,
inventory, and HR systems.
Leads to difficulties in measuring and
planning.
Inability to customize business rules to
unique business requirements.
Difficulty in adding new terminal or user
interface types (for example, mobile
PDAs
).
high
Fast, robust,
Integrated sales
processing
Current Solutions
Problems and Concerns
Priority
High-Level Goal
53
Continue (3/5)
User-Level Goals
U s e r - L e v e l G o a l s
 This may be the Actor-Goal List created during use-case modeling,
The users (and external systems) need POS to fulfill these goals:
 Cashier: process sales, handle returns, cash in, cash out
 System administrator: manage users, manage security, manage system tables
 Manager: start up, shut down
 Sales activity system: analyze sales data
 ……
User Environment
U s e r E n v i r o n m e n t
 Client
 Server
54
Continue (4/5)
 Product Overview (Context Diagram)
 How to do it?
 Summarize from the use case diagram.
NextGen POS
Cashier
S yste m
Administrator
Store
Manager
Calls upon
services
Calls upon
services
«actor»
Payment
Authorization
Service
«actor»
Tax Calculator
«actor»
Accounting
S yste m
«actor»
Hum an
Resources
S yste m
«actor»
Inventory
S yste m
«actor»
Sales Activity
S yste m
55
Continue (5/5)
 Assumptions and Dependencies
A s u m p t i o n s a n d D e p e n d e n c i e s
 Cost and Pricing
C o s t a n d P r i c i n g
 Licensing and Installation
L i c e n s i n g a n d I n s t a l a t i o n
 Summary of System Features
(Features are things a system can do)
 sales capture
 payment authorization (credit, debit, check)
 system administration for users, security, code and constants tables, and
so forth.
 automatic offline sales processing when external components fail
 real-time transactions, based on industry standards, with third-party
systems, including inventory,
 accounting, human resources, tax calculators, and payment authorization
services
 definition and execution of customized "pluggable" business rules at fixed,
common points in the processing scenarios
 Other Requirements and Constraints
Including design constraints, usability, reliability, performance,
supportability, design constraints, documentation, packaging, and so
forth: See the Supplementary Specification and use cases.
56
Vision, Features, or Use Cases. Which First?
 It is not useful to be rigid about the order of some
artifacts. They help clarify another.
 A suggested sequence is:
 1. Write a brief first draft of the Vision.
 2. Identify user goals and the supporting use cases.
 3. Write some use cases and start the Supplementary
Specification.
 4. Refine the Vision, summarizing information from
these.
57
Common Problems
 Insufficient user involvement
 Creeping user requirements
 Ambiguous requirements
 Gold plating
 Minimal specification
 Overlooked user classes
 Inaccurate planning