CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 8 Requirements I
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
From an Old Exam Question
A computing system is likely to need some sort
of database (i) At what stage in the waterfall
process, would the decision be made to use a
relational database? Give the reasons for your
answer. (ii) At what stage in the waterfall
process, would the decision be made to use an
Oracle database? Give the reasons for your
answer. (iii) At what stage in the waterfall
process would the database schema be specified?
Give the reasons for your answer.
7
From an Old Exam Question (Answer)
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
the relational database model) is usually not a
requirement of the client. It comes later, as
part of the design. However. During the
feasibility study it is important to know about
relational databases, such as Oracle, and to
study their capabilities.
8
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!
9
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).
10
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
11
The Requirements Process
Feasibility Study
Feasibility Report
System Models
Definition of Requirements
Specification of Requirements
Requirements Document
12
Functional Requirements

• Requirements about the functions
• that the system must perform
• Functionality
• Data
• Interfaces
• Users and human factors

13
Example of Functional Requirements
Library of Congress Repository Support for
complex digital objects. (How many? What
size?) Access management. (What users? What
objects? Policies?) Identification. (Which
identification system?) Information hiding.
(Where are the interfaces?) Open protocols and
formats. (How are these chosen?) Integration
with existing systems (What legacy systems must
be accommodated?).
14
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
15
Non-Functional Requirements

• Requirements about the context in
• which the system is built
• Documentation and training
• Resources
• Security
• Physical environment
• Quality assurance

16
Examples of Functional and 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
17
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
18
Example of Non-Functional Requirements

• Example Library of Congress Repository
• Hardware and software systems (IBM/Unix)
• Database systems (Oracle)
• Programming languages (C and C)
• Regulations covering government contracting
• Importance of developing a system that will be
  respected by other major libraries

19
Unspoken Requirements

• Example
• Resistance to change
• Departmental friction
• Management strengths and weaknesses

20
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.
21
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?
22
Requirements Analysis
2. Understand the requirements in depth
Domain understanding Examples Philips light
bulbs Understanding of the real requirements
of all stakeholders
23
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.
24
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
25
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