CS 5150
Software Engineering
Lecture 8
Requirements 1
CS 5150
1
ISSA - Google Tech Talk
User 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
2
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
3
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
4
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
5
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
6
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
7
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
8
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
9
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
10
Requirements in Software Development
Feasibility and
Planning
Requirements
All process
models include a
requirements
activity
Design
Implementation
CS 5150
Operation and
Maintenance
11
Requirements in Iterative Refinement
Evaluation/acceptance
Implementation
CS 5150
Requirements
Design
12
Requirements in Iterative Refinement
Concurrent
Activities
Requirements
Outline
Description
Design
Implementation
CS 5150
Initial
Version
Intermediate
Versions
Final
Version
13
Requirements in the Modified Waterfall Model
The requirements need
continual updating as the
project continues.
Feasibility study
Requirements
System design
Program design
Implementation (coding)
Testing
Acceptance & release
Operation & maintenance
CS 5150
14
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
15
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
16
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
17
The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Model
Feasibility
Report
Work with
the client to
understand
the
requirements
Analysis Report
(optional)
CS 5150
Organize the
requirements in
a systematic and
comprehensible
manner
Requirements
Specification
Documentation of
Requirements
18
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
19
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
20
Requirements Analysis: Stakeholders
Identify the stakeholders:
Who is affected by this system?
Client
Senior management
Production staff
Computing staff
Customers
etc., etc., etc.,
Example: Andrew project (Carnegie Mellon and IBM)
CS 5150
21
Requirements Analysis:
Stakeholders & Viewpoint Analysis
Viewpoint Analysis. Analyze the requirements as seen
by each group of stakeholders
Example: University Admissions System
• Applicants
• University administration
Admissions office
Financial aid office
Special offices (e.g., athletics, development)
• Academic departments
• Computing staff
Operations and maintenance
CS 5150
22
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
23
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
24
Requirements Analysis: Understand the Requirements
New 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
25
Requirements Analysis: Conflicts
Conflicts:
Recognize and resolve conflicts
(e.g., functionality v. cost v. timeliness)
Example: Dartmouth general ledger system
CS 5150
26
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
27
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
28
Non-Functional Requirements
Requirements that are not directly related to the
functions that the system must perform
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Marketing and public relations
Example: In the NSDL, the NSF wanted a system
that could be demonstrated by the end of 2002
CS 5150
29
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
30
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
31
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
32
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.
•
CS 5150
Its documentation must be kept current (but clearly
identify versions).
33
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
34
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
35
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.
CS 5150
36