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
The information obtained from the team during inception and elicitation is expanded and refined during elaboration. This requirement engineering task focuses on defining,
redefining and refining of models, namely, the requirements model system or problem domain and analysis model solution domain. It tries to model the WHAT rather than
the HOW.
The requirements model is created using methodologies that capitalizes on user scenarios which define the way the system is used. It describes how the end-users and
actors interact with the system.
The analysis model is derived from the requirements model where each scenario is analyzed to get the analysis classes, i.e., business domain entities that are visible to the
end-user. The attributes of each analysis class are defined and responsibilities that are required by each class are identified. The relationships and collaboration between
classes are identified and a variety of supplementary UML diagrams are produced. The end-result of elaboration is an analysis model that defines the informational, functional
and behavioral domain of the problem. The development of these models will be discussed in the Requirements Analysis and Model, and Requirements Specifications
section of this chapter.
Elaboration Work Product
The requirements model and the analysis model are the main work product of this task.
3.2.4 Negotiation
In negotiation, customers, stakeholders and software development team reconcile conflicts. Conflicts arise when customers are asking for more than what the software
development can achieve given limited system resources. To resolve these conflicts, requirements are ranked, risk associated with each requirements are identified and
analyzed, estimates on development effort and costs are made, and delivery time set. The purpose of negotiation is to develop a project plan that meets the requirements of
the user while reflecting real-world constraints such as time, people and budget. It means that customer gets the system or product that satisfies majority of the needs, and
the software team is able to realistically work towards meeting deadlines and budgets.
Software Engineering 67
J.E.D.I
The Art of Negotiation
Negotiation is a means of establishing collaboration. For a successful software development project, collaboration is a must. Below are some guidelines in negotiating
with stakeholders.
1. Remember that negotiation is not competition. Everybody should
compromise. At some level, everybody should feel that their concerns have been addressed, or that they have achieved something.
2. Have a strategy. Listen to what the parties want to achieve. Decide on how we are going to make everything happen.
3. Listen effectively. Listening shows that you are concern. Try not to formulate your response or reaction while the other is speaking. You might get
something that can help you negotiate later on. 4. Focus on the other partys interest. Dont take hard positions if you want to
avoid conflict. 5. Dont make it personal. Focus on the problem that needs to be solved.
6. Be creative. Dont be afraid to think out of the box. 7. Be ready to commit. Once an agreement has been reached, commit to the
agreement and move on to other matters.
3.2.5 Specification
