Use Cases

Imagine fictitious people who want to use your product.
Who are they? What are their goals for your product?
We can describe each user and goal in a "Use Case".

Here are some examples of users and goals for education software:

• Students want to participate in a lesson, answer test questions, and send in homework.
• Teachers want to take attendance, assign lessons, view students' progress, and grade tests.

What should be in a use case?

• Brief Description: a paragraph that describes who interacts with the use case, what happens, when, etc.
• Normal Flow of Events: the typical steps that happen
• Alternate Flow(s) of Events: any atypical steps, unusual variations, odd cases, or errors
• Special Requirements
• Pre-Conditions
• Post-Conditions
• Extension Points

To improve your use case

Iteratively add more detail to the outline to specify the steps of the use case.

• Each step should clearly state who is performing the action and the result of the action
• For loops, you can use phrasing like: "User can continue adding items until he indicates he's done."
• Beware of "if... then..." phrase because it is harder to follow. Instead, consider using an alternate flow
• Question to ask: Is there enough information specified to complete the system analysis, design and test?

You are done when the use case has a complete flow of events, has terminology described in a support glossary and defines all inputs to and outputs from the use case.

To make your use case easier to read

• Formal: you describe in third person, e.g. "Student signs in. Student edits his profile. Student chooses a classroom."
  Easier: you decribe in first person, e.g. "I sign in. I choose a classroom. I edit my profile."
• Formal: you describe what the system does, e.g. "The system retreives a list of classrooms."
  Easier: you describe what the user sees, e.g. "I see a list of classrooms."
• Formal: passive voice, e.g. "The Add Course use case is initiated by the Student."
  Easier: active voice, e.g. "I initiate the Add Course use case."

To descibe you user interface

Put your user interface details in a separate document.

• Use visual or even physical mock-ups to describe UI
• Describe navigation using storyboards
• UML class and sequence diagrams are great aids here

To describe your data validations

Put your data validations in a separate document.

• "Student identification numbers are numbers that are used to verify that a student is eligible to register for courses."
• "The student indentification number must be unique."
• "The student identification number must be 6 to 8 alpha-numeric characters."

Example Use Case

Title: Student creates a course schedule Primary Actor: Student Secondary Actor: Course Registration System Brief Description:

• A student wants to choose course for a specified semester.

Normal Flow

• I sign in. (Detailed in diferent use case)
• I see choices: Create A Schedule, Modify A Schedule, Delete A Schedule.
• I choose Create A Schedule.
• I see choices: Fall Semester, Spring Semester, Summer Semester.
• I choose Fall Semester.
• I see a list of available fall semester courses from the Course Catalog System.
• I can sort the list by the course titles and classroom locations.
• I can add and delete courses as desired.
• I choose to submit my schedule.

Alternate Flows

• I can choose to cancel at any time.
• Course is full.
• Course is cancelled.
• Course registration date has passed.
• Any other error.

---

What's Next?

• Index Of Articles: Web Design & Development
• Functional Specifications Template
• Functional Specifications Tutorial
• Statement Of Work
• Wireframes

blog comments powered by Disqus