requirements analysis - northeastern university

REQUIREMENTS ANALYSIS

M. Weintraub and F. Tip

Thanks go to Martin Schedlbauer and to Andreas Zeller

for allowing incorporation of their materials

READY, FIRE, AIM

2


3

SPECIFICATION PHASE

Specificationrequirements gathering

What is it and

How do we get there?

WHAT IS IT?

A requirement specifies what stakeholders want for a system.

FORMAL DEFINITION

6

1. A condition or capability needed by a user 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).

ANSI/IEEE Standard 610.12-1990

PLAINER ENGLISH VERSION

A requirement is a system feature, capability, or constraint defining what a system should do,

not how it should or could be done

TYPES OF REQUIREMENTS

Non-functionalFunctional

DEFINITION – FUNCTIONAL REQUIREMENTS

9

An action the product must take to be useful.

Services the system must provide.

DEFINITION – FUNCTIONAL REQUIREMENTS

1. The product SHALL track individual

payments of coffee servings.

2. The product MUST heat water to 150F.

10

Example: Commercial Coffee Machine

DEFINITION – NON-FUNCTIONAL REQUIREMENTS

11

Any requirement that is not about functionality.

It qualifies a service (behavior).

DEFINITION – NON-FUNCTIONAL REQUIREMENTS

1. The product MUST be capable of

serving 45 cups of coffee per hour.

2. The product MUST heat water to the

brewing temperature within one minute.

3. Any displays must present in English,

Spanish, Chinese, and Hindi.

12

Example: Commercial Coffee Machine

Quality Attributes

1. Reliability and Availability

TYPES OF NON-FUNCTIONAL REQUIREMENTS

Reliability: The probability of failure-free software operation for a specified period of time in a specified environment. (ANSI/IEEE Def.)

Availability: The degree a system is available for use

Measurements

▪ observed faults

▪ average uptime

Quality Attributes



The system shall experience at most two

Severity 1 failures per month.

The system shall support “five nines”

availability.

Means the system can have a yearly downtime of ~5.25 min/yr

Quality Attributes


2. Performance


Specifies timing and capacity expectations for the system.

Measurements

▪ Service times

▪ Throughput

▪ Capacities

Quality Attributes


2. Performance


The system should be capable of processing

55K jobs per hour.

The average wait-time for service should be

less than five minutes.

Quality Attributes


2. Performance

3. Security


Rules for privacy, integrity, and availability

Privacy: only the right people/systems have access to the

information

Integrity: The information is not changed improperly

Availability: The information is available when it is needed.

Measurements

▪ Access logs, Change logs,…

Quality Attributes


2. Performance

3. Security


The system should require two step

authentication.

The system should require passwords to be

longer than eight (8) characters.

The system should log all login attempts.

The system should flag all incorrect login

attempts.

Quality Attributes


2. Performance

3. Security

4. Maintainability


Rules for the ease for introducing changes to the system

Repairing a defect

Introducing a feature

Measurements

▪ Mean time to repair

▪ Development start to release velocity

Quality Attributes


2. Performance

3. Security

4. Maintainability


The average time for the repair of a

severity-1 issue should be no more than

24 hours.

Quality Attributes


2. Performance

3. Security

4. Maintainability

5. Portability


Rules for the types of environments in which the system may operate/run.

Measurements

▪ releases

Quality Attributes


2. Performance

3. Security

4. Maintainability

5. Portability


The system core should operate in any of the

following operating systems:

1. Windows 10

2. Tiny Core linux

3. Fedora linux

4. Ubuntu server LTS

Constraints


Rules that limit the project.

May describe a how (exception to the “what” rule)

These aren’t design specifications, but conditions that

limit the project.

Constraints


Accuracy

Currency conversions should be accurate to

three (3) decimal places.

Programming

The project shall use Java 8 and Junit 4.

Design

The system shall use the Gale-Shapley

stable match algorithm.

Constraints


Standards

The SRS (SRD) shall adhere to IEEE Std.

830-1998.

Project

The first release should be available by 12/1.

The team will use Jira, Jenkins/Sonarqube,

and the KCS github server.

External Interfaces


Rules that specify interfaces to external systems

External Interfaces


Hardware

The system should interface with a Wasp

WLR 8950 Barcode scanner.

Software

The project shall use KCS LDAP server for

Authentication and Authorization (AA).

External Interfaces


Communications

The system shall use LDAP over TLS or

SSL. (control)

Billing data messages shall follow the

Medicare EDI specifications. (data)

User Experience/User Interface


Rules defining the principles governing the user’s interaction with the system.

Error Handling

and Recovery


Rules defining how the system should deal with errors generated by:

1. End Users

2. External Systems

3. Internal issues

Error Handling

and Recovery


Example responses to end user generated errors

▪ Ignore

▪ Warn user

▪ Allow retries

▪ Log and proceed

▪ Substitute values

▪ Break connection

EXPRESSING REQUIREMENTSIETF RFC 2119

32

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement level of the document in which they are used.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

IS THIS REQUIREMENT CLEAR?

33

The assignment SHALL be due on the date assigned.

IS THIS REQUIREMENT CLEAR?

34

The assignment SHALL be due on the date assigned.

At day/mon/year hh:mm is reasonably clear.

At day/mon/year is not clear.So, when is it due?

This requirement is incomplete.

HOW MANY INTERPRETATIONS CAN YOU FIND IN THIS STATEMENT?

35

I saw a man on the hill with a telescope.

5

HOW MANY INTERPRETATIONS CAN YOU FIND IN THIS STATEMENT?

36

I saw a man on the hill with a telescope.

1. There’s a man on a hill, and I’m watching him with my telescope.

2. There’s a man on a hill, who I’m seeing, and he has a telescope.

3. There’s a man, and he’s on a hill that also has a telescope on it.

4. I’m on a hill, and I saw a man using a telescope.

5. There’s a man on a hill, and I’m sawing him with a telescope

DOCUMENTING REQUIREMENTS

Many, many techniques for expressing requirements.

IEEE standard 830-1998 is a common way to organize them as a document.See the document: http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf (~40 pgs)

http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf

SOFTWARE REQUIREMENTS SPECIFICATION OUTLINE (IEEE 830-1998)

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, acronyms, and

abbreviations

1.4 References

1.5 Overview

2. Overall description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 Constraints

2.5 Assumptions and dependencies

3. Specific requirements

Appendixes

Index

SOFTWARE REQUIREMENTS SPECIFICATION OUTLINE (IEEE 830-1998)

Many ways to organize the detailed requirements.

Use the one that best fits your situation.

▪ System mode

▪ User class

▪ Objects

▪ Features

▪ Stimulus

▪ Functional hierarchy

TRACEABILITY

Linkage from a requirement to all downstream artifacts (design, test, code)

Addresses key management questions:

Did we cover all the requirements in theimplementation?

If we change a requirement, what is the scope of change in the downstream artifacts?

PRIORITY

Defines the importance and urgency of a requirement to the project.

Usually a small ordered set

Rarely do stakeholders agree across the board.

High

Critical

Medium

Low

GOOD REQUIREMENT

A requirement is “good” if

1. It is about the system.

2. It is testable.


The process of gaining the necessary understanding of the requirements.

REQUIREMENT DEFICIENCIES ARE THE PRIME SOURCE OF PROJECT FAILURES (GLASS’ LAW)

~45% of project failures involve requirements phase issues (Chaos Study)

▪ Incomplete requirements (13%)

▪ Lack of user involvement (12%)

▪ Changing specifications (9%)

▪ Unrealistic expectations (10%)

Feasibility

StudyUser

Requirements

ElicitationSystem

Requirements

Elicitation

User Requirements

Specification

System Requirements

Specification and Modeling

Business

Requirements

Specification

Source: Sommerville, Software Engineering, 10th Ed, Fig 4.6

System Requirements

Document/Spec.

(SRD/SRS)

Start

STEPS IN REQUIREMENTS ANALYSIS

1. Define Vision

2. Identify Stakeholders

3. Elicit Requirements

4. Record Requirements

5. Construct Prototypes

45

DEFINE THE VISION

Identifies the need or opportunity drivingwhy the project exists.

May be called a concept of operation.

1. Serves to align stakeholders toward in common direction.

2. Defines success at a very high level.

3. May be used to pitch executive/VCsupport.

STAKEHOLDERS

1. Anyone who operates the system

normal and maintenance operators

2. Anyone who benefits from the system

functional, political, financial and social beneficiaries

3. Anyone involved in purchasing or procuring the system

Have a valid interest in the system

1. Regulatory organizations(financial, safety, and other regulators)

2. External systems/organizations that interface with the system under design

3. People or organizations opposed to the system (negative stakeholders)

Are affected by the system

47

ELICIT REQUIREMENTS

Gathering the requirements from

Stakeholders

Documents (e.g. manuals, standards)

Interviews are the best way to elicit requirements

Sounds simple – but is the hardest part!

48

WHY ELICITATION IS HARD

Problems of scope

What is the boundary of the system?

What details are actually required?

Ask why does this matter?

Ask how does this fit into the bigger

picture?

Ask if this is how it works today or if it's

how they'd like it to work?

49


Problems of scope

Problems of understanding

▪ Users do not know what they want

▪ Users don’t know what is needed

▪ Have a poor understanding of their computing environment

▪ Don’t have a full understanding of their domain

▪ Omit “obvious stuff”

▪ Are ambiguous

• Ask to walk though simple scenarios

• Ask what do they do and what is

painful (or fun) about doing this?

• Ask what ideas they have

• Be careful about scope!

• Ask if someone else knows this

other part

• Reflective listening – repeat what

you understand and walk through an

example

50


Problems of scope

Problems of understanding

Problems of volatility

• Requirements change over time

Maintain version control over

requirements

Keep track of relationships between

requirements.

Don't accept changes without

understanding why the change is

needed

Sometimes you have to say no.

51

SETTING THE STAGE FOR THE INTERVIEWS

Identify list of stakeholder groups you need to meet with and criteria each one must have or should have.

Find individuals who meet the criteria.

Prioritize groups/individuals

1. Impact to the project

2. Knowledge and experience

3. Ownership

Arrange meetingsAdapted from: https://www.slideshare.net/Makewa/4-pre-planning-stakeholders-analysis-hu

THE INTERVIEW PROCESS

Before the interview Schedule the interview

Set the start and end times.

Have at least two people from the projectteam (dev team ideally) attend.

Set up how the meeting information will bepreserved/recorded/noted

Have a plan for the discussion


Before the interview

During the interview

Listen and don’t lead the subject.

Initiate by asking probing questions and encourage the subject to explain both what they are discussing and why it’s important.

Don’t be passive.

Persist in understanding wants and exploring needs

Walk through use cases/scenarios

TAKE NOTES

Schedule follow-ups for further questions and validation


Before the interview

During the interview

After the interview

Assess the information

Identify confirmations, contradictions, ornew material.

Identify resolution paths for contradictions.

Extend the SRS.

Follow-up with the subject for clarification or validation.

SUCCESSIVE REFINEMENT OF REQUIREMENTS

From here, you refine the requirements to be more and more detailed.

The purpose is to define a testable construct that can be implemented/achieved

The more precise, the better.

Four Feet

Two Ears

Two Eyes

Four Paws with

claws

Two Ears

Two Eyes good for

low light vision

THE DEVIL IS IN THE DETAILS

Missing explicit details are called assumptions.

Many, many details are possible.

While the hope is for a complete set ofrequirements, the reality is usually sufficiency.

Adapted from Fran Orford www.francartoons.com. Used with permission.

http://www.francartoons.com/

MANY ORGANIZATIONS ARE POSSIBLE

The number of requirements can be

staggering.

The simplest organization is a set of statements with links and priorities.

ORGANIZING BY FEATURE

Simple list of statements.

Pros

Simple to learn.

Common tool is a spreadsheet or list.

Cons

Hard to find how requirements relate.

Managing requirements this way usually creates a mess.

USE CASE

An actor

A scenario

A use case is a collection of related scenarios – successful and failing ones

Useful for clients as well as for developers

60

EXAMPLE: PLACING AN ORDER

61

I’m sitting down at my machine and I want to place an order…

Adapted from http://tynerblain.com/blog/2007/04/09/sample-use-case-example/


Who are the actors?

Shopper

1. Registered

Has an existing account, possibly with billing and shipping information)

2. Guest

Does not have an existing account

Fulfillment system

Billing system62


Triggers The user indicates that it’s time wants to purchase items in the cart.

63


Preconditions There are items in the cart.

64


Post-conditions The order will be placed in the fulfillment system.

The user will be given a tracking ID for the order.

The user will be given an estimated delivery date for the order.

65


Normal Flow

1. The system will present the billing and shipping information that the user previously stored.

2. The user will confirm that the existing billing and shipping information should be used for this order.

3. The system will present the amount that the order will cost, including applicable taxes and shipping charges.

4. The user will confirm that the order

information is accurate.

5. The system will provide the user with a tracking ID for the order.

6. The system will submit the order to the fulfillment system for evaluation.

7. The fulfillment system will provide the system with an estimated delivery date.

66

8. The system will present the estimated delivery date to the user.

9. The user will indicate that the order should be placed.

10. The system will request that the billing system should charge the user for the order.

11. The billing system will confirm that the charge has been placed for the order.

12. The system will submit the order to the

fulfillment system for processing.

13. The fulfillment system will confirm that the order is being processed.

14. The system will indicate to the user that the user has been charged for the order.


Alternate Flow 3A1: The user enters billing and shipping information for the order. The user desires to use different shipping and billing information.

a. The user will indicate that this order should use alternate billing or shipping information.

b. The user will enter billing and shipping information for this order.

c. The system will validate the billing and shipping information.

67Exploring alternatives is key to successful requirements analysis!


Alternate Flow(another example)

5A1: The user discovers an error with their the billing or shipping information.

a. The user indicates that the billing and shipping information is incorrect.

b. The user updates the billing and shipping information associated with their account.

c. The system will validate the billing and shipping information.

d. The use case returns to step 2 and continues.

68

OTHER WAYS TO EXPRESS FLOWS THROUGH THE SYSTEM

Data Flow Diagrams

Sequence Diagrams

State Transition Diagrams

BE SKEPTICAL

1. Do the requirements meet the real needs?

2. Do any requirements conflict?

3. Is the requirements set complete?

4. Are the requirements realistic / feasible?

▪ Technically realistic

▪ Budget realistic

5. Are the requirements verifiable?

▪ Can tests be defined so one can demonstrate the system satisfies the requirement?

FINAL NOTE ABOUT REQUIREMENTS

The job may never be done.

If the problem is complex enough, it will likely never be described completely.

Change happens.

The environment changes.

Once used, new priorities or requirements come to light.

Compromises get exposed; priorities change.