CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 7 Requirements I
2
Administration
Project teams Does everybody have a
project? Which projects have less than 7
people? Has every project sent an email to the
course team, with the name of the project,
client, and team members with NetID?
3
Administration
Assignment 1 Due Friday at 500 p.m. Submit by
email. Feasibility study (group
assignment) Remember to send a copy to your
client Survey (individual assignment) Sending
email to cs501-l_at_lists.cs.cornell.edu All mail
to this address must be sent from an email
address in the cornell.edu domain. To block
spam, all mail from outside Cornell is rejected.
4
Administration
Lecture 8, Thursday February 14 Guest lecture by
Rich Reitman (may be included in quiz)
5
Peer to Patent
6
From an old exam question
What are the visibility requirements of your
project? How does your process provide
visibility? Visibility is an aspect of the
software development process -- keeping everybody
informed of the progress, e.g. with schedules,
milestones, presentations, reports, etc. What
risks do you see for your project? How does your
process manage risk? Risks can be categorized by
(a) function, (b) timeliness, (c) resources. All
CS 501 projects have timeliness risks.
7
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
8
Requirements in Software Development
Feasibility and Planning
All process models include a requirements activity
Requirements
Design
Operation and Maintenance
Implementation
9
Requirements in the modified Waterfall Model
The requirements will need continual updating as
the project continues.
Feasibility study
Requirements
System design
Program design
Implementation (coding)
Testing
Acceptance release
Operation maintenance
10
Requirements in iterative refinement
Evaluation/acceptance
Requirements
Design
Implementation
11
Requirements in Iterative Refinement
Concurrent Activities
Initial Version
Requirements
Outline Description
Intermediate Versions
Design
Implementation
Final Version
12
From an old 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?

13
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. 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).
14
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.
15
From an old 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?
• This is part of the System Design.

16
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.
17
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.
18
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.

19
The requirements process
Feasibility Study
Feasibility Report
Work with the client to understand the
requirements
Organize the requirements in a systematic and
comprehensible manner
Documentation of Requirements
Analysis Report (optional)
20
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 ..."
21
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
22
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)
23
Viewpoint analysis
Example University Admissions System
Applicants University administration Admissio
ns office Financial aid office Special offices
(e.g., athletics, development) Academic
departments Computing staff Operations Softw
are development and maintenance
24
Requirements analysis
2. Understand the requirements in depth
Domain understanding Examples Philips light
bulbs Understanding of the real requirements
of all stakeholders Who can disrupt this
project?
25
Requirements analysis
3. Organize the requirements Classification
into coherent clusters (modeling) (e.g., legal
requirements) Recognize and resolve conflicts
(e.g., functionality v. cost v.
timeliness) Example Dartmouth general ledger
system
26
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.
27
Requirements analysis 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.
28
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.
29
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
30
Example of non-functional requirements

• Example Library of Congress Repository
• Use systems 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

31
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.

32
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)
33
Requirements documentation (continued)
Requirements of proposed system Overview Functio
nal Requirements Usability requirements Non-func
tional requirements System models
Scenarios Use cases Models used during
analysis
34
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.
35
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.
36
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).