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 framework.
An oldie-but-nearly-goody is FURPS, which listed qualities 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, which gets us to:
FURPSS with two SSes
- Functionality
- Usability
- Reliability
- Performance
- Supportability
- Security
A 3-way split of design thinking
In practise the responsibility for achieving these qualities is using broken down as:
- Functionality: this is what analysts and developers devote much of their attention to
- Usability: this is what designers, together with those 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. That is, being an expert in one of these areas does not make you an expert in the other two. To be a good, all-round lead in software requires some competence in all three. You must make the effort to learn some of the body of knowledge of all three areas, not just rely on picking stuff up as you go along.
When FURPSS is not enough
FURPSS is quiet minimal taxonomy and works very well for a lot (maybe most?) vertical application development, aka 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 about 40 qualities, under eight main quality headings:
• Functional suitability
• Performance efficiency
• Compatibility
• Usability
• Reliability
• Security
• Maintainability
• Portability
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 size project, maintainability matters already before you've finished building release 1; some projects never see the light of day because they become unbuildable.
Reading and learn some Square. But for most projects, it is more of a framework to pick from (which, exactly, of these 40 ways of looking at software quality are helpful to my project?). But it's a good way to review wether there is anything important that you might have missed.
All That is Old Is New Again. ISO 5055
SQuaRE has not altogether taken the world by storm. In fact, ISO5055 has subsequently been developed, which moves a little away from SQuarRE's focus on behaviour (you might think that is the right focus, but sometimes you just have to get technical) and back to the 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.
But that is not the point of ISO5055. It's actual 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 is good.
It is enough for most application development. ISO5055 is something of a confirmation that RPSS are the four top-level quality requirements that are most wanted, alongside Functionality and Usability. - SQuaRE is good, for when you want to peruse, or use, a bigger checklist, or help for thinking about quality across stages of the lifecycle.
References
- ISO25010 allows you to read a sample
- ISO5055 preview
