Analysis vs Requirements Discipline in RUP

Both RUP disciplines, Requirements and Analysis, study the problem domain and therefore concentrate on the software requirements. Quickly enough the question raises: what's the difference between Requirements and Analysis, that justifies the existence of both disciplines?

I have being lately involved in the design of an internal course on Analysis and Design. In searching for the right answer to the above question, this is what I came out with:

While both disciplines deal with the problem domain, the Requirements discipline does that to capture the client thoughts and reasons. To simplify the task at hand the Requirements discipline uses natural language as vehicle, since that's the language the customer speaks. As a consequence the requirements specification is inherently imprecise and frequently incomplete or conflicting. Of course, the requirements engineers will probably do their best effort to minimize that.

The Analysis discipline also focuses on the problem domain, but its goal is to communicate the requirements to the designers/developers. The natural way to do that is to use a formal modeling language, frequently UML. The main objective is to work out all the imprecision’s of the requirements, completing them and resolving eventual conflicts. Frequently that will lead to a review/rework of the requirements. I look at this part of the process as a sort of intake of the requirements.

A typical area where Analysis clearly complements Requirements is in modeling the user interaction requirements. This effort produces a visual representation of what is expected, which can be captured more easily and descriptively that way than with plain prose.

Another area where Analysis models definitely add value is in organizing our data requirements at the interface level. That can be the data showing up on a user interface, but also the data contracts of a service interface or the content of an exchange file.

What about the Project Start Architecture (PSA)?

I notice increasing interest on the Project Start Architecture (PSA) artifact as more and more organizations enters the Enterprise Architecture arena. Unfortunately not everyone is on the same page concerning the usage of this document. As this keeps heating arguments in circles around me, I thought I would collect my thoughts on this subject.

The PSA, as I know it, is an architectural artifact of DyA, the enterprise architecture framework of Sogeti. They have made available a template as well as a whitepaper written by Joost Luijpers, but this is currently only available in Dutch.

The document can be divided in two main parts. The first one identifies those pieces of the reference architecture that are relevant to the project by the time it starts. This imposes an architectural framework to the project team. It is important to notice that this part of the PSA can not be modified during the project. Constrasting with that, the second part of the PSA ussually will be amended in the course of the project. In this one we record two different kinds of information. First we put there design decisions made by the project team within the limits of the PSA (conform the enterprise architecture) if they are candidates for standardization. Next we also record there agreed deviations from the framework imposed by the PSA. That’s it. The PSA contains no more and no less.

Where I see people frequently go wrong with the PSA is by recording project specific design decisions on it. In fact they (ab)use the PSA as a replacement for the software architecture document (SAD).

Maybe a good deal of the confusion derives from an "unfortunate" selection of the name of the role responsible for creating and updating the PSA. In DyA this role is called the project architect. But that’s also the name of the role for the lead designer within the project team for many development methodologies (like RUP). What DyA really means is the enterprise architect assigned to the project. But I can understand why.

TOGAF vs RUP Architecture?

There's a great deal of interest today on the subject of Architecture. But not everyone is meaning the same by that term! Even within large IT organizations embracing open methodologies such as RUP and TOGAF there's lots of discussion and misconception about this issue.

I recently got to an ah-ha point on this, partly due to a discussion at the Application Architecture masterclass I'm doing, but also thanks to this article from Vitalie Temneco (from which I have also temporally borrowed a couple of great pictures bellow).

As I currently look at it, the major differences can be summarized like this:

	RUP	TOGAF
Level	Software Architecture	Enterprise Architecture
Scope	A Project	The Enterprise
Purpose	Timely and effective delivery of software	Realization of the business vision
Artifacts	Vision Uses Cases Non-Functional Requierments Software Architecture Document	Architecture Vision Business Architecture Data Architecture Technology Architecture Architecture Contract
Application Architecture	The internal structure of the system determined by its components and their inter-relationships	The collection of applications that work together to realize the enterprise vision

Looking clossely it is clear where the RUP and TOGAF lifecycles actually overlap!

The point where the TOGAF process intercepts RUP is at the begining of phase F, when enterprise architecture artifacts are handed over to RUP implementation teams. This is completed when both parties agree on the scope of the implementation in the form of the Architecture Contracts in phase G.

Next picture shows the actual flow of artifacts crossing from the TOGAF to the RUP domain.