We supplement Scrum with architectural processes. Part 1. Requirements

Having chosen any methodology for the project, it is usually necessary to adapt it, supplement it. For example, Scrum is often supplemented with XP. But even in this case, the process of architecture formation is poorly defined, which is one of the main reasons for the dramatic drop in the development speed in a few months or the failure of the project.

In this series of articles, the author offers his vision of architectural processes within Scrum, which he worked out on several projects (mobile banks), including the current one ( CleanEngine ). The scope of the approach: business critical, mission critical and life critical projects.

The articles use the definitions, terms and approaches of the Carnegie Mellon Software Engineering Institute (SEI) architectural school, as well as the authors associated with this school. It is also assumed that the team does not violate the basic principles of Scrum, such as, for example, self-organization. At the same time, it is not necessary that the team consisted of highly skilled professionals, as required by Scrum. It is enough to have competences in the team, with Scrum Master or Architecture Owner (about it later).
')

Introduction to the first article

The first article of the cycle concerns the basis of development - the requirements. A categorization, an approach for their management, as well as a formalization option are proposed. Forming requirements is beyond the scope of this article, although examples of approaches will be.

Definitions

For the purposes of this article, by architecture we understand the definition given in the book Software architecture in practice (SAP). . "The lowest level to which we are still talking about architecture is concepts and entities. Classes, methods, attributes, etc. are beyond the scope of this concept.

A stakeholder is a person who benefits or loses a successful project.

Types of architectural requirements () and their formalization

Below we consider the types of system requirements that, in the opinion of SEI, have an impact on the architecture and are necessary / sufficient to make architectural decisions. In SAP, they are referred to as architecture drivers. Depending on these requirements and their mutual influence, certain architectural patterns and tactics are selected.

High Level Functional Requirements (FT)

In the English literature can be found under the name High-Level Functional Requirements.
These requirements describe what the system should do, what functionality to provide, but in general, distant features. Usually, this is the level at which the customer operates. For example, a personal account of the buyer, search and selection of goods, payment from the card, personal account of the seller, maintenance of the product catalog, instant notification of the order.

Such requirements can be described in the form of short sentences or phrases. How convenient, the main thing is not to lose the point. However, it is useful to describe them in the form of very global user stories. For then the people involved in the formation of the architecture will be seen not only what needs to be done, but also for whom and for what purpose. Those. traceability requirements. This in turn has a positive effect on the quality of the architecture, on the achievement of its goals by the stakeholders. Also, this will allow in the future to extract smaller user stories. They, in turn, can also have an impact on architecture, usually specifying.

It is convenient to record them in the Vision of the project at the stage of project initiation (Sprint 0, Initiation Phase, Inception Phase) and support there. At the same time in the task tracker to conduct them as large User Story, milestones, initiatives, etc., depending on the chosen format for maintaining requirements. For example, when using Confluence and Jira from Atlassian in the latter, it is convenient to create Epic, and in the former it is convenient to create a project vision and integrate Epic data.

Of course, some of these requirements may become irrelevant over time or new ones will appear. Especially after the next CusDev. This can affect the architecture very much, but usually just the appearance of another component.

Non-functional Requirements / Quality Attributes (AK)

In the English literature can be found under the name Non-Functional Requirements or Quality Attributes.

These requirements describe what qualities a system should possess and to what extent. For example, it should be available 99.9999% of the time, the cyclomatic complexity of the method should be less than 7. These are the very words that are used to speak about the quality of the product: security, reliability, maintainability, and so on.

There are a lot of such attributes of system qualities (over 170, according to some publications). Determining which of them the system should have is complicated by the fact that they are “nested” in each other. For example, it is impossible to say that performance or reliability is not “invested” in usability. Therefore, they often use corporate or industry standards, such as ISO 25010, as a reference / checklist for such characteristics. It is useful to sit down with the customer and walk through this ISO after discussing with him and choosing the relevant quality attributes. This list will also be the starting point for the Quality Plan, but this is a separate story and perhaps a separate series of articles.

AK often interfere with each other. So, to ensure the reliability of the system often have to sacrifice performance. Similarly, performance is in conflict with maintainability. Therefore, it is important to prioritize such AKs in order to understand what is more important for the system and to take appropriate decisions. For example, if it is important to cover the Android application with tests (testability), then the MVP pattern can most likely be applied. If there is no such need and the application is simple, then perhaps it would be better to leave MVVM.

Finally, the system in any case has these qualities, but to some extent. For example, the system cannot have zero performance or "full". Moreover, a small increase in any characteristic can mean a significant change in the architecture and a significant increase in the budget. Therefore, of all possible AKs, only those that are most significant for the system and try to determine the necessary and sufficient level are distinguished.
One of the most specific and strict formats for AK is the so-called “6 part scenario”:

Field	Value
Source	User
Stimulus (trigger)	User request
Artifact (affected artifact)	System
Environment (conditions)	Run-time, not depending on third-party services
Response (system response)	User can use the system
Response measure	99, 999% of the time

They can be applied as one of Acceptance Criteria to User Story or Epic. They can also be part of Definition of Done (Done Criteria). Since AKs usually belong to a large part of the system or to it as a whole, it is often necessary to describe them at the Epic level.

A simpler and less rigorous writing format - in one sentence in Acceptance Criteria (for example, the system response speed should be 0.5 seconds). Such a format is quite acceptable and sufficient, if from Done Criteria it clearly follows, for example, where, by whom and under what conditions this acceptance criterion will be tested. For example, a user story should be published on the staging environment and tested at 200 requests / sec for 10 minutes in such and such conditions.

Constraints

Restrictions, in turn, are divided into business constraints (Business Constraints) and technical constraints (Technical Constraints). Whatever category they belong to, the limitation is that it cannot be changed or canceled, and even as a fraction. It is either satisfied or not. This is their main difference from the quality attributes that can be satisfied at some X%.
For example, the system must support Windows 8.0 and higher; use .Net, for, licenses are purchased and corporate culture is based on it. Restrictions can be the budget, staff, organizational structure, operating system, software, development tools, libraries, hardware and others.
If the restrictions relate to the entire system as a whole, then they can be listed in the Project Vision. If to some part of the system, then, like AK, in the Acceptance Criteria of the corresponding Epic. The format is usually a short sentence.

Vision of the project

For clarity, I will give the table of contents of the vision of the current project. The vision of the project is a living document in which general basic information is kept and from which everything originates. The constitution of the draft, so to speak. Its structure is formed for a specific project.

1. purpose
2. Problem and solution
3. Stakeholders and early followers
4. High-level functional requirements
5. Quality attributes
6. Restrictions
7. Key indicators
8. Risks

In this case, the document concerns only part of the development. In other projects, for example, there were items about marketing and promotion, processes and roles, key partners and others.

Summary

So, in this article the types of architecturally significant requirements, their formalization and examples were considered. More detailed information about them can be found in the sources in the list of references. Processes and roles will be discussed in the next article.

Literature

[SG] Scrum Guide, Ken Schwaber and Jeff Sutherland, 2013
[SBoK] Scrum Body of Knowledge, Scrum Institute, 2016
[SAP] Software Architecture in Practice, Rick Kazman, Paul Clements, Len Bass, 2012
[DAD] Disciplined Agile Delivery, Scott Ambler and Mark Lines, 2012
5. ISO 25010 .