The Software Requirements
Process
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What Is a Requirement?
(1) A condition or capability needed by a stakeholder
to solve a problem or achieve an objective.
(2) A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed documents.
(3) A documented representation of a condition or
capability as in (1) or (2)
Source: IEEE Std 610.12-1990
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What Is a Requirement?
The IIBA built on the IEEE definition:
A requirement is a condition or capability needed by a
stakeholder to solve a problem or achieve an
objective.
[source: IIBA Business Analysis Body of Knowledge (IIBA, 2008]
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What Does a Requirement Look Like?
• A sentence (“The system shall…”)
• A structured sentence (as in a business rule)
• A structured text template
• A table or spreadsheet (list of stakeholders)
• A diagram (workflow)
• A model (entity-relationship diagram and details)
• A prototype
• A graph
• Any format that communicates
[source: Seven Steps to Mastering Business Analysis, Barret, 2009]
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
How Requirements Work
Requirements are not solutions
Design translates requirements into solutions
Many stakeholders mix requirements with their
proposed solutions
Requirements gathering is discovering the
essence of the system
Essence is the business reason of the work -
what the work would be if there was no project
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Raw Requirements
Higher-level statements of the business
goals, objectives, and success factors
Often expressed in initiating documents
Often vague and subjectively interpreted
Can be intermingled with ideas and
suggestions for potential designs
A raw requirement is an environmental or customer requirement that has not been analyzed and formulated as a well-formed requirement. (IEEE Std 1233, 1998 Edition)
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Example
Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”
What are the status messages?
How are they provided to the user?
If displayed, how long are they displayed?
What is the acceptable timing interval?
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Well-Formed Requirements
Abstract: Independent of its implementation
Unambiguous: Interpreted in only one way
Traceable: Associated with source
Validateable: Fit criteria
A well-formed requirement is a statement of system functionality
(a capability) that can be validated, and that must be possessed
by a system to solve a customer objective, and is qualified by
measurable conditions and bounded by constraints. (IEEE Std 1233, 1998 Edition)
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Example
The traffic monitor shall display status
messages in a designated area of the user
interface
The messages shall be updated every 60
seconds, plus or minus five seconds
Messages shall remain visible continuously
Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Requirements Classification
Functional Requirements
- Things the product must do
- Action verbs – calculate, produce, inspect, publish
Nonfunctional Requirements
- Qualities the product must have
- Look and feel, performance, security, regulatory
Constraints
- Boundaries and limits on the solution
- Business constraints
- Technical constraints
- Glossary and naming conventions
- Training, knowledge transfer
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Examples
Functional
The rail system shall move people from San Francisco to Los Angeles
Nonfunctional
The rail system shall operate at an optimal cruise speed of 100 miles per hour
Constraint
The rail system shall operate at a maximum speed of 130 miles per hour
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Approaches
Traditional Requirements specification produced before
starting design and build
Agile Developers and architects do not have a
requirements specification as a starting point
The requirements are somewhere (they separate the what from the how)
If you identify a requirement, record it
Incremental Combination of traditional and agile approaches
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Why Document Requirements?
People forget things
Verbal communication is subjective
People sometimes answer the same question differently if asked twice
Writing something down forces a person to think about it more carefully than when they say it
Having more eyes to review highlights ambiguity
New people joining the project need to know requirements
If it’s not in writing, it doesn’t exist
What are Software
Requirements?
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What is a Software Requirement?
Software requirements include 3 distinct levels
Business Requirements
Why the project exists
Business objectives
User requirements
What the user will be able to do with the product
Functional requirements
Behaviors or operations under specific conditions
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What is a Software Requirement?
Nonfunctional requirements
Properties or qualities that the solution must have (look
& feel, usability, performance, operational,…)
Technical constraints
Pose restrictions on acceptable solution options:
Predetermined language
Predetermined hardware
Restrictions on message sizes, software sizes, number and size
of files, protocols, architecture standards, etc.
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Players
Customer
User
Supplier
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Levels
BUSINESS
REQUIREMENTS
USER
REQUIREMENTS
FUNCTIONAL
REQUIREMENTSDESIGN
BUSINESS
ANALYSIS
SOFTWARE REQUIREMENTS
CUSTOMER USER SUPPLIER
BUILD
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
User Requirements Bridge the requirements of the business and the
requirements of the software
A user is anyone who is affected by the project
Includes people and external systems that interact directly
Includes people and external systems that receive system by-products (reports, decisions, questions)
Software development provokes change in the behavior of users
Business workflow often changes, along with policies, procedures, interactions between people
When defining user requirements, users will be faced with decisions about how and where to change their work
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Functional Requirements
Describe software functionality that developers must build
Sometimes called behavioral requirements
Typically in the form of “shall” statements
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Specification
Basic issues addressed in an SRS are:
Functionality
External interfaces
Performance
Non-functional requirements
Constraints imposed on the solution
[IEEE Standard]
Exercise
PMI Tools & Techniques Forum
March 4, 2009
Ivars Lenss, PMP
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Exercise
You have been assigned a project to manage
development of software for an ATM machine.
Your customer provides you with some business
requirements, a use case diagram and
architecture diagram for the ATM machine.
You are planning to meet with your stakeholders
to discuss software requirements.
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Use Case Diagram
START
SESSION
VIEW
BALANCE
WITHDRAW
CASH
MAKE
DEPOSIT
CANCEL
TRANSACTION
TRANSFER
MONEY
BANK
CUSTOMER
ATM
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Architecture Diagram
BANK HOST
SYSTEM
BANK
CUSTOMER
HOST
COMMUNICATION
MODULE
DATA
REPOSITIORY
INTERFACE
ATM
SOFTWARE
INTERFACE
ATM
HARDWARE
INTERFACE
MONEY
STORAGE
UNIT
DEPOSIT
STORAGE
UNIT
CAPTURE
CARD
DA
TA
BA
SE
CU
ST
OM
ER
AC
CE
SS
INT
ER
FA
CE
ATM DEVICE
AT
M A
CC
ES
S
INT
ER
FA
CE
ADMINISTRATOR
ACCESS INTERFACE
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Exercise
Divide into groups
Each group will make a list of questions to ask to define requirements for the ATM software
Write any questions that you would need to ask of your software supplier, your users, or your customer to elicit requirements for your software specification
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
What is a Software Requirement?
Software requirements include 3 distinct levels
Business Requirements
Why the project exists
Business objectives
User requirements
What the user will be able to do with the product
Functional requirements
Behaviors or operations under specific conditions
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Specification
Software specifications may contain all of the functionality of the product or part of a larger system
Larger systems will typically have an SRS stating the interfaces between the systems
The interfaces place external performance and functionality requirements upon the software
Avoid placing design requirements in an SRS
Specify the problem, not the solution
Specify the system, not the project
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Software Requirements Attributes
Stability
Status
Acceptance criteria [metric]
Complexity [metric]
Performance [metric]
Urgency [metric]
Business value [metric]
Risk [metric]
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Establishing Metrics
Project Metrics – measurements associated with
the project
Cost, effort, schedule, risk, resources, etc.
Product Metrics – measurements associated
with the product
Defects, performance, size, etc.
Software requirements are a good place to
choose appropriate product metrics
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Some Useful Software Metrics
Product size
Estimated and actual duration
Estimated and actual effort
Work effort distribution
Defects
Requirements status
Requirements Patterns
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
[email protected] Ivars K. Lenss, PMP PMI Tools & Techniques Forum
March 4, 2009
Requirements Patterns
Requirement patterns recur repeatedly across commercial systems
Eight domains
1. Fundamental (things needed for any kind of system)
2. Information (information the systems needs)
3. Data Entity (divide data entities by characteristics)
4. User Function (inquiry, report, accessibility, interface)
5. Performance (how fast, how long, how big, how much)
6. Flexibility (ability to adapt to suit changing circumstances)
7. Access Control (user registration, authorization)
8. Commercial (pertaining to systems used to run a business)
Source: Software Reruirements Patterns, Withall, 2007
Further Reading
1. Wiegers, Karl E., Software Requirements , 2nd ed., Microsoft Press, 2003
2. Wiegers Karl, E., More about Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, 2006
3. Withall, Stephen, Software Requirement Patterns, Microsoft Press, 2007
4. Hass K., Wessels D., Brennan K., Getting It Right, Business Requirement Analysis Tools & Techniques, Management Concepts, 2008
5. IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
6. IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications
7. IEEE Std 1074-2006, IEEE Standard for Developing a Software Project Life Cycle Process