CS 501: Software Engineering

1. CS 501: Software Engineering Lecture 7 Requirements I

2. Administration Quiz 1 Collect answer books from reception at 301 College Avenue Mean score was 15.5 Assignment 1: Feasibility study Due Friday at 5:00 p.m. See slight revisions to submission instructions Remember to submit your questionnaires Remember to send a copy to your client

3. Lectures on Requirements Analysis and Specification Requirements I: Requirements Analysis Requirements II: Scenarios and Use Cases Requirements III: Informal Methods of Specification Requirements IV: Formal Methods of Specification

4. Requirements in Software Development Feasibility and Planning All process models include a requirements activity Requirements Design Operation and Maintenance Implementation

5. Requirements in the Waterfall Model Feasibility study Requirements System design Program design Coding Testing Acceptance testing Operation & maintenance

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

7. From an 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?

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

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

10. From an Exam Question (Answer) 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

11. 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 commonest mistake is to build the wrong system!

12. 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. 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 developer.

13. Requirements Documentation (first part) 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)

14. Requirements Documentation (continued) Requirements of proposed system Overview Functional Requirements Usability requirements Non-functional requirements System models Scenarios Use cases Models used during analysis

15. Realism and Verifiability Requirements must be realistic, i.e., it must be possible to meet them. Not: 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.

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

17. New and Old Systems 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. 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.

18. Requirements Analysis Requirements Specification Requirements Model The Requirements Process Feasibility Study Feasibility Report Work with the client to understand the requirements Organize the requirements in a systematic and comprehensible manner Documentation of Requirements Requirements Analysis (optional)

19. Requirements Analysis 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 Often described in a separate document for consultation with the client. "Our understanding of your requirements is that ..."

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

21. Non-Functional Requirements Requirements that are not directly related to the functions that the system must perform • Usability, documentation and training • Reliability and quality assurance • Performance • Supportability • Implementation and technical constraints • Interfaces and compatibility • Operation and physical environment • Packaging and security • Legal and business • Resources

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

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

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

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

26. Requirements Analysis: 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 do not understand, delve further • Repeat what you hear • Small group meetings are often most effective

27. 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?

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

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

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

31. Models A model is a simplification of reality. • We build models so that we can better understand the system we are developing. • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ

32. Principles of Modeling • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. • Every model can be expressed at different levels of precision. • The best models are connected to reality. • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. BRJ

33. The Unified Modeling Language UML is a standard language for modeling software systems • Serves as a bridge between the requirements specification and the implementation. • Provides a means to specify and document the design of a software system. • Is process and programming language independent. • Is particularly suited to object-oriented program development.

34. Useful Texts Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.

35. Rational Rose Rational Rose is a system for creating and managing UML diagrams. It is available for all Computer Science Department computers, but you may have to install it. See: http://adm/Software/purify_install.htm for installation instructions. See: http://www.rational.com/products/index.jsp for information about the system.