INFORMATION SYSTEM CASE DIAGRAMS

Information System Case Diagrams



Information System Case Diagrams

Case I: Idol-Pop

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.

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).

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 ...