Domain Analysis
System Analysis
System Specification
System Modeling
Project Discussion and Exercise
Reference materials and recommended readings
Assignment and Required Readings

Domain Analysis
What is an enterprise system domain?

A collection of current and future enterprise system (software) applications that share a set of common characteristics.

A well-defined set of characteristics that accurately, narrowly, and completely describe a family of problems for which enterprise application system solutions are being, and will be sought.

Example: open information sharing systems is a domain of enterprise systems

Another example: open global file sharing systems is a domain of enterprise systems
Why analyze an enterprise system domain?


Identify opportunities for creating or recognizing reusable system requirements, specifications, designs, implementations, test plans, and user documentation.
Characterize a family of related application systems that conform to a common solution framework for a well-defined problem domain.
 Example: Napster, Gnutella, FreeNet and Scour Exchange are each a global file sharing application system, where the application centers about Internet-based sharing of music or multi-media (e.g., music video) files.
What is domain analysis?

Figure 1. (SADT tm
) Model of Domain Analysis (after Arango and Prieto-Diaz, 1989)
What do we model when conducting a domain analysis?
 Common and Variable properties (components, dependencies, error conditions, etc.)
 of an enterprise system in the domain
Semantics of the system properties
 also known as a conceptual system model
 an configuration of system entities/objects, components, user roles, control schemes, etc. that constitute the system data model
 Dependencies (i.e., relations ) or links between system properties that establish the

 conceptual model, workflow (data flow), and business process flow (control flow)
A vocabulary or lexicon (i.e., a data dictionary) that identifies common objects, attributes, values, relations, constraints or computational processes that collectively constitute a language for the domain
 Also called a domain-specific language
Examples and counter-examples of application systems that are respectively in and not in the domain
 Napster, Gnutella, FreeNet, Scour Exchange and Free Haven are application systems in the domain of global file sharing systems


 The World Wide Web is not in the domain of global file sharing systems.
However to many users, it is a global file system that provides access to files on
(de)centrally managed Web servers.
 Reusable requirements : requirements that account for system features found in members of the system's product family
Generic and taxonomic classification of the elements and dependencies that bound the scope of application systems within the domain.
 Sometimes called a system meta-model (a model of models, or a model of a family of interrelated models)
When is a domain analysis complete?
 This is a business decision, since a domain analysis is never exhaustively complete.
 Domains tend to evolve more slowly than the enterprise systems that support them.

System Analysis
Moving from System Requirements to System Specification

Use Cases and Rich Pictures identify many system elements and dependencies

Use Cases help identify user-system interactions, transactions or processes

Rich Pictures help identify different roles people play, their concerns, overall process flow dependencies, and scope of overall problem domain.

Specifications require identification of:
 enterprise system components ,
 user-system interfaces ,
 user processes for interacting with the system,
 information processes performed within the information system (technology),
 both user activities (e.g., storing, sharing and retrieving business model assets) and computational services (e.g., "file serving") may provide inter-firm service offerings, intra-firm capabilities, or core competencies
 user inputs and system outputs ,
 outputs may be information resources or products for enterprise use
 internal system inputs and outputs between system components,
 process control guid ance or decision-making constraints ,
 human roles or automated mechanisms that enables processing steps,
 error conditions, error handling/signaling
 erroneous user input
 erroneous system output
 erroneous internal system inputs/outputs
 boundary values or anomalous values in inputs or outputs that require special handling
 patterns that configure and bundle inputs, actions/function steps, outputs into workflows (flow of data objects) and processes (flow of control according to business rules).

Specified elements and dependencies need to be organized into abstractions:

Hierarchical abstraction:

Top-level: the Big picture of the system

Middle-levels: sub-systems (a configured collection of components or internal sub-systems), sub-sub-systems, etc.

Lowest-level: where system/software mechanisms operate

Two kinds of hierarchical system abstractions of interest:

Generic: from most general (domain-independent) to most specific
(domain-specific)

Taxonomic: from whole to part

Each is orthogonal to the other

Generic and domain-specific component abstraction:

Components are to be parts of the implemented information system


Components have interfaces through which inputs and outputs pass

User-system interface

Sub-system to sub-system interface

Component to component

Taxonomic classification :

System to sub-system, sub-system to sub-sub-system, etc. to component.

How the parts compose the whole; how the whole is decomposed into parts

System Specification

Enterprise system meta-model for the focal problem domain

System components (coarse-grain): e.g., a database management system; a Web server; a Web browser; an electronic billing and payment system; a corporate accounting system.

Inputs

Objects (entities) or data containers (e.g., text files; mp3 files; video stream; database; directory)

Objects have attributes (e.g., length; format; data encoding)

Attributes have values (e.g., length is 64Kbytes; format is ASCII; data encoding follows MPEG3 standard)

Values have ranges (good data values vs. erroneous data values)

Boundary and anomalous values

Information artifacts (e.g., enterprise data model; bar chart; UML design diagram; data entry record)

May be contained within a single object (data type)

May incorporate and compose multiple objects (complex data type)

Other object types

Documents (formatted in HTML, PDF or .DOC)

MIME objects ("registered" objects types that are associated with specific application programs -- .mp3 objects require an "mp3" player application)

Temporal and Spatial identifiers (e.g., timestamps; GPS coordinates; URL addresses)

Namespaces and Universal (Unique) Resource Identifiers

Etc.

Outputs

Includes same types as Inputs

Reports (for printing), Displays (for browsing or reading), and Forms (for subsequent data entry).

Objects or artifacts that include data specifying how to layout and present according to an implicit/explicit style guide or data exchange standard

User Roles

Control, guidance or decision-making constraints

Business or application data exchange protocols

Business processes

Business rules

System Modeling

Entity-Relation (ER) Data Modeling

Object-Oriented (OO) Modeling
 Component-Based Modeling

Project Discussion and Exercise

Reference materials and recommended readings

Assignment and Required Readings