Since

we selected the solu/on concept in a prior module, we now move from the domain of the stakeholders, and begin dening of our solu/on of interest,

 The objec/ves of this module are to: Dene how the solu/on will meet the stakeholders capabili/es. These are the stakeholders func/onal requirements. Dene how the solu/on ts within the context or enterprise environment, that is how it will t within the opera/onal environment. Capture the usage of the solu/on, its behavior and opera/ons. In this module we will be focusing on the capabili/es/func/ons that the stakeholders expect and require (this is as compared to system characteris/cs which will be considered in the next module). Addi/onally, we are s/ll considering the solu/on as a black box. We are dening capabili/es within the system, but we are not dening the system internal mechanisms, architecture or components.

Here is our overall Systems Engineering Framework ow. We have completed the generate, evaluate and select system concepts and in this module we are covering how to dene the systems context and system-level usages and usage scenarios (These are the two sec/ons that are in yellow/green)

Completing a complete set of system requirements requires this two-pronged approach. In this module, we follow the upper prong and develop use cases and the associated sequence diagrams and activity diagrams -- trace the transactions between the system and the external actors/stakeholders with which it interacts for every important scenario (including operational, maintenance, initialization, upgrade, etc.). These use cases are used to develop the input/output and functional requirements for the system.

 In this module we are going to bound the solu/on, that is, fully understand was is the scope of the systems, and what is outside of the system. We are also going to understand what the solu/on must do, that is, its func/ons. We are going to follow this overall set of steps: First, we will dene the usages of the solu/on (what is it that the the users/ ac/ve stakeholders of the system want to do?). This will be the capabili/es of the system. Second, we will dene the solu/on boundary (what are the external interfaces?). By dening the outside/inside of the system, we will be dening the context within which the system operates. Third we will dene the usage scenarios (how is the solu/on going to be used?) Note that these steps are o[en performed concurrently, and they are highly itera/ve.

Step 1 dening the usages of the system. Remember we are looking at a black box view of the solu/on. That is, we dont care about solu/on internals at this point

 To dene the usages of the solu/on, we rst must consider: what must the solu/on do? What capability must it provide? This is described from the ac/ve stakeholders perspec/ve and captures the use of the solu/on, and the (ac/ve) stakeholders with which it will interact. The usage will describe some basic func/onality or capability provided to ac/ve stakeholder. If your solu/on directly interacts with an individual (user, maintainer, etc), the usages typically start with an ac/on by the individual (as described in the 3rd bullet). But, depending on how your solu/on ts within the environment, a usage may start with your system responding to an input from another system (if some external system interacts with the individual) or even some internal ac/on/func/on performed by the system itself. Remember, ac*ve stakeholders are individuals, en**es, and other (external) systems that interact with our system when it is opera*onal

Each usage should cover the WAVE: W - What does it do (not how) A from the Ac've stakeholder view V provides Value to the stakeholder E covers an En're scenario. The source of these usages are the stakeholder expecta/ons/requirements (the capabili/es they described). They may need to be expanded and the set of all usages should meet all the capabili/es of all the stakeholders. For a complex system there are usually hundreds of usages. Once dened, they are used later during valida/on and verica/on, as well.

In this module we are going to look at two tools to dene usages: rst we will look at Use Cases. These Use Cases graphically depict how the stakeholder will use the system. The formal use case model describes the role of the ac/ve stakeholder as the actor. Some/mes an ac/ve stakeholder may have dierent roles. It is important to dis/nguish the roles and the way that specic role interacts with the solu/on. For a complex system there are usually hundreds of Use Cases. These are used later during valida/on and verica/on, as well.

So what is the deni/on of a Use Case? Press pause and read through this slide on your own.

10

This is an example of an ATM Use Case Diagram, at a high level. Note that it can show the sequen/al order of the use cases. In this case, it shows that the Login use case precedes the others and the Logout Use case succeeds the others. Although the bank is depicted as a human, this is really the ATM system.

11

The steps to dene the solu/ons usages: 1.Dene the external interfaces for the opera/onal system. These are the Ac/ve Stakeholders themselves or the Actors (if there are mul/ple roles played by an Ac/ve Stakeholders). Be clear about your Actor deni/ons so that you can trace them to the ac/ve stakeholders. 2.Dene the usages of each of the external interfaces, star/ng with the stakeholder capabili/es (earlier in the process). It is a good idea to ini/ally focus on the usages by the people. External system interac/ons may be a result of people (user) interac/ons. Once the human interfaces are dened, then dene the interfaces with the external systems. 3.Dene any rela/onship between the usages: Are any usages dependent on other usages? 4.Document the detailed steps of the usages via the Use Case Diagram and associated text.

12

Now lets look at an ATM example of the associated text for a withdrawal use case. Press pause and read this slide so that you understand how to diagram a Use Case and the associated text.

13

In our overall module outline, we are now at Step 2 dening the boundary of the solu/on. Remember we are looking at a black box view of the solu/on. At this point, we dont care about anything internal to the solu/on (e.g., subsystems, hardware, so[ware, etc)

14

 Now we are going to look at an important diagram used to dene and describe the solu/on boundaries: the Context Diagram. The Context Diagram is used to scope the solu/on by dening ALL of the solu/ons opera/onal interfaces into a SINGLE diagram. All of the previously-dened usages of the solu/on are summarized in this single diagram and the context diagram provides a sta$c view of the solu/on. The context diagram denes the informa/on and control ows that cross the solu/on boundary, that is, it shows the informa/on to/from the system from outside of the system. The Context Diagram highlights several important aspects of the solu/on: specically it illustrates, on one diagram, all of the external interfaces (human, system, environment, as appropriate). It also documents the external events and data both to and from the outside world (that is, outside of the solu/on). It does not explain what is inside the black box solu/on.

15

The important purpose of the Context Diagram can be summarized as on this slide: First to clarify and conrm the opera/onal environment in which the solu/on has to operate. It is important to ensure understanding the enterprise or mission. Once the Context is agreed to by all stakeholders it becomes very useful for maintaining focus on the development eort, and can help prevent scope creep. Second the Context provides a diagram of the opera$onal external interface details at an adequate level of detail to allow an understanding of what the solu/on must do. It can also clarify and verify that the informa/on ows between the solu/on and external en//es agree with the system usages and other business or mission documenta/on. Last, by examining the informa/on ows, and the external interfaces, the Context Diagram provides an understanding of the func/onality of the solu/on.

16

 The purpose of the context diagram is to get very clear about what is within the scope of the system, what is outside of the scope, and what external systems our system interacts with. Ac/ve stakeholders are always shown because they interact with the system when it is in use (when the system is opera/onal). Context Diagrams may also show passive stakeholders, but they typically inuence the solu/on, not directly interact with it (so they would be diagrammed as only input)

17

Here there is a dierent type of external system. Some/mes the external interface to the environment is important to the understanding of the system context. For example any complex solu/on opera/ng in Space. If that is true for your system of interest, then it should be shown in the context diagram and external inputs/outputs would be dened.

18

1.

2. 3.

4.

Iden/fy all external en//es, users and ac/ve stakeholders that need to interface with the opera/onal solu/on (including the environment if applicable). All the ac/ve stakeholders must be included, as previously dened. Draw an object and labeling it with the name of the solu/on to be developed. Thus, your solu/on is treated as a black box (a single en/ty with no details of what is inside of the solu/on). Surround this solu/on-object with other objects labeled with the names of the ac/ve stakeholders, external systems and the environment (if applicable). Using dierent shapes to dis/nguish dierent categories can be helpful in understanding the overall solu/on boundaries and interfaces. Add the inputs and outputs between the solu/on and the ac/ve stakeholders. These inputs and outputs should be based on (or summarize) the solu*on usages previously dened, and may be summarized to make the diagram more readable.

19

 Here is an example of a Context Diagram for an ATM. This is clearly a more complicated and more complete example of a system context diagram. Note that there are users customers including one unfriendly customer, maintainers, admin, and servicers, even bank management. This slide also illustrates how to show external systems in the Context Diagram. Some of the ATM stakeholders are external systems (e.g. Bank or Computer Network) but all of these stakeholders are ac/ve ones.

20

30

31

Please read through these case example on your own. It provides a step-by-step example for this modules team assignment.

32

33

34

 These are typically derived from the stakeholder capability requirements. Ensure consistency and completeness with your ac/ve stakeholder list and stakeholder expecta/ons/requirements, created in an earlier module. You may need to iterate your stakeholder lists, ac/ve/passive dis/nc/on and stakeholder expecta/ons/requirements to ensure you have accurately captured their desired capabili/es (func/ons).

35

More deni/on of one of the system usages in a Use Case format and including text.

36

More deni/on of one of the system usages in a Use Case format and including text

37

Have you included your ac/ve stakeholders from the earlier module? Do you have new informa/on that might have changed a passive stakeholder into an ac/ve one (or vice versa)? Have you included appropriate external systems? Be sure you are consistent with the stakeholder expecta/ons/requirements.

38

Context Diagram only shows opera/onal interface (interfaces to the Ac/ve Stakeholders). It may or may not show interfaces to Passive Stakeholders, since those interfaces are not opera/onal ones. If important to the solu/on, the context diagram will also show the opera/onal interface to the environment, but that interface is not important in this example.

39