Software Requirements Workshop Presentation

The Software Requirements
Process

PMI Tools & Techniques Forum
Ivars K. Lenss, PMP

Ivars@Lenss.us

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

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]

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]

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
March 4, 2009

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

March 4, 2009

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

March 4, 2009

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

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

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

March 4, 2009

What are Software
Requirements?

Ivars K. Lenss, PMP

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

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.

March 4, 2009

Software Requirements Players

 Customer
 User
 Supplier

March 4, 2009

Software Requirements Levels

SOFTWARE REQUIREMENTS

BUSINESS BUSINESS USER FUNCTIONAL
DESIGN BUILD
ANALYSIS REQUIREMENTS REQUIREMENTS REQUIREMENTS

CUSTOMER USER SUPPLIER

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

March 4, 2009

Functional Requirements

 Describe software functionality that
developers must build
 Sometimes called behavioral
requirements
 Typically in the form of “shall”
statements

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]

March 4, 2009

Exercise

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

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.

March 4, 2009

Use Case Diagram

ATM
START
SESSION CANCEL
TRANSACTION

VIEW
BALANCE

WITHDRAW
CASH

BANK
CUSTOMER TRANSFER
MONEY

MAKE
DEPOSIT

March 4, 2009

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

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

March 4, 2009

Software Requirements Attributes

 Stability
 Status

 Acceptance criteria [metric]
 Complexity [metric]
 Performance [metric]
 Urgency [metric]
 Business value [metric]
 Risk [metric]
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
March 4, 2009

Some Useful Software Metrics

 Product size
 Estimated and actual duration
 Estimated and actual effort
 Work effort distribution
 Defects
 Requirements status
March 4, 2009

Requirements Patterns

Ivars K. Lenss, PMP

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)
March 4, 2009
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

Software Requirements Workshop Presentation

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Software Requirements Workshop Presentation

Semelhante a Software Requirements Workshop Presentation (20)

Software Requirements Workshop Presentation