In performing elicitation task and beginning to write out goals and use cases, we will run into much inconsistency and conflict of concerns. We're not going to discuss some types of inconsistencies. How we can handle those inconsistencies and how we can start to manage conflicts using a systematic process. Inconsistencies reduce risk and thus, they must be identified early. Inconsistencies from elicitation are violations of rules between items. Look back at all of the goals that you've created. Hopefully, those are at a high level and hopefully, most will agree. However, when you delve even a little bit deeper, you're likely to find inconsistencies and different opinions coming to light. Each stakeholder has his or her own focus and their own concerns. Given this, their discussion of the product goals will probably differ. When you get down deeper into the product, more conflicts will come up. When we take a look into nonfunctional requirements, these conflicts will be even more exacerbated. For example, in terms of nonfunctional requirements, security and usability constantly fight. Security and speed also often fight. So, we need now to detect and resolve these inconsistencies. Since we're working in a spiral process overall, detection and inconsistency management is not a one shot deal. And like everything in software engineering, we have to find a balance. Elicit and get views early. Then, re-elicit and re-elicit and re-elicit as you find issues. Your final document cannot contain inconsistent specifications. Your developers should be able to work strictly from your document and not just make assumptions, where some of those assumptions may be completely wrong. So what kinds of inconsistencies do we have? A primary source of inconsistency in documents is the terminology clash. A terminology clash is the use of words that sort of mean the same thing, but they may not. For example, in our prior examples in this course and in requirements elicitation, we've discussed having borrowers and patrons in a library system. Is a borrower the same as a patron? Maybe a borrower is someone who actually checks out a book, where as a patron is someone who just comes in and browses. We don't know. Designation clashes are another type of inconsistency, where we're using the same name for different concepts, in different statements. In the example that I just gave, a borrower could be the same as a patron, we have to find out. But as a clearer example, we're often tempted to write the user of the software should be able to do this. What's a user? In a library system, this could be a person who walks in and browses. It could be one who borrows books. It could be someone who just uses the computers in the library. Could be someone who uses the library card system, etc. Structure clashes also occur in our statements for the same concept, but structured in different ways and to different degrees. For example, we might say that the latest return date for a book is at some particular point in time, say 5:00 pm on Friday, or we might say that the latest return date for a book is during some time interval on a Friday. You can also think of this and how you go and turn homework in for classes. Is the deadline Monday at 11:59 pm? Also keep in mind, that a lot of software count is going to count it late if you submitted it 9:59 pm plus 30 seconds. Or is it due sometime on Monday? Can you turn it in early or what? You know teachers also fall short on this, in calculating late penalties too, and in trying to describe how we're going to assess late penalties. You'll see syllabi things like, if this assignment is one day late, you will lose 20% of your grade. Okay. With one day, one day late. Does that mean one day between classes? Does that mean 24 hours? What if you're 30 seconds late, after the first day? What if it's 11.99 hours late on the first day? Does the same penalty apply in all of these situations? These are all examples of structured clashes that we need to be able to think through. Some statements are going to be strongly conflicted. Others have weak conflicts. Strong conflicts are conflicts that are not satisfiable together. They are logically inconsistent. For example, we might have the requirement that meeting participant constraints may not be disclosed to anyone else. As another requirement, we could have that the meeting initiator should know the participant constraints. Definitely, a strong conflict there. One says the initiator has to know, the other one says that no one can know. These conflicts often arise due to differing viewpoints. In this case, we have the initiator's viewpoint versus the participant's viewpoint. Weak conflicts occur much more frequently. Weak conflicts are usually boundary conditions. They capture a particular combination of circumstances that are strongly conflicting, when the combination of the statements becomes true. In other words, it can be made true, through possible system behaviors. As an example of this. Let's say that the librarian stakeholder states that a borrower should return a borrowed book copy, within two weeks. Then the borrower might go back and say, the borrower should keep a borrowed book as long as it's needed. These statements are weakly conflicted, because they only conflict if the borrowed item is needed for more than two weeks. The boundary condition here is needing to borrow the book copy for more than two weeks. For those of you out there who are software testers. This becomes especially important as you write test cases. Requirements engineers? Think about the fringed cases. Help your testers know what is required. As we'll go over and diagramming and specification writing, making sure that our statements are testable, is of vital importance. Think through the edge cases. Think through the sad paths. Think all the ways that your writing can be interpreted.
