Agile Architecture Method Explained - Chapter 3 - Step 2: Identify Key Scenarios

From Guidance Share

Jump to: navigation, search


Understand your key scenarios in order to shape your application to meet these scenarios and later to use as tests of candidate architectures and architectural spikes. Key scenarios are those that are the most important scenarios for the success of your application. Key scenarios can be defined as any scenario that meets one of the following criteria:

  • Architecturally significant use case
  • Intersection of quality attributes with functionality
  • Intersection of cross-cutting concerns

For example your authentication strategy is a key scenario as it is an intersection of a quality attribute, security, with functionality, how a user logs into your system. How your security requirements impact your application’s performance is also a key scenario since it represents the intersection of two cross cutting concerns.

Architecturally Significant Use Cases

Architecturally significant use cases have impact across many aspects of you design. Architecturally significant use cases are especially important in shaping the success of your application. They are:

  • Business Critical. They are business-critical, have a high usage level compared to other features, or imply high technical or technological risk.
  • Broad Impact. They intersect with both functionality and quality attributes, or are cross cutting concerns. An example may be a CRUD operation that is security sensitive.
  • High Impact. They are the scenarios that matter the most, cut across the layers and tiers of the application, or have an end-to-end impact on the application.

Architecturally significant use cases are those that are important for the success and acceptance of the deployed application, and exercise enough of the design to be useful in evaluating the architecture. These use cases can be categorized as system scenarios and user scenarios. System scenarios are those that have an impact mainly on the internal operations of the application and infrastructure, such as message communication between layers, connecting to data stores, and performing input and data validation. User scenarios are those initiated by or controlled by the user, such as creating an order, viewing a product, or updating a customer record.

User Stories, System Stories, and Business Stories

Use stories from multiple perspectives to help expose the key scenarios for your system. User stories describe how your users will interact with the system. System stories describe how the system will work and organize its functionality. Business stories describe how the system will meet business needs or work within business constraints. For example:

  • User Story. A user places an order and gets a license key within 30 seconds.
  • System Story. The license process system will be able to process 100 license requests per minute.
  • Business Story. The system will require no more than two servers for deployment.
Personal tools