CS 5150 1

CS 5150 Software Engineering

Lecture 8

Requirements 1

CS 5150 2

ISSA - Google Tech TalkUser Experience of Online Advertising

• Monday 2/16 4:30pm Philips 203• Molly Stevens, head User Experience Researcher,

Google Ads• Designing and targeting unintrusive ads that are

also useful

• The future of Online Ads

CS 5150 3

Administration

Assignment 1

Due Friday at 11:00 p.m. Submit by email.

• Feasibility study (group assignment)

Remember to send a copy to your client

• Survey (individual assignment)

Quiz 1

Uncollected answer books are at the reception at 301 College Avenue

CS 5150 4

Administration

Assignment 2

Presentations will be on March 3 to 6. See the available times on the home page of the web site.

• Sign up now.

• Client must be able to attend.

• Not all members of the project team need attend.

More information about the presentations will be given in a later class.

CS 5150 5

Quiz 1: Visibility

Question: How does your process provide visibility?

Objective: Keep everybody informed of the progress

• client, management (instructor + TA), colleagues in team

Visibility has many aspects

• sequential processes have intermediate deliverables

• iterative processes have visible products after each iteration

• presentations and reports are visible milestones

• schedules, progress reports, and team meetings keep track of progress between major milestones

CS 5150 6

From Quiz 1: Process Steps

A proposed software system is likely to be based on Web technology.

(i) How much should the choice of technology be considered during the feasibility study?

(ii) In how much detail should the choice of technology be specified during the requirements phase of the project?

(iii) At what stage should the decision be made to use an Apache Web Server 2.2 with Tomcat 6.0?

CS 5150 7

Quiz 1: Process Steps (answer)

How much should the choice of technology be considered during the feasibility study?

During the feasibility study it is important to know that the project is technically feasible.

This can be achieved by identifying one possible technical approach and analyzing it sufficiently to show that it is capable of fulfilling the requirements of the system. It can also be used to estimate costs of hardware, software, etc.

However, this is only a possible approach. When the system design is carried out in detail, totally different technology may be chosen (e.g., not Web-based).

CS 5150 8

Quiz 1: Process Steps (answer)

In how much detail should the choice of technology be specified during the requirements phase of the project?

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

The client's requirements are that the system performs various functions, e.g., collects certain data, saves it, displays it, performing calculations, etc.

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

CS 5150 9

Quiz 1: Process Steps (answer)

At what stage should the decision be made to use an Apache Web Server 2.0 with Tomcat 4.1?

This is a design decision. It is part of the system design.

CS 5150 10

Lectures on Requirements Analysis and Specification

Requirements I: Requirements Analysis

Requirements II: Models -- Scenarios and Use Cases

Requirements III: Informal Methods of Specification Formal Methods of Specification

CS 5150 11

Requirements in Software Development

Requirements

Operation andMaintenanceImplementation

Design

Feasibility andPlanning

All process models include a

requirements activity

CS 5150 12

Requirements in Iterative Refinement

Requirements

DesignImplementation

Evaluation/acceptance

CS 5150 13

Requirements in Iterative Refinement

OutlineDescription

ConcurrentActivities

Requirements

Design

Implementation

InitialVersion

IntermediateVersions

FinalVersion

CS 5150 14

Requirements in the Modified Waterfall Model

Requirements

System design

Testing

Operation & maintenance

Program design

Implementation (coding)

Acceptance & release

Feasibility study The requirements need continual updating as the project continues.

CS 5150 15

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.

CS 5150 16

Goals during the Requirements Phase

• Understand the requirements in detail.

• Specify the requirements in a manner that is clear to the client. Ensure that the client understands the description of the requirements and their implications.

• Specify the requirements in a manner that is clear to the people who will design and implement the system.

The Requirements Documentation is the defining document that describes the goals of the system that is being built.

It may form a legal contract between client and software developers.

CS 5150 17

Stages in the Requirements Phase

Requirements define the function of the system from the client's viewpoint.

This phase can be divided into:

• Analysis to establish the system's services, constraints and goals by consultation with users.

• Modeling to organize the requirements in a systematic and comprehensible manner.

• Specification in a manner and level of detail that is understandable by both users and development staff.

CS 5150 18

The Requirements Process

FeasibilityStudy

RequirementsAnalysis

RequirementsModel

RequirementsSpecification

FeasibilityReport

Documentation ofRequirements

Work with the client to understand the requirements

Organize the requirements in a systematic and comprehensible manner

Analysis Report (optional)

CS 5150 19

Requirements Analysis

High-level abstract description of requirements:

• Specifies external system behavior

• Comprehensible by customer, management and users

Should reflect accurately what the client wants:

• Services that the system will provide

• Constraints under which it will operate

Often described in a separate report for consultation with the client.

"Our understanding of your requirements is that ..."

CS 5150 20

Requirements Analysis: Interviews with Clients

Client interviews are the heart of the requirements analysis and definition.

Clients may have only a vague concept of requirements.

• Allow plenty of time.

• Prepare before you meet with the client

• Keep full notes

• If you do not understand, delve further, again and again

• Repeat what you hear

• Small group meetings are often most effective

CS 5150 21

Requirements Analysis: Stakeholders

Identify the stakeholders:

Who is affected by this system?

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

Example: Andrew project (Carnegie Mellon and IBM)

CS 5150 22

Requirements Analysis: Stakeholders & Viewpoint Analysis

Viewpoint Analysis. Analyze the requirements as seen by each group of stakeholders

Example: University Admissions System

• Applicants

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

• Academic departments

• Computing staffOperations and maintenance

CS 5150 23

Requirements Analysis: Understand the Requirements

Understand the requirements in depth:

• Domain understanding

Example: Philips light bulbs

• Understanding of the real requirements of all stakeholders

Stakeholders may not have clear ideas about what they require, or they may not express requirements clearly.

They are often too close to the old way of doing things.

• Understand the terminology

Clients often use specialized terminology that they think you understand.

CS 5150 24

Requirements Analysis: Understand the Requirements

Understanding the requirements may need studies:

Market research

focus groups, surveys, competitive analysis, etc.

Example: Windows XP T-shirt

Technical evaluation

experiments, prototypes, etc.

Example: Windows XP boot faster

CS 5150 25

Requirements Analysis: Understand the RequirementsNew and Old Systems

In requirements analysis it is important to distinguish:

• features of the current system• proposed new features

Clients often confuse the current system with the underlying requirement.

A new system is when there is no existing system.

A replacement system (or subsystem) is when a system is built to replace an existing system.

A legacy system is an existing system that is not being replaced, but must interface to the new system.

CS 5150 26

Requirements Analysis: Conflicts

Conflicts:

Recognize and resolve conflicts

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

Example: Dartmouth general ledger system

CS 5150 27

Requirements Analysis: Conflicts Negotiation with the Client

Sometimes the client will request some functionality that is very expensive or impossible. What do you do?

• Talk through the requirement with the client. Why is it wanted? Is there an alternative that is equivalent?

• Explain the reasoning behind your concern. Explain the technical, organizational, and cost implications.

• Be open to suggestions. Is there a gap in your understanding? Perhaps a second opinion might show other approaches.

Before the requirements phase is completed the client and development team must resolve these questions.

CS 5150 28

Functional Requirements

Functional requirements describe the functions that the system must perform. They are identified by analyzing the use made of the system:

• Functionality

• Data

• User interfaces

Analyzing and specifying the functional requirements is the theme of the next two lectures.

CS 5150 29

Non-Functional Requirements

Requirements that are not directly related to the functions that the system must perform

Product requirementsperformance, reliability, portability, etc...

Organizational requirementsdelivery, training, standards, etc...

External requirementslegal, interoperability, etc...

Marketing and public relationsExample: In the NSDL, the NSF wanted a system that could be demonstrated by the end of 2002

CS 5150 30

Example of Non-Functional Requirements

Example: Library of Congress Repository

Use technology that the client's staff are familiar with:

• Hardware and software systems (IBM/Unix)

• Database systems (Oracle)

• Programming languages (C and C++)

Recognize that the client is a federal library:

• Regulations covering government contracting

• Importance of developing a system that will be respected by other major libraries

CS 5150 31

Unspoken Requirements

Examples:

• Resistance to change

• Departmental friction

• Management strengths and weaknesses

Discovering the unspoken requirements is often the most difficult part of developing the requirements.

CS 5150 32

Realism and Verifiability

Requirements must be realistic, i.e., it must be possible to meet them.

Wrong: The system must be capable of x (if no known computer system can do x at a reasonable cost).

Requirements must be verifiable, i.e., it must be possible to test whether a requirement has been met.

Wrong: The system must be easy to use.

Right: After one day's training an operator should be able to input 50 orders per hour.

CS 5150 33

Evolution of Requirements

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

• 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).

CS 5150 34

Requirements Documentation (continued on next slide)

The form of documentation varies, but is likely to contain the following:

General

Purpose and scope of system

Objectives and criteria for success

List of terminology, organizations involved, etc.

Description of current system(s)

CS 5150 35

Requirements Documentation (continued)

Requirements of proposed system

Overview

Functional Requirements

Usability requirements

Non-functional requirements

Models

Scenarios

Use cases

Models used during analysis

CS 5150 36

Requirements Documentation (continued)

Detailed Specifications

Business rules, specifications, etc. (e.g., reference to an accounting standard)

Data flow, sources of data, data formats and constraints, data validation

etc., etc.,

The most common fault in requirements documentation is to gloss over the details. This results in misunderstandings between the client and the developers.