1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 8 Requirements Analysis and Specification.

1 CS 501 Spring 2002

CS 501: Software Engineering

Lecture 8

Requirements Analysis and Specification


Administration


Project Presentations

Requirements Analysis

System design

Unit & Integration Testing

System Testing

Operation & Maintenance

Program design

Coding

Acceptance Testing

Requirements

Design

Implementation


Feedback in the Waterfall Model


System design

Unit & Integration Testing

System Testing

Operation & Maintenance

Program design

Coding

Acceptance Testing


Iterative Refinement

OutlineDescription

ConcurrentActivities

Requirements

Design

Implementation

InitialVersion

IntermediateVersions

FinalVersion


The Requirements Process

FeasibilityStudy

RequirementsAnalysis

RequirementsDefinition

RequirementsSpecification

FeasibilityReport System

Models Definition ofRequirements

Specification ofRequirements

RequirementsDocument


Why are Requirements Important?

Causes of failed software projects (Standish Group study, 1994)

Incomplete requirements 13.1%Lack of user involvement 12.4%Lack of resources 10.6%Unrealistic expectations 9.9%Lack of executive support 9.3%Changing requirements & specifications 8.8%Lack of planning 8.1%System no longer needed 7.5%

The commonest mistake is to build the wrong system!


Types of Requirements

• Functionality

• Data

• Interfaces

• Users and human factors

• Documentation and training

• Resources

• Security

• Physical environment

• Quality assurance


What is a Requirement?

A requirement is a statement of need as expressed by a client.

Example (Quiz 1). The Piccadilly television advertising project.

The client's requirements are that the system collects certain data, saves it, and carries out specified processes, e.g., displaying it, performing calculations, etc.

The decision of how to store and manipulate the data (e.g., using the relational database model) is usually not a requirement of the client. It comes later, as part of the design.

10 CS 501 Spring 2002

Requirements Analysis and Definition

High-level abstract description of requirements:

• Specifies external system behavior

• Comprehensible by customer, management and users

Should reflect accurately what the customer wants:

• Services that the system will provide

• Constraints under which it will operate

Described in a Requirements Document that can be understood by the client.

11 CS 501 Spring 2002

Library of Congress Requirements Study

Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others

Advisors: Mailing list of about 20 knowledgeable stakeholders.

Timetable: Preliminary report (2 months). Final report (1 month).

12 CS 501 Spring 2002

Functional Requirements

Example: Library of Congress repository

• Support for complex digital objects

• Access management

• Identification

• Information hiding

• Open protocols and formats

• Integration with other systems (scope)

13 CS 501 Spring 2002

Current Storage Structure (in Unix files, by aggregate)

Index Generation(including pre-processing)

American Memory User Interface(retrieval, navigation, & display)

Object Administration System

Repository

NDLP Workflow Tracking Support

Handle-server

NDLP collections already released

NDLP collections in conversion

Coolidge collection(for repository test)

Future NDLP collections

NOW FUTURE

ILS OPAC InterfaceOther User Interfaces (e.g. RLG, OCLC, DLF partners)

Other applicationsand materials

ILS

Handle assignment & registration Handle resolution

Supporting infrastructure

DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY

AM user interface plus access management

for objects/collections

14 CS 501 Spring 2002

Non-Functional Requirements

Product requirements

performance, reliability, portability, etc...

Organizational requirements

delivery, training, standards, etc...

External requirements

legal, interoperability, etc...

Marketing and public relations

Example: NED musical notation

15 CS 501 Spring 2002

Examples of Non-Functional Requirements

Privacy (Mercury digital library)

Functional requirement: Usage data for management of system

Non-functional requirement: Usage data must not identify individuals

Minimizing records (NeXT)

Functional requirement: Retain all required records

Non-functional requirement: Discard all other records

16 CS 501 Spring 2002

Unspoken Requirements

Example:

Resistance to change at XXX

17 CS 501 Spring 2002

Non-functional Requirements

Example: Library of Congress repository

• Hardware and software systems (IBM/Unix)• Database systems (Oracle)• Programming languages (C and C++)

• Weaknesses and defensiveness of some staff• Departmental friction

18 CS 501 Spring 2002

Documentation

Reasons for documentation:visibility (e.g., project plan, interim report)

user support (e.g., user manual) team communication (e.g., interface specifications)

maintenance and evolution (e.g., requirements)

Characteristics of documentation:accurate and kept currentappropriate for audiencemaintained online (usually)simple but professional in style and appearance

Documentation is expensive --> Quality not volume

19 CS 501 Spring 2002

Evolution of Requirements

• If the requirements definition is wrong, the system will be a failure.

• With complex systems, understanding of requirements always continues to improve.

Therefore...

• The requirements definition must evolve.

• Its documentation must be kept current (but clearly identify versions).

20 CS 501 Spring 2002


1. Identify the stakeholders:

• Who is affected by this system?

ClientSenior managementProduction staffComputing staffCustomersetc., etc., etc.,

Example: Andrew project

• Who can disrupt this project?

21 CS 501 Spring 2002


2. Understand the requirements in depth:

• Domain understanding

Examples: Tote Investors, Philips light bulbs

• Understanding of the real requirements of all stakeholders

22 CS 501 Spring 2002

Interviews with Clients

Client interviews are the heart of requirements analysis and definition. Allow plenty of time.

Clients may have only a vague concept of requirements.

• Prepare before you meet with them

• Keep full notes

• If you don't understand, delve further

• Repeat what you hear

• Small group meetings are often most effective

Clients often confuse the current system with the underlying requirement.

23 CS 501 Spring 2002

Viewpoint Analysis

Example: University Admissions System

• Applicants

• University administrationAdmissions officeFinancial aid officeSpecial offices (e.g., athletics, development)

• Computing staffOperationsSoftware development and maintenance

• Academic departments

24 CS 501 Spring 2002


3. Organize the requirements:

• Classification into coherent clusters

(e.g., legal requirements)

• Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)

Example: Dartmouth general ledger system

25 CS 501 Spring 2002


4. Model the requirements:

• Informal

Prose

• Systematic

Procedural models

Data-centric models

Object models

• Formal models

26 CS 501 Spring 2002

Requirements Specification: Purpose

1. Document that describes the requirements to the stakeholders in a precise manner

• Expressed in the terms that the stakeholders understand

• Comprehensible from many viewpoints

• Reviewed by stakeholders so that they understand implications

• Must be clear about assumptions (things left out)

27 CS 501 Spring 2002


2. It describes the requirements to the implementers

• As precise and specific as possible

• Expressed in terms that they understand

• Comprehensible to new team members

28 CS 501 Spring 2002


3. It records the requirements for the future

• An essential part of system evolution

4. If may be a contractual document

• See you in court!

29 CS 501 Spring 2002

Requirements Specification: Process

The client must understand the requirements specification.

• Do not assume that anybody has read a document.• Do not assume that anybody understands a document.

Go through the requirements specification with the client, line by line.

It is usual for the client and developer to sign the requirements document when it is agreed.

[Compare with the plans to build a house. This is the specification of the system that you are about to build.]

30 CS 501 Spring 2002

Requirements Analysis v. System Design

Dilemma.

• Requirements analysis should make minimal assumptions about the system design.

• But the requirements definition must be consistent with computing technology and the resources available.

In practice, analysis and design are interwoven. However:

1. Do not to allow the requirements analysis to prejudge the system design.

2. Do not allow assumptions about the design to have influence the requirements analysis.

1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 8 Requirements Analysis and Specification.

Documents

Transcript of 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 8 Requirements Analysis and Specification.