ACTIVITY

Start up a document, call it "Requirements Specification for $x"$ where $x$ is the title of your system.

Also, place the following headers in the document to be filled out:

Overview

Description

Actors

Security Goals

Use Cases

Primary Actor

Preconditions

Main Flow of Events

$[$MisuselAbuse$]$ Case

Security Requirements

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.

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.

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.

Now write either a misuse case or abuse case $($your choice$)$ for that use case. A few notes:

Be sure to include both flow of events and harm done.

Make sure the flow affects your main flow, not your preconditions. You may violate a

precondition in the process, but this section is for demonstrating how you can abuse$/$misuse

the main flow.

Update the header to label each one as either Abuse or Misuse.

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.

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:

Add a list to the end of your requirements document that defines these security requirements.

Each security requirement should have a self$-$documenting identifier, e$.$g$.$ "Secl"

Add security requirement references to the step in the primary flows $($and alternative flows if

you added any$).$