Negotiating and Validating Requirements

Negotiating requiremnts

The inception, elicitation, and elaboration tasks in an ideal requirements engineering setting determine customer requirements in sufficient depth to proceed to later software engineering activities. You might have to negotiate with one or more stakeholders. Most of the time, stakeholders are expected to balance functionality, performance, and other product or system attributes against cost and time-to-market.

The goal of this discussion is to create a project plan that meets the objectives of stakeholders while also reflecting the real-world restrictions (e.g., time, personnel, and budget) imposed on the software team. The successful negotiations aim for a “win-win” outcome. That is, stakeholders, benefit from a system or product that meets the majority of their needs, while you benefit from working within realistic and reasonable budgets and schedules.

At the start of each software process iteration, Boehm defines a series of negotiating actions. Rather than defining a single customer communication activity, the following are defined:

  1. Identifying the major stakeholders in the system or subsystem.
  2. Establishing the stakeholders’ “win conditions.”
  3. Negotiation of the win conditions of the stakeholders in order to reconcile them into a set of win-win conditions for all people involved.

Validating Requirements

Each aspect of the requirements model is checked for consistency, omissions, and ambiguity as it is developed. The model’s requirements are prioritised by stakeholders and bundled into requirements packages that will be implemented as software increments.

The following questions are addressed by an examination of the requirements model:

  • Is each requirement aligned with the overall system/product objectives?
  • Were all requirements expressed at the appropriate level of abstraction? Do some criteria, in other words, give a level of technical information that is inappropriate at this stage?
  • Is the requirement truly necessary, or is it an optional feature that may or may not be critical to the system’s goal?
  • Is each requirement well defined and unambiguous?
  • Is each requirement attributed? Is there a source noted for each requirement?
  • Are there any requirements that conflict with others?
  • Is each requirement attainable in the technical environment in which the system or product will be housed?
  • Is each requirement, once implemented, testable?
  • Does the requirements model accurately represent the information, functionality, and behaviour of the system to be built?
  • Has the requirements model been “partitioned” in such a way that progressively more detailed information about the system is exposed?
  • Have requirements patterns been used to reduce the complexity of the requirements model?
  • Have all patterns been validated properly? Are all patterns in accordance with the requirements of the customers?
Advertisements
Advertisements
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments