COMET - Requirements model

The requirements model identifies the system requirements. These include functional requirements, non-functional requirements (quality of service) and constraints.

Non-functional requirements are statements concerning performance, availability, security, reliability and so forth. There are also other requirements specifying constraints that will have impact on the system to be developed, for instance available resources, special customer preferences, company strategy etc.

Use cases and scenario descriptions are used to capture the functional requirements. These use cases and scenario descriptions are also used to structure some of the non-functional requirements and constraints. Figure 1 shows the work products of the requirements model.

Figure 1: Requirements model work products

The Requirements Model contains the following work products:

• The Use Case Model. The Use Case Model describes the Product in terms of actors, use cases and scenario descriptions. The Use Case Model consist of two main parts:
  • The System Boundary Model, which identifies the Product under consideration (area of concern) and describes the Product boundaries as well as the main services offered by the Product.
  • The Use Case Scenario model, which includes more detailed descriptions of the Product resulting from further analysis using the common use case detailing technique, by diving into a use case discovering new use cases and actors. Use case scenarios are also described in this work product.
• Prototype. One or more prototypes may be produced during development of the Product, in order to test understanding of the requirement, or particular aspects of the design (e.g. HCI).
• Non-functional requirements. This work product identifies constraints, general requirements and other kinds of non-functional requirements not fitting into the previous work products of the requirements model.
  • Non-functional requirements can be made part of the use case model as these kinds of requirements are associated with use cases according to the use case template. General non-functional requirements that apply for the whole system are associated with the system boundary which is also included in the use case model.
• BCE model: This work product provides the link between the Requirements model and the Architecture mode and is the output of a technique used to derive the system domain models (architecture model and platforms specific model) from the business domain models (the Business model and the Requirements model).

The Use Case Model consists of the System Boundary Model and the Use Case Scenario model.

System Boundary Model

The System Boundary Model describes the system boundaries, the actors and their responsibilities, and the services offered by the system. Interactions between the system and its environment are identified and might also be detailed by modelling stimuli and responses using UML sequence diagrams.

Goals

The System Boundary Model should:

• Identify and describe system boundaries, main services and actors.
• Assure a common understanding of the system and its purpose.
• Identify interactions between the system and its environment.

Methods and techniques

The starting point for the development of the System Boundary Model is provided by the Business Model work products, the Context Statement, Vision for Change, Business Process and Role Model and Business Resource Model. Other important sources are the business stakeholders, who should be involved when determining the system boundary model.

Defining the boundaries of the system means finding out what is inside the system and what is outside the system (the outside is what the system interfaces with). The boundaries of the system are determined by the roles of the system in the Business Model. In the System Boundary Model, the boundaries of the system are defined in terms of actors and use cases. The actors are outside the system and represent the roles in the Business Model that interact with the system roles (roles inside the system boundary); the use cases are inside and represent the behaviour of the system roles.

Thus, UML actors are used to denote anything that interfaces with the system. Some examples are people, software, hardware devices, data stores or networks. In the model we let each UML actor define a particular role and thereby abstract the actual person or software system currently fulfilling the role. Hence, several actors may represent one physical person, because that person takes on different roles with regard to the system. On the other hand, one actor might represent several physical people, because they all take on the same role with regard to the system. Each role specifying interactions with the system may be represented by one or more actors (hence, roles are recursive). To help in defining actors the following questions might be helpful to elaborate:

• Who uses the system?
• Who maintains the system?
• What other systems use this system?
• Who gets information from the system?
• Who provides information to the system?
• Does anything happen automatically at present time?
• Who starts up and shuts down the system?

Each actor needs a descriptive name and a brief description that is one or two sentences long. This description should define the role represented by the actor with regard to the system.

Identify use cases: When the main actors are identified, the next step is to go through the list of actors and identify use cases for each one. Use cases describe things that the actors want the system to do. At this stage, people that will play roles defined by the actors should be involved.

To help identify use cases the following questions might be helpful to elaborate:

• What services are required from the system by the actor?
• Which events are/will be initiated by the actor, and which events are the actor interested in?
• Which events occur and who is/will be notified about them?

When dealing with existing systems, go through the list of actors and identify what services the system actually provides. Important sources of information would then be the user manuals, other documentation, source code, table structures and information gathered by studying system behaviour at runtime.

Relate to goals! The use cases should be related to goals, this because the purpose of the use cases should be to attain goals. It is important to be able to answer why to each use case. If you can't give a good answer to the "why-question", then it is probably not a proper use case. The relation to the goals is implicitly the answer to the why question.

Describe stimuli and responses for the use cases identified. Each actor communicates with the system through a set of use cases in order to reach their goals. The stimuli/response describe the stimuli sent to the system by the actor, and the responses back from the system. We can use UML sequence diagrams to model the most important stimuli/responses.

Deliverables and notation

The work product contains the following:

• UML Use Case diagram showing the system boundary, the actors and the actors responsibilities.
• UML Use Case diagram exploring the system boundary use case that identifies the needs. Each use case should be numbered for later reference
• General extra requirements that applies for the complete system are associated with the System Boundary

Example

Figure 2 shows an example of parts of a system boundary for a meeting room booking example, which is described in a UML use case diagram. The actors represent initiating system actors or external systems used by the meeting reservation system (e.g. the Email information system).

Figure 2: System Boundary Example – Meeting Room Example

Use Case Scenario Model

The Use Case Scenario Model digs into the identified use cases and describes these in detail. The COMET method describes a use case template that is used as a vehicle for this detailing.

Goals

The Use Case Scenario Model should Capture and describe all system services in detail.

Methods and techniques

The major input to determining the Use Case Scenario model is System Boundary Model, but the Business Model work products and early versions of the Architecture Model are also valuable input.

The use case template is the baseline for developing the Use Case Scenario Model. Each use case identified in the System Boundary Model is detailed using the use case template. The use case template consists of the following parts: 

Part	Description
Use case identification	Use case no. xx <name>. Each use case are identified for later reference
The UML use case diagram	UML use case diagram for the actual use case. The diagram should include extend and include relationships if there is any.
Goals	Description of the goal(s) for the use case, derived from the Goal Model in the Business Model. Preferred notation is prose text.
Actors/Roles	Description of the roles involved in the use case and their responsibilities. Preferred notation is prose text.
Description of scenarios (formal)	Description of the use case scenarios. This includes the primary scenario and related secondary scenarios. The scenarios are described using UML Activity diagram and/or UML sequence diagram.
Pre and post conditions	Description of the pre and post conditions for the use case. The post condition will often correspond to the goals. Preferred notation is prose text. UML state diagram might also be used to describe pre and post conditions as well as intermediate states of a use case. OCL might be also be used to specify pre and post conditions
Non-functional requirements	Description of non-functional requirements for this use case. These are described using text in the UML documentation field for the element in question.

Table 1: Use case template

The description part of the template describes scenarios. A scenario is an elaboration of a use case. Use cases are statements of system services. Scenarios add more detail and describe factors that may result in behavioural variations of a given use case. A Scenario describes the behaviour of the system in a particular situation. The use cases and the set of all scenarios together constitute the complete description of the services of a system. Scenarios are constructed by taking the use case and identifying possible different outcomes and different conditions that may result in different sets of scenarios.

Non-functional requirements are the collection of system requirements that are not directly related to what the system should do.

It is important that the derived use cases are proper use cases in the sense that they are meaningful from a business point of view and are not influenced by a specific system or a solution. For instance if you are designing a cashier machine, insert credit card and give your pin code are not proper use cases. Identify yourself is however, much better. In fact insert credit card and give your pin code is just one way of accomplishing the Identify yourself use case. Similarly use cases such as getName, getId, sortList and insertCoin are not proper use cases.

It is important that the use cases are carefully developed. They should not go into the details of a collaboration, but be related to the goal of the collaboration. Examples of proper use cases are: getPayment, registerParticipant and getHairDressed.

Deliverables and notation

The use case scenario model will consist of a set of filled-in use case templates describing the identified use cases. The notation is according to the use case template described above

Example

The figures below show examples of use case detailing (Figure 3 and Figure 4) and an example of a scenario for a use case (Figure 5).

Figure 3: Use Case detailing example

Figure 4: Use Case detailing example

Figure 5: Use Case scenario example

The Prototypes are part of the requirements model. Prototyping is very important to be able to reduce technical risks and to ensure end user involvement. Prototypes are commonly used to emphasise the UI, test critical use cases and test risky parts of the architecture.

It is common to build some prototypes during the elaboration phase to try out some ideas or to determine if a high risk feature is possible. As a result of the prototyping effort, you may decide that a certain feature is not feasible and remove it from the project. If that feature is key to the project it might even be decided to abandon the project.

Goals

The prototypes should seek to:

• Reduce technical risks

• Reduce the possibility of getting end user dissatisfaction

Methods and techniques

Important input when determining the prototypes are the use case model, the architecture design and the risk analysis. What to include in the prototype and how to implement it is dependent of the purpose.

If the main purpose is to emphasise the UI, choose the main use cases and design the UI. It is recommended to use tools that let you visually design a UI. It is easy and fast and to design UI's using such tools and you will often be able to reuse parts of the UI code in the real system. Implementing some UI event handling and some dummy data to simulate parts of the real system is often a good idea. This is also easily done with RAD tools.

If the main purpose is to test the architecture or parts of the architecture, choose a use case or a set of use cases that emphasise the wanted parts. Implement what is needed to be able to test the architecture. Sometimes it is more convenient to make tests regardless of the use cases; however implementing use cases are preferred because it gives more valuable experiences. In addition parts of the work might be reused directly in the actual system.

If the main purpose is to test some core use cases that comprise some risk. Implement those use cases, focusing on the risky parts.

Note that during the construction phase a set of increments are developed. Following a risk driven approach, the first iterations and increments incorporate the most risky parts of the system. What to include in a prototype and what to be left for the first increments should be elaborated. It is not any straightforward answers to this, however seek to avoid letting the elaboration phase last to long. The elaboration phase should approximately be 20 to 25% of the total project. However, at the end of the elaboration phase it is vital to be able to answer if it is possible to develop the system within a reasonable cost and time frame.

Deliverables and notation

Prototypes and related code are typical deliverables from this work product. They are documented in separate UML models.

It has also been shown to be useful to start writing on the user manual at this stage, to better understand both the functional requirements and requirements regarding user-friendliness.

This work product describes non-functional requirements that do not fit into the use case template. For instance, some non-functional requirements may be general for the whole system to be developed. These are described separately instead of being described with every use case. The distribution aspect of the system as well as interoperation with legacy systems and different software and hardware components might also be better described separate from the use cases.

See information on Quality specification in “Modeling QoS: Towards a UML Profile”.

Goals

The Non-functional Requirements work product should describe non-functional requirements that do not fit into the use case template.

Methods and techniques

This work product serves to be able to describe all remaining non-functional requirements, whatever they may be. A list of things to consider is as follows:

• Performance, uptime, availability, security, scalability, distribution, legacy interaction, use of any particular hardware and software components, usability, accuracy, robustness, expandability, change tolerance, maintainability, portability and reliability.

To be able to identify the required distribution handling, it might be convenient to model the actual physical distribution. One possible technique for modelling distribution is to use UML packages representing distribution locations and locate things (resources, roles, processes/steps) in their respective location (i.e. defining a «distribution unit» package).

Also external constraints, conditions, decisions, rules and so on that will have impact on the system development project, and thereby indirectly on the system to develop, are described in this work product. Examples are budget, available resources, time constraints, strategic decisions, use of standards, enterprise policy, enterprise culture, political situation etc.

Deliverables and notation

Usually a document describing non-functional requirements is the deliverable from this work product. Free text along with convenient illustrations will mainly be used to describe these general non-functional requirements. UML may be used at convenience.

The Reference architecture analysis is the first step in modelling the architecture, representing an intermediate step between Business Domain Models (Business Model and Requirements Model) and the architecture design. The key source for the analysis is the Use Case Model. Thus, The Reference Architecture Analysis is developed using a use case driven approach and provides the basis for the initial development of the Architecture Model.

Goal

The Reference Architecture Analysis should provide the link between analysis and design, in particular the link between the Use Case Model and the Architecture Model.

Methods and techniques

Recall the Reference Architecture with associated tiers and component types.

The first step of this analysis, (typically executed as part of developing the first increment of the Architecture Model you analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture. The System Boundary corresponds to the boundaries of the component of concern for the actual project. E.g., in projects concerning building or replacing an Application Component the System Boundary represents the Application Component of concern, where the actors is what's outside the Application component and the Use Cases is what's provided by the application component.. 

After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors. The aim of this task is to divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases. Thus, a subsystem contains a subset of the use cases of the System Boundary Model. Remark that the subsystems are non-exclusive, implying that a use case might be part of more than one subsystem. The result of this task is a functional decomposition of the main component. It is visualized using by group the use cases of the System Boundary use case diagram adding system boundaries representing the subsystems (example See figure below).

Figure 6: Subsystem grouping example

The actors/roles are important when it comes to obtaining the most appropriate decomposition as they group related use cases. Thus, the subsystem grouping are related to the actors/roles, and the subsystem design should strive to have as few relationships between actors and subsystems as possible. Related use cases and especially use cases that typically are executed in sequence should be provided by one subsystem. Recall that the subsystems might be overlapping when it comes to the use cases.

In some cases you might have projects concerning a set of Application Components. In such cases the described technique are applied recursively having subsystems representing Application Components. Also subsystems might again be decomposed into subsystems)

The subsystems are typically associated one to one with tool components as both seek to provide related end user functionality. A tool component is defined as functional part of the system, which enable end users to fulfil a task or a set of related tasks. When defining a set of reasonable tools a rule of thumb is typically to have tools providing the support required to fulfil the responsibility of a role or a set of roles. The end user prefers to have few tools, which are efficient and tailored to what they need to do in order to fulfil their responsibility. Thus, derive the tools based on the subsystem decomposition. Other inputs are the System Boundary Model and the corresponding use case scenarios as well as the WARM analysis. The ideal situation would probably be to have a tool dedicated for each Human Role of the System Boundary Model. However, the typical situation is that you will end up with tools supporting more than one role and also several tools supporting one role. The granularity of the actors/roles is an issue in this respect. Defining very fine granular roles it would typically be impractical to have one tool supporting each role, however, this situation will typically lead to a situation where each role only interact with one tool. On the other hand defining course grained roles you will more often end up with several tools supporting one role. Thus, the role design is crucial and will have major impact on the system design. An important input to the subsystem design is also the knowledge of the typical usage patterns, as a standard requirement for every system is to deliver efficient services and support to the end users.

To derive further components the subsequent step is to continue applying the Reference Architecture with associated tiers and component types on the Subsystem design and associated Use Case Scenarios. A scenario is typically initiated by an actor interacting with a tool. Analyse the scenario and identify the services required (Business Services /controllers) as well as the information objects required (Business Entities). The Resource Service components need to provide the required information objects. The information objects are identified by analysing the dataflow taking place in the use case scenario.  Also the Business Resource Model might be used as input for identifying the entities. Having overlapping subsystems (one use case appear in several subsystems), the actual use case typically should appear as a service at the Business layer and be provided by one Business Service component. The control of flow as well as a convenient categorization of services is provided by the Business Services.  Thus, analysing the scenarios is a main task when identifying Business Service components. Typically the Business Services provide more generic services than the Tool components. Also a Business Service are typically used by a set of tool components

By applying the Reference Architecture Analysis you get the initial version of the Component Structure and it is derived using the Use Case Model and also the Business Model as input. This technique reduces the gap between the Business Domain model and the System Domain models and visualise the traces between the two domains. 

Deliverables and notation

First version of the Component Structure and Internal Design. It is recommended to derive two views, one using the bus architecture pattern (Object Management Architecture pattern) and the other a Component Structure without the Bus component. The latter will typically be evolved further by assigning interfaces, interface dependencies etc. Both should apply the COMBINE Component stereotypes.