CS 5150 Software Engineering Lecture 8 Requirements 2 Administrivia CS 5150 • Quizzes being graded • Feasibility study/plan due Friday • Sign-up online for presentation slots 2 Your Feasibility Reports • • • TAs convinced me to use CMS • Shorter does not mean less quality Most important points • • CS 5150 Will update the website with proper links Clear on scope. What’s in, what’s out? If you’re uncertain, discuss the uncertainty. Plan with reasonably detailed effort estimates and a few high-level milestones 3 Some Suggestions • • • CS 5150 Make one person responsible for the final edit • Inconsistencies within a document leave a bad impression Explain any jargon that might not be clear to non-computer people or people outside the domain of your project If possible, get an edit from someone with native-level English fluency 4 • Last Lecture: Functional Requirements Functional requirements describe what the system should do, not how it should do it • • • • • CS 5150 High-level functions Services Data User interfaces Any questions inspired by your role-playing last time? 5 Other Kinds of Requirements • • • • CS 5150 Product requirements • Performance, reliability, portability, ... Organizational requirements • Delivery, training, standards compliance, ... External requirements • Legal, interoperability, ... Marketing and public relations • Must work well on a particular benchmark or data set, ... 6 • • • Example of Non-Functional Requirements Library of Congress Repository Use technology that is familiar to existing staff • • • Databases (Oracle) Programming languages (C/C++) Client’s (federal government) special constraints • • CS 5150 Systems (IBM/UNIX) Regulations governing contracting, accessibility, ... Importance of respect of other institutions 7 Requirements Analysis vs System Design • • Where is the line between defining what a software system should do and how it should do it? • What we have are guiding principles: • • CS 5150 There is no such hard line! Do not allow assumptions and constraints about system implementation affect functional requirements Do not allow high-level requirements analysis to predetermine system design 8 Scenarios/Stories/Use Cases • • 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. Some people think “scenario” should only be used for complete user interactions • CS 5150 I don’t see a need to fuss about this terminology 9 Developing a Scenario with a Client • • In general, scenarios can be written by the client, users or developers/designers One example of how to develop a scenario in collaboration with a client • CS 5150 Developing a system that will allow college students to take exams from their own rooms using a web browser 10 A Typical Student • • • CS 5150 Individual: Jane Smith is a senior at Cornell studying computer science; she wants to move to California and work for Facebook. [Would anything be different at a different university?] Situation: Jane lives in an on-campus dorm and likes to do work in the engineering library. [Does on-campus versus off-campus matter?] Equipment: Jane has an ASUS laptop on which she installed a custom version of Linux. [What software and/or hardware requirements are there?] 11 A Typical Interaction (1/4) 1. JS opens her computer and connects to the service. [How does she know the service exists? How does she find it?] 2. JS logs in. [How does she authenticate? Is integration with other authentication systems needed?] 3. JS peruses the list of exams. [Is it tailored to specific users? What does she do if the exam she’s expecting to take isn’t there?] CS 5150 12 A Typical Interaction (2/4) 4. JS selects CS 1234 Exam 2. [Does she have other options? What if she selected it accidentally?] 5. A list of questions is displayed, each marked to indicate whether it is completed. [Where does this information come from? Can it work offline?] 6. JS selects a question. [Can already answered questions be edited?] 7. JS chooses to submit a new answer. She has the option of typing in the browser or attaching a file. [What kinds of files are supported? What kinds of question formats?] CS 5150 13 A Typical Interaction (3/4) 8. JS chooses to edit another answer. [Can she edit the existing answer, or just replace it?] 9. JS is done and chooses to submit the exam. [Does the system check that all questions are answered? What happens to her solutions? Are notifications sent?] 10.JS logs off. [Do any caches need to be cleared?] 11.JS wants to change an answer, but the system blocks her because she already submitted. [Can she still see her solutions?] CS 5150 14 A Typical Interaction (4/4) 12.In a parallel universe, JS does not submit the exam, but logs out to finish it later. [Is this permitted? If not, what it she is disconnected accidentally?] 13.Later JS logs back in and completes the exam. [Is there anything different about logging in the second time?] 14.Later JS logs in to check her grade. [Is she notified when grading is done?] 15.JS requests a regrade. [What are the policies? Does the system enforce the automatically?] CS 5150 15 Models • A model is an abstraction/simplification of reality • • • CS 5150 We build models of complex systems so we can talk about them, even if we don’t understand the details We build models to sharpen our understanding of real systems Models can be informal or formal 16 Principles of Modeling • • • • CS 5150 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 mostly independent models. 17 Useful Texts on Modeling • • • CS 5150 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) • • • • UML is a common language for modeling software UML is used to connect requirements to actual implementations UML is a way to specify and document high level design decisions UML is process and programming language independent • CS 5150 UML is tilted towards object-oriented design/programming 19 Rational Rose • Rational Rose is a company that makes UMLrelated tools • • CS 5150 Acquired by IBM Available on Computer Science department computers (?) 20 UML: Diagrams and Specifications • • • CS 5150 In UML, a model is a diagram and a specification (text) The diagram is typically a graph of elements and their relationships Each diagram is supported by documentation that elaborates on the entities and their relationships 21 Scenarios Become Use Cases in UML • • • • CS 5150 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 Actors and Use Cases • An actor is a user of a system in a particular role • • CS 5150 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 23 Use Cases and Actors • • • • CS 5150 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 CS 5150 25 Outline of TakeExam Use Case (1/2) • • • 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. CS 5150 26 Outline of TakeExam Use Case (2/2) • 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 CS 5150 27 Use Cases for the Exam System (continued) CS 5150 28 Relationships Between Use Cases: <<includes>> CS 5150 29 Relationships Between Use Cases: <<extends>> • • CS 5150 <<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 • • • • • • CS 5150 Strength of Scenarios and Use Cases: Exceptions Scenarios are very useful for analyzing special/unusual requirements Examples Undoing. 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 Process • Scenarios are a tool for requirements analysis • • • They can be used as test cases for acceptance testing Use cases are a tool for modeling requirements • • • CS 5150 They are useful to validate use cases and in checking the design of a system 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. 32