1.1 Elicitation of Requirements

Allows S.E. to discover the requirements of a software.

Scenarios

“A narrative description of what people do and experience as they try to make use of computer systems and applications”… basically they are a concrete, focused, informal description of a single feature of the system to be.

➡️ Example of scenario:

Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from her car. Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appears to be relatively busy. She confirms her input and waits for an acknowledgment. John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated time of arrival (ETA) to Alice. Alice received the acknowledgment and the ETA.

This is a concrete scenario: it does not describe all possible situations in which a fire can be reported.

Because of this an abstraction from details and specificities must be done: use cases are produced following this operation.

Use cases formulation

Starting from a scenario, structure the description in terms of:

• Participating actors → describe who the users of the software are going to be

• Describe the Entry Condition → describe the situation(s) that make the actors interface with the software

• Describe the Flow of Events → describe the interactions that are done with the system

• Describe the Exit Condition → describe the event(s) that stops the usage of the system

• Describe Exceptions → describe the special cases and events in which the system is used

• Describe Special Requirements (Constraints, Nonfunctional Requirements)

Tips to define good use cases

• Use cases named with verbs that indicate what the user is trying to accomplish

• Actors named with nouns

• Use cases steps in active voice

• The causal relationship between steps should be clear

• A use case per user transaction

• Separate description of exceptions

• Keep use cases small (no more than two/three pages)

• The steps accomplished by actors and those accomplished by the system should be clearly distinguished
  • This helps us in identifying the boundaries of the system