1

Requirements Elicitation

Lectures 10 & 11

2

References

• Chapter 4: Requirements Elicitation from Object Oriented Software Engineering: Conquering Complex and Changing Systems.

3

Introduction• Requirement is a feature that the system must

have or a constraint that it must satisfy to be accepted by a client.

• Requirements engineering aims at defining the requirements of the system under consideration.

• Requirements engineering consists of two main activities– Requirements Elicitation

• Results in the specification of the system that the client understands

– Analysis• Results in a model that the developers can

unambiguously interpret.

4

Tools to Bridge the Knowledge Divide

• Clients and users are domain experts.• Developers have knowledge to build systems.• Scenarios and use cases are used to bridge

the knowledge gap.• Scenarios describe examples of system use in

terms of series of interactions between the user and the system.

• Use cases are abstractions that describe classes of scenarios.

• Developers and clients should be able to understand both.

5

Requirements Elicitation

• Successful requirements elicitation depends upon communication between clients and developers.

• Imperfect and error prone communication results in an unusable and/or useless system.

• Erroneous requirements– Are expensive to correct.– Are discovered late during the development stage.– May require significant changes in the developed

system.

6

Requirements Elicitation(Contd.)

• Requirements elicitation focuses on describing the purpose of the system.

• Allows the development of system specifications,– Identification of problem area and definition of a

system to solve the problems.

• System specification is structured and formalised during analysis to produce an analysis model.

• System specification and analysis model represent the same information with different notations and language.

7

Requirements Elicitation(Contd.)

• System specification supports the communication between clients and developers.

• Analysis model supports the communication among developers.

• Both models represent external aspects of the system and therefore occur concurrently and iteratively.– Both models focus on the user’s view of the system.

• Aspects of the system that are not directly visible to the user do not form a part of the requirements.

8

Requirements Elicitation Activities• Identification of actors

– i.e., different types of users the future system will support.

• Identification of scenarios– i.e., examples of future system in use.

– Developers use scenarios to communicate with users to enhance their understanding of the problem domain.

• Identification of use cases– Transformation of scenarios into use cases that

completely represent the future system.

– Use cases are abstractions determining the complete scope of the system.

9

Requirements Elicitation Activities(Contd.)

• Refinement of use cases– Developers ensure that the functionality of the

system is complete.– Involves detailing each use case and describing the

behaviour of the system in the presence of errors and exceptions.

• Identification of relationships between use cases– Consolidation of use case model through

elimination of redundancies.– Ensures the consistency of system specification.

10

Requirements Elicitation Activities(Contd.)

• Identification of nonfunctional requirements– Developers, clients and users agree on aspects that

are visible to the system but not directly related to the functionality.

– e.g.,• Constraints on performance of the system.• Documentation.• Resources consumed by the system.• Security• Quality

11

Information used in Elicitation

• Client supplied documents about the application domain.

• Manuals and technical documentation about the legacy system.

• Documentation on users and clients,– Qualifications,– Roles,– Tasks,– Resources

12

Elicitation Methods

• Joint Application Design (JAD)– Focuses on building consensus among developers,

users and clients by jointly developing the system specification.

• Knowledge Analysis of Tasks (KAT)– Focuses on eliciting requirements from users

through observation.

• Usability Testing– Focuses on validating the requirements elicitation

model with the user through a variety of methods.

13

Functional Requirements• Describe the interactions between the system

and its environment independent of its implementation.– Environment includes

• Users• Any other system that the system being developed has

to interact with.

• This description does not focus on any of the implementation details– E.g., processor, language, display technology.

14

Functional Requirements: ExampleDistributed flight planning and scheduling system. It is supposed to be an online system involving an interaction between a central CAA server that will maintain data on flight corridors, a meteorological server that contain data on weather information at flight terminal (i.e., airfields) and individual flight terminal servers that contain information on airfield status, rescue and crash facilities, emergency services, etc. on that particular airfield. Once a pilot submits a request for a flight plan indicating the flight terminals and the tentative start and end times of the flight, the system collects flight corridor information, enroute and terminal weather conditions and terminal status and provides the following information to the pilot for every flight corridor that is available,a.Waypoints,b.Altitude for each leg,c.Tentative start time and end time,d.Alternative emergency terminals for each leg,e.Weather information for each leg and at terminals. The pilot can select one flight plan that corresponds to the flight corridors specified by the system. This system should be web-enabled and can be integrated with an IVR (Integrated voice response) enable call center where people can dial for flight enquiries.

15

Non-Functional Requirements

• Describe user visible aspects of the system that are not directly related to the functional behaviour of the system.

• May include– Quantitative constraints

• E.g., response time, throughput, etc.

– Accuracy

16

Pseudo Requirements

• Requirements imposed by the client that restrict the implementation of the system.

• Typical pseudo requirements– Implementation platform– Programming language

• For life-critical systems, pseudo requirements include process and documentation requirements.

• Usually have no direct effect on the user’s view of the system.

17

Levels of Description of Requirements

• Work Division– Set of use cases describing the work processes of

the users that are relevant to the system.

• Application Specific System Functions– Set of use cases describing the application domain

related functions that the system provides.

• Work Specific System Functions– Set of use cases describing supporting functions.

• Dialog– Set of use cases describing the interaction between

the users and user interface of the system.

18

Requirements Validation• Requirements are continuously validated with

the clients and the users.

• Validation is a critical step in the development process,– Both the client and the developer are dependent on

system specifications.– Involves checking if the specification is

• Correct• Complete• Consistent• Unambiguous• Realistic

19

Requirements Validation(Contd.)

• Correctness– A specification is correct if it is correct if it represents a

client’s view of the system.

• Completeness– A specification is complete if all possible scenarios

through the system including exceptional behaviour are described.

• Consistency– A specification is consistent if it does not contradict

itself.

20

Requirements Validation(Contd.)

• Clarity– A specification is unambiguous if cannot be

interpreted in ways more than one.

• Realism– A specification is realistic if the system can

be implemented within constraints.

21

Requirements Verifiability and Traceability

• Verifiability– A specification is verifiable if, once the system is built, a

repeatable test can be designed to demonstrate that the system fulfils the requirement.

• Traceability– A system specification is traceable if each system can

be traced to its corresponding set of requirements.– Traceability is not a constraint of the content of the

specification but on its organisation.– Traceability facilitates the development of tests and the

systematic validation of the design against requirements.

22

Greenfield Engineering• Development starts from scratch.

• No prior system exists.

• A greenfield project is triggered by a user need or the creation of a new market.

• Requirements are extracted from users and clients, i.e., the application domain.

23

Reengineering

• Redesign and reimplementation of the existing system triggered by technology enablers or by new information flow.

• Sometimes the functionality of the new system is extended when the essential purpose of the system remains the same.

• Requirements for the new system can be extracted from an existing system.

24

Interface Engineering

• Redesign of the user interface of an existing system.

• Only the user interface of the legacy system is changed.

• The legacy system cannot be discarded without entailing a high cost.

25

Actors• Actors represent external entities that interact

with the system and exchange information.

• Actors define classes of functionality.

• Actors are role abstractions and do not necessarily directly map to persons.

• The functionality each actor accesses is substantially different from the functionality of other actors.

26

Identifying Actors• Identification of actors in a system is the first

step in requirements elicitation.

• Identification of actors is used to – define the boundaries of the system, – to find all the perspectives from which the

developers need to consider the system.

• When a system is developed for an existing organisation, most actors usually exist before the system is developed.– They correspond to roles in the organisation.

27

Identifying Actors(Contd.)

• Who are the actors?– User groups that are supported by the system to

perform their work.– User groups that execute the system’s main functions.– User groups that perform secondary functions.

• E.g., maintenance, administration.– Any external hardware or software that the system

interacts with.

• After identifying the actors, functionality accessible to each actor is to be determined.– This information is extracted using scenarios and

formalised using use cases.

28

Example: Actors

• FRIEND: a distributed system for accident management.

• Actors– FieldOfficers: represent police and fire officers who

respond to an incident.– Dispatchers: police officers responsible for

answering 911 calls and dispatching resources to an incident.

• Actors interact with the system through different interfaces.

29

Example: Actors(Contd.)

FRIEND

FieldOfficer Dispatcher

30

Scenarios• A scenario is a narrative description of what

actors do and experience as they try to use computers and applications.

• A scenario is a concrete, focused and informal description of a single feature of the system from the viewpoint of a single actor.

• Scenario focus around the work that the system performs rather than the system itself.

• Scenarios are open-ended and informal, and cannot completely replace traditional approaches.

31

Types of Scenarios• As-is Scenario

– Used to describe a current situation.

– Based on the observation of users and their actions.

– Validated for correctness and accuracy with the users.

• Visionary Scenarios– Describe a future system, either reengineered or

designed from scratch.

– Used both as • Coarse design representations• Communication mechanism to elicit requirements from

users

– Can be viewed as inexpensive prototypes.

32

Types of Scenarios(Contd.)

• Evaluation Scenarios– Describe user tasks against which the system is to

be evaluated.– Collaborative development by users and

developers also improves the definition of the functionality tested by these scenarios.

• Training Scenarios– Tutorials used for introducing new users to the

system.– Step by step instructions designed to hand-hold the

user through common tasks.

33

Identifying Scenarios

• Developers and users write and refine a series of scenarios to gain a shared understanding of the system.

• Initially each scenario may be high level and incomplete.

• Scenarios should be documented in application domain related terminologies.

• Scenarios can be incrementally and iteratively refined to include increasing amounts of details.

34

Identifying Scenarios(Contd.)

• What are scenarios– Tasks the actor wants the system to perform.– Information and the manner in which it is accessed.– External changes the actor needs to inform the

system about.– System events that need to be notified to the actor.

• Actor and scenario identification allows developers to understand the application domain.

• Scenarios are formalised into use cases.

35

Example: ScenarioScenario Name WarehouseOnFire

Instances of Participating Actors

Bob, Alice: FieldOfficer

John: Dispatcher

Flow of Events 1. Bob notices smoke from warehouse. Alice uses FRIEND laptop to report emergency.

2. Alice enters the address of the warehouse and requests rescue facilities via FRIEND.

3. John alerted to the emergency via audio alarm on his workstation. Reviews information sent by Alice and acknowledges it. Allocates rescue facilities requested and confirms their ETA to Alice.

4. Alice receives the acknowledgement and ETA on FRIEND laptop.

36

Use Cases

• A scenario is an instance of a use case.– A use case specifies all possible scenarios for a given

aspect of functionality.

• A use case is initiated by an actor.

• After its initiation, a use case may interact with other actors as well.

• A use case represents a complete flow of events through the system.– A series of related interactions is described that results

from the initiation of the use case.

37

Example: Use CaseUse case name ReportEmergency

Participating actor

Initiated by FieldOfficer

Communicates with the dispatcher

Entry condition 1. The FieldOfficer activates the “Report Emergency” function of his/her terminal.

Flow of Events 2. FRIEND responds by presenting a form to the officer.

3. The FieldOfficer fills the form, by selecting the emergency level, type, loaction and brief description of the situation. The FieldOfficer also describes possible responses to the emergency situation. When completed, the FieldOfficer submits the form, at which point the Dispatcher is notified.

38

Example: Use Case (Contd.) 4. The Dispatecher reviewas the submitted

information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher selects a response and acknowledges the emergency report.

Exit condition 5. The FieldOfficer receives the acknowledgement and the selected response.

Special requirements

The FieldOfficer’s report is acknowledged within 30 seconds. The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

39

Heuristics for writing scenarios and use cases

• Use scenarios to communicate with users and to validate functionality.

• First, refine a narrow vertical slice(i.e. one scenario) to understand the user’s preferred style of interaction.

• Next, define a horizontal slice(i.e. many not very detailed scenarios) to define the scope of the system. Validate with the user.

• Use mock-ups as a visual support only; user interface design should occur as a separate task once the functionality is sufficiently stable.

40

Heuristics for writing scenarios and use cases (Contd.)

• Present the user with multiple alternatives(as opposed to extracting a single alternative from the user).

• Detail a broad vertical slice when the scope of the system and the user preferences are well understood. Validate with the user.

41

Identifying Relationships among Actors and Use Cases

• Relationships among actors and use cases enable the developers and users to reduce the complexity of the model and increase its understandability.

• Communication relationships between actors and use cases are used to describe the system in layers of functionality.

• Relationships are extended to separate exceptional and common flows of events.

• Include relationships between use cases reduces redundancy among use cases.

42

Communication Relationship between Actors and Use Cases

• Used to represent the flow of information during the use case.

• The actors initiating the use case should be distinguished from other actors the use case communicates with.– Access control can be represented at this level.

• Relationships between actors and use cases are identified when use cases are identified.

43

Communication Relationships among Actors and Use Cases:

Example

44

Extend Relationship between Use Cases

• A use case extends another use case if the extended use case may include the behavior of the extension under certain conditions.

• Advantages of separating exceptional and optional flows of events from the base use case are– Base use cases become shorter and easier to

understand.– Common case is distinguished from exceptional

enabling the developer to treat each type of functionality differently.

45

Extend Relationship between Use Cases (Contd.)

• Base use cases and exceptions are complete use cases.– Both have entry and exit conditions.

– Both are understandable by the user as an independent whole.

46

Extend Relationship: Example

47

Include Relationship between Use Cases

• Used to factor out redundancies among use cases.

• Advantages of factoring out shared behavior from use cases are– Shorter descriptions

– Fewer redundancies

• Behavior should only be factored out into a separate use case if it is shared across two or more use cases.

• Excessive fragmentation of system specification over a large number of use cases makes the specifications confusing to user and clients.

48

Include Relationship: Example

49

Extend Vs. Include Relationships

• Similar but confusing constructs.

• Main distinction is the direction of the relationship.

• In the includes relationship conditions under which the target use case is initiated are described in the initiating use case.

• In the extends relationship, the conditions under which the extension is initiated are described in the extension as an entry condition.

50

Non Functional Requirements• Describe user-visible aspects of the system not

directly related to the functional behavior of the system.

• Span a number of issues, e.g.,– User interface look and feel– Performance issues– Security

• Should be defined with the functional requirements as they have an impact on the development and cost of the system.

51

Non Functional Requirements (Contd.)

• After identification and description, these requirements are to be prioritized.

• Some non functional requirements need to be incorporated to enable the system to operate correctly.