There was an interesting topic that was brought up on Software Architecture yesterday in LinkedIn. As always, new keywords keep coming up in the Software arena, and the one that I encountered yesterday was ‘Architecturally Significant Requirements’, which had been coined in 2016. The definition of ASR seems pretty straight-forward, although it would be difficult to find out which requirements are architecturally significant, and if there are any hidden requirements in the existing requirements that are architecturally significant. This is a good challenge to have for a Software Testing professional, as they are well-placed to dig out and detect these kind of stuff when they learn about the software.
The indications of whether a requirement is an ASR as per Wikipedia are:
- Associated with high business value and/or technical risk.
- A concern of a particularly influential stakeholder.
- Has a first-of-a-kind character, e.g. none of the responsibilities of already existing components in the architecture addresses it.
- Has QoS/SLA characteristics that deviate from all ones that are already satisfied by the evolving architecture.
- Has caused budget overruns or client dissatisfaction in a previous project with a similar context.
Sounds familiar? To me, there were many requirements like that during my course of testing systems software and applications, especially in the areas of performance (e.g. application support for 100,000 devices!). The process of finding out whether the software would satisfy such a requirement (which would blow the existing design) is excruciatingly slow, which often involves multiple iterations of testing. ‘Go step by step’, the developers would advice, ‘let’s first test 20,000 devices, and then 40,000, and so on’. It would sound nice till that day when the software would work for 80,000 devices and the design would break for 100,000! Then, re-design everything from scratch! Why not start testing with 100,000 itself, right? When I consider this example, I can see all the bullets above checked. It was such a furor.
Anyways, what are my tips to detect an ASR?
- Consider the requirements aspects that I described, and see what are the stake-holders asks are in these areas
- Look for hidden requirements within requirements
- Engage with Product Owners and Business Analysts and participate in meetings that they have with stakeholders
- Research on industry/business solutions that are similar to your product/application and see what those comparable products offer and how your product is going to match or beat them
- Bring them up right upfront and get them addressed while in architecture/design stages!
Too much for a Software Testing person, you think? I would say no, because the value-add of a Software Tester is not limited to testing developed software, but engage right from the beginning from requirements and architecture, while the contours of the product are being designed. That would prevent heartburns later for everyone!
If you are looking for requirements and architecture analysis for your product in your organisation from a Software Testing and Quality perspective, feel free to reach out to me.