Requirements for Software Archi­tects – Part 1

In this three-part series titled “Requirements for Software Archi­tects”, you will learn about the impor­tance of your customer’s requirements, the different roles of Agile Requirements Engineering, and modern techniques.

Click on image to enlarge.
Figure 1: How projects really work

Intro­duction and overview

In the world of software devel­opment, Requirements Engineering and Software Architecture are fields of activity that jointly and largely contribute to the successful completion of software devel­opment projects. Ultimately, the objective is to meet the customer’s needs and satisfy the customer. And in order to do so, you need to truly under­stand the customer and know what they actually require.

In this stage, requirements and requirements management are key players in the software devel­opment process – they reflect the customer’s requests in software projects. They serve as key briefings for nearly all other activ­ities. Conse­quently, properly surveying, documenting, reviewing, maintaining, and refining requirements impacts the entire software lifecycle and is therefore crucial for the success of software devel­opment projects.

In the software lifecycle, the requirements and software architecture phases directly succeed each other and are therefore quite deeply inter­twined. Accord­ingly, a lack of requirements management has direct and severe conse­quences on architectural design decisions.

Figure 2: Software Lifecycle

At this point, it is not just about ensuring that the Requirements Engineer or the Product Owner have documented the right requirements (from the customer); rather, the objective is to have the Software Architect properly under­stand the Product Owner and review and analyze the requirements presented by the same so that they can make their architectural decision based on that information.

In the following sections, we will give an overview of requirements management and software architecture and how they complement and influence each other. To do so, we will look at the two roles of Software Architect and a Product Owner as well as their respon­si­bil­ities and tasks in software devel­opment projects. But first, we will explain some basic terms.

Requirements defin­ition and basic terms

A “requirement” is a prereq­uisite, a mandatory need, as well as an expec­tation. As with many terms from the IT world, there are numerous defin­i­tions for the term “requirement”.

On the other hand, the Requirements Engineering Board (IREB) defines requirement as:

• A need that is perceived by a stakeholder.
• A skill or property that a system is expected to have.
• A documented illus­tration of a need, a skill, or a property.

For the Inter­na­tional Institute of Business Analysis (IIBA), a requirement is a useful repre­sen­tation of a need that is generally described using documents.

Based on this information, requirements can be defined as a statement about the charac­ter­istics that must be achieved or services that must be rendered for a piece of software or system.

Types of requirements

There are many subdi­vi­sions or classi­fi­ca­tions of requirements in liter­ature. For the purpose of this material, we will only look at two (familiar) main categories: functional (FR) and non-functional requirements (NFR).

Non-functional requirements are in turn subdi­vided into two categories: The quality requirement or quality criteria and constraints.

Figure 3: Good vs bad requirements

Functional requirements

The “WHAT” defines the functional requirements of what the product should do. An example:

“The system should calculate an employee’s worked hours for a certain period of time.”

This means that the functional requirements solely refer to the behav­ioral outcomes that the system or software’s function­ality are supposed to deliver.

Non-functional requirements (NFRs)

Non-functional requirements (NFR) describe how well the system is supposed to perform and under which boundary condi­tions. They are a challenge for each PO and are typically sub-divided into two areas:

• Quality criteria
• Constraints

Quality criteria

… are requirements that relate to a quality problem that is not covered by functional requirements. They are sub-divided (e.g., according to Volere) into execution quality and further devel­opment quality:

1. Execution quality (during operation/runtime)

• Relia­bility (system maturity, recov­er­ability, fault tolerance)
• Look and feel
• Usability (appro­pri­ateness, learn­ability, operability)
• Perfor­mance and efficiency (response times, required resources, economicalness)
• Security requirements (confi­den­tiality, information security, data integrity, availability)
• Correctness (fault-free results)

2. Further devel­opment and evolution quality

• Operating and environ­mental conditions
• Maintain­ability, change­ability (analysability, stability, verifi­a­bility, expandability)
• Porta­bility and trans­fer­ability (adjusta­bility, instal­la­bility, conformity, replaceability)
• Flexi­bility (support for standards)
• Scala­bility (manage changes to the scope of the problem)

ISO 25010 contains a different breakdown of the non-functional requirements. Here, the quality requirements are described based on eight criteria:

Figure 4: ISO/IEC 25010 standard. Software product quality model

1. Functional suitability

• Functional completeness
• Proper function­ality
• Adequate function­ality

2. Relia­bility

• Maturity
• Avail­ability
• Fault tolerance
• Recov­er­ability

3. Perfor­mance efficiency

• Time behavior
• Resource usage
• Capacity expen­diture

4. Usability

• Adequate recog­niz­ability
• Learn­ability
• Operability
• User error protection
• User interface aesthetics
• Acces­si­bility

5. Maintain­ability

• Modularity
• Reusability
• Analysability
• Modifi­a­bility
• Testa­bility

6. Security

• Data protection
• Integrity
• Non-manip­u­la­bility
• Admin­is­tra­bility
• Authen­ticity

7. Compat­i­bility

• Co-existence (with additional software)
• Inter­op­er­ability

8. Porta­bility

• Adjusta­bility
• Instal­la­bility
• Replace­ability

Constraints

… are requirements that restrict the solution space beyond that, which is required to meet specific functional and quality requirements.

There are different types of constraints, e.g., time-related schedule constraints, regulatory or legal restric­tions, etc.

In software projects, constraints refer to factors that impact the project—such as time, money, scope (what is known as the “magic triangle”) or resources such as equipment or a lack of personnel.

Figure 5: The magic triangle

The constraints also depend on the company’s field of activity as well as the services that it offers. In healthcare, for instance, certain provi­sions or laws can impact the quality of the software or even the imple­men­tation of the entire software architecture.

For all these reasons, it is important that the software architect handles the different constraints right at the beginning of the project and clarifies them with the key roles.

We look forward to seeing you again in the next article of our blog series: “Agile Requirements Engineering and their Roles”.

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://cdn-images‑1.medium.com/max/1200/1*ApoaIZicyU0b7Jgg9MMJhw.jpeg

Figure 2: ITech Progress CPSA-Foundation Course (Presen­tation) – Chapter 1: Basic terms — classi­fying the software architecture into the software lifecycle

Figure 3: https://www.softwareone.com/-/media/global/social-media-and-blog/content/requirements-engineering-4-graph1.png?mw=1024&rev=bc1dea2cb4d145c79f1f5b544e3a10cd&sc_lang=de-at&hash=43114D2C3FE79F36503891506BDBA9FA

Figure 4: https://www.researchgate.net/profile/Lina-Garces/publication/326584873/figure/fig2/AS:652083346808834@1532480193500/Standard-ISO-IEC-25010-Software-product-quality-model-and-system-quality-in-use-model.png

Figure 5: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png

This is a trans­lation of ITech Progress’ blog post “Requirements for Software Archi­tects: Mit Requirements Engineering zu den besten Anforderungen”. Here you can find the original blog post in German.