One to help in dealing with clashes is to create a glossary of terms. Glossary elaboration generally takes place during domain understanding and during requirements elicitation. But, you should continue to refine this as you move forward. As you can see in this example, the terms of advocacy, autonomy, ethics and more are completely spelled out. Do note that in this example, there is still a lot of leeway in the definitions that should be clarified later. A glossary should contain precise, intelligible definitions of all terms used and their accepted synonyms. For example, borrower, patron. You may feel silly putting towards all this effort into writing some things thinking, "Oh, well, everyone should know that." They don't, don't assume. For example, if we're working on software for an airplane, what is the system? What is a wing? What are engine components? Obviously, you do have to start going down the rabbit hole somewhere, but again, that's where you need to find balance. What do you need to explain so that all requirements are clear and non-conflicting between your clients and your developers? These types of conflicts should be analyzed in terms of differences between their underlying objectives. Once these have been identified, they should be propagated to the requirements. Weak conflicts are often rooted in underlying personal objectives of stakeholders. And guess what? It's up to you to handle them. For example, password based authentication for increased security, often conflicts with, we want to be able to get in this system really fast, we want to be really usable. Confidentiality and accountability also tend to conflict. Increasing maintainability or modularity may result in increasing the development cost going against budget concerns. Given all this, you need to explore tradeoffs. In terms of security, if you're in a high security environment, many stakeholders will hopefully agree that security first. They may not like it, but they'll be more lenient in understanding yes, this is useful, we can sacrifice some usability. Others may say, no, usability is absolutely first, this is required. You got to find the balance between the two. Not everyone will be happy. Several techniques have been created to help reason between the wants and the desires of stakeholders. And some of these techniques are listed in the related readings that I hope you consider. For example, Boehm et al in 1995, wrote about a spiral model for negotiation based reconciliation of Win conditions. In 2001, WinWin was developed and this was a quantitative reasoning technique and the WinWin paper referenced here is a case study about its success. Stakeholders identified with their personal objectives, the personal objectives were the Win conditions. Differences between the Win conditions were captured together with risks and uncertainties. Differences were then reconciled through negotiation, where the negotiation considered the overall objectives, the constraints and alternatives. Since these was working in a spiral model, all of these were pooled into the next iteration of the spiral.
