This site is currently a working draft of the ITABoK 3.0. Release date is planned for beginning of 2018. In the meantime please utilize the current ITABoK version 2.0
Architecturally Significant Requirements
Architecturally significant requirements is a term used in the ITABoK to describe a set of concepts which relate to the development and delivery of value to an organization. Architecturally significant requirements can be broken into several different factors, depending on how the engagement model is implemented.
Requirements are recognized and developed throughout the entire portfolio of the enterprise. The goal of which is to represent value streams across the enterprise and to trace those value streams through the decision making process. Traditional architecturally significant requirements are mapped to innovation and ideation, business case development, project and or product requirements, epics and stories. And represent needs from both business and technology leadership.
For the purpose of the ITABoK, all thinking, ideas and desires about a business or technology system can be characterized as requirements, though depending on the full engagement model in use by an organization they may be called other names and use other format.
Architectural requirements are hard to determine, primarily because they need to be gathered so early in the lifecycle before details are known. Many organizations continually add detail and refinement to ASRs through the enterprise lifecycle with a common architecture goal of value traceability in decision making. Architects should start early in project life-cycles based on when an architect engages in a project, with the end goal being integration into the innovation and project/product funding lifecycle itself.
ASR representation in the life cycle.
||ASRs are represented as ideas and characteristics according to the innovation cycle. These are funneled either into experimentation or into a business case by a value stream owner. All ASRs at this level are considered architecturally relevant.
||ASRs are represented as course-grained ideas with the goal of understanding program cost or value generation. Traditionally these are used for rough scoping purposes to satisfy budget and staffing needs. Most ASRs at this level are considered architecturally relevant.
||For details on Epic and Story level integration with ASRs see the Lean and Agile Integration. Some ASRs at this level are considered architecturally relevant.
||Few ASRs at this level are considered architecturally relevant though it is necessary for the architect to continuously review to ensure identification of architectural impact.
Either way at some point the solution architect and business architect and will have to begin extracting relevant architectural requirements. So what exactly are ‘relevant’ requirements?
The ITABoK simplifies the guidelines for identifying ASRs. There are three primary types of requirements which will be important to your architecture design decisions.
Types of Requirements
Requirements are typically placed into these categories:
- Functional requirement ─ Describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as features.
- Non-functional requirements ─ Are the ones that act to constrain the solution. Nonfunctional requirements are known as quality attribute requirements.
- Constraint requirements ─ Are the ones that act to constrain the solution. No matter how the problem is solved the constraint requirements must be adhered to.
Much work has gone into what makes a requirement significant to an architect. The SEI paper on the subject written by IBM provides significant detail on the subject. The literature suggests many categories of impacts which make a requirement relevant or not. However the thing that makes a requirement relevant is when an architect thinks it is.
The following describe categories of impact which potentially make a requirement relevant to the architecture.
- Requirements which deeply impact relevant product or frameworks within the business and technical roadmap.
- Requirements which impact managed quality attributes.
- Requirements which impact capabilities of the organization or the roadmap.
- Requirements which are deeply political or have an executive champion.
- Requirements which imply innovative business models or approaches.
“The vast majority of ‘requirements’ are not required for value. They are really more about the preferences of a single system user. Start learning value management over user preferences now for better systems.” – Paul Preiss
Architects are(n’t) engineers (itabok principle), which impacts the level and type of requirements to help understand critical design decisions but doing so based on best case overall value. Define what makes for a relevant architecture decision. Although this is a complicated topic in more mature environments which should use a calculation based on strategic importance.
Architectural Structural Impacts
What is an architecturally significant component? This is a full article in its own right but for the sake of clarity let’s define it as a component that should be decided by the architect of a project instead of another stakeholder such as development, operations or business stakeholder.
A significant architectural component is controlled by two decisions. One decision is controlled by architectural complexity but can be decided based on total cost of ownership. This may be an application server, a new type of client we will support, an ESB or a rules engine, but it is definitely not a minor development pattern such as singleton or even minor component frameworks. The other type of decision is strategic importance. If we have done our jobs as architects we will have a target state architecture. Architectural component decisions that move us closer to our target state architecture are also significant at the project level.
When you are in the process of design you should gather any requirements that lend themselves to decisions about architecturally significant components. This is a skill that most seasoned architects take for granted since after many projects you will get a sense for these that is almost a bit like a ‘Spider Sense’.
Quality Attribute Impacts
Another area of requirement decisions are those that deeply impact quality attributes. Often called the ‘~ilities and ~illiancies’ of a system, these are the horizontal cross-cutting concerns that impact a system such as performance, security, usability, RAS, and flexibility. During a requirements gathering phase the architect should be deeply alert for any requirement or idea that impact one of these items and should illicit requirements that allow for measurement of effective quality attributes. A great tool for the practicing architect is to build a set of questions which have definite impact on quality attributes and can be measured. Here are a couple of examples from my own practice:
- “How many concurrent users do we need to support and in what portions of the system?”
- “How flexible and decoupled should the system be? Which functional components will change often over time?”
Technical Capability Impacts
One of architectures key roles is the understanding and management of technology capability impacts from both business and technology requirements. During the implementation of the engagement model the architecture team should determine what level of capability impact makes a requirement architecturally significant. These impacts can be compared with resource utilization, time impacts, business capability impacts, cost of delay, financial cost or value numbers based on the chosen value management implementation.
Political and Stakeholder Impacts
Realistically certain requirements represent preferred capabilities, features or value perceived by a relevant or powerful stakeholder. These requirements become architecturally significant from a political and organizational perspective. Generally the higher the power or influence of a stakeholder the more relevant their preferred requirements will become.
Incremental Business Innovation
The final type of architecturally significant requirement often comes from the architects themselves. These are technical capabilities that allow for incremental innovation in projects close to the customer. For example, if we are building a web interface to our system, could this be extended to a mobile application? If so, how beneficial would that mobile usage be to our organization? Often architects and project members identify innovative components which do not deeply impact a project scope or timeline. Even if they do, these ideas form the opportunity to innovate in the next round of projects or innovative ideation.
Architectural requirements generally do no match detailed requirements specifications. Instead the following chart identifies areas of importance for ASRs.
||The requirement addresses one and only one thing.
||The requirement is fully stated in one place with no missing information.
||The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
||The requirement is atomic, e.g., it does not contain conjunctions. For example, “The postal code field must validate American and Canadian postal codes” should be written as two separate requirements: (1) “The postal code field must validate American postal codes” and (2) “The postal code field must validate Canadian postal codes.”
||The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
||The requirement has not been made obsolete by the passage of time.
||The requirement can be implemented within the constraints of the project.
||The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited.
||The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms.
||The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis.
||The implementation of the requirement can demonstrate measurable value to one or more areas of the organization.