How do software architects deal with non-functional requirements?

The full results of our exploratory study on how software architects deal with non-functional requirements (based on a set of interviews with software architects) were presented at the RE’12 conference (full paper is available here and the summary/slides can be browsed below)

What was the motivation of this work? Research papers on software architecture often include sentencens like:

  • “[NFRs] play a critical role during system development, serving as selection criteria for choosing among myriads of alternative designs
  • “the rationale behind each architecture decision is mostly about achieving certain NFRs”
  • “quality attribute requirements strongly influence a system’s architecture”

but the problem is that there is very little evidence that this is really how software architects work in practice. Therefore, we set out to see if we could confirm or not this assumption.

Some of the observations that can be derived from the analysis of the interviews’ data were quite surprising (for full details and the threats to validity see the full text linked above, in the following we single out some simplified results):

  • In fact, nobody had a permanent software architect role. Instead, they played the role of software architect (and others simultaneously) depending on the project
  • There is a lot of confusion regarding the exact meaning of several non-functional requirements
  • Non-technical requirements (price, license, provider) are as important as the technical ones, i.e. the SW architecture can never be the ideal one but the one that satifies all these non-technical constraints).
  • The software architect, and not the client, is the one that decides which NFRs are needed
  • System compliance with the NFRs is hardly ever verified
  • No tool support to manage the NFRs is used.

5 Responses to How do software architects deal with non-functional requirements?

  1. [...] full results of our empirical study can be read here but you can read here some of the findings plus the discussion they triggered with Frank Buschmann [...]

  2. [...] Do quality requirements really influence the choice of a software architecture? From – Today, 12:17 AM After a set of interviews with software architects it turns out that our (naïve) view on how software architectures happen in practice was quite wrong. [...]

  3. PJ says:

    So to clarify, you surveyed a group of people, out of whom (in your words) “nobody had a permanent software architect role” and “played” the software architecture role, and discovered that definition and management of NFRs amongst this group was inconsistent and unverified.

    Do you think you might have got different results had you interviewed people who do have a permanent software architecture role?

    • jordi says:

      We chose people that defined themselves as software architects. The fact that their companies had no explicit software architect position came as a surprise to us as well.

      So, it´s not that we didn´t interview “the” software architect of the company, what happened is that in all those companies the role of software architect was taken by different people depending on the project.

      Of course, we’re not saying that this is the case for all companies (in the paper we describe the characteristics of the companies that took part of the study) but I do believe that it´s significant that in all our companies this was the situation

  4. [...] related blog post with more detail can be found here. Share this:ShareEmailPrintDiggFacebookRedditStumbleUponTwitter Qualitative Studies, [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress
More in requirements, survey
Architecture Quality revisited

Top 5 modeling posts – April/June 2012

Conceptual modelling for the rest of us with ConML