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 requirements document? 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:

How to Proceed 1. Establish the scope of the work 2. Establish the adjacent systems (outside world) that surrounds the work 3. Identify connections between the work and the adjacent systems 4. From the connections, identify the business events that affect the work 5. 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