Abuse & Misuse Cases


The purpose of this activity is to get you acquainted with writing abuse and misuse cases in tandem with writing use cases.


This activity is for groups of 4-6 people. Your instructor will assign each team a different system. For this exercise, your team is in charge of coming up with the system's functionality, as well as specifying the requirements. Please assign the following roles:


  1. Give your system a title. Start up a document on GoogleDocs (make sure it has edit sharing permissions with the instructor), call it "Requirements Specification for X" where X is will title of your system. Also, place the following headers in the document to be filled out:
  2. Conduct a requirements elicitation session with the customer. Document the main features of the system. The customer is in charge of brainstorming the functionality, but must be reasonable as the instructor can override any customer decision. The scribe takes informal notes from this meeting (no requirements just yet).
  3. Elaborate on the requirements by outlining two use cases and filling in the Overview section. What is the system, in general? What are the general security goals of the system? Who are the actors (both regular and malicious)? Write the titles of three use cases, and define the relevant actors for each use case. Don't write the scenarios just yet.
  4. Write the main flow for one use case. Make this about 4-10 steps. Be specific about what information is being exchanged. You may add alternative flows if you see the need, but they are not required for this exercise.
  5. Now write either a misuse case or abuse case (your choice) for that use case. A few notes:
  6. Sketch your other use cases (no need to be super-detailed on the use case). Write a detailed abuse or misuse case for each use case. Thus, your requirements document should have at least one abuse case and at least one misuse case, and three in total.
  7. Now that you have defined multiple different abuse and misuse cases, generalize those into security requirements that are not specific to any particular use-case, but are specific to your system. Document it this way:
  8. Be ready to discuss your abuse and/or misuse cases with the rest of the class.

Submission & Grading

Share your document with your instructor and course assistant. They will provide feedback on the document, but this will not be graded.