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.
  1. Identifying scenarios: Developers observe users so as to develop detail scenarios of different functionalities of the system.
  1. Identifying use cases: Developers derive from the scenarios the use cases.
  1. Refining use cases: Developers ensure that the system specification is complete by detailing each use case.
  1. Identifying relationships between use cases: Developers consolidate the use case by eliminating any redundancies.
  1. 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.

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
  1. Application-specific system functions: Describes the functions of the system in the application domain.
  1. Work-specific system functions: Describes supporting functions of the system such as management function, grouping functions, etc.
  1. 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.

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!
  1. Identifying scenarios. Pages 132 - 134
  1. Identifying use cases. Pages 135 – 137.
  1. Refining use cases. Pages 138 - 139.
  1. Identifying relationships among use cases. Pages 140 - 143
  1. Identifying participating objects. Pages 143 - 146
  1. 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 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.
  1. Identify procedure: A set of actions with precondition to trigger the action and a postcondition. May be ordered or unordered.
  1. Identify goals: Identified through interviews during or after the performance of a task.
  1. Identify typicality and importance: Identified elements are rated according to their importance in accomplishing tasks.
  1. 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.

1