Group Project - Use Case Model

Now that your document's Section 1 has laid out a vision for your project the next planning stage as part of Requirements Engineering is to determine all the ways your actors will interact with your system. This is Section 2. Note that one important thing to remember is you want to figure out the best ways for your users to interact with your system. Don't forget that. When writing descriptions for Use Cases, which can be tedious, it can lead to losing sight of the forest for the trees, meaning one can forget what the big picture is, how the pieces fit together, and how they together serve the broader goals for the application. So remember never to lose sight of that and continue to question and revise your Use Case descriptions in order to refine them to represent your broader vision.

In this assignment you will continue to create content for your project document, extending what you did in the Systems Analysis assignment. Your systems analysis was Section 1. Your Use Cases descriptions will be Section 2. Note that in the next assignment, Section 3, you will be creating your user interface mockup diagrams. Remember, for now, we are putting the content for each section in a separate document in your shared drive directory.

Section 2: Use Case Descriptions

Your Section 2 should provide a complete list of all needed use cases, meaning it describes all the ways you plan for your users to interact with your application. Note that you should create two subsections:

• 2.1 Use Case Listing - Provide a table with three columns that includes a complete, ordered list of all of your application's use cases.
  • Use Case # - should list the unique use case number (i.e. 2.1, 2.2, etc.)
  • UI Context - where does it take place? For example, one might list Profile Screen as the UI Context for a use case involving changing a profile picture
  • Use Case Name - each use case should have a unique, descriptive name
  
  
  
• 2.2 Use Case Descriptions - provide a detailed, formal Use Case description for every one of your use cases. Use the following format to describe each use case:
  
  

  Number:	Should be the same number you listed in the Use Case Listing, something like 2.x, note that these tables should be properly ordered according to their numbers.
  Name:	This brief label should be unique and should adequately describe the interaction so that a developer reading your document may easily scan and find it by name and have good idea what it is.
  Actor(s):	You definied the types of actors in your System Analysis. For each Use Case you should simply list those that will employ each use case.
  Story	Provide a numbered, step by step description of how the user will interact with the system in order to properly complete the use case. The story should include specific user interface components and interactions, like buttons and left-mouse clicks.
  Scenario	A scenario uses sample data to provide an instance of a story. All data entry and selection should be described here with data that might be used in your application for a user interaction.
  Exceptions	Specify the special cases that must be handled in order to prevent application failure.

  
  

Note, this is not an easy assignment, you are having to envision all the ways your users will be interacting with your application.

Handin Instructions

Each team should submit their Use Case Model PDF via Brightspace.

Grading

This assignment will be graded based on the thoroughness and quality of the submitted document. Does it adequately describe the vision for the team in sufficient detail? Is it well written using precise language? Does it include all required sections? Is it carefully organized?

---

Web page created and maintained
by Richard McKenna