1. 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 8 Requirements I

2. 2 CS 501 Spring 2003 Administration

3. 3 CS 501 Spring 2003 Project Presentations Requirements Analysis System design Unit & Integration Testing System Testing Operation & Maintenance Program design Coding Acceptance Testing Requirements Design Implementation

4. 4 CS 501 Spring 2003 Feedback in the Waterfall Model Requirements Analysis System design Unit & Integration Testing System Testing Operation & Maintenance Program design Coding Acceptance Testing

5. 5 CS 501 Spring 2003 Iterative Refinement Outline Description Concurrent Activities Requirements Design Implementation Initial Version Intermediate Versions Final Version

6. 6 CS 501 Spring 2003 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. 7 CS 501 Spring 2003 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. 8 CS 501 Spring 2003 Why are Requirements Important? Causes of failed software projects (Standish Group study, 1994) Incomplete requirements13.1% Lack of user involvement12.4% Lack of resources10.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!

9. 9 CS 501 Spring 2003 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. 10 CS 501 Spring 2003 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. 11 CS 501 Spring 2003 The Requirements Process Feasibility Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of Requirements Document

12. 12 CS 501 Spring 2003 Functional Requirements Requirements about the functions that the system must perform Functionality Data Interfaces Users and human factors

13. 13 CS 501 Spring 2003 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. 14 CS 501 Spring 2003 Current Storage Structure (in Unix files, by aggregate) Index Generation (including pre-processing) American Memory User Interface (retrieval, navigation, & display) Object Administration System Repository NDLP Workflow Tracking Support Handle-server NDLP collections already released NDLP collections in conversion Coolidge collection (for repository test) Future NDLP collections NOWFUTURE ILS OPAC InterfaceOther User Interfaces (e.g. RLG, OCLC, DLF partners) Other applications and materials ILS Handle assignment & registration Handle resolution Supporting infrastructure DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY AM user interface plus access management for objects/collections

15. 15 CS 501 Spring 2003 Non-Functional Requirements Requirements about the context in which the system is built Documentation and training Resources Security Physical environment Quality assurance

16. 16 CS 501 Spring 2003 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. 17 CS 501 Spring 2003 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. 18 CS 501 Spring 2003 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. 19 CS 501 Spring 2003 Unspoken Requirements Example: Resistance to change Departmental friction Management strengths and weaknesses

20. 20 CS 501 Spring 2003 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. 21 CS 501 Spring 2003 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. 22 CS 501 Spring 2003 Requirements Analysis 2. Understand the requirements in depth: Domain understanding Examples: Philips light bulbs Understanding of the real requirements of all stakeholders

23. 23 CS 501 Spring 2003 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. 24 CS 501 Spring 2003 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

25. 25 CS 501 Spring 2003 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