PB007 Software Engineering I — Requirements Specification, Use Case Diagram1 Requirements Specification, Use Case Diagram PB007 Software Engineering I Lukáš Daubner daubner@mail.muni.cz PB007 Software Engineering I — Requirements Specification, Use Case Diagram2 We must do EXACTLY as written! ̶ Let’s brainstorm… PB007 Software Engineering I — Requirements Specification, Use Case Diagram3 We must do EXACTLY as written! PB007 Software Engineering I — Requirements Specification, Use Case Diagram4 Functional Requirements ̶ Functional requirement tells WHAT the system should do (or should not do), i.e., describes the system’s functionality. ̶ Common format: ̶ Examples: ̶ 1. The ATM verifies the validity of inserted card ̶ 2. The ATM verifies the PIN provided by the customer ̶ 3. The ATM does not allow to withdraw more that 10 000 CZK for a single card within 24-hour period PB007 Software Engineering I — Requirements Specification, Use Case Diagram5 Non-functional Requirements ̶ Non-functional requirement is a constraint imposed on the system. Often related to (quantitative) attributes like performance, security, availability, etc. It also includes environment and regulatory constraints. ̶ They must be testable! ̶ Příklady: ̶ 1. The ATM will be programmed in Rust ̶ 2. The ATM will use 256-bit AES encryption for communication with bank ̶ 3. The ATM will verify the card validity in less than 3 seconds. PB007 Software Engineering I — Requirements Specification, Use Case Diagram6 Why do we distinguish between them? ̶ Taxonomy ̶ Functional requirements are modelled in this course ̶ It is relatively easy to do so ̶ Easy to have an overview what is done and what needs work ̶ Non-functional requirements are tougher ̶ Could be hidden ̶ Could be forgotten ̶ Could require specialized test cases, or approaches PB007 Software Engineering I — Requirements Specification, Use Case Diagram7 Use Case Diagram ̶ Use Case Diagram is a method to capture FUNCTIONAL requirements in graphical way. ̶ A.K.A. The most important UML diagram [citation needed] ̶ It consists of: ̶ System boundary ̶ Actors ̶ Use cases ̶ Relationships PB007 Software Engineering I — Requirements Specification, Use Case Diagram8 Example Use Case Diagram PB007 Software Engineering I — Requirements Specification, Use Case Diagram9 Actors Use Case Diagram ̶ A role that represents some external entity ̶ External with respect to system ̶ Directly communicate with the system ̶ They are not a single specific person ̶ On the other hand, a specific person can act as multiple actors, which could change over time ̶ Actor must have meaningful name ̶ Actor should have short description PB007 Software Engineering I — Requirements Specification, Use Case Diagram10 How to identify actors Use Case Diagram ̶ Who or what uses the system? ̶ What role they have in the interaction? ̶ Are there any other systems involved? ̶ Who/what sends/receives data to/from the system? ̶ Are there any events occurring periodically? PB007 Software Engineering I — Requirements Specification, Use Case Diagram11 Use Cases Use Case Diagram ̶ Describes an interaction between the system and external actors. Actions that actors perform in the interaction. ̶ Use case always begins with some action initiated by actor (primary actor) ̶ Other actors might join this interaction (secondary actors) ̶ Use cases are described from actors' point of view ̶ The name should represent an activity or behaviour PB007 Software Engineering I — Requirements Specification, Use Case Diagram12 How to identify actors use cases Use Case Diagram ̶ What systems’ functions in required by a particular actor? ̶ Does the system store or retrieve some data? Who triggers it? ̶ What is happening when a system state changes? Are actors notified about it? ̶ Are there any external events that affect the system? What alerts the system about these events? PB007 Software Engineering I — Requirements Specification, Use Case Diagram13 How to model it Use Case Diagram ̶ Recommended steps: ̶ Define the system boundary ̶ Find actors ̶ Find use cases ̶ Determine relationships between actors and uses cases ̶ Specify use cases in detail PB007 Software Engineering I — Requirements Specification, Use Case Diagram14 Work, work In this seminar… ̶ Activity – Functional & Non-functional requirements ̶ Visual Paradigm demo ̶ Team work on project ̶ Use case diagram PB007 Software Engineering I — Requirements Specification, Use Case Diagram15 You gotta do what you gotta do Task for this week ̶ Create a list of functional and non-functional requirements as a numbered list in the use case diagram specification ̶ Order the functional requirements according to the user roles ̶ Formulate 3 non-functional requirements (make them up) ̶ Based on the requirements list, create initial use case diagram ̶ Meaning actors, use cases and communication associations between them ̶ Look for gaps in the project specification and ask about information you are missing. ̶ Do your part in peer review ̶ Link to roster is in study materials