Architecture Requirements Specification

I am continuing my review (and understanding) of the TOGAF 9.1 framework. I recently posted a blog about the Architecture Definition Document. The Architecture Requirements Specification is related to the Architecture Definition Document; but it provides a quantitative view of the solution.

What does quantitative mean? Quantitative has to do with quantity and is measured in numbers.

According to the TOGAF specification, the Architecture Requirements Specification “provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.”

The Architecture Requirements Specification is first created in Phase A: Architecture Vision. Section 36.2.6 of the TOGAF specification states that the Architecture Requirements Specification can contain the following contents:

  • Success measures
  • Architecture requirements
  • Business service contracts
  • Application service contracts
  • Implementation guidelines
  • Implementation specifications
  • Implementation standards
  • Interoperability requirements
  • IT Service Management requirements
  • Constraints
  • Assumptions

I quickly realize that the TOGAF specification does not define what an architecture requirement is. I need some clarification. I understand the difference between qualitative and quantitative; but I do not want to recreate the Architecture Definition Document here with quantitative details. So I will start with defining the term “architectural requirement”. The good news is that there is great blog posting titled Capturing Architectural Requirements here The author defines an architectural requirement as “any requirement that is architecturally significant, whether this significance be implicit or explicit”. He also quotes from the Rational Unified Process® (RUP®) that:

“A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.”

He notes that the FURPS+ system provides a systematic approach for classifying requirements.

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

I agree with the author that classifying the requirements will help us to differentiate and understand them better.

The author then provides a five-step approach to gathering the architectural requirements:

  1. Maintain a complete list of architectural requirements (regardless of whether all items are relevant to a particular project). See Appendix B: Architectural Requirements for a sample list.
  2. For each architectural requirement, formulate one or more questions that can help in the specification process. Make sure all the system’s stakeholders can understand these questions.
  3. Assist stakeholders by showing them the potential impact of answering a question one way or the other.
  4. Capture the responses from your stakeholders to each of the questions.
  5. Assist the architect by ensuring that the stakeholders — in addition to answering these questions — assign a priority or weighting to each architectural requirement. This weighting will allow the architect to make tradeoffs between requirements.

Note: You should click on the Appendix B link to view the summary of architectural requirements to consider. They are grouped together using the FURPS+ system.

I also recommend that you view the Sample Architectural Requirements Questionnaire and a summary of the architectural analysis mechanisms. The Questionnaire is how you should organize your requirements questions (and add columns for answer and priority).

This should help me focus on gathering only architectural requirements. Otherwise, I could end up gathering all kinds of requirements.

Another resource for defining an architecture requirement is found here The author states the same concern that I have about TOGAF. That is, there is really no clear definition provided. The author provides the following characteristics of an architecture requirement:

Characteristic Question to Ask
It should describe a necessary change to components in an architecture. This might mean adding new components, removing outdated ones, replacing or improving components, or changing the way in which they are organized and how they work together. What is going to change?
It should include the reasoning or motivations behind the change. Why does it need to change?
It should explain why the existing components are inadequate, limiting or constraining. What problems, issues or concerns are caused by the current architecture?
It should outline the available options for future architectures that address all concerns. How do alternate target architectures eliminate the problems of the current architecture?
It should explain the benefits, value, risks, costs, opportunities, constraints, and future options associated with each alternative. How do we decide between one alternative and another?
It should outline any alternative routes to close the gaps and get from the current to the target architecture. How do we make the transition or transformation from what we’ve got now to what we need in the future?


I think that these are good open-ended questions to ask. It does help with keeping you within a scope. But I would like to start with a structure provided by the FURPS+ system.

The Architecture Requirements Specification is finalized in Phase F: Migration Planning.

You can download a copy of an Architecture Requirements Specification here:

The table of contents is very simple:


There are no examples or detailed descriptions in the document. It’s really not that helpful to get started.

I found another document titled Software Architecture Document that might be helpful here:

It has a lengthy table of contents. Here is part of it:


This document provides examples and detailed descriptions.

To be perfectly honest, I am wondering if anyone creates the Architecture Requirements Specification. Perhaps they prefer a much more agile solution? Or they say that Agile does not support providing this Specification in advance?

I will keep searching for good examples of this document and its use.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s