CMSC 345

The Requirements Specification

Why do we need requirements Without the correct requirements, you

cannot design or build the correct product, so product does not enable users to do their work

The cost of good requirements gathering and system analysis is minor compared to the cost of poor requirements

Classes of requirements

1. Functional Requirements

2. Nonfunctional Requirements

3. Constraints

Functional requirements Functional Requirements are things

the product must do – an action the product must take if it is to provide useful functionality to the user The product shall produce an amended

de-icing schedule when a change to a truck status means that previously scheduled work cannot be carried out as planned

Nonfunctional requirements Nonfunctional requirements are

the properties or qualities the product must have.

The product shall use company colors, standard company logos and standard company typefaces

Constraints Constraints are global issues that

shape the requirements

Passengers on board an aircraft will use this product

The product shall run on the company’s existing UNIX machines

Why do we need requirementsdocument? Customer Questions

Do you understand my problem? Can you develop and deliver a system that will

solve my problem? How long will it take? How much will it cost?

Developer Questions What is your problem? How do you currently handle your problem? When do you need a solution? How much are you willing to pay for a solution?

Volere Requirements Process Suzanne and James Robertson

The Atlantic Sytems Guild Text:

“Measuring the Requirements Process”

Website:www.systemsguild.com

How to Proceed1. Establish the scope of the work2. Establish the adjacent systems (outside

world) that surrounds the work3. Identify connections between the work

and the adjacent systems4. From the connections, identify the

business events that affect the work5. Study the response to the event

How to Proceed (2)6. Determine the best response that

the organization can make for the event

7. Determine the product’s role in the response

8. Determine the use case(s) for the product

9. Derive the requirements for each use case

The Work Is the business activity of your client Your product will help with the work,

so you must understand the work Understand how it relates to the

outside world Show work’s connection to outside

world via context diagram

Business Events Businesses respond to events

Buying a book in bookshop Paying your credit card bill

Business event responses are triggered by the arrival of a data flow (from an adjacent system) So triggering the event is outside

control of the work

Temporal Business Events Some events are triggered by the

passage of time – a pre-determined time or date has arrived

Response is to produce information and send it to an adjacent system

Finding Business Events B/E result from communications from

outside world; look to context diagram Each data flow that enters or leaves

the work is the result of a business event

It is the works response that is interesting to the requirements analyst

Work Responds to Events For every business event, there is a

pre-planned response (some work) Isolate this work – fairly unconnected

from other event responses Adjacent systems are the customers

for the business events – what does the adjacent system want from that event?

Determining the Product The product is the part of the work

you choose to build (automate) Establish the product’s scope Examine the responses to the

business events and determine the product boundary

Extend the boundary until it gets into the brain of the adjacent system

Event-driven Use Cases The use case is the part of the response

that is done by the product Derived from the business events Actors interact with the product Use cases represent the components of

the product and are described in terms of functional requirements

Each requirement says what the product has to do to allow the actor to complete his work

Finding Functional Requirements Use cases are described by a set of

steps that complete the functional task of the use case

Each step is a task described by the actor

What must the product do to complete each step? These are the functional requirements

Finding Non-functional Requirements The characteristics of the work

that are represented by the use case or functional requirements

The properties the functionality must have

Functional requirements are verbs Nonfunctional requirements are

adjective

Volere Requirements Specification Template Framework for writing a

specification Categorizes requirements into

useful types

A Requirements Specification Contains all the requirements and

constraints. A complete description of the of the

product’s capabilities Must be written to be meaningful to

both the customer and the developers

Sometimes two documents

Product Constraints Purpose of the Product The Client, Customer and other

Stakeholders Users of the Product Requirements Constraints Naming Conventions and Definitions Relevant Facts Assumptions

Functional Requirement The Scope of the Work

Work Context Diagram Business Events

The Scope of the Product Product Boundary (Use case diagram) Use Cases

Functional and Data Requirements

Nonfunctional Requirements Look and Feel Requirements Usability Requirements Performance Requirements Operational Requirements Maintainability and Portability

Requirements Security Requirements Cultural and Political Requirements Legal Requirements

Project Issues Open Issues Off-the-Shelf Solutions New Problems Tasks Cutover Risks Costs User Documentation Waiting Room

The Requirements Shell Requirement #:Unique ID Requirement Type:The type from the

template Event/use case #:List of Events / Use cases

that need this requirement Description: A one sentence statement

of the intention of the requirement Rationale:A justification of the requirement Source: Who raised this requirement?

Requirements Shell (2) Fit Criterion: A measurement of the

requirement such that it is possible to test if the solution matches the original requirement

Dependencies: A list of other requirements that have some dependency on this one

Conflicts: Other requirements that cannot be implemented if this one is

Supporting Materials: Pointer to documents that illustrate and explain this requirement

Requirements Shell (3) Customer Satisfaction: Degree of

stakeholder happiness if this requirement is successfully implemented (Scale 1 (uninterested) – 5 (extremely please))

Customer Dissatisfaction: Degree of stakeholder unhappiness if this requirement is successfully implemented (Scale 1 (hardly matters) – 5 (extremely displease))

History: Creation, changes, deletions, etc. Copyright © Atlantic Systems Guild