Welcome to Requirements, Risk Analysis, and Prioritization. At this point, we assume that you have a set of requirements available from elicitation and you've started negotiating at least a little bit with your customers. You've done artifact analysis, stakeholder analysis, plus additional interview and group session evaluations. Now, you need to determine risks and alternatives and prioritize tasks based on these. Remember that this is usually an iterative process. So you need to go back and elicit more along the way for more feedback. The waterfall model of development or of requirements engineering really just doesn't work, people change their minds and things change overall, so you must adapt. Agile models can help us, however, they can also cause issues, as most environments can not follow a true agile model. In this course, we're going to talk about conflict resolution. From stakeholders statements, resolution tactics, analysis of alternatives involving risk, integrating risk management into your program, and prioritizing concerns based on risk versus functionality. A systematic approach can be taken to deal with conflicting issues. These approaches require you to deal with alternatives and the risks that these alternatives present. We can begin looking at the risks by looking at individual statements. Intuitively, statements overlap each other if they refer to some common terms or common phenomena. For example, acquiring, borrowing, and returning a book are all interrelated concepts because they all have the same common concept of a book copy. We can perform conflict analysis formally or informally. In the informal techniques, you'll look at each of the statements and determine whether the overlapping statements are satisfiable together and under what circumstances they are not. In heuristic detection, we use detection heuristics based on pre-determined categories or requirements and conflicts that are already known. For example, you can check information requirements versus confidentiality requirements. For example, know about the loan status of books versus the statement, I don't know who's borrowed what. In heuristic analysis, you can also look at requirements mentioning decreasing or increasing statements that share terminology or related concepts. For example, you might have that you want to increase the coverage of subscriptions or you might have a conflicting statement of decrease the operational cost. Check satisfaction requirements that can be instantiated to multiple competing system components. So you're doing basically unit level testing as well as integration level testing. Formal methods can also be used especially if you are already writing in a formal language. In this case, theorem proving, or derivation, can determine set boundary conditions automatically. Again, to go the formal route, your requirements need to be formalized into a logic based specification language. This could be algebraic, first order, could be using goal models, could be event based but there needs to be some kind of model that you can compare. Lightweight detection also exists, that is slightly less formal. In that case, in using lightweight detection, map your statements to assertion templates. The assertion templates, or at least a few of them, are discussed in the elicitation course. And they allow you to discover overlapping statements given assertion templates that conflict.
