Core process workflows in RUP

There are nine core process workflows in the Rational Unified Process, which represent a partitioning of all
workers and activities into logical groupings.
A workflow is a sequence of activities that produces a result of observable value.
In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram.
The core process workflows are divided into six core “engineering” workflows:

1. Business modeling workflow
2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
And three core “supporting” workflows are:

1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow

The actual complete workflow of a project interleaves these nine
core workflows, and repeats them with various emphasis and intensity at each iteration.
I'm going to say a few words about first three core workflows.
Business Modeling
One of the major problems with most business engineering efforts, is that the software engineering and the business
engineering community do not communicate properly with each other. This leads to the output from business
engineering is not being used properly as input to the software development effort, and vice-versa. The Rational
Unified Process addresses this by providing a common language and process for both communities, as well as
showing how to create and maintain direct traceability between business and software models.
In Business Modeling we document business processes using so called business use cases. This assures a common
understanding among all stakeholders of what business process needs to be supported in the organization. This is
documented in a business object-model.
Requirements
The goal of the Requirements workflow is to describe what the system should do and allows the developers and the
customer to agree on that description. To achieve this, we elicit, organize, and document required functionality and
constraints; track and document tradeoffs and decisions.
A Vision document is created, and stakeholder needs are elicited. Actors are identified, representing the users, and
any other system that may interact with the system being developed. Use cases are identified, representing the
behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to
be relevant to the users. Each use case is described in detail. The use-case description shows how the system interacts step by step with the
actors and what the system does. Non-functional requirements are described in Supplementary Specifications.
The same use-case model is
used during requirements capture, analysis & design, and test.The following figure shows an example of a use-case model:

Analysis & Design
The goal of the Analysis & Design workflow is to show how the system will be realized in the implementation
phase. You want to build a system that:
performs—in a specific implementation environment—the tasks and functions specified in the use-case
descriptions.
fulfills all its requirements.
is structured to be robust (easy to change if and when its functional requirements change).
Analysis & Design results in a design model and optionally an analysis model. The design model serves as an
abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and
written.
The design model consists of design classes structured into design packages and design subsystems with welldefined
interfaces, representing what will become components in the implementation. It also contains descriptions of
how objects of these design classes collaborate to perform use cases.
The design activities are centered around the notion of architecture. The production and validation of this
architecture is the main focus of early design iterations. Architecture is represented by a number of architectural
views. These views capture the major structural design decisions. In essence, architectural views are abstractions
or simplifications of the entire design, in which important characteristics are made more visible by leaving details
aside.
BA should pay special attention to first two (and maybe sometimes three) engineering workflows, and to second supporting workflow (Configuration and Change Management).