Chapter 4: Requirements Elicitation:
This activity happens to be the most important pertaining to software engineering. If the
application is very small and simple (example, writing a small program for a school
assignment) one may not go into a lot of details because such projects are simple and may
not require many different inputs and operations. However, developing large applications
for clients do require detail study into the use of the application and the users who would
be using the system as well as where the system will be installed (the hardware –
platform - for operation).
Thus requirement elicitation is about communication between the users (including the
clients) and the developers. This communication enable the developers to understand the
users environment as well as knowing exactly what the users need and want. Failure to
communicate may lead to a faulty system that may not have all of the functionalities
required by the users. Also such failures can be costly to correct.
So requirements elicitation focuses on describing the purpose of the system. The focus is
mainly on the users view of the system. Requirement elicitation thus involves the
following:
1. Identifying actors: Developer identifies the different types of users the future system
will support.
2. Identifying scenarios: Developers observe users so as to develop detail scenarios of
different functionalities of the system.
3. Identifying use cases: Developers derive from the scenarios the use cases.
4. Refining use cases: Developers ensure that the system specification is complete by
detailing each use case.
5. Identifying relationships between use cases: Developers consolidate the use case by
eliminating any redundancies.
6. Identifying nonfunctional requirements: Developers (and users) look for any
requirements that were not functional but of importance to the system such as
performance requirements, documentation, etc.
During this phase of development, the developers interact most with the clients and users
with the intention of obtaining information that would explain the functional
requirements, nonfunctional and pseudo requirements, levels of description, correctness,
completeness, consistency, clarity and realism, verifiability and traceability and
greenfield engineering, reengineering and interface engineering.
1
Functional Requirements:
Describe the interactions between the system and its environment independent of its
implementation. The environment would include the user and any other system that may
interact with the new system. (Pp. 125).
Nonfunctional and Pseudo Requirements:
The nonfunctional requirements include such things as performance – how fast the
system reacts to user requests, how precise the output is (especially numerical). The
SatWatch example on page 127.
Pseudo requirements are imposed by the client. They may require that the system be
developed in a particular language for a specific platform, etc.
Levels Of Description:
The use cases and scenarios should not only describe the system and users but should
also consider the operating environment. Also the operating environment could change
which would obviously affect the system, especially if the system takes some time to
develop and considering the rapid development of new technologies. They should look at
the following 4 levels of description:
1. Work division: Describes the work processes of the users the will use the system
2. Application-specific system functions: Describes the functions of the system in the
application domain.
3. Work-specific system functions: Describes supporting functions of the system such
as management function, grouping functions, etc.
4. Dialog: Interaction between the users and the user interface.
Correctness, Completeness, Consistency, Clarity and Realism:
There must be continuous dialog between the client and the developer, especially before
any code is written. The coding should only be begun after the designs have been
established to be all of the above. That is, the design must completely, etc. reflect the
requirements. (pp. 128)
Correctness and completeness are difficult to verify before the system is actually built.
However, by reviewing the specification carefully (including the use cases and
scenarios), with the client, one can “fairly confidently” conclude if the system that is to
be developed would be correct and complete. Often, this could be augmented with
prototype demonstrations.
2
Verifiability and Traceability:
Verifiable if after the system is designed; it could be tested repeatedly with various data
to prove that it fulfills the requirements.
Traceable if each function can be traced to its corresponding set of requirements.
Greenfield Engineering, Reengineering, and Interface Engineering:
Greenfield Engineering – developing a system from scratch.
Reengineering – redesign and re-implement an existing system.
Interface Engineering – redesign of the user interface of an existing system.
Requirements Elicitation Activities:
1. Identifying actors. Pages 130-132. Same actor can figure in two or more use cases!
2. Identifying scenarios. Pages 132 - 134
3. Identifying use cases. Pages 135 – 137.
4. Refining use cases. Pages 138 - 139.
5. Identifying relationships among use cases. Pages 140 - 143
6. Identifying participating objects. Pages 143 - 146
7. Identifying nonfunctional requirements. Pages 146 – 147
Guide to writing use cases:
 Use case should be named with verb phrases. The name of the use case should
indicate what the user is trying to accomplish. Page 137
 Actors should be named with noun phrases.
 The boundary of the system should be clear i.e. the steps accomplished by the
actor should be distinguished from the steps accomplished by the system.
 The causal relationship between successive steps should be clear.
 See the hand out for more details.
Heuristics for developing scenarios and use cases. Page 139.
Refining use cases:
Give a much more detailed description of the use case. Examples on page 45 gives the
first version of the ReportEmergency use case and page 138 gives a refined version. This
3
also includes functionality that was not already covered by use cases and scenarios –
developers may now add new use cases and scenarios or may even drop some that
already exist.
Identify relationships between actors and use cases:
Differentiate between the initiating actor and other actors. This would help not only to
develop the use case diagrams but also the sequence diagram (interaction diagram).
Use extend to display extended relationship making sure that the original use case and the
extended use cases are different but could be used in conjunction to show extension of
the base use case. The example on pages 140 –141 explains this.
Identifying participating objects (analysis objects):
Both users (client) and developers must agree on terms that are used in the documents
produced and a record kept of all terms used.
Participating objects are identified from each use case, and this results in the initial
analysis model.
Identifying initial Analysis Objects:
When we have several subgroups (or even many people in the same group) working on a
project, terminology can create problems. Different groups may use the same term to
mean different things or the other way around.
So to establish clear terminology, developer need to identify participating objects from
each use case.
Nonfunctional requirements:
This involves issues from security, interface development, response time, etc. Page 147
.
Managing Requirements Elicitation:
Knowledge Analysis of Tasks (KAT):
1. Identify objects and actions: Interview the task performer, check documents, etc.
2. Identify procedure: A set of actions with precondition to trigger the action and a
postcondition. May be ordered or unordered.
3. Identify goals: Identified through interviews during or after the performance of a task.
4. Identify typicality and importance: Identified elements are rated according to their
importance in accomplishing tasks.
4
5. Construct a model for task: The information gathered above will enable the creation
of a task model.
Joint Application Design (JAD):
Involves meeting between the developers, users and clients.
Usability Testing:
Done to find problems with the system or part of the system. Generally done under
controlled conditions. The focus is on ease to learn the system, time to accomplish a task,
or the rate of errors a user makes when accomplishing a task. The goal of usability test is
to obtain qualitative information on how to fix usability problems.
5