The document discusses the software requirements process and what constitutes a software requirement. It addresses that a software requirement can exist at the business, user, or functional level and includes conditions or capabilities needed by stakeholders. Requirements must be well-formed to be unambiguous and validateable. They should be documented to ensure common understanding as a project progresses.

1. The Software Requirements
Process
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
Ivars@Lenss.us

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

22. Exercise
 PMI Tools & Techniques Forum
 March 4, 2009
 Ivars Lenss, PMP

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

32. Requirements Patterns
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP

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