1. ConOps and Use Cases Copyright, 2003 © Jerzy R. Nawrocki Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/require/ Requirements Engineering Lecture 3 Requirements Engineering Lecture 3

2. J. Nawrocki, Use Cases and ConOps BibliographyBibliography ISO/IEC 12207 Standard for Information Technology— Software life cycle processes—Life cycle data, IEEE/EIA 12207.1-1997, April 1998. IEEE Guide for Information Technology – System Definition - Concept of Operations (ConOps) Document, IEEE Std 1362-1998, March 1998. S. Adolph, P. Bramble, A. Cockburn, A. Pols, Patterns for Effective Use Cases, Addison-Wesley, Boston, 2003. 

3. J. Nawrocki, Use Cases and ConOps ISO/IEC 12207 contents 6.1 Acquisition plan 6.2 Change request or modification request 6.3 Concept of operations description 6.4 Database design description 6.5 Development process plan 6.6 Evaluation records 6.8 Maintenance process plan 6.9 Operation process plan 6.10 Problem report and problem resolution report 6.11 Project management plan 6.12 Software architecture description...

4. J. Nawrocki, Use Cases and ConOps Generic description - 12207 a) Date of issue and status; b) Scope; c) Issuing organization; { Cover page d) References; e) Context; f) Notation for description; g) Body; h) Summary; i) Glossary; j) Change history.

5. J. Nawrocki, Use Cases and ConOps Concept of Operations - 12207 Purpose: Describe, in users’ terminology, how the system should operate to meet the users’ needs. Content: a) Generic description information (previous slide); b) Description of current situation or system; c) Justification for and nature of changes; d) Concepts for the proposed system; e) Operational scenarios; f) Summary of impacts; g) Analysis of the proposed system; h) Priorities, assumptions, constraints, advantages, limitations, alternatives, and trade-offs considered. Use cases

6. J. Nawrocki, Use Cases and ConOps IEEE Std 1362 History R.J. Lano, A Structured Approach for Operational Concept Formulation, TRW SS-80-02, Redondo Beach, CA, 1980. 1992: Software Systems Technical Committee of the American Institute of Aeronautics and Astronautics (AIAA), a standard for and Operational Concept Document. 1993: MS thesis, California State University, Sacramento; accepted as MIL-STD-498. IEEE Std 1362-1998 by R. Thayer, R. Fairley, P. Bjorke.

7. J. Nawrocki, Use Cases and ConOps ConOps structure - 1362 1. Scope 2. Referenced documents 3. Current system or situation 4. Justification for and nature of changes 5. Concepts for the proposed system 6. Operational scenarios 7. Summary of impacts 8. Analysis of the proposed system 9. Notes Appendices Glossary

8. J. Nawrocki, Use Cases and ConOps 1. Scope 1.1 Identification Number, title, and abbreviation of the system 1.2 Document overview Purpose, audience, security, ConOps outline 1.3 System overview Purpose, sponsors, context diagram System Person 1 Person 2 Institution Device

9. J. Nawrocki, Use Cases and ConOps 3. Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints Constraints on the hardware, the hours of operation of the system, the number of available personnel,..

10. J. Nawrocki, Use Cases and ConOps 3. Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints 3.3 Description of the current system or situation The operational environment Major system components and their interconnections Interfaces to external systems or procedures Functions (features) Inputs, outputs, data flows Cost of system operations Operational risk factors Performance // Safety and security aspects //...

11. J. Nawrocki, Use Cases and ConOps 3. Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints 3.3 Description of the current system or situation 3.4 Modes of operation for the current system or situation Operational, degraded, maintenance, training,.. 3.5 User classes and other involved personnel 3.5.1 Organizational structure 3.5.2 Profiles of user classes 3.5.3 Interactions among user classes 3.5.4 Other involved personnel 3.6 Support environment

12. J. Nawrocki, Use Cases and ConOps 4. Justification for changes 4.1 Justication for changes New user needs, environments etc. Disadvantages of the current system. 4.2 Description of desired changes Features, processing, interfaces, personnel, environment,.. 4.3 Priorities among changes Essential, desirable, optional 4.4 Changes considered but not included

13. J. Nawrocki, Use Cases and ConOps 5. Concepts for the proposed.. 5.1 Background, objectives, and scope 5.2 Operational policies and constraints 5.3 Description of the current system or situation 5.4 Modes of operation for the current system or situation 5.5 User classes and other involved personnel 5.5.1 Organizational structure 5.5.2 Profiles of user classes 5.5.3 Interactions among user classes 5.5.4 Other involved personnel 5.6 Support environment

14. J. Nawrocki, Use Cases and ConOps Operational scenarios step-by-step interactionusersexternal interfaces circumstances A step-by-step description of system’s operation and interaction with its users and external interfaces under a given set of circumstances.

15. J. Nawrocki, Use Cases and ConOps 7. Summary of impacts 7.1 Operational impacts Changes in procedure; use of new data sources; changes in type and timing of data to be input 7.2 Organizational impacts Job positions, skill levels, responsibilities,.. 7.3 Impacts during development User involvement in software development; parallel operation of the new and old system,..

16. J. Nawrocki, Use Cases and ConOps Analysis of the proposed system 8.1 Summary of improvements New, enhanced, and deleted capabilities. Improved performance. 8.2 Disadvantages and limitations 8.3 Alternatives and trade-offs considered

17. J. Nawrocki, Use Cases and ConOps ConOps structure - 1362 1. Scope 2. Referenced documents 3. Current system or situation 4. Justification for and nature of changes 5. Concepts for the proposed system 6. Operational scenarios 7. Summary of impacts 8. Analysis of the proposed system 9. Notes AppendicesGlossary.., terms and definitions

18. J. Nawrocki, Use Cases and ConOps What is a use case? A story describing how an actor (user or device) cooperates with the system to accomplish a given purpose. Use cases IEEE SRS Abstraction level Size

19. J. Nawrocki, Use Cases and ConOps Advantages of use cases They are semiformal. They introduce structure to stories. They describe also error situations. They are part of O-O software development. They are basis for estimates, detailed requirements, interface designs, and test scenarios.

20. J. Nawrocki, Use Cases and ConOps Poorly written use case 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the „Add Course” button. Register for Course (Main Scenario)

21. J. Nawrocki, Use Cases and ConOps Poorly written use case Register for Course (Main Scenario cont.) 7. Check if the Student has the necessary prerequisites and that the course offering is open. 8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message „You are missing the prerequisites. Choose another course.” 9. Mark the course offering as „enrolled” in the schedule. 10. End do when the Student clicks on „Save Schedule.” 11. Save the schedule and return to the main selection screen.

22. J. Nawrocki, Use Cases and ConOps Poorly written use case 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the „Add Course” button. Too much user interface detail.

23. J. Nawrocki, Use Cases and ConOps Other frequent defects Too many use cases at low goal levels („Authorize user”). Using a use case for non-behavioral information (e.g. forms description – use adornments). Too long (should be short, usually 3-9 steps). Not a complete goal accomplished (also lack of alternative behaviors description). Sentence fragments (e.g. omitting the actors’ names in steps).

24. J. Nawrocki, Use Cases and ConOps Well-written use case 1.Student requests a new schedule. 2.The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System. 3.Student selects primary and alternate courses from the available offerings. 4.For each course, the verifies taht the Student has the necessary prerequisites and adds the Student to the course, marking the Student as „enrolled” in that course in the schedule. 5.When the Student indicates the schedule is complete, the system saves the schedule. Register for Course (Main Scenario)

25. J. Nawrocki, Use Cases and ConOps Patterns for effective use cases Shared Clear Vision Shared Clear Vision: Prepare a statement of purpose for the system that clearly describes the objectives of the system. The objectives of the system The problems that the system will solve The problems the system will not solve Who the stakeholders are How the system will benefit the stakeholders

26. J. Nawrocki, Use Cases and ConOps Patterns for effective use cases Visible Boundary Visible Boundary: Establish a visible boundary between the system and its environment by enumerating both the people and equipment that interact with the system.

27. J. Nawrocki, Use Cases and ConOps IEEE Std 1362 - Scope 1.1 Identification Number, title, and abbreviation of the system 1.2 Document overview Purpose, audience, security, ConOps outline 1.3 System overview Purpose, sponsors, context diagram System Person 1 Person 2 Institution Device

28. J. Nawrocki, Use Cases and ConOps Patterns for effective use cases Clear Cast Of Characters Clear Cast Of Characters: Identify the actors the system must interact with and the role each plays with respect to the system. Clearly describe each. Receptionist Receptionist: The Receptionist welcomes Customers to the pharmacy. He or she takes the Customer’s prescription. Anyone on the pharmacy staff can play the role of receptionist. Pharmacist Pharmacist: The Pharmacist fills and dispenses prescriptions for customers. Only the Pharmacist can check and authorize the prescription.

29. J. Nawrocki, Use Cases and ConOps Patterns for effective use cases User Valued Transactions User Valued Transactions: Identify the valuable services that the system delivers to the actors to satisfy their business purposes. Book trip Search for flights Promote vacations Create trip itinerary Update trip itinerary Delete trip itinerary Book trip Search for flights Promote vacations Change booking Cancel booking

30. J. Nawrocki, Use Cases and ConOps Patterns for effective use cases Ever Unfolding Story Ever Unfolding Story: Organize the use case set as a hierarchical story that can be either unfolded to get more detail or folded up to hide detail and show more context.

31. J. Nawrocki, Use Cases and ConOps Use case goal levels Book tripBook hotelBook flight User Goal Level Book trip Summary Level Book trip Book hotelBook flight Find flight Reserve seat Find hotel Reserve room Subfunction Level

32. J. Nawrocki, Use Cases and ConOps Ever Unfolding Story Book Flight Leel Leel: User Goal Main Success Scenario 1.This use case begins when a customer calls and requests a flight. 2.The customer describes her flight needs by specifying her origination, destination, travel dates, and preferred departure times looks up all flights 3.The system looks up all flights that match the customer’s preferences and presents the travel options to the customer. 4.The customer selects a flight. builds aflight itinerary 5.The system builds a flight itinerary for the customer. reserves the flight 6.The system reserves the flight for the customer. 7.The customer provides a credit card number and charges the price of the flight against it. issues the ticket 8.The system issues the ticket to the customer.

33. J. Nawrocki, Use Cases and ConOps A detailed version of Book Flight Construct itinerary Merchant bank Find flight Travel agent Airline reservation Reserve flight Issue ticket

34. J. Nawrocki, Use Cases and ConOps Ever Unfolding Story Find Flight Leel Leel: Subfunction 1.This use case begins when a customer contacts the travel agency and requests a flight. 2.The travel agent captures the customer’s trip origin and destination. 3.The travel agent looks up the airport codes for the origin and dest. 4.The travel agent captures the preferred departure times for the customer. 5.The travel agent captures the customer’s preferred class of service 6.The travel agent confirms that the customer’s preferences are correct. 7.The system requests from the airline reservation system a list of the flights available that match the customer’s preferences, which is presented to the travel agent.

35. J. Nawrocki, Use Cases and ConOps SummarySummary ISO/IEC Std 12207 and ConOps IEEE Std 1362 and ConOps: Current system Justification for change Concepts for new system Operational scenarios Impacts Use cases: Shared clear vision Visible boundary Clear cast of characters User valued transactions Ever unfolding story

36. J. Nawrocki, Use Cases and ConOps Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?