CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 8 Requirements Analysis and Specification

2
Administration
3
Project Presentations
Requirements
Requirements Analysis
System design
Design
Program design
Implementation
Coding
Unit Integration Testing
System Testing
Acceptance Testing
Operation Maintenance
4
Feedback in the Waterfall Model
Requirements Analysis
System design
Program design
Coding
Unit Integration Testing
System Testing
Acceptance Testing
Operation Maintenance
5
Iterative Refinement
Concurrent Activities
Initial Version
Requirements
Outline Description
Intermediate Versions
Design
Implementation
Final Version
6
The Requirements Process
Feasibility Study
Feasibility Report
System Models
Definition of Requirements
Specification of Requirements
Requirements Document
7
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 Unrealis
tic 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!
8
Types of Requirements

• Functionality
• Data
• Interfaces
• Users and human factors
• Documentation and training
• Resources
• Security
• Physical environment
• Quality assurance

9
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
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
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
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
DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP
PRODUCTION AND DELIVERY OF AMERICAN MEMORY
NDLP collections already released
NDLP collections in conversion
Coolidge collection (for repository test)
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)
ILS OPAC Interface
Other User Interfaces (e.g. RLG, OCLC, DLF
partners)
AM user interface plus access management for
objects/collections
Supporting infrastructure
Handle assignment registration
Handle resolution
Handle-server
NOW
FUTURE
14
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
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
Unspoken Requirements
Example Resistance to change at XXX
17
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
Documentation
Reasons for documentation visibility (e.g.,
project plan, interim report) user
support (e.g., user manual) team
communication (e.g., interface specifications) ma
intenance 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
--gt Quality not volume
19
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
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?
21
Requirements Analysis
2. Understand the requirements in depth
Domain understanding Examples Tote Investors,
Philips light bulbs Understanding of the real
requirements of all stakeholders
22
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
Viewpoint Analysis
Example University Admissions System
Applicants University administration Admissio
ns office Financial aid office Special offices
(e.g., athletics, development) Computing
staff Operations Software development and
maintenance Academic departments
24
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
25
Requirements Analysis
4. Model the requirements Informal Prose
Systematic Procedural models Data-centric
models Object models Formal models
26
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
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
28
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!
29
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
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.