The document discusses use case modeling for requirements gathering and documentation. It defines key use case concepts like actors, use cases, and how to identify them. Actors represent anything external to the system and use cases represent tasks or goals actors want to accomplish through interactions with the system. The document provides questions and examples to help identify actors and write use cases from the user's perspective to effectively capture requirements.

1. Writing Requirements the Use-Case Way Sreeram Kishore Chavali

2. What can go wrong in a product: examples Rich in Features Poor in presentation Interface Not intuitively designed Usability issues

3. Appeal Do not ever compromise at requirements stage Be Aggressive in specifying User Requirements (we are not stating our requirements) Always have the user in mind Don’t get tied down by technology alone. Technology is changing fast.

4. Need for Change Increased competition New Technologies changing systems user should be thrilled and excited and not just satisfied Plan for on-line usage not off-line usage Think differently Do things differently

5. Collecting User Requirements Identify users Identify their roles, responsibilities and needs Asking users is not enough observing user in action only can give complete picture of what he needs. User - Task Analysis Define Problem Statements

6. Use Case Model Use-Case Model is a model of the system’s intended functions (use cases) and its surroundings (Actors) The same use-case model is used in requirements analysis, design and test The use case model’s primary purpose is to communicate the system’s functionality and behavior to the customer or end user

7. Actor An actor represents anything that interacts with the system Actors are not part of the system, they represent roles a user of the system can play An actor may actively interchange information with the system An actor may be a passive recipient of information

8. Actor An actor can represent a human, a machine or another system.

9. Finding Actors: useful questions Who is interested in a certain requirement? where in the organization is the system used? Who will supply the system with the information, use this information, remove this information who will use this function

10. Finding Actors: useful questions Does the system use an external resource? What actors do the use cases need? Does one actor play several different roles? Do several actors play the same role?

11. Use Cases A use case model is a dialogue between actors and the system A use case is initiated by an actor to invoke a certain functionality in the system A use case is a complete and meaningful flow of events Taken together, all use cases constitute all possible ways of using the system.

12. Finding Use Cases: Useful Questions What are the tasks of the actor? Will the actor create, store, change, remove or read information in the system? What use case will create, store, change, remove, or read, this information? Will the actor need to inform the system about sudden, external changes?

13. Finding Use Cases: Useful Questions Does the actor need to be informed about certain occurrences in the system? Does the system supply the business with the correct behavior? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases?

14. Who Reads Use-Case Documentation? Customers - approve what the system should do Users - gain system understanding system developers- document system behavior reviewers - examine the flow of events system analysts (designer) - provide the basis for analysis and design

15. Who Reads Use-Case Documentation? System Tester - used as a base for test cases Project Leader - provide input to project planning Technical Writer - Basis for writing the user’s guide.

16. Example:Time Tracking System User will create a task. User will update the task status by entering the efforts spent against each task, for each date Actors are not identified Talks from system Perspective

17. Example: Use Case Approach Actors:Team Managers, Team Members, Department Heads Team Managers will use the system to assign a task to subordinate. Team Member will view the task and update the task status by specifying the details of the task execution

18. Use Case Model (Contd..) Department head will access the system to view projects status in his domain.

19. Summary and Suggestions Always identify Actors Prepare Actor - Attributes, Profiles, Responsibilities Identify Goals of each Actor Arrive at Actor - Tasks, sub-tasks While specifying requirements use Actor names Make Language User Oriented in all concept documents and requirements

20. Summary and Suggestions It is not necessary to use tools alone to document use-cases. It is the language used that is going to make the difference.