1. 1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 7 Requirements I

2. 2 CS 501 Spring 2008 Administration Project teams Does everybody have a project? Which projects have less than 7 people? Has every project sent an email to the course team, with the name of the project, client, and team members with NetID?

3. 3 CS 501 Spring 2008 Administration Assignment 1: Due Friday at 5:00 p.m. Submit by email. Feasibility study (group assignment) Remember to send a copy to your client Survey (individual assignment) Sending email to cs501-l@lists.cs.cornell.edu All mail to this address must be sent from an email address in the cornell.edu domain. To block spam, all mail from outside Cornell is rejected.

4. 4 CS 501 Spring 2008 Administration Lecture 8, Thursday February 14 Guest lecture by Rich Reitman (may be included in quiz)

5. 5 CS 501 Spring 2008 Peer to Patent

6. 6 CS 501 Spring 2008 From an old exam question 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. All CS 501 projects have timeliness risks.

7. 7 CS 501 Spring 2008 Lectures on Requirements Analysis and Specification Requirements I: Requirements Analysis Requirements II: Models -- Scenarios and Use Cases Requirements III: Informal Methods of Specification Formal Methods of Specification

8. 8 CS 501 Spring 2008 Requirements in Software Development Requirements Operation and Maintenance Implementation Design Feasibility and Planning All process models include a requirements activity

9. 9 CS 501 Spring 2008 Requirements in the modified Waterfall Model Requirements System design Testing Operation & maintenance Program design Implementation (coding) Acceptance & release Feasibility study The requirements will need continual updating as the project continues.

10. 10 CS 501 Spring 2008 Requirements in iterative refinement Requirements Design Implementation Evaluation/acceptance

11. 11 CS 501 Spring 2008 Requirements in Iterative Refinement Outline Description Concurrent Activities Requirements Design Implementation Initial Version Intermediate Versions Final Version

12. 12 CS 501 Spring 2008 From an old 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?

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

14. 14 CS 501 Spring 2008 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.

15. 15 CS 501 Spring 2008 From an old 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? This is part of the System Design.

16. 16 CS 501 Spring 2008 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.

17. 17 CS 501 Spring 2008 Goals during the requirements phase Understand the requirements in detail. Specify the requirements in a manner that is clear to the client. Ensure that the client understands the description of the requirements and their implications. Specify 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.

18. 18 CS 501 Spring 2008 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. Specification in a manner and level of detail that is understandable by both users and development staff.

19. 19 CS 501 Spring 2008 The requirements process Feasibility Study Requirements Analysis Requirements Model Requirements Specification Feasibility Report Documentation of Requirements Work with the client to understand the requirements Organize the requirements in a systematic and comprehensible manner Analysis Report (optional)

20. 20 CS 501 Spring 2008 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 consultation with the client. "Our understanding of your requirements is that..."

21. 21 CS 501 Spring 2008 Requirements analysis: interviews with clients Client interviews are the heart of the requirements analysis and definition. 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 Repeat what you hear Small group meetings are often most effective

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

23. 23 CS 501 Spring 2008 Viewpoint analysis Example: University Admissions System Applicants University administration Admissions office Financial aid office Special offices (e.g., athletics, development) Academic departments Computing staff Operations Software development and maintenance

24. 24 CS 501 Spring 2008 Requirements analysis 2. Understand the requirements in depth: Domain understanding Examples: Philips light bulbs Understanding of the real requirements of all stakeholders Who can disrupt this project?

25. 25 CS 501 Spring 2008 Requirements analysis 3. Organize the requirements: Classification into coherent clusters (modeling) (e.g., legal requirements) Recognize and resolve conflicts (e.g., functionality v. cost v. timeliness) Example: Dartmouth general ledger system

26. 26 CS 501 Spring 2008 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.

27. 27 CS 501 Spring 2008 Requirements analysis: negotiation with the client Sometimes the client will request some 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 show other approaches. Before the requirements phase is completed the client and development team must resolve these questions.

28. 28 CS 501 Spring 2008 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.

29. 29 CS 501 Spring 2008 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 NSF wanted a system that could be demonstrated by the end of 2002

30. 30 CS 501 Spring 2008 Example of non-functional requirements Example: Library of Congress Repository Use systems 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 Importance of developing a system that will be respected by other major libraries

31. 31 CS 501 Spring 2008 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.

32. 32 CS 501 Spring 2008 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)

33. 33 CS 501 Spring 2008 Requirements documentation (continued) Requirements of proposed system Overview Functional Requirements Usability requirements Non-functional requirements System models Scenarios Use cases Models used during analysis

34. 34 CS 501 Spring 2008 Requirements documentation (continued) Detailed specifications Business rules, specifications, etc. (e.g., reference to an accounting standard) Data flow, sources of data, data validation etc., A common fault in requirements documentation is to gloss over the details. This results in misunderstandings between the client and the developers.

35. 35 CS 501 Spring 2008 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.

36. 36 CS 501 Spring 2008 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).