Mastering Solution Architecture: Capturing Non Functional/Quality Attribute Requirements using Scenarios.

In the fast-paced world of software development, it's easy to get caught up in the day-to-day challenges of coding and forget about the bigger picture. Recently, while working on a project , I found myself grappling with issues that went beyond mere functionality. Questions about system performance, scalability, and maintainability kept surfacing, reminding me of the critical importance of software architecture.

In this blog post, I want to share some key insights from my learnings, drawing parallels to a recent project. Whether you're a seasoned architect or a developer looking to broaden your perspective, these principles can help you build more robust, flexible, and successful software systems.

Let's explore how focusing on quality attributes(Non-Functional Requirements), using scenarios to capture requirements, and employing a systematic design process can transform the way we approach software architecture.

Understanding Stimulus

In the context of quality attribute scenarios the stimulus is a key component. The stimulus is the condition or event that arrives at the system and requires a response. It's essentially what triggers the scenario.

Examples for different quality attributes:

• Availability: A hardware failure, a software fault, or a sudden spike in system load
• Performance: Arrival of a service request, a periodic event trigger, or a data stream
• Security: An attempt to access sensitive data, a denial-of-service attack, or a system probe
• Modifiability: A request to add, delete, or change functionality
• Usability: A user action like clicking a button or entering data

Importance of stimulus:

• The stimulus helps define the specific situation that the architecture needs to address.
• It provides context for the system's response and helps in evaluating whether the response is adequate.
• In architectural design: Understanding the nature of potential stimuli helps architects design systems that can appropriately detect and respond to various situations. It also aids in defining interfaces and interaction patterns between system components
• In testing and evaluation: It also aids in defining interfaces and interaction patterns between system components.

Understanding Scenarios

Without going into definition, just putting some examples of drafting a general and concrete scenario, both of them equally important to get to the quality attribute scenario requirements.

Concrete Scenario: Applies for a particular system        

• Source: Online shoppers
• Stimulus: 1000 purchase requests per minute
• Environment: Holiday sale period
• Artifact: E-commerce website
• Response: Process purchase requests
• Response Measure: 99% of requests processed within 2 seconds

General Scenario: Applies for many systems        

• Source: Internal or external actor
• Stimulus: Tries to access/modify data or services
• Environment: Online or offline, connected or disconnected
• Artifact: System services, data, or components
• Response: Authenticate, authorize, or block access; log attempt
• Response Measure: Time/effort to detect attack; % of attacks resisted

Benefits of Using Scenarios:         

• Provides a consistent way to specify requirements across different quality attributes
• Makes quality requirements concrete and testable
• Helps in communicating requirements clearly among stakeholders
• Facilitates architecture evaluation against specific quality goals

In Summary, Scenarios serve as input to the architectural design process, helping architects make informed decisions about tradeoffs between different quality attributes. Further, scenario development is an iterative process. As the architecture evolves, scenarios may need to be refined or new ones added.

Priority of Scenarios

Not all scenarios are equally important. There are techniques for prioritizing scenarios based on their architectural impact and business importance.

Here's an overview of the main approaches: Often a combination of below techniques is most effective and the choice depends on the specific context of the project, the nature of the stakeholders involved, and the time and resources available for the prioritization process.

1. Stakeholder Voting: Each stakeholder is given a set number of votes (e.g., 100 points). Stakeholders distribute their votes among scenarios based on perceived importance. Scenarios with the most votes are considered highest priority.
2. Utility Trees: Scenarios are organized into a tree structure. The root represents the overall system utility. Branches represent quality attributes. Leaves are specific scenarios. Each scenario is assigned two rankings: importance to the business and difficulty of implementation. These rankings help prioritize scenarios.
3. Cost-Benefit Analysis: Estimate the cost of implementing each scenario. Estimate the benefit or value of each scenario to the business. Prioritize based on the best cost-to-benefit ratio.
4. Risk-Based Prioritization: Assess the risk associated with not addressing each scenario. Prioritize scenarios that mitigate the highest risks.
5. Business Goal Alignment: Map scenarios to specific business goals or objectives. Prioritize scenarios that align most closely with critical business goals.
6. Architectural Impact Analysis: Evaluate each scenario's potential impact on the architecture. Prioritize scenarios that have the most significant architectural implications.
7. MoSCoW Method: Categorize scenarios as: Must have Should have Could have Won't have (this time) Focus on "Must have" and "Should have" scenarios first.
8. Pairwise Comparison: Compare scenarios in pairs to determine relative importance. Can be combined with techniques like Analytic Hierarchy Process (AHP) for more rigorous analysis.
9. Time-Based Prioritization: Prioritize based on when scenarios need to be addressed in the project timeline. Useful for phased development approaches.
10. Weighted Criteria: Define a set of criteria important for the project (e.g., business value, technical risk, cost). Assign weights to these criteria. Score each scenario against the criteria and calculate a weighted total.
11. Quality Attribute Workshop (QAW): A facilitated method to identify important quality attribute scenarios. Includes steps for scenario brainstorming and prioritization with stakeholders.

Using scenarios as inputs to architectural design

Scenarios play a crucial role in architectural design, serving as key inputs to guide decision-making and shape the architecture. Here are some guiding principles how scenarios act as input in architectural design

1. Identifying Architectural Drivers: Scenarios help identify the most important quality attributes and functional requirements. These become the architectural drivers that significantly influence design decisions.
2. Guiding Design Decisions: Each scenario provides specific context and requirements that the architecture must address. Architects use these scenarios to make informed decisions about architectural elements, their relationships, and properties.
3. Selecting Architectural Tactics: Scenarios describe specific quality attribute requirements. Architects select appropriate tactics (design techniques) to achieve these quality attributes based on the scenarios.
4. Evaluating Design Alternatives: Proposed architectural solutions can be evaluated against the scenarios. This helps in comparing different design options and choosing the most suitable one.
5. Resolving Trade-offs: Scenarios often reveal conflicts between different quality attributes. They provide the context necessary for architects to make informed trade-off decisions.
6. Defining Interfaces: Scenarios that describe system interactions help in defining component interfaces and communication protocols.
7. Allocating Responsibilities: Scenarios help in determining what functionalities and qualities different parts of the system need to provide. This guides the allocation of responsibilities to various architectural elements.
8. Determining Required Resources: Performance and availability scenarios, for instance, help determine the required hardware resources and system configuration.
9. Establishing Constraints: Scenarios often imply constraints that the architecture must respect, such as technology choices or operational environments.
10. Driving Incremental Design: In iterative development approaches, scenarios can be prioritized to guide which aspects of the architecture to focus on in each iteration.
11. Creating Prototypes: Scenarios can be used to create focused prototypes that explore critical aspects of the architecture.
12. Defining Acceptance Criteria: Scenarios essentially become testable requirements, helping define criteria for architectural evaluation and system acceptance testing.
13. Communicating with Stakeholders: Scenarios provide a common language for discussing architectural decisions with various stakeholders.
14. Identifying Required Architectural Structures: Different types of scenarios may require different architectural structures (e.g., module structures, component-and-connector structures, allocation structures).
15. Guiding Documentation: Scenarios help determine which architectural views and documents are most important to create and maintain.
16. Risk Identification: Analyzing scenarios can reveal potential risks in the architecture, guiding risk mitigation strategies.

In Summary, Scenarios serve as practical inputs for architects, ensuring the architecture meets real-world needs and constraints. This approach bridges the gap between abstract quality attributes and concrete design decisions, resulting in architectures that are both effective and aligned with stakeholder requirements.