Once we've identified conflicts, record any and all conflicts and the statements that are associated. This includes identification of conflicting statements, non-conflicting statements, and overlapping statements. One way to identify and track these overlaps, and the lack thereof, is through something called an interaction matrix. Within an interaction matrix, which was presented by Katonya and Sommerville, in 1997, each statement that you have collected is labeled in some kind of short way. Like our number one for requirement number one. Or NFR one for non functional requirement number one. List all of the requirement labels as column headers. Then, again, for the rows, list all requirement labels as row headers. Again, each requirement label represents a single statement. In order to fill out the table, a cell has a one in it, if the row or column combination of statements conflicts. If the row and column does not overlap, put a zero. Otherwise, you need to put some number, that's in between one and above, for statements that overlap but do not conflict. And, in this case, the number can be anything other than one or zero. Use the same N for all statement comparisons. The goal of the interaction matrix is to count the number of non-conflicting overlaps, and the number of conflicts. And we'll see an example, in just a minute, of how we can implement and use this. So here we have an example interaction matrix, where we randomly select an n. We're going to say that it equals 1,000. In the top row, in the left column, you can see the statements that are being compared. Zeros are placed in the cells where there is no overlap. So, obviously, S1 does not conflict with S1. S2 does not conflict with S2, and so on. So we've got that diagonal of zeros going down. The comparison between S2 and S3, however, must be done manually. In this example, we look at S2 and S3, those two statements, and see that there is no conflict. So that gets a 0 as well. Not only is there no conflict, there's also no overlap. As you're doing this, you need to consider how much the statements relate to each other. If there's no relationship, it gets a zero. Ones are placed in the cells where statements do conflict. So, here, in this example, you see that S1 and S3 do conflict. Now, you also see a bunch of 1,000s in this chart. N, in this case, is our 1,000 and these show statements that overlap each other, but do not conflict. They are related, but they do not conflict. So note, that in the Interaction Matrix model, there is no way to demonstrate week conflicts. A conflict is a conflict, period. From this, we use the Interaction Matrix to describe conflicts and non conflicting overlaps. Conflicts need to be addressed. Non conflicting overlaps are okay for now, but we can keep track of these matrices over time in order to identify potential problem issues for when the requirements do inevitably change. This matrix is allowing us to see the relationships between all the statements. In order to calculate conflicts after you fill out the matrix, you sum down each column. Then, compute the quotient and the remainder divided by whatever you chose for N. For example, the S1 column, here sums to 1,002, meaning that S1 conflicts with 2 statements. To get the total of non conflicting overlaps, do the same thing but use the total of the totals. In this example, we have six conflicts, and two non conflicting overlaps. Now, obviously, if we include all requirements in the document, the creation of this matrix is really impractical. We need to do it incrementally and also tailor things down a little bit. More scalable techniques can be used when the statements are recorded as objectives, requirements, assumptions and nonfunctional requirements within a requirements database. Conflict links created between conflicting items can then allow us to do analysis through queries. This helps us in quality assurance, maintenance, and later traceability. We could easily imagine this as a matrix only focusing on security based statements. This is just one example. A full interaction matrix helps us to keep track of conflicts and potential conflicts that may arise as requirements change. Full conflicts should be addressed pretty much immediately, and fixed in the analysis phase, which we're really talking about right now. Overlapping nonconflicts should be kept as warnings for later on. As you add more requirements into your system, add them into their individual interaction matrices. Not only will this help you to identify conflicts, but it will also help you to identify the statements early on that are too encompassing. And maybe need to be divided. If you have one statement that is touching 5 billion other statements, maybe you should do some revising. Some statements are too big and deal with multiple concerns. These should be split up into multiple statements, in order to reduce confusion and also reduce risk. You may also see from this matrix, that some requirements are highly overlapping. While this is not a bad thing in itself, it may cause problems down the road, so make note of it.
