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.