Writing Requirements the Use-Case Way Sreeram Kishore Chavali

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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