1. CS 5150 1 CS 5150 Software Engineering Lecture 8 Requirements 1

2. CS 5150 2 Administration Assignment 1: see the Assignments page on the web site Due Friday at 11:00 p.m. Submit by email. Feasibility study (group assignment) Remember to send a copy to your client Survey (individual assignment) See the Surveys page on the course web site. Test 1 Uncollected answer books are at the reception at 301 College Avenue

3. CS 5150 3 Administration Assignment 2 Presentations will be on October 13 to 15. See the available times on the home page of the web site. Client must attend. Not all members of the project team need attend. Sign up now. More information about the presentations will be given in a later class.

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

5. CS 5150 5 Requirements in Iterative Refinement Requirements Design Implementation Evaluation/acceptance The requirements are revised for each iteration.

6. CS 5150 6 Requirements in the Modified Waterfall Model Requirements System design Testing Operation & maintenance Program design Implementation (coding) Acceptance & release Feasibility study The requirements need continual updating as the project continues.

7. CS 5150 7 Requirements with Incremental Development Increment 1 Release Increment 1 Increment 2 Increment 3 Release Increment 2 Release Increment 3 Each increment has its own set of requirements.

8. CS 5150 8 Goals during the Requirements Phase Understand the requirements in detail. Define and record the requirements in a manner that is clear to the client. This may be a written specification or other form of communication. Define and record the requirements in a manner that is clear to the people who will design and implement the system. Ensure that the client and developers understand the description of the requirements and their implications. The set of requirements will be the basis for acceptance testing of the final system

9. CS 5150 9 Functional Requirements Functional requirements describe the functions that the system must perform. They are identified by analyzing the use made of the system: Functionality Data User interfaces Analyzing and defining the functional requirements is the theme of the next two lectures.

10. CS 5150 10 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 client (the National Science Foundation) wanted a system that could be demonstrated by the end of 2002

11. CS 5150 11 Example of Non-Functional Requirements Example: Library of Congress Repository Use technology 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, accessibility to people with disabilities, etc. Importance of developing a system that will be respected by other major libraries

12. CS 5150 12 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.

13. CS 5150 13 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: Operators should need no more than one day's training.

14. CS 5150 14 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 (next two lectures). Define, record, and communicate the requirements in a manner and level of detail that is understandable by both client and development staff.

15. CS 5150 15 The Requirements Process Feasibility study Analyze ModelDefine Feasibility report Specification or alternative description Work with the client to understand requirements Organize requirements in a systematic and comprehensible manner Report or alternative description (optional)

16. CS 5150 16 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 presentation to and consultation with the client. "Our understanding of your requirements is that..."

17. CS 5150 17 Requirements Analysis: Interviews with Clients Client interviews are the heart of the requirements analysis. 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 Small group meetings are often most effective Repeat what you hear

18. CS 5150 18 Requirements Analysis: Understand the Requirements Understand the requirements in depth: Domain understanding Example: Philips light bulbs Understanding of the real requirements of all stakeholders Stakeholders may not have clear ideas about what they require, or they may not express requirements clearly. They are often too close to the old way of doing things. Understanding the terminology Clients often use specialized terminology. If you do not understand it, ask for an explanation.

19. CS 5150 19 Requirements Analysis: Stakeholders 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)

20. CS 5150 20 Requirements Analysis: Viewpoint Analysis Viewpoint Analysis. Analyze the requirements as seen by each group of stakeholders Example: University Admissions System Applicants University administration Admissions office Financial aid office Special offices (e.g., athletics, development) Academic departments Computing staff Operations and maintenance

21. CS 5150 21 Requirements Analysis: Special Studies Understanding the requirements may need studies: Market research focus groups, surveys, competitive analysis, etc. Example: Windows XP T-shirt Technical evaluation experiments, prototypes, etc. Example: Windows XP boot faster

22. CS 5150 22 Requirements Analysis: 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.

23. CS 5150 23 Requirements Analysis: Conflicts Conflicts: Recognize and resolve conflicts (e.g., functionality v. cost v. timeliness) Example: Dartmouth general ledger system

24. CS 5150 24 Defining and Communicating Requirements: Option 1 -- Written Specification Written Detailed Specification Written documentation that specifies each requirement in detail. Carefully checked by client and developers. May be a contractual document. Provides visibility. Difficulties Details may obscure the overview of the requirements. Time consuming and difficult to create. Checking a detailed specification is difficult and tedious. Clients rarely understand the implications.

25. CS 5150 25 Defining and Communicating Requirements: Option 2 -- Outline Specification + Other Tools Written Outline of Requirements Documentation describing requirements in moderate detail. Carefully checked by client and developers. May be a contractual document. Provides visibility. Details provided by supplementary tools, e.g., User interface mock-up or prototype. Data base schema. State machine or other logical model.

26. CS 5150 26 Requirements: Negotiation with the Client Sometimes the client will request 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 suggest other approaches. Before the requirements phase is completed the client and development team must resolve these questions.

27. CS 5150 27 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).