Jun. 7, 2022
The Software Architect as a Clarifier of Requirements
In this first post on the role of the software architect, I would like to discuss the software architect as a clarifier of requirements. A software architect is dependent on clear quality requirements. Whether verbally articulated, or written down in the form of a specifications document, or on a white board, it is often the case that the requirements provided are not completely clear for the purpose of architecture (though they may be clear enough for UI design or development of functionality).
In particular the quality requirements should be clear and specific (where possible also measurable), preferably in the form of a quality attribute scenario, also known as a quality scenario in some circles. Many business analysts will not necessarily produce these in a manner suitable for architectural design.
When the architect has these quality requirements, the architect also needs to be able to determine what are appropriate tradeoffs that can be made in trying to achieve these requirements. This is crucial, as not all the quality requirements can always be met simultaneously. Architects must therefore select from a wide range of methods and tools to elicit not just clear quality requirements for projects, but the level of importance of each requirement in comparison to the others.
Quality requirements along with primary functional requirements, business constraints and some other key factors (which are sometimes called architectural concerns) are critical to identify priorities and use during the design process. If architects do not take the responsibility for ensuring that these architecturally significant requirements (ASR) are clear and relevant, then the architectural design process maybe futile as the most important issues may not be addressed.
There are methods and strategies which can be used by the software architect to discover and document quality requirements that are suitable for driving the architectural design process. One example is the Quality Attribute Workshop (QAW) created by the Software Engineering Institute at Carnegie Mellon University in the USA.
In a quality attribute workshop your goal is to acquire a short-list of quality requirements arranged in order of priority. Initially when working with a development team or organisation, it will often appear that many quality requirements are equally important. In one project, I worked with teachers, students, lab technologists, school administrators and a few developers. When I started the workshop the list of critical quality requirements was about 23. This is definitely not where you want to be when starting an architectural design. It is confusing to decide on components, how they should communicate with each other, patterns they should use and especially frameworks if things like security and ease of use or modularity and performance are equally important within a system or system component.
Generally speaking the successful quality attribute workshop will:
- Clarify how the workshop will be conducted for all participants
- Ensure that participants understand (roughly) how to write a quality attribute scenario (these should be short enough to fit on a single sticky note)
- Allow all participants to articulate the quality attribute scenarios that are most important to them
- Consolidate these quality attribute scenarios where there maybe overlaps and get everyone to agree on the complete list
- Give a limited number of votes to each participant and have them vote on the most important ones
The result of this exercise is usually a handful of requirements that more accurately reflect which quality requirements are most important and they can easily be ordered based on priority based on the number of votes. When I used this method in the project I mentioned my list of 23 became a list of 8 prioritised quality attribute scenarios. Bass et al. (2002) documents all the detailed steps for conducting the QAW.
This exercise is not a silver bullet of course and sometimes your gut feelings as an architect may be quite critical and may result in decisions that do not perfectly reflect all aspects of the results from the QAW. In fact as an architect we still have need to consider development risk, budget, schedule and many other constraints.
Contact me at claudine@callensoftware.com for information on consultancy services, workshops and trainings for individuals and groups.
References
Bass, L., Clements, P., & Kazman, R. (2022). Software architecture in practice. Addison-Wesley.