SOFTWARE ACQUISITION GOLD PRACTICE^TM

REQUIREMENTS TRADE-OFFS/NEGOTIATIONS

 

FOCUS AREA:        REQUIREMENTS -  Change Management

 

Definition and Summary:  Within a funding constrained environment, engaging in the explicit trade-off between required functionality, schedule, time, project/product stability, and risk without compromising overall system objectives.

More than 75% of large software projects suffer large cost and schedule overruns or fail outright.  Deficits in project requirements cause more than half of these failures and overruns.  This is in part due to the high complexity of the requirements task.  Finding ways to manage/reduce the complexity is an important step in reducing the risks of software development.

Establishing a sound process for negotiating and making requirements trade-offs reduces risks by providing the following benefits:

§        More complete requirements in the early stages of a project

§        Fewer requirements changes during development

§        Enabling a shared vision throughout the life cycle

§        Negotiation methods preserve the rationale of decision making

§        Control of “Scope Creep”

 

 

Description of the practice:

 

Summary DESCRIPTION

Requirements Negotiation (RN) is a practice implemented early in the planning stages for each project, or phase of an incremental or evolutionary development approach (and whenever requirements change) in a collaborative environment where there is mutual respect and trust among stakeholders.

Its purpose is to reach stakeholder agreement on what the real requirements are for a designated phase or release of a software product given the reality of cost, schedule, and perhaps technology constraints. Stakeholders work together to prioritize candidate requirements, identify potential conflicts among functional requirements or between functional and non-functional requirements, propose options, and adopt the options that satisfy stakeholder needs and, in so doing, establish a shared vision of the real requirements for the product.  Typically some form of Group Support System (collaboration tools), operating in a distributed environment, enables the collection and organization of artifacts resulting from these activities.  The activities of the requirements negotiation process and their relationships are illustrated in the figure below.

Some key benefits of this practice are:

§         More complete requirements in the early stages of a project

§         Fewer requirements changes during development

§         Enabling a shared vision throughout the life cycle

§         Negotiation methods preserve the rationale of decision making

§         Control of “Scope Creep”

Effective practices for requirements negotiation are:

 

 

DetailED description

Perhaps the best way to describe this practice is to pose, and then respond to, a series of questions as follows:

What is requirements negotiation (RN)?

The practice of Requirements Trade-offs/Negotiation (hereafter referenced as Requirements Negotiation (RN)) involves engaging success-critical stakeholders in making explicit trade-offs between required functionality, schedule, time, project or product stability, and risk without compromising overall system objectives.  During other requirements engineering activities, conflicts are identified that occur between stakeholders wanting incompatible features, or conflicts between requirements and resources, or between capabilities and constraints.  Negotiations are necessary to resolve such conflicts and make the necessary trade-off decisions.  Some synonyms for the RN process include:

§        Requirements triage

§        Release planning

§        Requirements prioritization

§        Optimal attainment of requirements

§        Requirements selection

§        Requirements allocation

 

Though the identifying terms may vary, all of these processes are concerned with identifying what needs to be done and what to do first.  The issue of who makes the decisions, and when, is what is critical to the success of a project, and an important part of making the practice effective.  This is what RN is all about.  RN is often implied rather than specifically referenced in the literature.  Articles on requirements engineering talk about involving the stakeholders in the process, collaborating and prioritizing requirements.  RN addresses how the collaboration occurs and how requirements are prioritized, when, and by whom.

How does RN fit into the software product life cycle?

The practice is most effective when implemented early in the development cycle to establish a shared vision of what is to be built and minimize the risk of not meeting customer expectations.  However, it is also applied throughout the cycle as part of change management in order to maintain the shared vision as the project unfolds.  Unfortunately, all too often, RN is implemented as the project approaches a delivery deadline, and developers or acquirers discover that it will be impossible to meet all of the requirements and still make the deadline.  At this point in time, it becomes the “last resort” attempt to salvage something from the project, but its effectiveness is diminished for many reasons; customer expectations are clearly not being met; lack of trust among stakeholders; most resources have already been used.  Regardless of what might be accomplished in the last minute negotiation, the project as a whole becomes a “lose-lose” scenario for most stakeholders.

How does it relate to other requirements engineering (RE) or requirements management (RM) processes?

Figure 1:  Requirements Engineering Processes

Figure 1 identifies five key processes of requirements engineering and their interrelationships.  This is premised on an evolutionary development approach where each of the processes would be repeated for each spiral (planned release) of the software effort.  There is a dichotomy (evident from the past five years of literature) relating to the role of RM versus other requirements engineering processes.  In much of the literature, RM is now viewed as the all-encompassing “oversight” process that ties the other four processes together to form a cohesive and effective requirements engineering discipline.  Yet in many cases, RM is regarded as the last process in a sequence of requirements activities that relates primarily to requirements changes, and is not implemented until after the initial requirements baseline has been established.  In this view, RM is ongoing while the other processes are implemented once at the beginning of the project.

The DACS view is that the essential role of Requirements Management is to provide the logistics for requirements engineering, the glue that binds the other processes, by managing the requirements engineering artifacts.  It provides the planning and communication that enables the other processes to be effective.  Therefore, RM starts along with requirements elicitation and continues throughout the life cycle of the effort.

Requirements negotiation is usually included as a subset of the requirements analysis process, but sometimes it is perceived as part of validation as well.  It may also be used effectively during elicitation.  The boundaries of the individual RE processes are somewhat blurred, but the boundary lines are not important as long as the activities of each process actually occur.

Who is involved in RN?  In what roles?

RN is most effective in a managed environment where the key stakeholders collectively take responsibility for the RE process and create a collaborative working environment that fosters trust and mutual respect and understanding of each stakeholder’s perspective.  Although the terms “negotiation” and “trade-offs” may suggest to the reader a competitive environment where the people involved have an adversarial relationship, this should not be the case for RN.  Key stakeholders need to work together (collaborate) in order to maintain a shared/common vision of what is to be built.  At a minimum, key stakeholders should include the acquirer, developer, user representatives, and domain experts.  Each of these stakeholders brings unique knowledge and concerns to the forum.  Eliminating or circumventing any one stakeholder can have a significant impact on the effort by skewing the common perspective.  By working together, the stakeholders develop a common vision of what can realistically be built, when, and why.  Note, in this context, that working together does not mean that stakeholders must meet face-to-face.  It simply means that the key stakeholders are included in the process and there are mechanisms for sharing their thoughts. 

What are the steps (activities) of the RN process?

Figure 2 illustrates the high-level steps that comprise the requirements negotiation process.  The dotted blue line is positioned to suggest that the first two steps (labeled 0.1 and 0.2) constitute preparation for the actual negotiation process and, in some environments, might be viewed as part of requirements elicitation, analysis, validation, or requirements management rather than requirements negotiation.  They are included here because the output of those steps provides the content required by the negotiation process, and because the negotiation process may identify new requirements and reveal more knowledge requirements attributes.  The end result of the negotiation process is a collection of agreements about requirements that reflect a common vision of what is to be built in a particular release, or series of releases.  It is not a finished, polished requirements document, but rather a documented consensus of what the requirements document should contain. Note that in this context we are using the term “requirements”, in its broadest sense, to include non-functional requirements, end-user processes, and items that are often identified as cost and schedule constraints rather than requirements.

Figure 2:  Activities of the Requirements Negotiation Process

 

Organize/group requirements:

Inputs to this process are candidate requirements, because the decision is yet to be made about their value to the project.  Some may be abandoned as a result of the RN process.  They include all types of requirements (functional, performance, cost, schedule, risk thresholds, etc.). They come from a variety of sources and stakeholders.  The level of detail may vary from phrases describing a desired capability to specific detailed statements.  It is important to organize these items into a hierarchical list and according to a domain taxonomy.  The list should include categories for different requirement types and establish the basic relationships among the requirements.  In many cases, this activity is considered part of requirements elicitation.  A requirements analyst is typically responsible for gathering and grouping the requirements.  The critical part of this activity is ensuring that all sources of requirements have, in fact, been considered.  Leaving out a stakeholder (not obtaining their views) only postpones the discovery of requirements until later in the process when it is more difficult and costly to address them.  Each requirement, thought, or idea needs to be uniquely identified, even in cases where the statements have not yet been converted into formal requirements statements.  Establishing the hierarchy among requirements is extremely important at this stage because it has an impact on how attributes will be generated.   

Requirements elicitation [Young, 2004] also includes translating (or evolving) the “stated” requirements into “real” requirements. 

Stated requirements – those provided by a customer at the beginning of a software development effort, for example, in a request for information, proposal, or quote or in a statement of work (SOW)

Real requirements – those that reflect the verified needs of and expectations of users for a particular system or capability

This analysis activity should precede prioritization and should involve a joint customer/user and requirements analyst effort. Customers and users need the support of technically trained professionals, and vice versa, to ensure effective communication.  Developers need to have that same understanding so that the solution they define addresses the needs in the way everyone expects.

This level of initial collaboration to evolve the real requirements sets a positive collaborative tone in which to negotiate when issues are identified later in conjunction with prioritizing.  Sometimes, the real requirements emerge only as a result of negotiating.   

Gather requirements attributes:

As requirements are identified, the team needs to gather the requirements attributes.  This can begin as soon as some requirements are identified and continue as more information becomes available and more requirements are known.  The attributes provide objective data to the decision making process.  Some important attributes include:

§        Source or origin

§        Effort

§        Schedule

§        Interdependencies

§        Impact

§        Risk

§        Priority

Some attributes are applicable only to functional requirements while others are applicable to all types of requirements.  Not all attribute values can/should be determined prior to negotiation. For example, the priority of a requirement may vary among stakeholders, and might be initially assigned but would need to be modified as a result of negotiation, or as a result of new requirements emerging, or other requirements changes.  It is important to establish a mechanism that allows for tracking attributes over the life of the project that can be used by the stakeholders, as appropriate, to keep the attribute data up-to-date.  The developer needs to provide effort and schedule estimates that are realistic and based on a sound estimating process, along with technical risk assessments.  These attributes are the primary drivers of decisions about implementation.  The team has to have trust in the estimates in order to use them in the negotiation process.  Typically, requirements are placed in a repository that maintains the relationship between the requirement and its attributes and allows searching and manipulation of the data by the authorized team members.

Assess relative priorities:

Several authors ([Davis, 2003] and [Simmons, 2004]) liken the negotiation process, a process of prioritizing requirements, to medical triage.  Medical triage is premised on balancing the need for treatment with the likelihood of a successful outcome by making the best use of existing resources, given constraints such as cost and the limited availability of human resources associated with most accidents or human tragedies.  Requirements triage attempts to determine which requirements a product should satisfy, given the time and resources available, by applying the concepts and techniques of medical triage.  Just as medial triage establishes severity categories and subsequent treatment action plans that allow triage staff to rapidly assess the victim situation, so to, the requirements engineering team establishes requirements categories and criteria for placing requirements in those categories.  For example, one triage approach might be to initially classify the requirements into three major groups:

1.       “Must have” - Requirements that must be satisfied in the next release

2.       “Not necessary”  - Requirements that can clearly be set aside for some later release

3.       “Maybe” - Requirements that are desirable but need to be weighed in light of cost and other resource constraints (which may be stated as other requirements).  Or, requirements viewed as must haves by some, but not all, stakeholders

This initial activity will allow the team to quickly converge on the items about which they agree and identifies/distinguishes those items that require more formal negotiation.  Triage should be a facilitated process and can be very effective in establishing the positive collaborative environment needed for successful negotiation.

The outcome of this step in the negotiation process is consensus among the stakeholders about what they agree on and what has to be further negotiated.  Just as is the case with medical triage, the team may pre-define the actions or process for dealing with each of their defined categories.   This brings objectivity to the remainder of the process, minimizing conflict, and minimizing the risk of inadequate requirements engineering.   In this context, triage is viewed as a step in the broader negotiation process that sets the stage for serious negotiation about those items for which issues exist, in an environment of cooperation.

Identify Win conditions (stakeholder views)

Although the terminology of triage is different, the activity coined as “requirements triage” is analogous to establishing “Win” conditions as part of the  “WinWin Negotiation model“ developed by Barry Boehm [Boehm, 1998] and others at the University of Southern California in the nineties.  The approach is focused on making winners of all key stakeholders involved in a project by providing a model that guides the stakeholders in expressing and negotiating objectives.  Stakeholders express their goals as Win Conditions.  Constraints and conflicts among Win Conditions are captured as Issues.  Stakeholders propose Options to reconcile issues and to describe candidate solutions.  When consensus is achieved, real requirements are captured as Agreements about options.  The WinWin process is comprised of the following steps:

Step 0: Engage the success-critical stakeholders, the people whose interests must be accommodated in order for the project to succeed.

Step 1: Refine and expand negotiation topics.  Start with a taxonomy of system requirements that identifies categories for win scenarios.

Step 2: Brainstorm stakeholder win conditions.

Step 3: Converge on win conditions.

Step 4: Define a glossary of key terms.

Step 5: Prioritize win conditions.

Step 6: Surface issues and constraints

Step 7: Build and refine the WinWin Tree: Win Conditions, Issues, Options, and Agreements until WinWin Equilibrium is achieved.

Step 8: Organize negotiation results.

The WinWin model supports cooperative decision making by focusing on establishing and managing the artifacts of the negotiation process, thereby providing the structure that fosters increasing cooperativeness, focuses participants on key issues, and reduces friction.  Figure 3 identifies the artifacts and their interrelationships (and implies the activities) of the WinWin model for requirements negotiation.

 

Figure 3: WinWin Artifact Relationships and Taxonomy [Boehm, 1998]

 

This is not a strictly sequential process.  In many cases, the activities are implemented in a concurrent manner.  The team can reach agreement about some conditions while others are left open waiting for options to be proposed.  However, whenever issues exist for a Win condition, options must be generated before any agreement can be made.  If no issues surface, then the team adopts the Win condition directly. As illustrated in Figure 3, Win conditions, Issues, Options, and Agreements are documented and become the artifacts of the process.  Although the terminology originates from the WinWin model, these activities are actually generic and essential for successful negotiation.

Key stakeholders each identify their goals and concerns with respect to the software effort as their WinWin conditions - their conditions for success, their individual priorities.  These statements address the key functional requirements that are important to each stakeholder, as well as non-functional requirements such as time to market, or cost threshold, or performance.  This is analogous to triage where the group agrees on those requirements that are “must haves” and classifies other conditions for further action if there is not an initial consensus of their priority.  If a Win condition is non-controversial then the team adopts it in the form of an agreement artifact.

Ensure coverage

Initially, and throughout the process, a requirements taxonomy is referenced to ensure that the negotiation process is not skewed by incomplete domain knowledge, or gaps in requirements/Win conditions.  Typically, a domain expert generates the appropriate taxonomy.  Having the taxonomy may reveal special areas such as regulations and guidelines that form the basis for requirement sets, or constraints of which stakeholders might not be aware.  It is important to revisit the taxonomy as a quality check during each step of the process, because each step of the process generates new ideas or decisions. Checking at each step finds and corrects inconsistencies where they originate, having the least impact on the overall project.

Identify issues/conflicts:

If the requirements triage process is thorough, there will likely be a group of requirements for which conflicts exist, or simply the issue of not having sufficient resources to implement all requirements.  For this group of requirements stakeholders identify issues relating to each requirement/win condition.  An issue may address several conditions.  There may be multiple issues.  Issues can be almost anything, a risk, a conflict with other statements, volatility, or general thoughts.  This is the part of the process that makes use of the attribute information, such as the interrelationships among requirements and the resources required to implement them, the risk factors, and so on.  Stakeholders will individually identify differing issues because of the unique perspective that each brings to the process.  Issues are logged (recorded) against the Win condition to which they relate.  This part of the process relies heavily on having the requirements organized in a hierarchical fashion.  Issues that impact a broad level requirement (parent) have a rippling impact on the child requirements, while issues relating to a child requirement have much less of an impact on the effort as a whole.  Also, making a decision to eliminate a parent requirement from a particular release automatically eliminates the children. 

Having appropriate participation from each stakeholder group is critical to the success of the process, particularly because of their unique awareness of potential conflict.  The developer technical stakeholder typically identifies many issues relating to capability, technology, and performance risks of which other stakeholders have no knowledge. Likewise, financial managers and marketing people raise important issues that a technical person might view as irrelevant, or not important.  End users can identify issues relating to user functionality perhaps better than technical stakeholders can.  The process must provide a forum that not only allows, but also encourages all stakeholder representatives to raise issues and share them.

Propose solution options:

This step in the process seeks to capture potential solutions to the issues.  The general goal of negotiation is to preserve all stakeholders’ Win conditions, or at least provide an alternative that is satisfactory to each stakeholder.  Therefore, proposing options is the “heart” of the process.  The other activities are prerequisites to this activity.  Note that options are not design solutions; they are alternative views or combinations of requirements.  For example, a Win condition may be that the software must be delivered in six months.  However, the technical stakeholder raises the issue that it will take one year to build the envisioned system given proposed staffing.  An option might be to build the system with “X” functionality to be delivered in 6 months and then to add the remaining required functionality to a release 6 months later.  In order to agree on this option, stakeholders would need to achieve consensus on what constitutes “X” functionality.  Options address how to achieve the needed capabilities within the constraints.

Proposing options may itself be an iterative process, where an option is proposed and then revised based on discussions from the team. Multiple options or approaches are encouraged.  Options may involve revision of the requirements.  Options need not be mutually exclusive.  There are no fixed guidelines for determining how many options are needed before making a decision, or what period of time should be allowed.  The success of the RN process, however, is contingent upon getting optimum participation from stakeholders, in order to investigate a full spectrum of alternative solutions before making a decision.  Again, having accurate and trustworthy attribute information is critical when stakeholders are expected to solve complex requirements problems.  Not taking action until all avenues for generating options or solutions have been exhausted is an important part of the negotiation process.  The criteria for moving to the decision-making activity may vary for the different Win conditions as well.  The WinWin model is not the silver bullet for reaching agreement.  It is only an aid that provides structure and support for people making difficult decisions about complex issues.

Options are logged against the issues they purport to resolve, and all members of the team should have access to the issue and option information as it materializes.

Make decisions:

Stakeholders must reach agreement about each requirement and/or Win condition.  Many (typically a majority of) conditions may be adopted early because there are no conflicts.  When issues are identified for a given Win condition (or set of conditions), the group focuses on proposing and eventually agreeing on adopting one or more options for that condition.  Typically, the negotiation process is implemented with a support tool that provides for creating and tracking all the artifacts of the process.  Without such a tool, it is difficult to apply the process for medium to large size projects.  It is important to capture the agreement as the artifact.  It constitutes the consensus of the team about the corresponding Win condition, which is indirectly a statement about one or more requirements.  The agreement is a different artifact from the requirements statements that eventually are written and further detailed in requirements documents.  For example, stakeholders may agree that requirement “a” is necessary for release two of a product, but has low priority for release one.  The requirement statement has not changed, but the negotiated agreement has a significant impact on when resources will be allocated for that requirement.  Negotiation aids in determining what the final requirements should be, but is not concerned with actually producing the final requirements document.  However, depending on the sophistication of the support tools used for negotiation, it may be possible for the tool to generate requirements documents based on the results of negotiation. 

What are the RN process artifacts?

Regardless of whether one approaches negotiation using a triage model or the WinWin model, the artifacts are the same, even though slightly different terminology might be used to reference them.  Table 1 describes these artifacts.

 

Table 1:  Artifacts of the Requirements Negotiation Process

Artifact	Description
Requirements	High-level statements of need, lists of features or capabilities desired, usage scenarios, or any documented expression of the stakeholders concepts of what should be built. The level of granularity needed is relative to the environment in which negotiation takes place.  When used early, as part of elicitation, statements of need may be sufficient to start.  Generally, the later in the life cycle that the negotiation occurs the more granularity is necessary.
Requirements Taxonomy	A documented taxonomy of the relevant software domain that provides appropriate categories for grouping requirements and serves as a guide for assessing coverage.  For example, weapons systems software will have performance requirements significantly different from supply tracking software, or procurement software.  The taxonomy may be selected from a domain taxonomy and then tailored to the needs of the specific project.
Requirements Attributes	Attributes are items of information that relate to a requirement.  The information is provided at different points in time by different stakeholders.  Some attributes are static (requirement source) while others are dynamic (priority, risk factor, etc.).  Attributes need to be identified and documented and be easily accessible during the negotiation process.
Win Conditions	Win conditions are requirements viewed by individual stakeholders as critical to the success of the project. Each stakeholder has their own list, and typically, some requirements are common to everyone’s list while others are not.  They represent the relative priority of requirements from the perspective of each stakeholder.  Although the process addresses them individually, the collection of Win conditions of a specific stakeholder constitutes their view of what is essential for the project and may include implementation requirements and other non-functional requirements.  Negotiation can be considered successful only if the individual stakeholders accept the agreements of the team, even though what is adopted may differ from their original concept.
Issues	Documented statements that delineate concerns about requirements (Win condition) or their implementation.  An issue may describe a conflict between the target requirement and other requirements, or constraints relating primarily to cost, schedule, or performance.  This brings objectivity to the negotiation process.  It is not important who raises the issue, but it is important that the issue be communicated to all stakeholders.
Options	Options are proposals for resolving issues.  Sometimes resolution involves changing the requirement. Options are documented and mapped to the issue(s) they purport to resolve. Option artifacts should be accessible to all stakeholders as they are proposed.
Agreements	Agreements represent consensus of the stakeholders to adopt a requirement directly, or, to adopt one or more options relating to a requirement.

 

Key Practices of Requirements Negotiation:

In their landmark work on negotiation titled “Getting to Yes: Negotiating Agreement Without Giving In” [Fisher, 1991], the authors describe seven elements of negotiation and further compact them into four basic points that, they claim, provide a proven reliable framework that anyone can use (see Table 2).  These elements and points are reflected in the key practices for requirements negotiation identified in the following paragraphs.  The 17 practices, described in the following paragraphs, are listed here because they have been either explicitly stated or implied throughout the referenced literature.

Table 2:  Elements and Principles of Effective Negotiation

 

Note there is no particular significance to the sequence or numbering of the practices in the following paragraphs.

 1 - Get the right stakeholders:   

Engage the success-critical stakeholders, those individuals whose interests must be accommodated in order for the project to succeed.  Success-critical stakeholders are the people who can make the agreements about the requirements, and make those agreements stick.  This is in contrast to lower-level representatives who would have to seek approval from their respective leaders in order to make agreements, or whose leaders, outside the context of the negotiations process, might repudiate any agreements made by the representatives [Briggs, 2002].  Do not leave out key stakeholder groups in order to avoid conflict, or to favor the interest of one stakeholder over another.  Studies have shown that this only delays the problems until later, when it is more costly or impossible to resolve and leads to project failure.  Davis [Davis, 2003] notes that in one of his case studies the absence of financial representatives led to subsequent disintegration of the compromise, forcing the entire project to return to the drawing board.

Identifying the right stakeholders is not a trivial task.  In a recent GAO report [GAO, 2004] indicating that DoD’s Acquisition Policies and Guidance need to incorporate additional best practices and controls, the report identifies “Requirements Development and Management” as one of the practices that needs to be further addressed.  The purpose is to ensure the contractual requirements are clearly delineated and understood by the acquisition stakeholders.  In the list of detailed characteristics of this practice the report states that a contractual requirements baseline is established prior to solicitation, and that requirements priorities (mandatory vs. optional) are clearly delineated.  There are inherent issues in these statements.  Who are the “acquisition stakeholders”?  Is the developer among them?  If not, how is the contractual requirements baseline established?  Who provides the technical knowledge during this process if the developer has not yet been selected?  To establish prioritization of contractual requirements some internal negotiation must occur within the acquirer organization.  Who represents the technical perspective in those negotiations?  Are “contractual requirements” negotiable once the developer has been selected?  What exactly are contractual requirements versus other types of requirements? Who is best qualified to represent the financial perspective for the acquisition? Who is needed to address the scheduling and period for delivered functionality? The acquirer needs to ensure that any contract is sufficiently flexible to allow including the developer in requirements negotiation following contract award, and that the contractual requirements baseline is not so rigid that it prevents change.

The right stakeholders may shift as the acquisition progresses and the scope and level of requirements become more detailed.

 2 - Establish a teamwork mentality:   

In a negotiation process, stakeholders have to balance their personal goals with the preferences of others to come up with a mutually satisfactory solution, and to develop a shared vision and a joint understanding about the development goals and alternatives [Grunbacher, 2002].  In order for this to happen, they have to develop a teamwork mentality.  This does not happen simply because the leader says, “Let it be so!”  It grows out of mutual respect and understanding of each person’s role, and the integrity of the requirements attributes.  It is often influenced by factors beyond the team’s control.  Hidden agendas often motivate the individual behavior of team members.  The “people” issues need to be addressed, as well as the technical infrastructure that supports the team.  Adversarial relationships among stakeholders tend to consume enormous energy, blur the goals, and stymie progress in building the product.

 3 - Plan team interaction:

Plan how the team should interact during each part of the process.  Bringing people together for a face-to-face meeting in a conference room may not be the optimum scenario for identifying win conditions, issues, or options.  Several alternatives exist that may be more cost effective and yield better results.  Choosing the right tools for the scope of the effort is an important element for supporting effective team interaction.  Developing/selecting requirements is a learning process.  Developers learn more about the customer’s and user’s world, while customers and users learn more about what is technically and economically possible.  This sharing and interaction among stakeholders is a prerequisite for creating products that satisfy all stakeholders.  Boehm [Boehm, 2001] argues that requirements are not “out there” waiting to be discovered.  Rather they emerge from a process of learning and negotiation as people discover the financial and technical constraints under which they must work, and as they learn about one another’s needs and interests.

Recent studies [Damian, 2000] have shown that, contrary to traditional wisdom and media effects theories, when it comes to requirements negotiations, groups meeting face-to-face perform no better than distributed groups using video conferencing and computer support.  Furthermore, one particular distributed group configuration significantly improved performance and was more conducive to negotiation than face-to-face meetings.  The particular distribution consisted of a facilitator, two customers (with conflicting viewpoints) and a system analyst, with the facilitator and one customer co-located in one area while the analyst and other customer were co-located in another area.  This suggests that electronic mediation of customer discussion is conducive to negotiation behaviors that produce the most favorable agreements, both in relation to the overall business goal and according to both customers’ perspectives.  Results also suggest that electronic mediation might help the group emphasize task-related matters over interpersonal aspects of the interaction, in that the lowered ability to perceive emotional cues perhaps encouraged more objective exploration of alternatives, which in turn produces a greater consideration of the overall business goal and, consequently, optimal agreements.

An empirical study of requirements engineering in distributed software projects conducted by Daniela Damian [Damian, 2001], seeking to determine whether distance negotiation is more effective,  found that it is important to have an initial face-to-face contact between the facilitator and the collaborators (stakeholders) before any computer-mediated meeting occurs.  This enabled them to get to know each other, get a sense of physical stature, and establish a relationship of trust.  Without such a meeting the facilitator proceeds with tunnel vision.

 4 - Use a Group Support System:    

Group Support Systems (GSS) aid in addressing the complexity inherent in requirements definition and negotiation.  A group support system is a collection of collaborative software tools that a team may use to focus and structure their mental effort as they work together toward a goal.  Briggs [Briggs, 2002] notes that field studies regularly report that teams using GSS can cut their labor hours for a project by 50% and cut the calendar days for their project by 70% - 90%.  Using a GSS can significantly cut the cognitive load of communication and deliberation by allowing multiple people to work together to structure their information artifacts, and by allowing simultaneous contributions without turn-taking. Teams can read and respond to one another’s contributions in real time, regardless of how the team is physically distributed.  GSS allows the team to focus and structure their interaction in predictable ways.

When selecting such tools it is important to assess the degree of interoperability with other tools used on the project and within the organization.  The tool should not only allow tracking of all the artifacts of negotiation, but it should be able to export the results to other tools used on the project, or be integrated with those other tools.

 5 - Establish a shared vocabulary: 

In most software development efforts each stakeholder group has key terms that become their jargon, often expressed with acronyms.  While jargon can simplify communication among those who know the jargon, it can hinder communication in a mixed group. For example, SLOC, POP, FTE, MNS, ORD and ETC are all valid terms that might be part of a requirements discussion, but they are barriers to team communication without explanation.  There are also terms unique to the domain that may seem obvious to the customer, but be interpreted quite differently by the developer.  Stakeholders need to verify and document one another’s terms as they proceed.  Often, the same term has different meaning for different people, and it is not easy to tell when this is happening.  Thus, the vocabulary of the team needs to be explored and shared throughout the effort and team members should be encouraged to ask for clarification of terms as necessary.  Other terms such as reliability, scalability, usability may have the same general meaning, but will need to be translated into more specific measurable statements for clarification.  For example, if the customer indicates that the system must be reliable, perhaps they are really thinking about the integrity of the data flow, but the developer may think that reliability means that the system will not crash.  The process of documenting the vocabulary allows inconsistencies to surface and be addressed.  The definitions are especially valuable as the composition of the team changes over time.  It is often the case that as people discuss the meanings of words, key project constraints emerge, assumptions surface, and new stakeholders are often identified.

By the way, in case you are wondering, here is the translation of the acronyms identified earlier in this paragraph:

SLOC – Source Lines of Code, a way of quantifying the size of a software effort in terms of the number of lines of source code generated

POP – Period of Performance, usually relating to a contract

 FTE – Full Time Equivalent, a term used to assess the quantity of staff resources needed without regard for their actual schedule, and based on an assumption of working 40 hours per week  

MNS – Mission Needs Statement, a document that expresses high-level requirements  

ORD – Operational Requirements Document, another document that contains requirements, typically more detailed than a Mission Needs Statement

ETC – Estimate To Complete, a term used in the context of Earned Value Management, to denote a calculated value that represents the cost of work required to complete remaining project tasks.

Take a moment to reflect on whether the clarification of these terms raised your comfort level with this material you just read.

 6 - Maintain a list of requirements: 

Requirements need to be organized so that each requirement statement is uniquely identifiable, and can be distinguished from other requirements during the negotiating process.  Keep the requirements in a spreadsheet, a database, a requirements management tool, or even in a bulleted list in a word processor.  It is best to establish and maintain a hierarchical list (based on the container relationship principle) which establishes parent/child and sibling relationships among requirements as part of the identification. For example, if three requirements are each part of (or a refinement to) requirement A, then they are identified as A.1, A.2, and A.3.  This makes it clear which requirements subsume other requirements and helps prevent meaningless arguments about parent (A) versus child (A.1).  The child requirements provide further clarification about what the parent requirement really means. The hierarchical identification also provides a unique identifier for each requirement.

 7 - Record requirements attributes: 

Attributes constitute whatever is known about the requirement.  One important attribute is necessity interdependencies. Often a requirement makes sense only when one or more other requirements are satisfied.  Necessity dependencies can be mutual, or one-way.  In a one-way dependency, the first requirement makes sense without the second, but the reverse is not true.  It is valuable to identify these interdependencies before the requirements are negotiated, so that negotiation can focus on the group if necessary.  For example, consider this list of requirements (in the initial wording of stakeholders) .

1.       Include a web-based user interface for  capturing user profile data

2.       Track entry and updates to user profile data by automatically recording the date and user login of the person making the entry or change when the web form is submitted

3.       Allow entry or update of user profile data either by the internal staff on behalf of a user, or by the user directly

4.       The interface should look and work the same regardless of the browser used (Internet Explorer, or Netscape)

Requirements 1 and 4 are mutually dependent.  “Web-based interface” implies that a browser will be used, and vice versa.  Requirement 4 implies Requirement 1.  Both need to be stated, and perhaps refined, for further clarification.  Requirements 2 and 3 are mutual with respect to each other, but both constitute a one way dependency supporting Requirement 1 by clarifying some characteristics of the interface.

Another important attribute is effort.  The unit of calibration is unimportant as long as you are consistent.  Popular units are function points, feature points, person hours, and lines of code.  It is vital for the developer (analyst) to provide this information prior to negotiation and be as accurate as possible.  In many cases, a decision about whether or not to implement a requirement is strictly a matter of cost relative to the cost of other requirements.  Within a hierarchical listing, you may only want to discuss the effort at the parent level, but that estimate might be derived by estimating the effort for the children.  The parent effort estimate can never be less than the sum of estimates for its children.

There are also effort dependencies that exist among requirements that are independent of the hierarchy.  For example, independently, requirement A and requirement C may each take five person-weeks, but once C is satisfied requirement A may then be satisfied in four person-weeks.  You would record the saving of one week for requirement A. Having estimates of effort provides flexibility for negotiation.

Relative importance (from the customer stakeholder’s view) should be captured while developers are determining the effort estimates.  Customers rank each requirement’s importance using a group voting mechanism that forces prioritization.  Otherwise, on an individual basis, each stakeholder considers all the requirements to be necessary, and has difficulty establishing priority.  Davis [Davis, 2003] describes a technique known as the hundred-dollar test, wherein stakeholders show their preference by distributing an imaginary $100 among the requirements; the more dollars allotted to a requirement, the stronger the interest.

Group voting typically works well because stakeholders rarely vote the same way for every requirement; they know that their votes would then have no effect on the overall decision.

  8 - Manage by probabilities of completion rather than absolutes:

Davis [Davis, 2003] claims that negotiation becomes much easier once everyone recognizes that nothing is absolute when attempting to understand customer needs and determine whether a product can be built within a given time.  The outcome can range from highly unlikely to highly likely.  He recommends using cumulative probability graphs.  The necessary data includes estimates of effort for past projects, and actual project duration.  To answer the question , “What is the probability of completing X work units (by any measure) in six months?”, just look at the data to see what % of projects that projected X or fewer work units actually managed to complete within six months.

 9 - Base decisions on more than mechanics:

Do not let the tool do the decision-making.  Tools have a support role only.  Human intelligence is needed to make the final decisions. Apply the “makes sense” check.  Reaching agreement is not the same as voting and accepting the majority. This type of voting is easy to do, but rarely achieves a workable solution.

 10 - Select an operational approach coupled with risk assessment:

§        Optimistic – Assume you can address all the requirements.  If the likelihood of success is too low, you remove requirements one at a time until the risk is acceptable.  Note: deciding which one to throw away is the essence of the negotiation practice.

§        Pessimistic – Assume you can address none of the requirements. Your risk level is obviously very low, so you add requirements one at a time until the risk is tolerable.  Note: Deciding which one to add first, and so on, requires agreement among the stakeholders about importance.

§        Realistic – Assume that you can start with some “reasonable” subset, then you add or remove requirements until you reach a compromise.

11 - Plan more than one release at a time:

Planning for only one release forces stakeholders into a binary decision about whether or not to include a requirement.  There is no middle ground.  Planning for consecutive releases provides an alternative when deadlock arises about including a requirement.  It creates an intermediate position.  If stakeholders cannot agree about including a requirement, it is allocated to the next consecutive release, as long as doing that makes sense.  This provides opportunities to revisit the requirement when planning for that later release, essentially postponing the negotiation of that requirement rather than rejecting it.

12 - Re-plan before every new release:

This prevents using decisions based on “yesterday’s information”.  The environment changes.  Resources change.  Requirements and needs change.  Stakeholders change.  These events are occurring independent of planned releases.  Therefore, it is important to revisit and re-negotiate the requirements for each release to address any changes that may have occurred and revise the overall plan accordingly.  Relative priorities established at the time of the previous release may need to be adjusted in light of changes in the environment, technology, or budget.

 13 - Find a workable solution:

Make the commitment up front to find a solution before ending negotiation.  Do not let arbitrary schedules dictate the outcome of negotiation.  Do not be intimidated into a solution that is not perceived as workable.  If the team accepts a schedule that has an unacceptably low probability of success, everyone loses, because it creates false expectations of a release, and often results in either poor quality or late delivery.  When time is critical, accepting a schedule that is technically feasible but does not deliver the desired product in time, is just as devastating.  Realistic solutions to such scenarios may involve re-scoping the functionality of each release, seeking innovative combinations of releases, or using the right tools to demonstrate the likelihood of success for proposed solutions.  Remember that perfection is impossible.  It may be better to be 90% correct now than 95% correct six months from now.  Negotiation seeks to find the right balance among stakeholders’ needs and constraints.

 14 - Provide training in the negotiation process:

The curriculum for IT professionals (who become analysts, project managers and requirements engineers) and most technical professional roles, rarely includes courses on negotiation, or managing stakeholder relationships, or such soft skills as collaborative techniques.  It is, therefore, important to ensure that key stakeholders involved in any requirements negotiation receive training in the negotiation process itself, prior to their participation on the team.  This is particularly true for the project manager or requirements engineer who may be expected to lead the team and plan the negotiation effort. 

 15 - Use a trained facilitator:

It may be extremely difficult for the developer to lead a negotiation effort because the developer is essentially a stakeholder with a particular viewpoint.  A facilitator needs to be independent of the stakeholders involved in the negotiation.  Their role is to focus on building relationships of trust and ensuring that each stakeholder has optimum participation for their respective role.  The facilitator establishes the environment for teamwork and efficient use of time, thus increasing stakeholder perceptions of productivity and the overall likelihood of success.

16 - Consider requirements, architecture, and marketplace simultaneously:

This practice applies specifically to COTS-based systems. Literature from the Software Engineering Institute (SEI) [Brownsword, 2000] asserts that COTS-based development involves composition and reconciliation, whereas custom system development is an act of creation.  While custom development starts with the requirements and creates a system that meets them, COTS-based development starts with a general set of requirements and then explores the marketplace’s offerings to see how closely they match the needs.  Engineers then integrate the products they buy into a system that meets the need.  The nature, timing, and order of activities performed and the processes used differ accordingly. Marketplace characteristics determine the future of a COTS-based endeavor.  The marketplace, not the needs of a particular system, drives COTS products changes.  Licensing affects cost, architecture, and user processes.  COTS product releases are independent from a given projects need.  COTS products have interdependencies and may conflict with evolving system architecture.  Any of the three drivers (architecture, requirements and marketplace) may affect the other two so none can proceed without accommodating the others.  Trade-offs occur frequently throughout the system’s lifetime.  This, in turn, necessitates changes in the processes used to develop COTS-based systems.  It becomes a business, organizational, and cultural change.

Note: A significant body of literature exists that addresses requirements trade-offs with respect to designing the architecture of the system.  However, this is not the focus of this practice, even though the activities of the practice are applicable to resolving conflicts between the functional requirements and the architectural design of the system.  Refer to the “Architecture First” Gold Practice [Architecture-First Approach] for greater detail on the concurrent evolution of requirements and architecture.

17 – Leverage the Triple Constraint:

The Triple Constraint is a project management term, also known as the Tetrad-Tradeoff Principle, the Holy Trinity, and the Iron Triangle, and usually illustrated with a triangle.  In theory, it means that the key project variables (typically cost, time and scope; most variables fit into one of these categories) are interconnected and cannot change without a corresponding balancing change on one or more of the remaining variables, just as adjusting the length of any one side of a triangle, in turn, affects the lengths of the remaining sides.  Scope refers to the necessary work to be performed in order to produce the desired project results – the functional requirements or features of the software product.  Time is defined as the duration of time it will take to complete the defined scope of the project.  Resources include the money and effort expended on people (labor), services and products.  Without an agreement to balance, as well as prioritize, these three dimensions (variables), there cannot be a reasonable commitment to reaching the project’s goals [Nelson, 2003].  Although seen as the responsibility of the project manager, stakeholders must be involved in the relative prioritization.  One way of doing this is to develop a 10% value chart [Barker, 2000].  Figure 4 is a sample chart extracted from Barker’s article titled “How Much is 10 Percent Worth?”

Figure 4: 10% Value chart for a Typical New Product Development [Barker, 2000]

The chart presents the estimated project dollar value impact of increasing/decreasing schedule, scope, and cost, respectively, by 10% (as expressed by stakeholders).  The component that is most important to the stakeholders is always the longest line on the chart.  It is a snapshot in time depicting how stakeholders view the triple constraint.  Using this chart early, as part of the negotiations process, helps to set expectations that there will be changes, and that the plan will be adjusted in accordance with the trade-offs discussed.  It also helps to quantify the relative importance and, therefore, provides an objective tool for achieving concurrence of the group on the relative priorities of the constraints.  The prioritization of the triple constraint can, and will, change throughout the life of the project.  It is important to communicate with stakeholders about how and why the changes are occurring, and what the new prioritization is.  The chart helps all stakeholders maintain awareness of these changes over time.

The 17 practices above represent the collection of practices gleaned from recent literature.  In his recently published “Requirements Engineering Handbook”, Young [Young, 2004] lists 30 best practices for requirements development and management.  Although he does not specifically mention the term “requirements negotiation” in that context, many of the listed practices (see Table 3) apply to the requirements negotiation process, as well as other requirements engineering processes, and reiterate the practices identified above.  He equates requirements negotiation with getting to the “real” requirements.  Some of those practices are as follows.  The wording of the practice statements reflects the perspective of the Requirements Analyst’s role.

Table 3:   Best Practices for Requirements Development and Management

Practice	Notes Relative to the Negotiation Process
Identify and involve all of the stakeholders in the task or project	Ensure that each stakeholder role is involved in the negotiation process
Ensure that the objectives of the project have been identified, documented, and agreed to by the stakeholders	Begin by creating the initial shared vision of what is to be built
Use requirements workshops to achieve a shared vision, facilitate commitment, and gain the buy-in of all stakeholders	It is critical for stakeholders to hear each other’s perspectives, and rationale, in order to cement the shared vision
Identify the real requirements.  Collaborate with customers and users concerning the stated requirements to identify the real requirements.  Look at the requirements from multiple viewpoints.	Can we collectively derive statements that provide a common understanding, address the domain scope, and provide real direction to the developer
Document the rationale for each requirement	Capture rationale as an artifact.  Why is this requirement listed?  What are its origins?
Use effective requirements gathering techniques	Collect requirements from multiple sources and organize them into a hierarchical structure
Involve customers and users throughout the development effort	Continuous communication prevents deterioration of the shared vision
Do not make requirements decisions	Do not assume you know better what the requirement really means than its originator.  Do not make arbitrary re-writes of requirements without consulting the source, and without a team review.  The real intent of the requirement is what must be preserved.
Use a project glossary and a project acronym list	The glossary is necessary in order for the team to develop and use a shared common vocabulary
Iterate the requirements and the architecture repeatedly to evolve better requirements and a more robust architecture	This is really about the right stakeholders identifying issues (architecture requirements), proposing options, and making agreements or requirements trade-offs
Utilize domain experts/ Subject Matter Experts (SMEs) who are knowledgeable and experienced in the functional areas being addressed by the technical effort	Domain experts need to be on the negotiating team to present issues and options based on their domain knowledge that is not otherwise available or known by other stakeholders. They also contribute to development of the shared vocabulary.
Identify the minimum requirements that meet real needs	This is analogous to performing requirements triage, and determining when negotiations are complete – when agreements have been reached regarding all the requirements
Prioritize requirements early and often	Revisit prioritization process whenever new requirements emerge
Use versions and releases of work products to accommodate new, changed and lower priority requirements	Move a requirement to a later release when stakeholders are at odds over whether or not to include it.  This essentially postpones negotiation until later versions.
Use an industrial-strength automated requirements tool.  Provide and use attributes of requirements	The selected tools (sometimes called Group Support Systems or Collaboration tools) that support the negotiation process should be integrated with, or interface with, tools selected for requirements management and for project management.  The tools must provide for collaborative workflow and capture requirements negotiation artifacts.
Develop or tailor and use project requirements policies and a requirements process that has continuous improvement built in.  Invest 8% to 14% of total project costs on the requirements process.	Develop policies and a process for negotiation and ensure that it is applied consistently.  The policy should address structuring of the team, leadership, and appropriate training of requirements analysts, project leaders, and stakeholders.
Develop, implement and enforce meeting rules that describe how project staff members are to treat one another	Plan team interaction. Determine what forums to use for effective outcomes.  Consider use of a facilitator, face-to-face meetings, distributed collaboration, etc.
Develop and apply a set of guidelines for effective meetings and guidelines for effective e-mailing	Ensure participants receive training in the use of Group Support Systems, and that “people” issues are addressed as part of that training
Perform a risk assessment of new and changing requirements	Analogous to analyzing new requirements and identifying potential issues
Learn how to manage teams effectively	Get appropriate training for stakeholders
Establish a quality improvement and process improvement climate	Foster/encourage a collaborative team environment where stakeholders feel comfortable raising issues and proposing options

 

 

Characteristics of implementation

 

Summary characteristics

Enabling Practices            Link to Requirements Trade-off Interrelationships Diagram

Enabled Practices:            Link to Requirements Trade-off Interrelationships Diagram

Impact Areas:                      Cost, Schedule, Risk, Technical Performance

Life Cycle Phase:               Concept and technology development (requirements and design) and support/maintenance of existing systems

Scope/Authority:                Project-level and above

Applicability:                        Acquisition; development

Use Indicators:                   Whenever time, scope, or resources are fixed, or requirements exceed the budget, budget not firm, inaccurate cost estimations or cost overruns

Use Inhibitors:                    None indicated

Appropriate Programs:     Software-intensive acquisitions, maintenance or operational projects

Inappropriate Programs:  Small, single product

Barriers:                                Political/cultural issues (turf, responsibility, accountability); rigid contractual agreements that freeze requirements, no access to users, inadequate resources allocated to requirements engineering

Facilitators:                          Strong leadership, RM tools, flexible contracts, iterative development approach, resources and budget allocated to requirements engineering

 

ANTICIPATED BENEFITS OF IMPLEMENTATION:

 

Adopting systematic requirements negotiation processes and techniques that support gathering, elaborating and negotiating the stakeholder objectives can positively influence project success in several aspects: [Grunbacher, 2002]:

§        More complete requirements in the early stages of a project – which in turn results in fewer changes during development

§        Enabling a shared vision – which is crucial when conditions in the environment trigger requirements changes.  The shared vision supports the re-negotiation during requirements change.

§        Dealing with changes – Negotiation methods preserve the rationale of decision making, thereby easing the task of reversing decisions about earlier assumptions.  It becomes a tool that aids projects that have to pursue a moving target, revisiting earlier objectives to see if they are still valid as conditions change.

§        Control of “Scope Creep” – According to Capers Jones, founder and chief scientist of Software Productivity Research LLC, even well-planned projects exhibit requirements expansion of up to 2% on their own each month throughout the project’s duration.  Negotiation, relative to incremental release planning, keeps the project focused on core functionality through continuous prioritization (“must haves”, “should haves” and “nice to haves”).

Detailed characteristics

 

Key Characteristics of the “Requirements Negotiation” Gold Practice

Characteristic	Comments
Applicable to a majority of requirements	§         Between 40% and 60% of requirements involve conflicts
Facilitates conflict resolution	§         Most conflicts are simple to resolve.  In Boehm’s research [Boehm, 1999] most conflicts (45% to 69%) required only one resolution option before an agreement was reached.
Involves success-critical stakeholders	§         The stakeholder roles of User, Customer and Developer contribute in varying ways to the project.  Users and Customers contribute more to requirement identification, while Developers contribute more to conflict and resolution identification §         Stakeholders must be those that have decision-making authority.
Non-functional requirements involve the greatest conflict	§         Operational requirements tend to have only half as many conflicts as non-functional requirements §         Non-functional requirements are more likely to be overlooked in the elicitation process, but tend to surface during the negotiation process §         Identifying conflicts is extremely difficult
Collaborative cultural environment	§         This practice requires a collaborative “people” environment where there is mutual respect among stakeholders §         Not intended for use in adversarial scenarios and, therefore, not effective unless stakeholders are committed to a common goal
Supported by  collaboration tools	§         Use of computer-based Groupware Support tools, such as databases, collaboration/work flow tools, and online meeting software are necessary for a successful implementation of the practice, especially on large projects. §         Studies have shown that remote location of stakeholders using collaboration tools gets better results than face-to-face meetings.

 

Relationships to other practices:

 

The figure below represents a high-level process architecture for the subject practice, depicting the nature of the influences on the practice (describing how other practices might relate to this practice). These statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices.  A brief description of these influences is included in the table below.  The arrangement of the statements in the figure and corresponding table does not imply any particular order or sequence in which they should be addressed.

 

Process Architecture for the "Requirements Negotiation" Gold Practice

 

Note: In the table below, specific Gold Practices with strong relationships to Requirements Negotiation are identified with italics.

Summary of Relationship Factors

INPUTS TO THE PRACTICE
Select and use appropriate tools	Because of the complexity of the process and the sheer volume of artifacts it uses and generates, it is important to support the process with appropriate tools.  Configuration Management strategies, an accepted practice for managing the code development, should be extended to include the requirements elicitation and refinement process and its artifacts.  Collaboration tools, group support systems, and requirements management tools are, for the most part, specific applications of a configuration management strategy, identifying the items to be controlled and tracking them through changes.  The major difference is that the requirements tools tend to focus on workflow and real time sharing of artifacts among the collaborators, while standard configuration management tends to focus on the entities themselves. In selecting a tool for requirements management/negotiation, it is important to assess how well the tool meshes with existing configuration management tools.  Developers accustomed to using CM tools will probably demand similar support tools for requirements negotiation.   Another practice that can have a positive impact on the requirements negotiation process is Track Earned Value.  An organization that is comfortable with the Earned Value approach has already learned about the value of deriving accurate estimates of work.  They will be able to generate reasonable estimates of effort for the requirements and those estimates will be valuable for prioritizing requirements and addressing release issues. Having confidence/trust in effort estimates is an important factor in the decision making process.
Plan stakeholder involvement	Involving key stakeholders is a critical element of the process.  Integrated Product and Process Development (IPPD) is premised on having Integrated Product Teams (IPTs) to address all issues relating to product development. The IPT creates the optimal environment to support requirements negotiation because the key stakeholders are involved by definition of the team, and the team is ongoing.  The shared vision is built in and continuously updated as the team addresses the issues of product development.    Management, on both the government side and the developer side, is responsible for ensuring that qualified people are allocated to the task.  For example, the lead requirements engineer should have people skills as well as technical knowledge; trained facilitators are used when appropriate; domain expertise is brought in as needed; resources are provided to the team for tool acquisition; and the team is not pressured by an arbitrary deadline for completing negotiations.  These factors are addressed in the practice called People Aware Management Accountability.
Establish an environment where negotiation can work	The right people, and the right resources, must be allocated if the negotiation process is to be successful.  People Aware Management Accountability addresses making commitments conducive to establishing a teamwork mentality and fostering high morale, in addition to providing resources, tasking the right people and providing training.   Acquisition practices can severely hinder or even prevent the success of a negotiations process.  Specifically, when the requirements are finalized by the acquirer, without involvement of technical expertise (and often before a developer is selected) and then attached to a contract, it can limit what is negotiable and often break down the team culture that is such an important element of successful projects.  Evaluating proposals against the requirements does not really provide the opportunity for the acquirer and developer to establish the shared vision, because it is seldom an iterative process.  Communication between candidate developers and the acquirer is one-way.  Acquisition Process Improvement (API) seeks innovative ways to involve the developer(s) in the process of making requirements trade-off decisions and, more specifically, providing true and accurate estimates to the negotiation process.  Contracts need to allow for flexibility in addressing the high-level contractual requirements, rather than force developers into adhering to detailed requirements that are unrealistic, technically incorrect, or simply not valid. Acquisition strategy needs to find ways to define criteria for project success so that developers can respond with innovative, and yet cost effective, solutions that allow for refinement of requirements through negotiation AFTER contract award.  Without consequences for late delivery, incomplete work, or cost overruns, there is no incentive for contractors to bid true.  API, therefore, needs to address creative ways to reward contractors for bringing projects in on time and within budget, and for satisfying negotiated (real) requirements.
Identify conditions for success and issues	Inputs to the negotiation process are requirements, or rather, stakeholder perceptions of requirements and issues.  This includes all types of requirements typically grouped into two categories: functional, and non-functional.  The functional requirements address the capabilities and operational features of the software product, but the non-functional requirements can be almost anything.  They may address performance, dependability, interoperability, usability, adaptability, reusability, affordability, timeliness, risk, and a host of other things too numerous to mention.  Such non-functional requirements are sometimes not perceived as requirements, but rather as constraints, or issues that have a bearing on the functional requirements.  Including them as targets for negotiation ensures more thorough coverage  early in the product cycle, and allows risks to be identified, issues resolved and a risk strategy developed early, thus preventing problems from developing.  The Ensure Interoperability practice addresses defining interoperability requirements and then managing them throughout the life cycle.    Assess Reuse Risks and Costs deals with identifying and planning for reuse in two ways: (1) designing software for reuse, and (2) identifying opportunities for reuse.  Further, it addresses understanding/assessing the costs of reuse and the inherent risks involved.  This practice may be helpful if reusability and affordability are key issues (requirements) under consideration.
Explore options and alternatives	Several practices may be helpful for exploring options and alternatives as part of the negotiation process.  Assessing Reuse Risks and Costs can assist with identifying attributes for reusability requirements (risk, cost, effort).   Plan for Technology Insertion provides guidance for preserving the functionality of the product over time while migrating to new, perhaps more affordable, technology.  This practice may assist development of options to address performance, dependability, interoperability, adaptability and affordability requirements.   Leverage COTS/NDI addresses the process changes that need to occur in development organizations in order to develop and maintain COTS-based systems and achieve the benefits of such systems.  This practice may assist in proposing options (solution sets) to satisfy requirements.
OUTPUTS FROM THE PRACTICE
Manage both inputs and outputs of the negotiation process	The negotiation process is now viewed as a component of Requirements Management. It either creates or uses requirements artifacts usually produced by the requirements elicitation process, and produces many artifacts that become the drivers for design.  Both the artifacts and the process must be managed in order to derive benefit for the project as a whole.  Manage requirements follows up with the negotiated agreements to allocate requirements to design and track the implementation to ensure that the requirements are satisfied.    It is important to apply the practice Capture Artifacts in Rigorous Model-based Notation to the output of the negotiation process. Selecting the right tools to support the negotiation process enables this to happen, and allows the project to better manage and utilize the artifacts for purposes of design, testing, tracking requirements and reporting progress.
Refine requirements and architecture in parallel	Chang [Chang, 2003] asserts that an inadequate architecture can severely constrain the ability to fulfill critical non-functional requirements, and that a synergy must exist between the process of refining requirements and architectures.  Negotiation is, in fact, a refinement process.  Non-functional requirements drive the selection and refinement of the software architecture, yet at the same time the architecture is necessary in order to optimize and balance the requirements. This is resolved by using an incremental approach in which initial requirements are elicited and specified at the high and often fuzzy level, and then used to guide/drive the identification and selection of suitable candidate architectures.  This simultaneous focus on architecture is addressed in the Architecture-first Approach.
Assess progress in generating a requirements solution set	Depending on how the artifacts of negotiation are captured, they facilitate gathering quantitative data for assessing progress of negotiation and progress of the project as a whole, since negotiation is cyclic, reoccurring with each planned release or as requirements change.  It is possible to track the number of requirements targeted for negotiation, the number of issues, options and agreements relative to those requirements, and the effort expended on negotiation.  Quantitative Progress Measurement addresses determining what data to collect and how to use it to generate and report accurate assessments of progress on a project.

RESOURCES:

 

§        Websites

Requirements Negotiation/Collaboration Process

These websites are focused on either the negotiating concept, collaboration support, or, specifically, requirements negotiation with group support systems.

0            USC Center for Software Engineering website – addresses the WinWin Spiral Model for Requirements and the Groupware Support System.
http://sunset.usc.edu/research/WINWIN/index.html

     

0            Ralph Young website – dedicated to improving requirements practices.  Our mission is to provide ideas, suggestions, recommendations, and resources for those who must understand and manage customer requirements in the systems and software engineering world.
http://www.ralphyoung.net/

 

0            IEEE Distributed Computing Online website – maintains a topic area on collaborative computing.  Initially it will focus on Collaborative authoring and editing, and Groupware (infrastructure for welding dispersed groups together),  The site will address some of these questions:

·      What tasks are done in groups, and why?

·      How do groups cooperate to get those tasks done?

·      Which tools can computer science construct to improve the process?

·      How should those tools be constructed?

·      How well do those tools work in the real world, and why?

      

       http://dsonline.computer.org/collaborative/

 

0            Collaborative Groupware Software – focused on open source software projects relating to groupware and collaborative activity.  The site is probably more useful to those tasked with building open source groupware tools, than those intending to use the tools.
http://sunset.usc.edu/research/WINWIN/index.html

      

0            Usability First Groupware– focused on groupware, computer-supported cooperative work (CSCW), and associated design and usability issues.  Has extensive links to Groupware resources, including empirical studies of Groups and Groupware use.  Probably most useful to those responsible for selecting or building tools to support the requirements management/negotiation process.
http://www.usabilityfirst.com/groupware/index.txl

      

0            DACS Topic Area on Collaborative Software Engineering – has a section on Computer Supported Collaborative Work (CSCW).
http://www.thedacs.com/databases/url/key.hts?keycode=2248

      

 

Requirements Management

These websites focus on requirements management and requirements engineering and may have a topic or section about requirements negotiation.

 

0            Managing Requirements.  This site provides practical information about requirements management for clients, project managers, analysts, quality assurance professionals, or students, as well as offering consulting services.

http://www.jiludwig.com/

 

0          International Council of Systems Engineering (INCOSE) Requirements Working Group (RWG).  The vision of the RWG is to be the acknowledged leader in advancing the state of the theory, education, and practices of requirements engineering and management in the systems engineering community.

http://www.incose.org/practice/techactivities/semanagement/rwg.aspx

 

0         Software Program Managers Network (SPMN) describes 16 Critical Software Practices for Performance-based Management.  One of the key practices is “Manage and trace requirements”.  

http://www.spmn.com/16CSP.html#requirements

 

0         Software Program Manager’s Network (SPMN) Lessons Learned (1998) is a bulletin that identifies lessons learned and current problems relative to various software related topics, including requirements management.     

         http://www.spmn.com/lessons.html#four

 

0         Successful Delivery Toolkit, Office of Government Commerce (OGC), United Kingdom has a section  dedicated to requirements management

     http://www.ogc.gov.uk/sdtoolkit/reference/deliverylifecycle/reqments_mgmt.htm

 

§        Tools and Methods

 

A multitude of methods and tools may be useful in implementing and improving the effectiveness of requirements negotiation.  However, most tools are designed to support the broader perspective of Requirements Management (RM), or are marketed as collaboration tools.  The first table contains RM tool surveys that are being updated continually on the web.  The second table identifies some more specific tool sources.  Readers are encouraged to share information about tools in use, and their effectiveness, by establishing a thread in our Gold Practice discussion forum for this practice.   You must be a Gold Practice member to contribute to the discussion forum.  The site has a link for applying for membership.

 

[The fact that a tool or tool vendor is listed (or not listed) here does not constitute an evaluation or endorsement of the product or vendor by the DACS.  These are simply links to tools currently available relative to the subject practice.]

Requirements Tool Surveys and Assessments

 

Requirements Engineering Tools

 

 

§         Experts and Contact Points

 

Barry Boehm, Director, USC Center for Software Engineering, and past Director of the DARPA Information Science and Technology Office, has written hundreds of papers and given hundreds of presentations on software engineering throughout his career.  He and his colleagues developed the WinWin Spiral Model for Software Development, and the WinWin Model for Requirements Negotiation.  His research from the 1990s has focused specifically on requirements negotiation.

e-mail: boehm@sunset.usc.edu
Phone: (213) 740-8163
FAX: (213) 740-4927

http://sunset.usc.edu/Research_Group/barry.html

 

Walker Royce, Vice President and General Manager at Rational Software Corporation, has led Rational in developing the Rational Unified Process for requirements. 

     See http://rational.com/

      

Karl Wiegers, Principal Consultant with Process Impact of Portland, Oregon, has authored several books and articles on requirements engineering and, more specifically, requirements management.

       E-mail:    mailto:kwiegers@acm.org

       http://www.processimpact.com/bio.shtml

 

Donald Reifer, Reifer Consultants, Inc., is one of the leading figures in the field of software engineering and management, with over 30 years of progressive experience in both industry and government.
       Phone: (310) 530-4493
       Fax: (310) 530-4297
       Email: info@reifer.com

 

Ralph R. Young is Director of Engineering Process Improvement in Defense Enterprise Solutions (DES) at Northrop Grumman Information Technology (IT).  DES is a Capability Maturity Model Integrated (CMMI) Level 5 organization.  Dr. Young was a member of the CMMI Level 5 SCAMPI (Standard CMMI Appraisal Method for Process Improvement) Team, and is an avid reader of industry literature.  He leads the DES Requirements Working Group of over 50 requirements engineers.  He teaches the 10-hour "Requirements Course for Practitioners" and consults frequently about both requirements engineering and process improvement for DES' internal and external customers.  Dr. Young offers a commercially available "Effective Requirements Practices Workshop" to assist organizations and enable organizational improvement.

          Phone: (703)556-1030

       Email: ralph.young@ngc.com

       http://www.ralphyoung.net/biography.html

§         Training Opportunities

The fact that a course is listed (or not listed) here does not constitute an evaluation or endorsement of the course by the DACS.  These are simply links to courses currently available relative to the subject practice.  In the interest of keeping the document manageable, the following types of training have not been included:

§         Pure consulting services

§         Training courses primarily based/offered outside of the continental US.

§         Courses focused on broader areas with requirements engineering as a component

§         Tool–specific training courses

 

Many of the vendors offer a virtual classroom alternative to the traditional classroom training, and many offer on-site training opportunities.  Click on the links provided to get this type of information.  The first table below lists training opportunities focused on requirements management with some sections addressing requirements negotiation, or involving stakeholders.  The second table below lists training opportunities in negotiating techniques and developing negotiating skill.

Courses on Requirements Management that Address Elements of Negotiation and Trade-off

 

Training on Negotiating Skills

 

 

         Bibliography

 

 

APPENDIX A

DEFINITIONS:

Requirements Negotiation - Resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, or between requirements and resources, or between capabilities and constraints.

SOURCES (Origins of the Practice):

 

Although defining requirements has existed as part of the software life cycle since the 1970s, the focus on managing requirements did not develop until the mid-1990s when the Software Program Managers Network identified it as one of their 16 critical practices  [SPMN, 1998].  In the same time frame, Barry Boehm and others at the University of Southern California were conducting research about making requirements trade-offs in conjunction with the spiral model for software development.  He and his colleagues developed at that time the WinWin Negotiation model, which utilized a computer-supported collaborative work system.  This model is still the focus and driving element of requirements negotiation today.  

RECOMMENDING SOURCES:

[This section identifies segments from specific DoD, industry, or academic sources that recommend, specify or otherwise support adoption of the subject practice either directly, or as part of a broader best practice initiative, or a practice with a different name.]

§         Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

Although it does not specifically use the term manage requirements, it essentially directs that activities be done that are comparable to managing requirements.

§         Capability Maturity Model Integration (CMMI), Version 1.1, Software Engineering Institute, CMU/SEI-2002-TR-011, TR-012, March 2002 [CMU/SEI-2002-TR-011], [CMU/SEI-2002-TR-012]   

Requirements negotiation and trade-offs are implied by the high level descriptions of several key process areas, Requirements Development, Requirements Management and Technical Solution.  The following statements are extracted from various paragraphs within these key process areas.

“The Requirements Management process area maintains the requirements.  It describes activities for obtaining and controlling requirement changes and ensuring that other relevant plans and data are kept current.  It provides traceability of requirements from customer to product, to product component.”

 

“When a project receives requirements from an approved requirements provider, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project’s plans.”

 

“Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements.  This activity continually assures them that the requirements are being properly defined.”

 

§         Report of Defense Science Board Task Force  on Defense Software, November 2000

The Task Force asserted that although there are many challenging technical issues, the major factor in successful software development is disciplined execution.  Therefore, it made several recommendations including “collect, disseminate, and employ best practices.”  The Task Force strongly endorses the following best practices:

§         Executable architectures

§         Iterative design/development

§         Requirements trade off

 

Regarding requirements trade-offs, the task force states: “In general, systems are over-specified, and in most cases there is no flexibility to adjust the specifications.  The acquisition/development team must have latitude to trade requirements for cost, schedule and risk.  This does not mean that overall system integrity can be compromised.”

 

§         GAO Report on Defense Acquisitions, March 2004 [GAO, 2004]  

The consensus of this report was that stronger management practices are needed to improve DOD’s software-intensive weapons programs.  The report goes on to state that the success (quality software product, on time and within budget) of leading software companies is attributable to creating a manageable evolutionary development environment, using disciplined processes, and useful metrics such as earned value.  A great deal of management attention is placed on the requirements-setting phase because missing, vague, or changing requirements tend to be the major cause of poor software development outcomes.

 

 

GLOSSARY

10% Value Chart	A chart that lets stakeholders and the project team discuss and capture vital information about relative priorities in the triple constraint - schedule (time), performance (scope), and resources (cost).  See [Barker, 2000].
Airlie Council	Refers to a group of experts convened by the Navy’s Software Program Manager’s Network (SPMN) in 1995 who established/identified nine best practices.  These practices have been augmented with other practices since 1995, and in current literature are referenced as the original Airlie best practices.
Best Practice	A documented practice aimed at lowering an identified risk in a system acquisition and is required or recommended by a bona fide DoD, industry, or academic source. -    [Turner, 2002]   Methodologies and tools that consistently yield productivity and quality results when implemented in a minimum of 10 organizations and 50 software projects, and are asserted by those who use it to have been beneficial in all or most of the projects. -    Jones, “Software Assessments, Benchmarks, and Best Practices”, 2000
Collaborative Computing	Collaborative computing, or computer supported cooperative work (CSCW) is the discipline that deals with using computers to support groups of people as they cooperate to achieve their goals.
COTS	Commercial Off-The-Shelf
CSCW	Computer Supported Cooperative Work – see Collaborative Computing
Derived Requirement	A logical extension of a higher level requirement
Facilitation	The art of leading people through processes toward agreed-upon objectives in a manner that encourages participation, ownership and productivity from all involved
IKIWISI	I’ll Know It When I See It
RDM	Requirements Definition and Management
Requirements	Capabilities and objectives to which software must conform, the common thread for all development activities.
Requirements Allocation	The assignment of responsibility for satisfying requirements to subsystems. Source: [SWEBOK, 2001]
Requirements Baseline	The set of requirements that has been formally reviewed and agreed upon, that serves as the basis for further development.  Can be changed only through formal change control processes.  Source: California Health and Human Services Agency Data Center (CA-HHSADC).
Requirements Change Control	Ensuring proposed changes to requirements are appropriately analyzed for impacts to cost, schedule, staffing, and risk, and ensuring approved changes are implemented in a controlled manner.  Source: California Health and Human Services Agency Data Center (CA-HHSADC).
Requirements Management	The process of eliciting, documenting, organizing, and tracking changing requirements and communicating this information across the project team to ensure that iterative and unanticipated changes are maintained throughout the project lifecycle. Spans the whole software life cycle.  Fundamentally addresses change management and the maintenance of requirements in a state that accurately mirrors the software to be, or that has been built.  Source [SWEBOK, 2001] The process of controlling the content and scope of a system through its requirements.  Includes creation and management of the baseline, change and version control of requirements, and traceability of requirements to implementation and verification.  Source: California Health and Human Services Agency Data Center (CA-HHSADC). The planning and controlling of the requirements elicitation, specification, analysis and verification activities.  Source [Sud, 2003]
Requirements Negotiation	Engaging in the explicit trade-off between required functionality, schedule, time, project/product stability, and risk without compromising overall system objectives.
Requirements Traceability	A subset of requirements management that traces the requirements through the entire system lifecycle.  Source: California Health and Human Services Agency Data Center (CA-HHSADC).
Requirements Validation	The process of examining the requirements document to ensure that it defines the right system (i.e., the system that the user expects).
SME	Subject Matter Expert
SPMN	Software Program Managers Network
Software Requirements Specification (SRS)	A structured collection of information that embodies the requirements for the software programs of a system.  Source: California Health and Human Services Agency Data Center (CA-HHSADC).
SWEBOK	Software Engineering Body of Knowledge
WinWin Negotiation Model	A requirements negotiation model that incorporates Boehm’s Theory W, “Make everyone a winner”, into the negotiation process.  Stakeholders begin by entering their Win Conditions.  Conflicts among stakeholders’ Win Conditions are identified and recorded as Issues.  Stakeholders propose options to address the issues, and make agreements to adopt one or more options.  The process is complete when all the win conditions are covered by the various agreements.
WinWin Spiral Model	A software development model that augments the Spiral Model for software development with Boehm’s Theory W, “Make everyone a winner”,  by adding three initial steps to the spiral: 1 – Identify next-level stakeholders, 2 – Identify Stakeholders’ win conditions, and 3 – Reconcile win conditions.
Use Case	A technique for reasoning about/describing the behavior of a system in a concrete setting - a technique for capturing functional requirements and making them concrete instead of conceptual.

 

CASE STUDIES from the literature:

Using Different Communication Media in Requirements Negotiation

By Daniela E. Herlea Damian, Armin Eberlein, Mildred L. G. Shaw, and Brian R. Gaines, University of Calgary

Published as a feature article in IEEE Software May/June 2000

http://www.softwarebusinessonline.com/newsletter2_april04.htm

 

Description:

This research focused on investigating both the group performance and interpersonal relationships involved in distributed requirements engineering and conducted laboratory experiments that compared the performance of groups negotiating requirements in face-to-face meetings with that of distributed groups using real-time computer conferencing.  The experiment investigated the effects on group performance of both the communication media and different physical configurations of customers and developers.  The scenario involved communication between a system analyst and two customers, mediated by a facilitator.  The system analyst indicates that it is impossible to implement the system in the given period, forcing the customers to work toward agreement on a subset of the original requirements.  Participants were drawn from the University of Calgary student population.

Results:

§         Contrary to traditional wisdom, the authors found that when it comes to requirements negotiations, groups meeting face-to-face perform no better than those using video conferencing and computer support

§         A particular distributed group configuration (customers holding conflicting views were physically separated from each other and co-located with the analyst or facilitator) significantly improved performance and was more conducive to negotiation than face-to-face meetings

§         The highest group performance occurred when customers were physically separated from each other and collocated with the facilitator or system analyst

§         Electronic mediation created a more task-oriented environment

 

Easy WinWin: Managing Complexity in Requirements Negotiation with GSS

By Robert O. Briggs, GroupSystems .com, and Paul Gruenbacher, Johannes Kepler University, Linz, Austria

Published in Proceedings of the 35^th Hawaii International Conference on System Sciences, 2002

 

Description:

More than 50% of large-scale software development projects suffer the doubling of budgets and schedules, and 25% fail outright.  Much of this overrun and failure is attributed to flawed requirements.  The requirements task is fraught with complexity.  This article reports on some sources and causes of complexity that emerged during more than 50 requirements negotiation workshops conducted during a two-year effort to develop and deploy a new requirements negotiation methodology.  This study focuses on the steps of EasyWinWin, a GSS-based requirements negotiation method, and how each step of the method addresses task complexity.

Results:

Some general results are:

§        Group Support Systems (GSS) can be useful to help manage the complexity inherent in requirements collection

§        Using GSS a team can significantly cut the cognitive load of communication and deliberation

§        Having only success-critical stakeholders involved can short-circuit the negotiate-repudiate-renegotiate cycle, which should, in turn, reduce coordination complexity – the frequency and intensity of interactions required to achieve the requirements

§        Use of an electronic brainstorming tool can surface many win conditions in a short period of time and promote stakeholder understanding of other stakeholder views.  A team of 10 stakeholders typically contributes about 300 ideas in an hour-long brainstorm.

§        This negotiation approach is applicable for activities not related to software as well: action planning and process improvement for example

§        The EasyWinWin is extremely helpful to structure the negotiation activities and allows the team to handle a much higher volume of information than a traditional paper or blackboard-based negotiation process would

§        Requirements projects using EasyWinWin typically require weeks rather than months to complete, and the resulting requirements have an order of magnitude increase in detail

§        The most difficult challenge is still the identification of conflicts among win conditions.  The interdependencies among win conditions may be subtle and varied.  There is a need for research in using intelligent agents to flag potential conflicts.

§        It is important to integrate the GSS with other requirements management tools

 

An Empirical Study of Requirements Engineering in Distributed Software Projects: Is Distance Negotiation More Effective?

By Daniela Damian, University of Technology, Sydney, Australia, 2001

Note: This is a synopsis of the research addressed in Damian’s other article from IEEE May/June 2000 (see above) from a slightly different perspective.

Description:

This research investigates requirements communication processes in distributed software development, determining the factors that enable virtual organizations to conduct requirements meetings efficiently.  Multimedia Web-based meeting tools, such as NetMeeting, are becoming ubiquitous for communication on the Internet. This study used NetMeeting in a laboratory setting to facilitate communication from two remote sites. Groups established included the role of facilitator, two negotiators (system users), and a system analyst.

Results:

Lessons Learned are:

§         Group Performance in face-to-face requirements meetings was no better than in distributed group meetings.

§         Remote collaboration of the two systems users benefited the negotiation.

§         The co-location of the two system users was helpful, but not beneficial.  Participants indicated that face-to-face interaction made them less willing to voice opinions and suggestions, less objective, and created feelings of sympathy or compassion for the co-located user.

§         Use of a shared electronic workspace was particularly useful in the requirements negotiation.

§         The video channel was useful in negotiation.  Participants chose to focus on the task object, rather than on the faces of the remote participants.

§         Human facilitation of distributed requirements negotiations was possible.  A perceived detachment from the group interaction and the slowing down in conversation enabled an enhanced ability to stay objective and assist the group process.

§         Initial face-to-face contact before the computer-mediated meeting is important.