Should some requirements be called out as “architectural” requirements?

re: Should some requirements be called out as “architectural” requirements?

Arnon Rotem-Gal-Oz — Sat, 27 Jun 2009 18:11:14 GMT

I think requirements that affect a system or subsystem as a whole can be considered architectural. These are better described as quality attributes of the system.

The reason this can be useful is to do some tradeoff analysis up front (without actually trying to encompass, gather and understand all the requirements up front)

You can read a post I wrote about that a few years ago http://www.rgoarchitects.com/nblog/2005/09/04/UtilityTreesHatchingQualityAttributes.aspx

re: Should some requirements be called out as “architectural” requirements?

Jason Lee — Sat, 27 Jun 2009 21:10:12 GMT

I think this is a common classification, more so in enterprise development and product development though. These requirements come from EA generally and EA is typically stuck justifying them. They most often blur the line of requirement and design, but I view a 'requirement' as the ultimate answer to 'why am I doing this' in a project. Quick example - let's say I'm standing up a Warehouse Management System. It needs to source purchase orders from both a merchandising system on the mainframe and an e-commerce system running on a WAS cluster (functional requirement). Additionally, EA has defined that as part of the project, a common pub/sub gateway for purchase orders should be developed to facilitate faster and more-decoupled integration going forward (architectural requirement). So, rather than designing two P2P interfaces, I design 2 P2C (canonical) publishing interfaces and one canonical to target subscription interface. Standard pub/sub type of stuff. What happens when development is already a month behind when they get to this interface or data mapping of the canonical gets mired down and takes three times as long as the estimate? The project leadership start thinking - "what's the value of this again?" and your stuck justifying your 'architectural requirement' that this additional work be done. That requirement can be (and often is) removed due to cost/time constraints, which all functional requirements of the project are met.

re: Should some requirements be called out as “architectural” requirements?

Caprica — Mon, 29 Jun 2009 01:46:36 GMT

I don't mind the odd architectural requirement (or principle in TOGAF speak), what really irritates me is most requirements I read are statements about a specific solution in the mind of the "business analyst" and not statements about what a business requires.

re: Should some requirements be called out as “architectural” requirements?

Max — Tue, 30 Jun 2009 03:41:21 GMT

One of the classifications is functional vs. non-functional requirements.

Mostly architecture of a system is concerned with non-functional requirements. The best example of a non-functional requirement is maintainability, which is definitely an architectural concern/requirement since it affects the way the system is broken down into parts (architecture).

Max.

re: Should some requirements be called out as “architectural” requirements?

NickMalik — Tue, 30 Jun 2009 16:33:18 GMT

Hi Max,

I disagree. Architecture is not constrained by the goofy way that requirements are separated into functional vs. non-functional. Architecture includes awareness and consideration of business process and business process variability, which is nearly all functional.

Personally, the notion of a non-functional requirement is something I attacked in a prior blog post. There are quality attributes, for sure, but the name "non-functional" requirements, and their traceability to business as currently understood in literature, is all wrong.

--- Nick

re: Should some requirements be called out as “architectural” requirements?

NickMalik — Tue, 30 Jun 2009 16:35:35 GMT

Hi Jason Lee,

I get you point, but what you are saying is that architectural requirements are optional, and functional requirements are required. Did I read that correctly?

Do you agree with that statement or are you sharing your concerns about current perceptions and practices?

--- N

re: Should some requirements be called out as “architectural” requirements?

NickMalik — Tue, 30 Jun 2009 16:37:22 GMT

Hi Arnon,

I really enjoy your posts. Thanks for sharing the link.

I agree with tradeoff analysis. The challenge is that the labeling of a requirement as "architectural" is nonsense. When doing tradeoff analysis, you must consider functional as well as quality tradeoffs.

--- N

re: Should some requirements be called out as “architectural” requirements?

Max — Tue, 30 Jun 2009 19:39:34 GMT

Nick,

I know that functional vs. non-functional classification is quite vague and often can be misleading. For example is performance a functional requirements or non-functional. While many people would say it is non-functional some people can argue it's functional as it affects externally visible behavior of a running system.

A more useful distinction (introduced by Paul Clements) is between what can be described as “behavioral requirements” and “developmental quality attributes” with the following definitions

Behavioral requirements - Behavioral

requirements include any and all information

necessary to determine if the run–time behavior

of a given implementation is acceptable. The

behavioral requirements define all constraints

on the system outputs (e.g., value, accuracy,

timing) and resulting system state for all

possible inputs and current system state. By

this definition, security, safety, performance,

timing, and fault–tolerance are all behavioral

requirements.

Developmental quality attributes -

Developmental quality attributes include any

constraints on the attributes of the system’s

static construction. These include properties

like testability, changeability, maintainability,

and reusability.

Do you like this one better?

Max

re: Should some requirements be called out as “architectural” requirements?

Patrick Blok — Tue, 30 Jun 2009 23:32:18 GMT

Agreed, no reason to classify requirements as 'architectural' and 'non-architectural'. Requirement might be more or less detailed, or are valid to the whole or only a part of the IT solutions but I find it hard to give a firm classification for this.

If one would follow the TOGAF ADM, then the requirements that are gathered by the architecture team during phases A till E, could be considered as "architectural requirements". But that's if we really want to justify the use of this term (which I don't).

re: Should some requirements be called out as “architectural” requirements?

Craig — Thu, 02 Jul 2009 12:05:19 GMT

My thinking goes less to systems and more to people and context. (I think (I am developing the idea as I type...))

If EA or IT is considerred a project stakeholder then requirements may flow in that are architectural, becasue they are (usually) about sustainability.

If EA/IT are considerred part of the 'performing organsiation' (aka the project team), then these enterprise requirements/needs are more likely to seen as be development constraints. That is, they are rules you have to play by to be alowwed to deploy into our environment.

The consideration about whether IT is a stakeholder will come from things like organisational structure, culture and maturity. It will also flow out of who is 'running the project.'

re: Should some requirements be called out as “architectural” requirements?

Ramesh Kunhiraman — Sat, 18 Jul 2009 00:10:17 GMT

I think an Architecture is about providing support to functional requirements. Those can be considered as architecture requirements.

Take a case of building or house. There is an architecture requirements for every functions like plumbing structure itself, electricals, elevator placement and ...

The right architecture will deliver the functionality effectively. If not we can say the Architecture is not wrong.

re: Should some requirements be called out as “architectural” requirements?

frens — Fri, 24 Jul 2009 19:06:53 GMT

Interesting discussion; my two cents here:

The discussion has a lot of similarities to the discussion on the differences between architecture and design. In these discussions the level of detail is often the thing on which they are distinguished, but I find that the line is often a bit arbitrary.

IEEE standard 1471 defines architecture as: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. The issue of course is in what you define as fundamental...

As for architectural requirements one could form a (quite simple) definition such as:

The functional and qualitative requirements which are required to be known in order to make the appropriate decisions in creating an architecture. Following this definition, non-architectural requirements are those which are not addressed by architecture but by design and / or implementation.

However the problem in my opinion is that (in a simple waterfall environment) in the requirements gathering phase one cannot yet make a definitive decision on whether a certain requirement is required knowledge in order to create an architecture.

So bottom line: I would say that there is no such classification as architectural versus non-architectural which helps us in our work of developing software intensive systems.

re: Should some requirements be called out as “architectural” requirements?

NickMalik — Sat, 25 Jul 2009 06:20:32 GMT

Hi Frens,

we agree.

--- N