When describing requirements, diagrammatic notations are often used to complement your natural language statements. Diagrams are dedicated to specific aspects of the system as it is or dedicated to the system to be. Diagrams allow you to show the items under consideration and their interrelations and declare ideas formally, but still in a graphical way. Then statements that prescribe or describe the statement properties are informally specified in natural language. In the semi-formal mode of diagrammatic notation, you can explain some syntax and some semantics, and then perform surface checks on the requirements document items. When we do those surface checks, these diagrams also allow us to have statements or pictures that are machine processable. We can also write more formal documentation. When we talk about formal documentation, this has many meanings. But usually, it's just meant to imply that your documents, your requirements, and your diagrams are in some machine processable form. This is great because it allows for easier traceability, validation, and verification of your document. The declaration sub-language is generally graphical for the stakeholders. But combined with formal Information, so that you can do a surface level analysis by automatic tools. Now, the diagrams that we're going to discuss support abstractions that are relevant to requirements engineering. And they're fairly standard, and widely used. They are mostly standardized into UML, where UML stands for the Unified Modelling Language. If you do a Google search for this, you'll find a zillion UML tools. So, now we're going to go into the introduction of UML models and compare some specific notations and constructs for the purposes of demonstrating your system's scope. We'll first look at the system's scope, then we'll move to conceptual structures, then activities and data, then information flows, system operations, interaction scenarios, system behaviors, multiple system views, and more. One of the simplest forms of diagrams is the use case diagram. A use case diagram is a diagram in which we collect all of the operations that an active system component has to perform. We stick all of those operations in a box. For each operation interacting in one way or another with another system component, you draw a line to capture that interaction. Now, be careful here. The lines are not explaining the ordering of interactions by any means. They're only showing that, hey we've got this actors on the outside of the box. We've got these components inside the box. The actors relate in someway to the components. Given this, you create a simple but very vague, outline view of the product components. You can also clarify using more natural language and diagrams, like annotations, interaction scenarios, and more, which we'll go into. Now, in these diagrams, note there is an includes notation. The includes notation allows you to additionally specify sub-operations to your operations. There is also an extend notation. The extend notation allows you to add preconditions or other preoperations. The extend notation is especially useful for specifying variant operations for exception cases as they are needed. These use case diagrams can also be extended to misuse cases, which are fantastic for expressing security concerns. There you have users and you have mis-users. You have your hackers there on the other side. We discuss misuse and abuse cases in the course requirements, goal development, and language conflict analysis. Okay, so as an example for a use case, here we have the ask constraints operation. This is for the software actor where the software actor is named scheduler. And the scheduler is interacting with the environment actor named participant. The conflict resolver interacts with the scheduler's Resolve Conflicts operation. An operation may include, notice the include notation, the operation may include finer-grained ones. Resolve Conflicts is a sub-operation of Determine Schedule. This is helpful and that you can factor out common sub-operations of multiple operations. Extend associates of variant operation with a normal one. The variant is to be applied in some exceptional situation characterized by condition named labeling the link. For example here, we have Deny Requests as an alternative course of action to be taken when the condition of unauthorized host. Use cases and mis-use case diagram should not get more complicated than this. Use them wisely. They are best for showing just who the actors are and that they do act in some way with big system components.
