Collecting Project Problem Requirements The ATCS Modeling Project: Informal Picture Follows

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ## An Example of one ATC System Architecture

Requirements Collection and Organization Scope the extent of the (ATCS) Collect and organize the following ATCS information: 1. ATC Organizational Structure 2. Roles within the ATC Organization 3. Services/Functions Per ATCS Role 4. Existing (non-human) Supporting ‘Systems’ within the ATC Organization

Layers of ATCS Components – Top Layer Problem (Requirements) Layer – The set of all ATC system functions is partitioned into disjoint subsets of functions/services – components In the final deliverable in UML/UMP these system functions are called ‘use cases’. The components are represented as ‘packages’. Related ATCS components can themselves be encapsulated into packages (of packages) called or stereotyped ‘sub-systems.’ In the final UML/UMP model all of these components (packages) appear in the Use Cases View Layer.

Roles, Actors and Viewpoints Organizational Divisions (Units) AccountantControllerInformation Specialist Air Traffic Control - Air Traffic Control Units Administration -Administration Units Communications -Communications Units A ATC System’s Functions are Partitioned into Disjoint Components (View Points): Simple Example

Requirements Questions What are the steps in deriving components as disjoint subsets of system functions/services? Answer. System functions are introduced from the systems’ stakeholders having a ‘vested interest’ in the system. Equivalent stakeholders determine one disjoint subset of system functions. Then, what causes these disjoint subsets to sometimes have relationships? Connectivity? Answer. One disjoint subset of functions/services may ‘need’ certain functions from another disjoint subset. Then, what may cause conflicts or inconsistencies among stakeholders and their subsets? Answer. Contentions.

UML Modeling & Programming Review Chapters 5-6 Related Material

Originating requirements analysis process ATC VORD Chapter 6 Modeling

Viewpoint-oriented elicitation The scope of system development is first established, e.g. the total population of stakeholders The scope is stratified into sets of stakeholders. Stakeholders represent different ways of looking at a problem or problem viewpoints This multi-perspective analysis is important as there is no single correct way to analyse all kinds of system requirements Perspective, viewpoint, view VORD Applied to produce full set of users’ requirements

Banking ATM system requirements The example used here is an auto-teller system which provides some automated banking services I use a very simplified system which offers some services to customers of the bank who own the system and a narrower range of services to other customers Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

Some Auto-teller Viewpoints Bank customers Representatives of other banks Hardware and software maintenance engineers Marketing department Bank managers and counter staff Database administrators and security staff Communications engineers Personnel department

Types of viewpoints Data sources or sinks –Viewpoints are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid Representation frameworks –Viewpoints represent particular types of system model. These may be compared to discover requirements that would be missed using a single representation. Particularly suitable for real-time systems Receivers of services –Viewpoints are external to the system and receive services from it. Most suited to interactive systems

External viewpoints Natural to think of end-users as receivers of system services Viewpoints are a natural way to structure requirements elicitation It is relatively easy to decide if a viewpoint is valid Viewpoints and services may be used to structure non-functional requirements

General Method-based Analyses Widely used approach to requirements analysis. Depends on the application of a structured method to understand the system Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods A viewpoint-oriented method (VORD) is used as an example here. It also illustrates the use of viewpoints

The VORD method: Our Method Start Here! Finish Modeling!

VORD process model activities ATMS Viewpoint identification –Discover viewpoints which receive system services and identify the services provided to each viewpoint ATMS Viewpoint structuring –Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy ATMS Viewpoint documentation –Refine the description of the identified viewpoints and services ATMS Viewpoint-system mapping –Transform the analysis to a UML object-oriented design

VORD standard capture forms

ATMS Viewpoint identification

ATMS Viewpoint service information

ATMS Viewpoint data/control

ATMS Viewpoint hierarchy: Information Structure

ATMS Customer/cash withdrawal templates

A Requirement is a Complete USE CASE in the Model WHO? The persons using this system service (Think of Roles in a Unit) WHAT? The name of the system service WHERE? The location in the system of the service (Think of the Unit) HOW? The way the service is accessed WHY? Is this service necessary? WHEN? The time in the system of the service usage HOW WELL? The quality of the service

Missing Use Case Information WHO? Is this missing? View Point/Actor Classes? WHAT? Is this missing? Service/Use Case Name? WHERE? Is this missing? Unit/Package Name? HOW? Is this missing? Scenario/Script? WHY? Is this missing? Rationale? WHEN? Is this missing? Before, During? After? HOW WELL? Is this missing? Performance?

QUESTION. UML Diagram Model Programming INPUT {See Figs 5.1, 5.10, 5.11 and 5.12 Row 1} Given the following paragraph of Requirements (index numbered ‘shall’ simple sentence format) for a Car Dashboard Display system, translate these requirements into an equivalent UML Use Cases model program. In doing the translation, first translate each sentence in the given requirements into equivalent UML Use Case Diagram modeling format. Note: Your answer here MUST be diagrammatically correct Rational Rose ‘code’, i.e. must pass through the model and access violations checkers. 1. There shall be a car dashboard display The car dashboard display shall be comprised of warning lights The warning lights shall be oil pressure level, doors state and fuel level The services of warning lights shall be turn_on warning lights and turn_off warning lights.

Problem Requirements Analysis WHO? WHAT? WHERE? HOW? WHY? WHEN? HOW WELL? Missing ‘Driver’ Car Dashboard Display Car Dashboard Display System Visualizing Access Missing ‘Rational’ Missing ‘Time’ Missing ‘Performance’

Services Included in Car Dashboard Display (CDD) Warning Lights Specialized Kinds of Warning Lights Specialized Services of Each Warning Light Parts of CDD Oil Pressure Level, Doors State, Fuel Level Turn_On, Turn_Off

Summary of Problem Information for Modeling View Point/Actor Classes – Driver Class Services/Use Cases – Car Dashboard Display, Warning Lights, Oil Pressure Level, Doors State, Fuel Level, Turn_On, Turn_Off Unit/System Package – Car Dashboard Display

UML Program Structures Generalization/Specialization Aggregation/Inclusion/Whole-Parts Access/Unidirectional Association Nested Packages/System-Subsystems View these in the Tools/Create Menu and Vertical Programming Bar