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
A specification is the final artifact or work product produced by the software engineer during requirements engineering. It serves as the foundation for subsequent software
engineering activities, particularly, the design and construction of the software. It shows the informational, functional and behavioral aspects of the system. It can be
written down as a document, a set of graphical models, a formal mathematical model, a prototype or any combination of these. The models serves as your specifications.
3.2.6 Validation
The work products produced as a consequence of requirements engineering are assessed for quality during validation step. It examines the specification to ensure that all
software requirements have been stated clearly and that inconsistencies, omissions, and errors have been detected and corrected. It checks the conformance work products to
the standards established in the software project.
The review team that validates the requirements consists of software engineers, customers, users, and other stakeholders. They look for errors in content or
interpretation, areas where clarification is required, missing information, inconsistencies, conflicting and unrealistic requirements.
Requirements Validation Checklist
As the models are built, they are examined for consistency, omission, and ambiguity. The requirements are prioritized and grouped within packages that will be implemented
as software increments and delivered to the customer. Questions as suggested by Pressman are listed below to serve as a guideline for validating the work products of the
requirement engineering phase.
Software Engineering 68
J.E.D.I
1. Is each requirement consistent with the overall objective for the system or product? 2. Have all requirements been specified at the proper level of abstraction? That is, do
some requirements provide a level of technical detail that is not appropriate at the stage?
3. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
4. Is each requirement bounded and clear? 5. Does each requirement have attribution? That is, is a source generally, a specific
individual noted for each requirement? 6. Do any of the requirements conflict with other requirements?
7. Is each requirement achievable in the technical environment that will house the system or product?
8. Is each requirement testable, once implemented? 9. Does the requirement model properly reflect the information, function and behavior of
the system to be built? 10.Has the requirements model been partitioned in a way that exposes progressively
more detailed information about the system? 11.Have the requirements pattern been used to simplify the requirements model? Have
all patterns been properly validated? Are all patterns consistent with customer requirements?
These and other questions should be asked and answered to ensure that all work products reflect the customers needs so that it provides a solid foundation for design and
construction.
3.2.7 Management
