Software Requirements Workshop Presentation

The Software Requirements

Process

PMI Tools & Techniques Forum

Ivars K. Lenss, PMP

[email protected]

[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


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

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)


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

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)


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


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

What are Software

Requirements?


Ivars K. Lenss, PMP


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


March 4, 2009


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

BUSINESS

REQUIREMENTS

USER

REQUIREMENTS

FUNCTIONAL

REQUIREMENTSDESIGN

BUSINESS

ANALYSIS

SOFTWARE REQUIREMENTS

CUSTOMER USER SUPPLIER

BUILD


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]

Exercise


March 4, 2009

Ivars Lenss, PMP


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.


March 4, 2009

Use Case Diagram

START

SESSION

VIEW

BALANCE

WITHDRAW

CASH

MAKE

DEPOSIT

CANCEL

TRANSACTION

TRANSFER

MONEY

BANK

CUSTOMER

ATM


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


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


March 4, 2009


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

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

Requirements Patterns


Ivars K. Lenss, PMP


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

Documents

Software Requirements Workshop Presentation