CS 501: Software Engineering
Lecture 7
Requirements I
1
CS 501 Spring 2005
Administration
Quiz 1
Will be returned in class on Thursday
Assignment 1: Feasibility study
Due Friday at 5:00 p.m.
Remember to submit your questionnaires
Remember to send a copy to your client
2
CS 501 Spring 2005
Lectures on Requirements Analysis
and Specification
Requirements I: Requirements Analysis
Requirements II: Scenarios and Use Cases
Requirements III: Informal Methods of Specification
Requirements IV: Formal Methods of Specification
3
CS 501 Spring 2005
Requirements in Software
Development
Feasibility and
Planning
Requirements
All process
models include a
requirements
activity
Design
Implementation
4
Operation and
Maintenance
CS 501 Spring 2005
Requirements in the Waterfall Model
Feasibility study
Waterfall model
with feedback
Requirements
System design
Program design
Coding
Testing
Acceptance
Operation & maintenance
5
CS 501 Spring 2005
Requirements in Iterative Refinement
Concurrent
Activities
Requirements
Outline
Description
Design
Implementation
6
Initial
Version
Intermediate
Versions
Final
Version
CS 501 Spring 2005
Requirements Analysis and Definition
From Lecture 2
The requirements analysis and definition establish the system's
services, constraints and goals by consultation with users. They
are then defined in a manner that is understandable by both
users and development staff.
7
This phase can be divided into:
• Requirements analysis
• Requirements definition
• Requirements specification
Requirements define the function of the system FROM THE
CLIENT'S VIEWPOINT.
CS 501 Spring 2005
Goals During the Requirements Phase
• Understand the requirements in detail (analysis).
• Describe the requirements in a manner that is clear to the client.
Ensure that the client understands the description of the
requirements and their implications.
• Describe 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.
8
CS 501 Spring 2005
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!
9
CS 501 Spring 2005
The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Model
Feasibility
Report
Work with
the client to
understand
the
requirements
Requirements
Analysis (optional)
10
Organize the
requirements in
a systematic and
comprehensible
manner
Requirements
Specification
Documentation of
Requirements
CS 501 Spring 2005
Requirements Analysis
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
Often described in a separate document for consultation
with the client.
11
"Our understanding of your requirements is that ..."
CS 501 Spring 2005
From an Exam Question
An online information system is being developed using a
modified version of the Waterfall model. It 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.0 with Tomcat 4.1?
12
CS 501 Spring 2005
From an Exam Question (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.
13
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 501 Spring 2005
From an Exam Question (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 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 specific Web technology) is usually not a requirement of
the client. It comes later, as part of the design.
14
CS 501 Spring 2005
From an Exam Question (Answer)
At what stage should the decision be made to use an
Apache Web Server 2.0 with Tomcat 4.1?
This is part of the System Design
15
CS 501 Spring 2005
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)
16
CS 501 Spring 2005
Requirements Documentation
(continued)
Requirements of proposed system
Overview
Functional Requirements
Usability requirements
Non-functional requirements
System models
Scenarios
Use cases
Models used during analysis
17
CS 501 Spring 2005
Requirements Documentation
(continued)
Detailed specifications
Business rules, specifications, etc. (e.g., reference to an
accounting standard)
Data flow, sources of data, data validation
etc., etc.,
A common fault in requirements documentation is to gloss over
the details. This results in misunderstandings between the client
and the developers.
Example: NSDL ad hoc queries
18
CS 501 Spring 2005
Realism and Verifiability
Requirements must be realistic, i.e., it must be possible to meet
them.
Not: 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.
19
CS 501 Spring 2005
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).
20
CS 501 Spring 2005
New and Old Systems
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.
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.
21
CS 501 Spring 2005
Functional Requirements
Requirements about the functions that the
system must perform that will be identified by
analyzing the use made of the system
• Functionality
• Data
• User interfaces
Understanding and specifying the functional
requirements is the theme of the next three lectures.
22
CS 501 Spring 2005
Non-Functional Requirements
23
Requirements that are not directly related to
the functions that the system must perform
• Usability, documentation and training
• Reliability and quality assurance
• Performance
• Supportability
• Implementation and technical constraints
• Interfaces and compatibility
• Operation and physical environment
• Packaging and security
• Legal and business
• Resources
CS 501 Spring 2005
Examples of Functional and NonFunctional Requirements
Privacy (NSDL 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
24
CS 501 Spring 2005
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: In the NSDL, the NSF wanted a system
that could be demonstrated by the end of 2002
25
CS 501 Spring 2005
Example of Non-Functional
Requirements
Example: Library of Congress Repository should use
systems that the library staff are familiar with:
• Hardware and software systems (IBM/Unix)
• Database systems (Oracle)
• Programming languages (C and C++)
As a federal library:
• Regulations covering government contracting
26
• Importance of developing a system that will be
respected by other major libraries
CS 501 Spring 2005
Unspoken Requirements
Examples:
• Resistance to change
• Departmental friction
• Management strengths and weaknesses
27
CS 501 Spring 2005
Requirements Analysis:
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.
•
•
•
•
•
28
Prepare before you meet with them
Keep full notes
If you do not understand, delve further
Repeat what you hear
Small group meetings are often most effective
CS 501 Spring 2005
Requirements Analysis
1. 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)
• Who can disrupt this project?
29
CS 501 Spring 2005
Requirements Analysis
2. Understand the requirements in depth:
• Domain understanding
Examples: Philips light bulbs
• Understanding of the real requirements of all stakeholders
30
CS 501 Spring 2005
Viewpoint Analysis
Example: University Admissions System
• Applicants
• University administration
Admissions office
Financial aid office
Special offices (e.g., athletics, development)
• Computing staff
Operations
Software development and maintenance
• Academic departments
31
CS 501 Spring 2005
Requirements Analysis
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
32
CS 501 Spring 2005
Models: Useful Texts
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified
Modeling Language. Addison-Wesley 1999.
Grady Booch, Object-Oriented Analysis and Design with
Applications, second edition. Benjamin/Cummings 1994.
Rob Pooley, Perdita Stevens, Using UML Software
Engineering with Objects and Components. Addison-Wesley
1999.
33
CS 501 Spring 2005
Models
A model is a simplification of reality.
• We build models so that we can better understand the
system we are developing.
• We build models of complex system because we cannot
comprehend such a system in its entirety.
Models can be informal or formal. The more complex the
project the more valuable a formal model becomes.
BRJ
34
CS 501 Spring 2005
Principles of Modeling
• The choice of what models to create has a profound
influence on how a problem is attacked and how a
solution is shaped.
• Every model can be expressed at different levels of
precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial
system is best approached through a small set of
nearly independent models.
BRJ
35
CS 501 Spring 2005
The Unified Modeling Language
UML is a standard language for modeling software systems
• Serves as a bridge between the requirements specification
and the implementation.
• Provides a means to specify and document the design of a
software system.
• Is process and programming language independent.
• Is particularly suited to object-oriented program
development.
36
CS 501 Spring 2005
Rational Rose
Rational Rose is a system for creating and managing
UML diagrams.
It is available for Computer Science Department
computers.
There will be a short introduction to Rational Rose in
class on Thursday.
*
37
CS 501 Spring 2005