Business Scenarios are a proven technique to link business requirements to architectural models. According to TOGAF a Business Scenario is a description of:
- A business process, application, or set of applications that can be enabled by the architecture
- The business and technology environment
- The people and computing components (called “actors”) who execute the scenario
- The desired outcome of proper execution”
Recently I have been working with another technique which is commonly used by Software Engineering People but mainly for Software Architecture: Quality Attribute Workshops (QAWs) from CMU SEI (Carnegie Mellon Software Engineering Institute. This technique make use of interactive workshops with the main stakeholders of a project. Where you the solution is to be developed either internally or externally (not a COTS), then this technique could be combined with the Business Scenario.
A Quality Attribute Workshop (QAW) is a systematic approach to elicit the needed requirements. This will ensure that all quality attributes are included in the final design. To This end it:
- is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system
- provides a way to identify important quality attributes and clarify system requirements before the software architecture has been created (Implementation Governance)
- is based on the qualities and the non-functional requirements that may be captured in the Architecture Vision document, the team will identify and elaborate specific quality attribute scenarios and document them
- produces a documentation that includes most of the quality attributes specified by the stakeholders
QAW defines two kinds of architectures:
- System Architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviours
- Software Architecture: the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them
The TOGAF specification considers the Enterprise as a System, however the term System in QAW is more related to IT Systems. QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them. A similar concept to what we try to achieve with the TOGAF Business Scenario but with a focus on IT systems quality attributes.
It is also a purpose of identifying scenarios from the point of view of a diverse group of stakeholders which can then be used by the system engineers to analyse the system’s architecture and identify concerns. QAW is mainly addressing non-functional requirements and there is still needs to understand the problems we try to solve, gather functional requirements like in Business Scenarios.
Quality Attribute Workshops ensure that quality attribute scenarios are identified, prioritized, and refined before the software architecture is completed. Individual requirements are viewed in a forum in relation to one another in the context of the overall problem. Architecture is based on complete set of requirements that add up to a whole problem description.
Technique requires involvement – at an early stage in architecture project
- Business stakeholders (end users)
- Systems stakeholders (installers, administrators, DBAs; network, training, acquirers, system and software engineers, etc.)
- Other stakeholders (such as Operations amongst others)
The QAW provides:
- Increased stakeholder communication, an informed basis for architectural decisions
- Improved architectural documentation, and support for analysis and testing throughout the life of the system
And the results include:
- A list of architectural drivers
- Raw scenarios
- A prioritized list of raw scenarios
- Refined scenarios
During the workshops the Stakeholders receive a “participant’s handbook” providing example quality attribute taxonomies, questions, and scenarios.
Below are the steps of the QAW.
Business and/or mission drivers for the system (goals and drivers), plan, strategies, high-level functional requirements, constraints, artifacts and quality attribute requirements should be presented to the stakeholders. Using Business Scenario in conjunction with QAWs can be an appropriate approach.
A QAW lends itself to the capture of many architecturally relevant materials:
- Software architectural documentation is a collection of view packets plus any documentation that applies to more than one view
- Each view packet contains a primary presentation, a catalogue of the view’s elements (including element behaviour), use case diagrams, sequence diagram, context diagrams, collaboration diagram, a variability guide, architecture background (rationale, analysis results, and assumptions about the environment), and other information including mapping to requirements
These elements may also be produced in a Business Scenario or produced later in the ADM phases A : Architecture Vision, C: Information Systems Architectures (stakeholders management and taxonomy of artifacts).
The outputs from the QAW can be summarised as:
- A list of architectural drivers
- Raw scenarios
- A prioritized list of raw scenarios
- Refined scenarios
- Questionnaire
Quality attribute requirements are the means by which a system is intended to meet its business goals and QAW helps to document them.
Software architectures must be designed so that their quality attributes are met.
The QAWs technique can be utilised as a complementary approach to gather all sort of requirements including those from Software Architectures when appropriate.
I read over the weekend that Google recently turned 15 years old. While the exact date the search giant came into existence is essentially a matter of opinion, and the company moves the celebration each year to a convenient date, reflecting on the accomplishments of this organization since 1998 never ceases to impress.
