Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software. Is that valid?
To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not. So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”
Consider this analogy
A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details. We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house. All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.
So are requirements architectural if the client tells them to the architect? I don’t think that is a useful definition.
Are some requirements more inherently architectural than others? Good question.
Some requirements came in the form of building codes. Were those architectural? Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.
In software, the same problem occurs. Business customers describe their use cases. Sometimes we talk about using data from other systems. Other times, we talk about speed and performance. Mostly we talk about functionality. What the application will do, and how it will make their lives better.
I don’t differentiate requirements as “architectural” vs. something else. It is not a distinction that I find useful. My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?” If so, what logic do you use to flip that attribute to “true?”
I’m just not seeing it.
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
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.
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.
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.
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
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
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
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
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).
PB
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.’
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.
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.
Hi Frens,
we agree.
— N