What is Requirements Architecture?
Requirements architecture is the organization and structure of software requirements artifacts. When trying to describe what requirements architecture is, it’s helpful to look at other types of architecture. First, think of what a building architect does – she designs a building so that it can be structurally sound, livable, and aesthetically appealing. She decides, based on engineering principles, where a supporting column or load-bearing wall should go. The pitch of the roof is determined in order to provide adequate runoff and minimize building materials. Room layouts are designed so that rooms flow into one another based on how people actually live. Windows are placed so that people can see outside, doors are placed so that they open without bumping into traffic flow or other doors, plumbing fixtures, etc.
Similarly, an application architect or software architect designs software so the application is usable, stable, and appealing to the user. In software architecture, components of the software are implemented so that changes can be made easily, integrations between other systems are smooth and only built when necessary, and so that the user experience is acceptable. One goal of a good software architecture is to handle scalability of the system and minimize complexity, and is therefore much more important as a system becomes more complex and is used by a wider variety of people. Think about the software architecture of an ERP as opposed to the software architecture of a simple script used by one person.
Requirements architecture is similar to both building architecture and software architecture. The purpose of a requirements architecture is to structure and organize requirements in such a way that the requirements are stable, usable, adapt to changes, and are elegant (more on why this is important later). When a requirements architecture is sound, it helps facilitate better design of the system it attempts to describe. When a requirements architecture is faulty, it can cause problems. When the requirements architecture is poor, the following problems result:
- No one knows why a requirement was changed
- Requirements cannot be reused
- Traceability is superficial or unused by other teams
- Requirements reviews involve irrelevant information
- Big picture of the system being built and reasons for building it are not well-understood
- It is important to keep in mind that the purpose of a good requirements architecture is to build working software that meets business objectives.
It is important to keep in mind that the purpose of a good requirements architecture is to build working software that meets business objectives.
Attributes of a Good Requirements Architecture
Just as software requirements must be testable, unambiguous, and concise, a requirements architecture must also possess certain attributes. The above blueprint provides some general guidelines for how to structure requirements, but keeping in mind the following attributes:
- Maintainable: Whatever choices you make in organizing requirements, ensure that you create a structure that can adapt to changes in requirements.
- Traceable: Do you know which requirements any given process flow step is traced to?
- Usable: Consider the stakeholders in the org chart—are the requirements architected in such a way that you could either produce output for each of them or such that they could navigate to the requirements in the tool and find the requirements objects that are relevant to them? The hierarchies and traces you create should be consistent: Don’t create one hierarchy where the FRs are children of the models and another hierarchy for the same project where FRs are not children of the models but are traced to them. The absolute worst thing to do is to list all requirements objects in a flat list or to manage your requirements in word or excel.
- Scalable: Imagine your requirements architecture with 10 times the number of requirements it has. Now imagine it with 100 times the number of requirements. Architectures should be able to support the addition of new requirements with minimal overhead.
- Elegant: Are there just enough hierarchies to facilitate use? Are you repeating hierarchies just to make traceability easier? Does your architecture contain duplicate models or requirements?
- Generalizable: The architecture approach should be repeatable. You ought to be able to go into any project and no matter the domain use the same approach to requirements architecture.
All architectures are tradeoffs – like in software architecture, you may need to sometimes sacrifice aesthetics for robust traceability or reuse. Or you may sacrifice usability for ease of exporting to external formats. Understand the tradeoffs you are making with your requirements architecture.
In a subsequent post, I will describe in more detail what a requirements architecture looks like and some best practices around maintaining relationships between requirements artifacts.
