Jaa

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

  • Artikkeli

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.

Comments

  • Anonymous
    June 27, 2009
    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

  • Anonymous
    June 27, 2009
    The comment has been removed

  • Anonymous
    June 28, 2009
    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.

  • Anonymous
    June 29, 2009
    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.

  • Anonymous
    June 30, 2009
    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

  • Anonymous
    June 30, 2009
    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

  • Anonymous
    June 30, 2009
    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

  • Anonymous
    June 30, 2009
    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

  • Anonymous
    June 30, 2009
    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

  • Anonymous
    July 01, 2009
    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.'

  • Anonymous
    July 17, 2009
    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.

  • Anonymous
    July 24, 2009
    The comment has been removed

  • Anonymous
    July 24, 2009
    Hi Frens, we agree. --- N