Log in / Register
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

Use Cases: A Tool for Requirements Gathering

One form of requirements documentation is called a use case,[1] which is a complete course of events initiated by a primary actor. Actors may be people, functional roles, or interfacing systems that interact with the enterprise (or system) under study. One or more use cases are developed for each actor to allow for scenario development and testing under different conditions. There are two levels of use cases: Business use cases describe the business process, and system use cases describe the interaction of one or more actors and the system to be developed.

Use cases are valuable to allow business personnel and technical creation teams to define and refine requirements in terms that are understood by all stakeholders.

(At a large telecommunications company, we taught the businesspeople to write use cases and thus the use cases were understandable to both other businesspeople and the IT development team with few questions.) Use cases specify the interaction that takes place between the actor and a business process[2] (whether automated or not).

The use-cases technique is designed to capture user needs early and fast. Enterprise requirements are captured in a form both businesspeople and developers find engaging. They can also serve as a chain of evidence from requirements to value delivered and are useful in consensus building, training, and quality testing, as discussed in Chapter 10.

Use Cases within Privacy Engineering

Another added benefit of employing use cases to add to the privacy engineering methodology is that management teams and developers can readily understand them and, in fact, have more than likely created use cases in other contexts. Here, we apply privacy requirements to this type of systems' engineering lifecycle methodology.

In addition to creating a cohesive design plan with integrated requirements, use cases can also be used to start to understand how system interfaces actually function and perhaps how a “feature” may act as a bug in practice to introduce unwanted risk or faulty controls according to the privacy policy requirements based on FIPPS/ISO or other relevant standards.

It should be noted that the development of use cases in this context also acts to lower the probability that bad data risk will have significant overall impact. Employing use cases allows the design team to role play potential risk and value scenarios and test various game theories to create policy requirements, education, and processes, thus avoiding another pitfall. Here, the expected people, process, or technology running within the use case should reveal where the anticipated design or feature leaves a gap or creates an unexpected value. Regulators will also be looking for documented scenario testing or gaming to determine where risks are contemplated and planned before data collection and processing. [A UK example: Fines pursuant to breaches found by the ICO[3] where no scenario testing or game play was undertaken by the data controller.]

  • [1] We will see later that the class or data model is another form of requirements documentation.
  • [2] Here, business process is any activity performed in furtherance of the goals or objectives of an enterprise. Business processes operate in any type of system or organization and are not limited to private commercial businesses.
  • [3] The Information Commissioner's Office (ICO) is the United Kingdom's independent authority set up to uphold information rights in the public interests, promoting openness by public bodies and data privacy for individuals. Each European Union member-state has a similar body to enforce the country-level requirements implemented after the 95/EC/ Data Protection Directive.
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
Business & Finance
Computer Science
Language & Literature
Political science