Once we've identified overlapping statements and documented them using techniques like the interaction matrix, we now need to generate conflict resolutions. In your elicitation process, you may already have come up with some alternatives that could be used. Explore those alternatives, those countermeasures first, then compare and select the most preferred alternatives. In order to generate more candidate solutions, go back through the elicitation that was already performed and perhaps, perform more focused interviews and group sessions based on the conflicts that you have identified. Do start this as early as possible, to reduce the number of interviews and group sessions needed. And definitely, generate conflict resolutions before the software development starts or at least as much as possible. If you don't, then, developers could be developing from inconsistent statements. In an agile process, this is going to be done repeatedly. But it's a little bit easier in the Agile situation because they're you're working in vertical slices. You're looking at individual function goals and you have lots of customer interaction. You can do more interviews and more group sessions at least in theory. Integration of goals then, becomes the bigger challenge in that agile environment. Now, why I said that you should start this as early as possible? We've got a balance to, do not start conflict resolution too soon. Allow for elicitation of useful information, within the stakeholders viewpoints, even if there is in consistency. Then, go back and try to fix things. In using techniques to elicit alternative conflict resolutions with stakeholders, through stakeholder driven elicitation, the goal is to come up with a solution that is reasonable and a compromise for all involved. Don't be afraid to appeal to the authorities, what really is needed. When resolving conflicts, address and resolve the boundary conditions. For example, in our library system, let's say we have the requirement of, keep copies of highly needed books unborrowable. Well, what is highly needed? When should they be unborrowable? What is the real boundary condition there? Identify it and see if that conflicts. Also, ensure that conflicting statements become satisfiable together, reasonably soon after we hit the boundary conditions. In any system, we may have boundary conditions that will continue to conflict but we want that conflict to be brief. Next, identify statements that are very frequently used. Usually, statements that are being weakened are those with lower priority, not those that have high interaction and high priority. We getting conflicting statements as needed. Do you know though, that in extreme cases, you may accidentally or maybe intentionally weaken statements to the point that they are universally true. If they're universally true, ask yourself if they actually deserve to be mentioned. Just gotta think about that one on your own. Finally, specialized the conflicting statements based on the user concerns. For example, instead of stating something like, Book loan status is known, you could weaken that statement to, Book loan status is known by staff users only. You might also need to say, Book loan status is known by users. In that case, we also need to ask, what is loan status? But anyway, you are weakening as you go and trying to reduce risk along that way. These techniques that we're going over, allow you to transform conflicting statements or similarly involved objects. And also help us to separate out and potentially, introduce new requirements as needed. The basis for your decisions are provided by evaluation criteria, such as the degree of contribution of the resolutions, where the degree of contribution is in how related it is to critical nonfunctional requirements and also the reduction of other risks and conflicts. We can learn more about how to understand the quality of our resolutions and the paper reasoning about partial goal satisfaction, which is included as a reading here.
