Specification (Iteration 1)

Capturing requirements

interviews
prototypes
scenarios
mock-ups
political & social factors
consensus building

Classifying requirements

functional (capabilities) vs. non-functional (constraints)
high-level or derived
emergent
priority: manditory, highly desirable, desirable, optional
scope: global, subsystem, component
volatility/stability

Non-Functional Requirements

Usability

Impedence mismatch with existing workflows
UI conventions
online help
documentation

Reliability/Dependability

mean-time between failures
fault tolerance/robustness
safety

Performance

Response time
Throughput
Availability
Accuracy
Algorithm complexity?

Supportability

How easy will it be to add new features? fix bugs?

Use Case Diagrams

We can represent the functional requirements of a system using a UML use case diagram. In this diagram requirements are represented as use cases (ellipses) and the users or external systems that the use case must interact with are represented as actors (stick figures).

An actor association is a line or arrow connecting an actor to a use case and represents a conversation between the use case and the actor. The direction of the arrow indicates who begins the conversation.

E-Store

Word Processor

E-mail Client

Telephone

Calculator

Use Case Elaborations

A use case diagram isn't much more than a list of requirements. Each use case needs a subsequent use case elaboration:

Name: Open Document
Description: Locates a document previously saved by the word processor, and makes it the current document being edited.
Priority: high

Domain Modeling

The behavior of a system is simply the various interactions between the system and its environment. Therefore, in order to understand system behavior, we must understand the system's environment.

There are two environments: the deployment environment and the business environment. The deployment environment includes the users and remote system that the system must interact with. It also includes the communication protocols that the system uses to communicate with remote systems as well as the interfaces the system uses to communicate with users. The deployment environment is captured by use case diagrams and UML deployment diagrams.

The business environment includes business concepts, rules, and processes. This information is captured in the domain model, which includes UML class diagrams, object diagrams, and activity diagrams.

The domain model includes business activities, processes, events, roles, entities, rules, and descriptions.

Processes, Activities, Roles, and Events

A process can be seen as a kind of finite state machine. The states are activities. The transition from on activity to the next is caused by an event. Usually the event is the completion of the current activity. Activities are associated with roles. A role is the person, persons, or device responsible for completing the activity.

Business processes can be modeled using UML activity diagrams.

Example 1: A Customer Support Workflow

Several states can be simultaneously active in a concurrent FSM. We use forks and joins, also called synchronization bars to show simultaneous activations or deactivations, and swim lanes to identify which processor or actor a given state is assigned to.