CS 5150 Software Engineering

1. CS 5150 Software Engineering Lecture 9 Requirements 2

2. Administration Feasibility Study Comments have been sent to all groups. Contact me if you have any questions.

3. Feasibility Studies: Scope The purpose of a feasible study is to establish if a project is feasible, at reasonable cost, within the planned period. • Many of your reports had not gone into the activities in enough detail to estimate the effort convincingly. • Several of the reports were vague about the scope. Without a clear definition of scope, it is not clear that the project is feasible. • Several projects are too ambitious. How will you monitor the progress and adjust the scope if necessary?

4. Feasibility Studies: Reports Appoint a team member to read and edit the entire report. Content • If different authors write different sections of the report are they consistent? E.g., do the scope, requirements, and plan agree on what is to be done? Style • Is the text comprehensible? Does the report use jargon that is not clear to the client? • If possible, have a native English speaker do the final editing.

5. Functional Requirements Functional requirements describe thefunctions that the system must perform. They are identified by analyzing the use made of the system: • Functionality • Data • User interfaces Modeling the functional requirements is the theme of the this lecture and the next.

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

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

8. Requirements Analysis v. System Design Dilemma about technical decisions • 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 allow assumptions about the design to influence the requirements analysis. 2. Do not to allow the requirements analysis to prejudge the system design.

9. Scenarios Scenario A scenario is a tool used during requirements analysis to describe a user's interactions with a proposed system. Scenarios capture the system as visualized by the user, by use of specific examples. Note on terminology Some authors restrict the word "scenario" to refer to the user's total interaction with the system. Other authors use the word "scenario" to refer to parts of the interaction. In this course, the term is used with both meanings.

10. Developing a Scenario with a Client Example of how to develop a scenario with a client The requirements are being developed for a system that will enable university students to take exams online from their own rooms using a Web browser. Create a scenario for how a typical student interacts with the system. In the next few slides, the questions in blue are typical of the questions to ask the client while developing the scenario.

11. Developing a Scenario with a Client: a Typical Student Individual: Jane Smith, senior at Cornell, major in computer science. [Where can she be located? Do other universities differ?] Equipment:[What equipment is supported? What software is required? Are there any network restrictions?] Scenario: 1. JS authenticates. [How does she authenticate?] 2. JS starts browser and types URL of Exam system. [How does she know the URL?] 3. Exam system displays list of options. [Is the list tailored to the individual user? If so how?]

12. Developing a Scenario with a Client (continued) 4. JS selects CS 1234 Exam 1. [Does she have other options?] 5. A list of questions is displayed, each marked to indicate whether completed or not. [Where does this information come from?] 6. JS selects a question and specifies whether she will submit a new answer or edit a previous answer. [Does she always have these options?] 7. For the first question, she is submitting a new answer. She has a choice whether to type the solution into the browser or to attach a separate file. She decides to attach a file. [What types of question are there: text, multiple choice, etc? What types of file are accepted?]

13. Developing a Scenario with a Client (continued) 8. For the second question, she is editing a previous answer. She chooses to delete a solution previously typed into the browser, and to replace it with an attached file. [Can she edit a previous answer, or must she replace it?] JS has now completed the exam. She selects an option that submits the exam to the grading system. [What happens to the solution? What if she has not attempted every question? Where is the exam stored? Is the grader notified?] 10. JS logs off. 11. JS now wishes to change a solution. The system does not permit changes once the solution has been submitted. [Can she still see her solution?]

14. Developing a Scenario with a Client (continued) 12. As an alternative to completing the entire exam in a single session, JS completes several questions, then saves her work to continue later. [Is this permitted?] 13. Later JS log in, finishes the exam, submits her answers, and logs out. [What is the process for re-authenticating?] 14. Later JS logins in to check her grades. [When are grades made available? How does she know?] 15. JS requests a regrade. [What are the policies? What are the procedures?]

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

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

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

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

19. Rational Rose Rational Rose is an IBM-owned system for creating and managing UML diagrams. It is available on Computer Science Department computers.

20. Models: Diagrams and Specification in UML In UML, a model consists of a diagram and a specification. A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). Each diagram is supported by technical documentation that specifies in more detail the model represented by the diagram. A diagram without a specification is of little value.

21. Modeling Scenarios as Use Cases Models Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood. This is the purpose of requirements modeling. A use case provides such a model. There is a good discussion of use cases in Wikipedia. The approach used in this course is less complex than the Wikipedia article.

22. Actor and Use Case Diagram • An actor is a user of a system in a particular role. An actor can be human or an external system. • A use case is a a task that an actor needs to perform with the help of the system. BookBorrower PressureSensor Borrow book RecordPressure

23. Use Cases and Actors • Actor is role, not an individual (e.g., librarian can have many roles) • Actor must be a beneficiary of the use case (e.g., not librarian who processes book when borrowed) In UML, the system boundary is the set of use cases. In naming actors, choose names that describe the use case, not generic names, such as "user" or "client".

24. Use Cases for Exam System TakeExam ExamTaker CheckGrades RequestRegrade Three separate use cases

25. Outline of TakeExam Use Case Name of Use Case: TakeExam Actor(s): ExamTaker Flow of events: 1. ExamTaker connects to the Exam server. 2. Exam server checks whether student is already authenticated and runs authentication process if necessary. 3. ExamTaker selects a exam from a list of options. 4. ExamTaker repeatedly selects a question and either types in a solution, attaches a file with a solution, edits a solution or attaches a replacement file.

26. Outline Specification of Use Case (continued) Flow of events (continued): 5. ExamTaker either submits completed exam or saves current state. 6. When a completed exam is submitted, Exam server checks that all questions have been attempted and either sends acknowledgement to ExamTaker, or saves current state and notifies ExamTaker of incomplete submission. 7. ExamTaker logs out. Entry conditions: 1. ExamTaker must have Cornell NetID. 2. Computing requirements: Supported browser

27. Use Cases for Exam System (continued) SetExam Instructor Grade Note that actor is a role. An individual can be a ExamTaker on one occasion and an Instructor at a different time. Regrade

28. Relationships Between Use Cases: <<includes>> <<includes>> TakeExam Authenticate ExamTaker CheckGrades <<includes>> The Authenticate use case may be used in other contexts

29. Relationships Between Use Cases: <<extends>> <<extends>> ConnectionFails TakeExam ExamTaker <<include>> is used for events that are in the flow of events of the source use case. <<extends>> is used for exceptional conditions, especially those that can occur at any time.

30. Scenarios for Analyzing Special Requirements Scenarios are very useful for analyzing special requirements. Examples • Reversals. In a financial system, a transaction is credited to the wrong account. How is it reversed? • Errors. A mail order company has several copies of its inventory database. What happens if they become inconsistent? • Malfeasance. In a voting system, a voter has houses in two cities. What happens if he attempts to vote in both of them? Murphy's Law: "If anything can go wrong, it will". Create a scenario for everything that can go wrong and how the system is expected to handle it.

31. Scenarios and Use Cases in the Development Cycle Scenarios are a tool for requirements analysis. • They are useful to validate use cases and in checking the design of a system. • They can be used as test cases for acceptance testing Use cases are a tool for modeling requirements • They are intuitive -- easy to discuss with clients • Use cases are often hard to translate into class models • A set of use cases can provide a framework for the requirements specification.