In Requirements Goal Development and Language Analysis, we move from the spoken word to precise writing. A first step in this is writing goals. We will talk about goals used in requirements engineering and, from this, writing use cases from what we learn. Use cases can be in diagram and written form. Then- the villains enter- misuse cases and abuse cases are discussed in how we can deal with them in a Requirements environment. In gathering requirements, you'll have many questions remaining. Often this leads to the need of more interviews and group sessions. We'll go through how to handle group meetings, dealing with inconsistency, and handling conflict between stakeholders.

Рецензии

Filled StarFilled StarFilled StarFilled StarHalf Faded Star

4.4 (оценок: 16)

5 stars

11 ratings

4 stars

3 ratings

3 stars

1 ratings

1 star

1 ratings

Из урока

Use, Misuse, and Abuse Cases

Once goals have been identified, they can be pulled together to create use cases; these are easy to read and understand by both customer and developer. To address security, misuse cases and abuse cases can also be defined, in written or drawn form.

Преподаватели

Kristen Walcott-Justice

Assistant Professor

Текст видео

Sometimes, we need to create use cases to work in negative environments. By negative environments, I mean things like insecurity. Within security, we can use something called a mis-use case rather than a use case. Please see the additional reading associated with this section of the lesson. Just like with maintain verses avoid statements, as was discussed before, mis-use cases are a dual of use cases. Use case diagrams show the interactions in a system between the actor and the system. And overall, they're good at showing functionality. The focus on the actors also makes it easier to focus on the stakeholder's interactions, and really figure out what their interest in the system is. When we move from functional requirements to non-functional requirements though, use cases are rather lacking. We tend to write requirements on a positive side, saying, we need this in the system, and this in the system. But negative actions are needed too, especially when we bring in security. Misuse cases allow us to add in negative cases, and they describe the process of executing malicious acts against the system. Overall, they describe potential system behaviors that are unacceptable from the view of the stakeholders. As the opposite of a use case, a misuse case explains actions and ungoals that result in loss for the organization or stakeholders. For this reason, we create misuse cases that represent unwanted behavior, given some black hat hacker or some other kind of crook. Misuse cases show unwanted action in the system. Usually, they focus on security requirements. In the example that you see here, a crook is trying to steal credit card information. Also, they're trying to spread viruses into the system or potentially back to the user. Just as in use cases, we're only here identifying risk goals, not how to fix them. In use cases, or here, you can define a path, you can also define alternatives, and more. Even in traditional use cases though, remember that is not up to the requirements engineer to start specifying algorithms or give full techniques. You are only defining the requirements themselves and the goals, or in this case the anti-goals, within. You're identifying the goals and the anti-goals. Who is involved? What is the function occurring? Notice in this example, the difference between the use case and the misuse case. One, displays the wanted behavior, while the other shows the unwanted behavior that could be occurring due to a hacker. Misuse cases were originally developed for dealing with e-commerce systems. We've also learned that some other classes of non-functional requirements that seemed clearly beyond the scope of use case diagrams, can at least somewhat be represented in this misuse case diagrams. While the misuse cases are closely aligned with use cases. This is helpful, because no new notation system needs to be learned. It's just a different way of thinking. Misuse cases for one system can also be referenced by similar systems, allowing for more re-use.