To design the software architecture for a system you must consider the software qualities it must have.
To think through that, you will want a checklist or a framework, or a reference model.
An oldie-but-nearly-goody is FURPS, which views software quality under five top-level headings:
- Functionality
- Usability
- Reliability
- Performance
- Supportability
but anyone working in software since the invention of the internet cannot ignore Security (which in FURPS was a sub-heading under functionality) as a top level concern, so that gets us to:
FURPSS with two SSes
- Functionality
- Usability
- Reliability
- Performance
- Supportability
- Security
A 3-way split of design thinking
In a typical software project, the responsibility for achieving these qualities is often split out as:
- Functionality: this is what analysts and developers devote much of their attention to
- Usability: this is what designers, and others who care, pay attention to
- Reliability, Performance, Supportability, Security: when these go wrong, everyone turns to the project architect, or principal engineer, or the tech lead.
I think this 3-way split matches the competencies required to deal with each area well. Being an expert in one of these areas does not make you an expert in the other two. A team lacking one of these competencies is at higher risk of delivering flawed software. And to be a good all-round lead in software requires you to learn some of the body of knowledge of all three areas. Don't relying on just picking stuff up as you go along.
When FURPSS is not enough
FURPSS is a minimal taxonomy and works very well for a lot, maybe most, vertical application development, a.k.a. enterprise software. But for bigger or more complex projects you need a bigger checklist. You need …
ISO/IEC 25010 (SQuaRE)
SQuaRE stands for Systems and software Quality Requirements and Evaluation. It defines over forty qualities, under nine main quality headings:
• Functional suitability
• Performance efficiency
• Compatibility
• Interaction Capability (previously, Usability)
• Reliability
• Security
• Maintainability
• Flexibility (previously, Portability)
• Safety
In addition, SQuaRE considers quality across stages of the product lifecycle (which FURPSS does not highlight), from early use and development to quality in use. (For even a medium sized project, maintainability matters already before release 1. Some projects never see the light of day, because they become unbuildable or unmaintainable even before first release).
A great place to browse through Square and many other quality standards, is at arc42.org which offers a browsable graph of quality definitions and a large library of definitions, references, and examples.
Almost no small or medium project will benefit from documenting and considering forty nine quality attributes, but they will benefit from the project architect knowing which of those forty nine attributes are relevant to the project. Square, or the arc42 website, are excellent as a resource to browse, and pick from, and ask the question, which, exactly, of these forty-plus ways of looking at software quality are helpful to my project? It is a good way to review whether there is anything important that you might have missed.
All That is Old Is New Again. ISO 5055
But SQuaRE has not taken the world by storm. ISO5055 has subsequently been developed, which moves away from SQuarRE's broad view of system behaviour back to a narrower, techy, inside view of the system. It's key headings are:
- Security
- Reliability
- Performance Efficiency
- Maintainability
Which is all but identical to the RPSS of FURRPSS. I take this as a validation of sorts that FURPSS is a solid starting point for most small and medium projects.
But that is not the point of ISO5055. It's full title is “Information technology — Software measurement — Software quality measurement — Automated source code quality measures” and it intends to be a way to automate the detection of quality failures before the system is deployed. Specifically it proposes to automate checking for the 138 issues listed in Mitre's Common Weakness Enumeration.
Conclusions for a project architect
- FURPSS with two SSes is good.
It is enough for most application development. ISO5055 affirms RPSS as the four key quality requirements that sit alongside Functionality and Usability. - Take some time to browse SQuaRE or quality.arc42.org.
They give you a bigger perspective for reviewing whether there is anything important you have missed, and for thinking about quality across stages of the lifecycle.
References
- You can read the forty nine definitions at ISO25010 on the ISO Online Browsing Platform.
- ISO5055 preview.
- quality.arc42.org for their large library of resources.
- ISO25010 itself costs about £350 to buy.
