2. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
3. 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]
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
4. 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]
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
5. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
6. Raw Requirements
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)
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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
7. 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?
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
8. Well-Formed Requirements
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)
Abstract: Independent of its implementation
Unambiguous: Interpreted in only one way
Traceable: Associated with source
Validateable: Fit criteria
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
9. Example
Requirement: “The traffic monitor running in the
background shall provide status messages at
regular intervals not less than every minute.”
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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
10. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
11. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
12. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
13. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
14. What are Software
Requirements?
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
15. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
16. 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.
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
17. Software Requirements Players
Customer
User
Supplier
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
18. Software Requirements Levels
SOFTWARE REQUIREMENTS
BUSINESS BUSINESS USER FUNCTIONAL
DESIGN BUILD
ANALYSIS REQUIREMENTS REQUIREMENTS REQUIREMENTS
CUSTOMER USER SUPPLIER
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
19. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
20. Functional Requirements
Describe software functionality that
developers must build
Sometimes called behavioral
requirements
Typically in the form of “shall”
statements
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
21. Software Requirements Specification
Basic issues addressed in an SRS are:
Functionality
External interfaces
Performance
Non-functional requirements
Constraints imposed on the solution
[IEEE Standard]
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
23. 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.
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
24. Use Case Diagram
ATM
START
SESSION CANCEL
TRANSACTION
VIEW
BALANCE
WITHDRAW
CASH
BANK
CUSTOMER TRANSFER
MONEY
MAKE
DEPOSIT
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
25. Architecture Diagram
ADMINISTRATOR
ACCESS INTERFACE MONEY
STORAGE
ATM UNIT
HARDWARE
ATM ACCESS
DEPOSIT
INTERFACE
INTERFACE
CUSTOMER ACCESS
STORAGE
ATM UNIT
INTERFACE
SOFTWARE
BANK INTERFACE CAPTURE
CUSTOMER
CARD
DATA
DATA
BASE
REPOSITIORY ATM DEVICE
INTERFACE
HOST
COMMUNICATION
MODULE
Ivars K. Lenss, BANK HOST
PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
SYSTEM
26. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
27. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
28. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
29. Software Requirements Attributes
Stability
Status
Acceptance criteria [metric]
Complexity [metric]
Performance [metric]
Urgency [metric]
Business value [metric]
Risk [metric]
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
30. 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
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
31. Some Useful Software Metrics
Product size
Estimated and actual duration
Estimated and actual effort
Work effort distribution
Defects
Requirements status
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
33. 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)
Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us
March 4, 2009
Source: Software Reruirements Patterns, Withall, 2007
34. 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