Understanding User Requirements

1. Understanding User Requirements Prepared by: Mamdoh Omar Al-ghrauiz 120050265 Supervise: Eng.Tasneem Darweesh

2. Documenting Use Cases • At this stage of the exploration, the participants should be thinking of essential use cases. Constantine and Lockwood (1999) define an essential use case as "...a simplified, generalized, abstract, technology-free and implementation-independent description of one task or interaction...that embodies the purpose or intentions underlying the interaction.

3. Documenting Use Cases Cont.: • " That is, the focus should be on the goal the user is trying to accomplish and the system's responsibilities in meeting that goal. Essential use cases are at a higher level of abstraction than concrete use cases, which discuss specific actions the user takes to interact with the system. To illustrate the difference, consider the following two ways to describe how a user might initiate a use case to request a chemical: • Concrete  Enter the chemical ID number. • Essential  Specify the desired chemical.

4. Documenting Use Cases Cont. • The phrasing at the essential level allows many ways to accomplish the user's intention of indicating the chemical to be requested: enter a chemical ID number, import a chemical structure from a file, draw the structure on the screen with the mouse, select a chemical from a list, and others. Proceeding too quickly into specific interaction details begins to constrain the thinking of the use-case workshop participants. The independence from implementation also makes essential use cases more reusable than concrete use cases.

5. Documenting Use Cases cont. • The participants in the Chemical Tracking System workshops began each discussion by identifying the actor who would benefit from the use case and writing a short description of the use case. Then they defined the preconditions and postconditions, which are the boundaries of the use case; all use-case steps take place between these boundaries.

6. Documenting Use Cases Cont. • Estimating the frequency of use provided an early indicator of concurrent usage and capacity requirements. Next, the analyst asked the participants how they envisioned interacting with the system to perform the task. The resulting sequence of actor actions and system responses became the normal course. Numbering the steps made the sequence clear. Although each participant had a different mental image of the future user interface and specific interaction mechanisms, the group was able to reach a common vision of the essential steps in the actor-system dialog.

7. Documenting Use Cases Cont. • The analyst captured the individual actor actions and system responses on sticky notes, which he placed on a flipchart sheet. Another way to conduct such a workshop is to project a use-case template onto a large screen from a computer and complete the template during the discussion, although this might slow the discussion down.

8. Documenting Use Cases Cont. • After the workshop participants described each use case and no one proposed additional variations, exceptions, or special requirements, they moved on to another use case. They didn't try to cover all the use cases in one marathon workshop or to pin down every detail of every use case they discussed. Instead, they planned to explore the use cases in increments, and then review and refine them into further detail iteratively.

9. Documenting Use Cases Cont. • Figure 8-5 shows the sequence of events for developing the use cases. Following the workshop, the analyst wrote a detailed description of each use case like the description in Figure 8-6. There are two ways to represent the actor-system dialog steps, which is the heart of the use case. Figure 8-6 shows the dialog as a numbered list of steps, indicating which entity (the system or a specific actor) performs each step.

10. Documenting Use Cases cont. • The same notation is used to describe alternative courses and exceptions, which also show the step in the normal course at which the alternative branches off or where the exception could take place. Another technique is to present the dialog in a two-column table, as shown in Figure 8-7 (Wirfs-Brock 1993). The actor actions are shown on the left and the system responses on the right. The numbers indicate the sequence of steps in the dialog. This scheme works well when only a single actor is interacting with the system. To improve the readability, you can write each actor action or system response on a separate line so that the alternating sequence is clear, as shown in Figure 8-8.

11. Documenting Use Cases cont.

13. Use Cases and Functional Requirements • Software developers don't implement business requirements or use cases. They implement functional requirements, specific bits of system behavior that allow users to execute use cases and achieve their goals. Use cases describe system behavior from an actor's point of view, which omits a lot of details. A developer needs many other views to properly design and implement a system.

14. Use Cases and Functional Requirements cont. • Many functional requirements fall right out of the dialog steps between the actor and the system. Some are obvious, such as "The system shall assign a unique sequence number to each request." There is no point in duplicating those details in an SRS if they are perfectly clear from reading the use case. Other functional requirements don't appear in the use-case description. The analyst will derive them from an understanding of the use case and the system's operating environment. This translation from the user's view of the requirements to the developer's view is one of the many ways the requirements analyst adds value to the project.

15. Use Cases and Functional Requirements cont. • You can document the functional requirements associated with a use case in several ways. The approach you choose depends on whether you expect your team to perform the design, construction, and testing from the use-case documents, from the SRS, or from a combination of both. None of these methods is perfect, so select the approach that best fits with how you want to document and manage your project's software requirements.