J.E.D.I
3.2.2 Elicitation
After inception, one moves onward to elicitation. Elicitation is a task that helps the customer define what is required. However, this is not an easy task. Among the
problems encountered in elicitation are discussed below:
1. Problems of Scope. It is important that the boundaries of the system be clearly
and properly defined. It is important to avoid using too much technical detail because it may confuse rather than clarify the systems objectives.
2. Problems of Understanding. It is sometimes very difficult for the customers or
users to completely define what they needed. Sometimes they have a poor understanding of the capabilities and limitations of their computing
environment, or they dont have a full understanding of the problem domain. They sometimes may even omit information believing that it is obvious.
3. Problems of Volatility. It is inevitable that requirements change overtime.
To help overcome these problems, software engineers must approach the requirements gathering activity in an organized and systematic manner.
Collaborative Requirements Gathering
Unlike inception where QA Question and Answer approach is used, elicitation makes use of a requirements elicitation format that combines the elements of problem solving,
elaboration, negotiation, and specification. It requires the cooperation of a group of end- users and developers to elicit requirements. They work together to:
• identify the problem • propose elements of the solution
• negotiate different approaches • specify a preliminary set of solution requirements
Joint Application Development is one collaborative requirement gathering technique that is popularly used to elicit requirements.
The tasks involved in elicitation may be categorized into three groups, namely, pre-joint meeting tasks, joint meeting tasks and post-joint meeting tasks.
Pre-Joint Meeting Tasks 1. If there is no product request, one stakeholder should write one.
2. Set the place, time and date of the meeting. 3. Select a facilitator.
4. Invite the members of the team which may be the software team, customers, and other stakeholders.
5. Distribute the product request to all attendees before the meeting. 6. Each attendee is asked to make the following:
• a list of objects that are part of the environment that surrounds the system
Software Engineering 64
J.E.D.I
• a list of other objects that are produced by the system • a list of objects that are used by the system to perform its functions
• a list of services processes or functions that manipulate or interact with the objects
• a list of constraints such as cost, size and business rules • a list of performance criteria such as speed, accuracy etc.
Note that the list are not expected to be exhaustive but are expected to reflect the persons perception of the system.
Joint Meeting Tasks 1. The first topic that needs to be resolved is the need and justification of the new
product. Everyone should agree that the product is justified. 2. Each participant presents his list to the group.
3. After all participants presents, a combined list is created. It eliminates redundant entries, adds new ideas that come up during the discussion, but does not delete
anything. 4. The consensus list in each topic area objects, services, constraints and performance
is defined. The combined list from the previous task is shortened, lengthen, or reworded to reflect the product or system to be developed.
5. Once the consensus list is defined, the team is divided into sub-teams. Each will be
working to develop the mini-specifications for one or more entries on the consensus list. The mini-specification is simply an elaboration of the item in the list using words
and phrases.
6. Each sub-team, then, presents its mini-specification to all attendees. Additions, deletions and further elaboration are made. In some cases, it will uncover new
objects, services, constraints,or performance requirements that will added to the original lists.
7. In some cases, issues arise that cannot be resolved during the meeting. An issue list is maintained and they will be acted on later.
8. After each mini-specification is completed, each attendee makes a list of validation criteria for the product or system and presents the list to the team. A consensus list
of validation criteria is created. 9. One or more participants is assigned the task of writing a complete draft specification
using all inputs from the meeting. Post-Joint Meeting Tasks
1. Compile the complete draft specifications of the items discussed in the meeting. 2. Prioritize the requirements. One can use the Quality Function Technique or MoSCoW
Technique.
Quality Function Deployment Quality Function Deployment is a technique that emphasizes an understanding of
what is valuable to the customer. Then, deploy these values throughout the engineering process. It identifies three types of requirements:
Software Engineering 65
J.E.D.I
1. Normal Requirements
These requirements directly reflect the objectives and goals stated for a product or system during meetings with the customer. It means that if the requirements
are present, the customer is satisfied.
2. Expected Requirements
These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. The absence of
these requirement may cause for significant dissatisfaction. Examples of expected requirements are ease of human or machine interaction, overall
operation correctness and reliability, and ease of software installation.
3. Exciting Requirements
These requirements reflect features that go beyond the customers expectations and prove to be very satisfying when present.
With the succeeding meetings with the team, value analysis is conducted to determine the relative priority of requirement based on three deployments, namely, function
deployment, information deployment, and task deployment. Function deployment is used to determine the value of each function that is required for the system.
Information deployment identifies both data objects and events that the system must consume and produce. This is related to a function. Task deployment examines the
behavior of the product or system within the context of its environment. From the value analysis, each requirements are categorized based on the three types of requirements.
MoSCoW Technique
Each requirement can be evaluated against classes of priority as specified in Table 4 During the software engineering process, a short meeting should be conducted to review
and probably, reassign priorities.
Classification Meaning
Must Have This requirement will be included in the
delivered product.
Should Have The current project plan indicates that this
requirement will be included. If
circumstances change, it may be traded out. Could Have
The current project plan does not indicate that this requirement will be included. If
circumstances change, it may be traded in.
Wont Have This requirement will not be included in the
delivered product.
Table 4 Classification of Priorities
Software Engineering 66
J.E.D.I
Elicitation Work Product
The output of the elicitation task can vary depending on size of the system or product to be built. For most systems, the output or work products include:
• A statement of need and feasibility • A bounded statement of scope for the system or product
• A list of customer, users, and other stakeholders who participated in requirements elicitation.
• A description of the systems technical environment • A priority list of requirements, preferably, in terms of functions, objects and
domain constraints that apply to each
3.2.3 Elaboration
