1. SWE 513: Software Engineering
Requirements I

2. Feedback in the Waterfall Model
Requirements Analysis
System design
Program design
Coding
Unit & Integration Testing
System Testing
Acceptance Testing
Operation & Maintenance

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

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

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

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 most common mistake is to build the wrong system!

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

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

9. The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Definition
Requirements
Specification
Feasibility
Report
System
Models
Definition of
Requirements
Requirements
Document
Specification of
Requirements

10. Functional Requirements
Requirements about the functions
that the system must perform
Functionality
Data
Interfaces
Users and human factors

11. Example of Functional Requirements
BU Registration System
• 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?).

12. Non-Functional Requirements
Requirements about the context in
which the system is built
Documentation and training
Resources
Security
Physical environment
Quality assurance

13. Examples of Functional and Non-Functional Requirements
Privacy
Functional requirement:
Usage data for management of system
Non-functional requirement:
Usage data must not identify individuals
Minimizing records
Retain all required records
Discard all other records

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

15. Example of Non-Functional Requirements
Example: Library System
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

16. Unspoken Requirements
Example:
Resistance to change
Departmental friction
Management strengths and weaknesses

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

18. Requirements Analysis
1. Identify the stakeholders:
• Who is affected by this system?
Client
Senior management
Production staff
Computing staff
Customers
etc., etc., etc.,

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

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

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

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