We have discussed three ways of starting to represent our requirements and our system goals. These have included goals statements, use cases and use case diagrams, and misuse cases and misuse case diagrams. Before we go into more precise methods of specifying requirements, let's take a big step back and look at the data that we currently have. First, we have probably identified some conflicting stakeholder viewpoints. We've also identified non-functional requirements, all of the "iddies" like efficiency. We've also looked at security requirements. We've also noticed a lot of conflicts, most likely, between budget, time and the overall concerns for the system. Our goal is that we want to reach agreement by all of the parties. Secondly, we've likely run into critical objectives that have not yet been met or even thought about, sort of the "unknown unknowns" as was discussed in the elicitation course. These kinds of things involve things like safety hazards, security threats, development risks and much more. Now, we need to start pinning things down to gather new requirements for a more realistic robust system to be. Thirdly, you should not be asking yourself what is best for the new system to be. Something may not be possible, something's may be conflicting. So, we're now looking into alternative options, where these arise from different ways of considering how a same objective can be met. We can also look to see how responsibilities can be assigned in different manners. And add in automated functionality. Another alternative path would be to say, this is going to be way too hard to implement. We can't make this automated. And so you step back and reduce it. Overall, the goal is to resolve conflicts and risks. To do this, we evaluate alternatives in terms of their contribution to non-functional requirements and the reduction of risks and conflicts while keeping all of the functional requirements in mind. Lastly, in selected alternatives, remember that these alternatives may not be able to implement everything due to constraints. To resolve conflicts, we must address cost, schedule and other constraints, and consider how to support incremental development. How can we create a product that is coming along quickly enough to give our users confidence? Can we make prototypes? Can we add modularity and give more room for growth later in the program? These are all possibilities. When analyzing risk and discussing alternatives, group sessions are a good technique to help us get started. In addition to using interviews and the other elicitation techniques discussed in the elicitation course, group sessions can also be used in addition to these techniques for prioritization and analysis.