CS 501: Software Engineering
Lecture 8
Requirements Analysis and Specification
1
CS 501 Spring 2002
Administration
2
CS 501 Spring 2002
Project Presentations
Requirements
Requirements Analysis
System design
Design
Program design
Implementation
Coding
Unit & Integration Testing
System Testing
Acceptance Testing
Operation & Maintenance
3
CS 501 Spring 2002
Feedback in the Waterfall Model
Requirements Analysis
System design
Program design
Coding
Unit & Integration Testing
System Testing
Acceptance Testing
Operation & Maintenance
4
CS 501 Spring 2002
Iterative Refinement
Concurrent
Activities
Requirements
Outline
Description
Design
Implementation
5
Initial
Version
Intermediate
Versions
Final
Version
CS 501 Spring 2002
The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Definition
Feasibility
Report
System
Models
Definition of
Requirements
Requirements
Document
6
Requirements
Specification
Specification of
Requirements
CS 501 Spring 2002
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!
7
CS 501 Spring 2002
Types of Requirements
• Functionality
• Data
• Interfaces
• Users and human factors
• Documentation and training
• Resources
• Security
• Physical environment
• Quality assurance
8
CS 501 Spring 2002
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.
9
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.
10
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).
11
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)
12
CS 501 Spring 2002
DRAFT OVERVIEW OF ITS SUPPORT
FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY
NDLP collections
already released
Coolidge collection
(for repository test)
NDLP collections
in conversion
Future
NDLP collections
Other applications
and materials
NDLP Workflow
Tracking Support
Current Storage Structure
(in Unix files, by aggregate)
Object Administration System
ILS
Repository
Index Generation
(including pre-processing)
American Memory User Interface
(retrieval, navigation, & display)
AM user interface plus
access management
for objects/collections
Other User Interfaces
(e.g. RLG, OCLC, DLF partners)
ILS OPAC Interface
Supporting infrastructure
Handle assignment
& registration
Handle-server
13
NOW
Handle resolution
CS 501
FUTURE
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
14
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
15
CS 501 Spring 2002
Unspoken Requirements
Example:
Resistance to change at XXX
16
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
17
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 current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
Documentation is expensive --> Quality not volume
18
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).
19
CS 501 Spring 2002
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
• Who can disrupt this project?
20
CS 501 Spring 2002
Requirements Analysis
2. Understand the requirements in depth:
• Domain understanding
Examples: Tote Investors, Philips light bulbs
• Understanding of the real requirements of all stakeholders
21
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.
22
CS 501 Spring 2002
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
23
CS 501 Spring 2002
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
24
CS 501 Spring 2002
Requirements Analysis
4. Model the requirements:
• Informal
Prose
• Systematic
Procedural models
Data-centric models
Object models
• Formal models
25
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)
26
CS 501 Spring 2002
Requirements Specification: Purpose
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
27
CS 501 Spring 2002
Requirements Specification: Purpose
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!
28
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.]
29
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.
30
2. Do not allow assumptions about the design to have
influence the requirements analysis.
CS 501 Spring 2002