1. 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 8 Requirements Analysis and Specification

2. 2 CS 501 Spring 2002 Administration

3. 3 CS 501 Spring 2002 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 2002 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 2002 Iterative Refinement Outline Description Concurrent Activities Requirements Design Implementation Initial Version Intermediate Versions Final Version

6. 6 CS 501 Spring 2002 The Requirements Process Feasibility Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of Requirements Document

7. 7 CS 501 Spring 2002 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!

8. 8 CS 501 Spring 2002 Types of Requirements Functionality Data Interfaces Users and human factors Documentation and training Resources Security Physical environment Quality assurance

9. 9 CS 501 Spring 2002 What is a Requirement? A requirement is a statement of need as expressed by a client. Example (Quiz 1). The Piccadilly television advertising project. 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.

10. 10 CS 501 Spring 2002 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.

11. 11 CS 501 Spring 2002 Library of Congress Requirements Study Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others Advisors: Mailing list of about 20 knowledgeable stakeholders. Timetable: Preliminary report (2 months). Final report (1 month).

12. 12 CS 501 Spring 2002 Functional Requirements Example: Library of Congress repository Support for complex digital objects Access management Identification Information hiding Open protocols and formats Integration with other systems (scope)

13. 13 CS 501 Spring 2002 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

14. 14 CS 501 Spring 2002 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: NED musical notation

15. 15 CS 501 Spring 2002 Examples of 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

16. 16 CS 501 Spring 2002 Unspoken Requirements Example: Resistance to change at XXX

17. 17 CS 501 Spring 2002 Non-functional Requirements Example: Library of Congress repository Hardware and software systems (IBM/Unix) Database systems (Oracle) Programming languages (C and C++) Weaknesses and defensiveness of some staff Departmental friction

18. 18 CS 501 Spring 2002 Documentation Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume

19. 19 CS 501 Spring 2002 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).

20. 20 CS 501 Spring 2002 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 Who can disrupt this project?

21. 21 CS 501 Spring 2002 Requirements Analysis 2. Understand the requirements in depth: Domain understanding Examples: Tote Investors, Philips light bulbs Understanding of the real requirements of all stakeholders

22. 22 CS 501 Spring 2002 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.

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

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

25. 25 CS 501 Spring 2002 Requirements Analysis 4. Model the requirements: Informal Prose Systematic Procedural models Data-centric models Object models Formal models

26. 26 CS 501 Spring 2002 Requirements Specification: Purpose 1.Document that describes the requirements to the stakeholders in a precise manner Expressed in the terms that the stakeholders understand Comprehensible from many viewpoints Reviewed by stakeholders so that they understand implications Must be clear about assumptions (things left out)

27. 27 CS 501 Spring 2002 Requirements Specification: Purpose 2. It describes the requirements to the implementers As precise and specific as possible Expressed in terms that they understand Comprehensible to new team members

28. 28 CS 501 Spring 2002 Requirements Specification: Purpose 3. It records the requirements for the future An essential part of system evolution 4. If may be a contractual document See you in court!

29. 29 CS 501 Spring 2002 Requirements Specification: Process The client must understand the requirements specification. Do not assume that anybody has read a document. Do not assume that anybody understands a document. Go through the requirements specification with the client, line by line. It is usual for the client and developer to sign the requirements document when it is agreed. [Compare with the plans to build a house. This is the specification of the system that you are about to build.]

30. 30 CS 501 Spring 2002 Requirements Analysis v. System Design Dilemma. Requirements analysis should make minimal assumptions about the system design. But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However: 1. Do not to allow the requirements analysis to prejudge the system design. 2. Do not allow assumptions about the design to have influence the requirements analysis.