Requirements for Software Archi­tects – Part 2

Welcome back to the second article in our “Requirements for Software Archi­tects” blog series. We will dedicate this article to agile requirements engineering and their roles.

Basic terms of software architecture

Defin­ition

There are numerous defin­i­tions of software architecture, which is why we are limiting ourselves to just two:

The funda­mental principles or properties of a system in its environment, embodied in its elements, relation­ships, and in the principles of its design and devel­opment. (ISO/IEC/IEEE 42010)

A software or computer system’s software architecture is one or several struc­tures of a system that comprises the software elements, the exter­nally visible properties of these elements, and the relationship between the same. (Bass, Clements, Kazman Software Architecture in Practice, Addison Wesley, 2003.)

The tasks of software architects

Software archi­tects are tasked with actively designing the software architecture and ensuring its imple­men­tation and effec­tiveness. In the process, they are essen­tially required to meet the following objectives in a project:

• Assist with the design, imple­men­tation, mainte­nance, and operation of the system
• Ensure that the functional requirements can be fulfilled
• Achieve quality requirements to the desired extent
• System­at­i­cally reduce complexity
• Specify architecture-related guide­lines for imple­men­tation and operation

An architect’s work can be broken down into six activities:

• Clarify requirements
• Draft struc­tures
• Create cross-cutting concepts
• Assess archi­tec­tures
• Supervise imple­men­tation
• Commu­nicate architectures

The first step of “clari­fying requirements” consti­tutes the interface with requirements engineering, among other things. In the process, the architect attempts to determine which requirements are archi­tec­turally relevant.

ASR: Archi­tec­turally Signif­icant Requirements

Archi­tec­turally Signif­icant Requirements (ASRs) comprise the most important architectural requirements. Whether they are functional or non-functional requirements is irrel­evant. Therefore, ASRs are requirements that directly impact architectural design.

An architect should have coordi­nated and documented all the NFRs with the stake­holders. A functional or non-functional requirement can often obtain or lose ASR status in different phases of the software lifecycle.

Its design and partic­u­larly its design decisions should therefore create trans­parency based on which ASRs a decision or design is based on to achieve compre­hen­si­bility and ensure an effective architecture.

Figure 1: Architecture in technical perspective view

In order to achieve this, software archi­tects should consis­tently review these requirements and explain the differ­ences and partic­u­lar­ities. Awareness should be raised among the PO, RE, and BA in particular, as well as with other actors, for a better under­standing and improved communication.

Some common sources for ASRs include:

• Requirements documen­tation (e.g., product backlog)
• Stipu­lation with the service level (SLA)
• Specialized knowledge
• Applicable standards or guidelines

As long as ASRs exist in the documen­tation, they can be analyzed and improved by software archi­tects. However, if they are not documented or incom­pletely documented, there is the risk of an ineffective architecture. An ineffective architecture is unable to meet functional and non-functional requirements and not only poses a signif­icant project risk but is furthermore expensive to change the longer the project progresses.

Therefore, to put architectural design on the right track, Archi­tec­turally Signif­icant Requirements (ASR) must have priority in identi­fi­cation and documentation.

Agile requirements engineering

As previ­ously estab­lished, requirements should not only be properly surveyed but also under­standably commu­ni­cated. They should also be checked to see if they are being met. Requirements are constantly changing and require maintenance.

Agile requirements engineering is a cooper­ative, iterative, and incre­mental approach that is intended to achieve this goal. It is largely divided into two phases: The defin­ition phase (creating the requirements) and the actual imple­men­tation phase (devel­opment). Unlike conven­tional proce­dures, both the defin­ition and imple­men­tation phase take place in parallel.

This results in many advan­tages, which include quickly and flexibly responding to changed or new conditions.

This is guaranteed by the fact that the requirements description is never concluded and is constantly re-written and amended during the entire devel­opment period. In other words, if individual aspects of a process differ from acceptable thresholds or if the resulting product is unacceptable, the process or the achieved results must be adjusted. Adjust­ments should be made as quickly as possible to reduce further devia­tions. This approach pursues four objectives:

1. Famil­iar­ization with the relevant requirements at an adequate level of detail (at each point in time during the system devel­opment process).
2. Reach an adequate consensus on requirements among the stakeholders.
3. Record and document the requirements according to the constraints and requirements of the organization.
4. Perform all requirements-related activ­ities according to the principles of agile manifest.

Requirements engineering activ­ities are highly diver­sified and depend on the type of system and organi­zation speci­fi­cation to be developed. Never­theless, agile requirements engineering also includes the following four central activ­ities that have been estab­lished by IREB:

• Surveying requirements: Requirements are deter­mined as efficiently, thoroughly, and error-free as possible using many different methods, which also includes detailing and refinements.
• Documenting requirements: Requirements must be adequately described with high quality so as to create the requirements speci­fi­cation with all the relevant requirements.
• Reviewing and coordi­nating requirements: The overall quality of the requirements speci­fi­cation is reviewed, which also includes coordi­nating its contents with the stakeholders.
• Requirements management: Requirements management deals with preparing requirements for use, managing the versions, setting prior­ities, etc.

The difference between requirements engineering and requirements management

Often times, the terms “Requirements Engineering” and “Requirements Management” are erroneously used inter­changeably. When referring to a holistic requirements engineering approach, it must always be done strictly within the meaning of requirements management. Looking back at the afore­men­tioned, four central activ­ities, requirements engineering mainly relates to the first three items. Requirements engineering is requirements management and comprises the fourth central activity.

However, both specialized terms are inextri­cably linked with each other and go hand-in-hand with requirements management: You cannot manage without inves­ti­gation, and there is no benefit in inves­ti­gating requirements without efficient management and preparation.

The Product Owner (PO), Business Analyst (BA), and Requirements Engineer (RE) roles

Agile requirements engineering is not carried out in an ad-hoc manner; rather, it is accom­plished via different roles. In practice, there is often only one role (such as PO, BA, RE, or all combined). Regardless of how many roles exist in practice, the subdi­vision can be used to profitably arrange the different activ­ities and respon­si­bil­ities of requirements engineering and management, and structure your actual work.

The Product Owner is respon­sible for increasing value – i.e., profitability (ROI = Return of Investment) – not just in terms of the product but also in terms of the product team. Therefore, it is a demanding job, and he/she is assigned with carrying out three essential tasks:

1. Represent the interests of customers
2. Collab­orate with the devel­opment team and the Scrum Master
3. Manage the product backlog

He/she is supposed to bring the right function­ality to the project in the right priority. Accord­ingly, he/she is supposed to master the following skills and tasks:

• Stake­holder analysis
• Surveying techniques
• Conflict management
• Prior­i­ti­zation (e.g., priority poker)

Similar to the PO role, the Business Analyst (BA) is supposed to have creativity and surveying techniques. Furthermore, they assist the Product Owner with surveying business requirements, their accep­tance criteria and checking if and how the requirements suit the business processes.

Finally, the Requirements Engineer (RE) handles speci­fying requirements over the long term and trans­lating them into the technical field.

All three roles should have the following skills:

• Stake­holder analysis
• Creativity techniques
• Surveying techniques (typically via inter­views, design thinking, persona, etc.),
• Documen­tation techniques
• Modeling (typically via UML)
• Prior­i­tizing requirements

All these skills can be used based on requirements and the area of responsibility.

In the next and last part of this blog series, we will look at the different, modern techniques that can be used in requirements engineering. We look forward to seeing you again.

Sources:

• Sommerville, Ian (2009). Softwa­reengi­neering (9th ed.). Addison-Wesley. ISBN 978–0‑13–703515‑1.
• Andreas Winter­steiger, Scrum Schnelle­in­stieg [a quick intro­duction to Scrum]
• McGreal, Don; Jocham, Ralph (June 4, 2018). The Profes­sional Product Owner: Lever­aging Scrum as a Compet­itive Advantage. Addison-Wesley Profes­sional. ISBN 9780134686653.
• https://t2informatik.de/
• North, Intro­ducing Behaviour Driven Development
• Dan North et al.: Question about Chapter 11: Writing software that matters. (no longer available online.) Archived from the original on November 7, 2009; retrieved on November 9, 2011: “The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved consid­erably over the years into the method­ology we describe in the book. Back when it was focused purely on the TDD space– around 2003–2004 – this was a valid description. Now it only covers a small part of the BDD proposition”
• Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Defin­itive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
• “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
• Ken Schwaber; Jeff Sutherland. “The Scrum Guide”.org. Retrieved October 27, 2017.
• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

Figures:

Figure 1: https://media.geeksforgeeks.org/wp-content/uploads/20200704172739/Untitled-Diagram160.png

This is a trans­lation of ITech Progress’ blog post “Requirements for Software Archi­tects – Agile Requirements Engineering und seine Rollen”. Here you can find the original blog post in German.