Business Analysis Notes

Basics

RUP in Brief

4 min read · Updated

In short The Rational Unified Process (RUP) is an iterative software development process framework built around use cases and UML. Few teams run it by the book today, but its analyst artifacts (Vision, Requirements Management Plan, Software Requirements Specification) and its traceability chain are still worth borrowing.

Based on: IBM Rational Unified Process document templates (Vision, SRS, Requirements Management Plan); “Developing a Product Vision in IBM Rational Unified Process” (article, in Russian); IIBA, BABOK® Guide v3, section 11.3; Yu. A. Maglinets, Analysis of Requirements for Information Systems (in Russian), lectures 3-4.

On this page

Key ideas#

What RUP is#

RUP is a process for software development and project management from Rational Software, later part of IBM. It was developed by Philippe Kruchten, Ivar Jacobson and others as a companion to the UML modeling language. RUP describes a generic process that an organization or team tailors to its own needs. It can be run in a fairly sequential, document-heavy way or in a lighter, iterative way.

Maglinets classifies RUP among the methodologies designed specifically for building information systems (see Business Analysis Methodologies and ARIS). The BABOK® Guide’s Information Technology perspective describes the Unified Process as adaptive but not agile, and notes that its inception and elaboration phases are the most relevant to business analysts.

Six principles#

RUP rests on six principles, summarized:

  1. Identify and reduce major risks early and continuously.
  2. Center the work on use cases as the expression of customer requirements.
  3. Expect requirements and design to change during development.
  4. Build a component-based architecture and test it early.
  5. Assure quality continuously, at every stage.
  6. Work as a close-knit team, with architects in a key role.

Phases and disciplines#

RUP divides a project into four phases: Inception, Elaboration, Construction and Transition. Requirements baselines are typically set at phase boundaries. Within each phase, work is organized into disciplines such as business modeling, requirements, analysis and design, implementation and testing. The analyst’s work is concentrated in the requirements discipline, especially during inception and elaboration.

Analyst artifacts#

  • Vision: a short description of the product: the problem, stakeholders and users, key needs, and a list of high-level features with attributes such as status, benefit, effort, risk, stability and target release. It guides decisions throughout the project and supports acceptance at the end.
  • Requirements Management Plan: how requirements are gathered, identified, traced, given attributes, baselined and changed, including the change control board.
  • Software Requirements Specification: the detailed requirements. RUP offers two variants: one built on a use-case model plus supplementary specifications for non-functional requirements, and a “traditional” variant based on IEEE 830.

The RUP templates also show a typical traceability chain: stakeholder requests → stakeholder needs (in the Vision) → features (in the Vision) → use cases → supplementary requirements.

Why the Vision matters#

The article on RUP’s Vision document argues for it using Standish Group CHAOS report data: clear goals and minimized project scope appear among the top success factors for IT projects. A short, agreed Vision addresses both.

How to apply it#

Even if your team does not use RUP:

  1. Write a short Vision. Problem statement, stakeholders, key needs and a list of high-level features. The RUP template suggests keeping a full product to roughly 25-99 features so the list stays manageable; a small project needs fewer. Keep the Vision as the reference for scope decisions.
  2. Borrow the feature attributes. Status, benefit, effort, risk and target release work as backlog fields in any tool.
  3. Adopt the traceability chain. Link requests to needs, needs to features, features to use cases or stories. It makes impact analysis fast. See Requirements Traceability.
  4. Do inception and elaboration thinking up front, even in agile teams: settle the problem, scope and architecture risks before the backlog grows.
  5. Tailor ruthlessly. RUP itself says to adapt it. Drop artifacts nobody reads.

Example#

The analyst at The Workshop, a fictional chain of 12 bike-repair workshops, writes a short Vision and a feature list for the outside development team:

Feature Benefit Effort Risk Target release
Online booking of repair slots Critical Medium Low 1
Repair-status text messages Critical Medium Medium 2
Parts used recorded per job Important Medium High 2
Monthly dashboard per workshop Useful Low Low 3

Each feature traces back to a stakeholder need (for example, “customers want to know when the bike is ready without calling”) and forward to use cases written during elaboration.

Pitfalls#

  • Running every artifact. RUP is a framework to tailor, not a checklist to complete.
  • Treating RUP as waterfall. It is designed to be iterative; one long elaboration phase defeats the point.
  • Losing the feature level. Jumping from stakeholder requests straight to detailed use cases removes the layer where scope is negotiated.

Sources and further reading#

  • IBM Rational Unified Process (RUP) document templates: Vision, Software Requirements Specification, Requirements Management Plan.
  • “Developing a Product Vision in IBM Rational Unified Process” (article, in Russian).
  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 11.3 (Information Technology perspective: Unified Process).
  • Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007. Lectures 3-4 (classification of methodologies).
  • Standish Group, CHAOS report, as cited in the RUP Vision article.