1. CS 501: Software Engineering
Lecture 7
Requirements I

2. Administration
Quiz 1
• Collect after class or from reception at 301 College Avenue
• Average grade was 17 out of 20
Assignment 1: Feasibility study
Due Friday at 5:00 p.m.
Remember to send a copy to your client

3. Quiz 1 -- Part of Question 1
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.

4. Lectures on Requirements Analysis and Specification
Requirements I: Requirements Analysis
Requirements II: Models -- Scenarios and Use Cases
Requirements III: Informal Methods of Specification
Requirements IV: Formal Methods of Specification

5. 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.
This phase can be divided into:
Requirements analysis
Requirements definition
Requirements specification
Requirements define the function of the system FROM THE CLIENT'S VIEWPOINT.

6. 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. Requirements in Software Development
Feasibility and
Planning
All process models include a requirements activity
Requirements
Design
Operation and
Maintenance
Implementation

8. Requirements in the Modified Waterfall Model
Feasibility study
Waterfall model with feedback
Requirements
System design
Program design
Coding
Testing
Acceptance & release
Operation & maintenance

9. Requirements in Iterative Refinement
Concurrent
Activities
Initial
Version
Requirements
Outline
Description
Intermediate
Versions
Design
Implementation
Final
Version

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

11. The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Model
Requirements
Specification
Feasibility
Report
Work with the client to understand the requirements
Organize the requirements in a systematic and comprehensible manner
Documentation of
Requirements
Requirements Analysis (optional)

12. 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.
"Our understanding of your requirements is that ..."

13. 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)

14. Requirements Documentation (continued)
Requirements of proposed system
Overview
Functional Requirements
Usability requirements
Non-functional requirements
System models
Scenarios
Use cases
Models used during analysis

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

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

17. 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).

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

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

20. Non-Functional Requirements
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

21. Examples of Functional and Non-Functional 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)
Retain all required records
Discard all other records

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

23. 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
Importance of developing a system that will be respected by other major libraries

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

25. 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.
• Prepare before you meet with them
• Keep full notes
• If you do not understand, delve further, again and again
• Repeat what you hear
• Small group meetings are often most effective

26. 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?

27. Requirements Analysis
2. Understand the requirements in depth:
• Domain understanding
Examples: Philips light bulbs
• Understanding of the real requirements of all stakeholders

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

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

30. 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?

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

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

33. 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 *