7.4.1 Purpose
The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives.
7.4.2 Description
Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.
Business analysts use a requirements architecture to:
- understand which models are appropriate for the domain, solution scope, and audience,
- organize requirements into structures relevant to different stakeholders,
- illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,
- ensure the requirements work together to achieve the overall objectives, and
- make trade-off decisions about requirements while considering the overall objectives.
Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)).
Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work.
7.4.3 Inputs
- Information Management Approach: defines how the business analysis information (including requirements and models) will be stored and accessed.
- Requirements (any state): every requirement should be stated once, and only once, and incorporated into the requirements architecture so that the entire set may be evaluated for completeness.
- Solution Scope: must be considered to ensure the requirements architecture is aligned with the boundaries of the desired solution.
7.4.4 Elements
.1 Requirements Viewpoints and Views
A viewpoint is a set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related. Viewpoints provide templates for addressing the concerns of particular stakeholder groups.
Requirements viewpoints frequently include standards and guidelines for the:
- model types used for requirements,
- attributes that are included and consistently used in different models,
- model notations that are used, and
- analytical approaches used to identify and maintain relevant relationships among models
No single viewpoint alone can form an entire architecture. Each viewpoint is stronger for some aspects of the requirements, and weaker for others, as different groups of stakeholders have different concerns. Trying to put too much information into any one viewpoint will make it too complex and degrade its purpose. Examples of viewpoints include:
- Business process models,
- Data models and information,
- User interactions, including use cases and/or user experience,
- Audit and security, and
- Business models.
Each of those viewpoints has different model notations and techniques, and each is important to ensure a cohesive final solution. The solution would likely not be a success if the business analyst only looked at the business process viewpoint.
Similarly, trying to put conventions from many viewpoints in one single viewpoint would make it overwhelming to analyze and contain information irrelevant to particular stakeholder groups.
The actual requirements and designs for a particular solution from a chosen viewpoint are referred to as a view. A collection of views makes up the requirements architecture for a specific solution. Business analysts align, coordinate, and structure requirements into meaningful views for the various stakeholders. This set of coordinated, complementary views provides a basis for assessing the completeness and coherence of the requirements.
In short, the viewpoints tell business analysts what information they should provide for each stakeholder group to address their concerns, while views describe the actual requirements and designs that are produced.
.2 Template Architectures
An architectural framework is a collection of viewpoints that is standard across an industry, sector, or organization. Business analysts can treat frameworks as predefined templates to start from in defining their architecture. Similarly, the framework can be populated with domain-specific information to form a collection of views that is an even more useful template to build architecture from if it is accurate because the information is already populated in it.
.3 Completeness
An architecture helps ensure that a set of requirements is complete. The entire set of requirements should be able to be understood by the audience in way that it can be determined that the set is cohesive and tells a full story. No requirements should be missing from the set, inconsistent with others, or contradictory to one another. The requirements architecture should take into account any dependencies between requirements that could keep the objectives from being achieved.
Structuring requirements according to different viewpoints helps ensure this completeness. Iterations of elicitation, specification, and analysis activities can help identify gaps.
.4 Relate and Verify Requirements Relationships
Requirements may be related to each other in several ways when defining the requirements architecture. Business analysts examine and analyze the requirements to define the relationships between them. The representation of these relationships is provided by tracing requirements (see Trace Requirements (p. 79)).
Business analysts examine each relationship to ensure that the relationships satisfy the following quality criteria:
- Defined: there is a relationship and the type of the relationship is described.
- Necessary: the relationship is necessary for understanding the requirements holistically.
- Correct: the elements do have the relationship described.
- Unambiguous: there are no relationships that link elements in two different and conflicting ways.
- Consistent: relationships are described in the same way, using the same set of standard descriptions as defined in the viewpoints.
.5 Business Analysis Information Architecture
The structure of the business analysis information is also an information architecture. This type of architecture is defined as part of the task Plan Business Analysis Information Management (p. 42). The information architecture is a component of the requirements architecture because it describes how all of the business analysis information for a change relates. It defines relationships for types of information such as requirements, designs, types of models, and elicitation results.
Understanding this type of information structure helps to ensure that the full set of requirements is complete by verifying the relationships are complete. It is useful to start defining this architecture before setting up infrastructure such as requirements life cycle management tools, architecture management software, or document repositories.
7.4.5 Guidelines and Tools
- Architecture Management Software: modelling software can help to manage the volume, complexity, and versions of the relationships within the requirements architecture.
- Legal/Regulatory Information: describes legislative rules or regulations that must be followed. They may impact the requirements architecture or its outputs. Additionally, contractual or standards-based constraints may also need to be considered.
- Methodologies and Frameworks: a predetermined set of models, and relationships between the models, to be used to represent different viewpoints.
7.4.6 Techniques
- Data Modelling: used to describe the requirements structure as it relates to data.
- Functional Decomposition: used to break down an organizational unit, product scope, or other elements into its component parts.
- Interviews: used to define the requirements structure collaboratively.
- Organizational Modelling: used to understand the various organizational units, stakeholders, and their relationships which might help define relevant viewpoints.
- Scope Modelling: used to identify the elements and boundaries of the requirements architecture.
- Workshops: used to define the requirements structure collaboratively.
7.4.7 Stakeholders
- Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, Sponsor, Tester: may assist in defining and confirming the requirements architecture.
- Any stakeholder: may also use the requirements architecture to assess the completeness of the requirements.
7.4.8 Outputs
- Requirements Architecture: the requirements and the interrelationships among them, as well as any contextual information that is recorded.
