SWEBOK v3 and v4 — Software Requirements
SWEBOK Guide, by its nature, is similar to other Bodies of Knowledge (PMBOK, BABOK, etc.) and stands for the Guide to the Software Engineering Body of Knowledge. It is not a standard but a guide that defines the scope of software engineering as a discipline (that is important to address). It outlines Knowledge Areas described in terms of its component processes, practices, inputs, outputs, tools, and techniques. Those areas are representations of the discipline at a particular moment.
Of course, Software engineering can’t ignore such a massive topic as requirements. So it contains a dedicated chapter, or, in SWEBOK terms, knowledge area (KA) “Software Requirements”.
I started learning about industry standards and Bodies of Knowledge a few years ago. So I went through SWEBOK Guide v3, published in 2014, to review existing KAs focusing on the “Software Requirements.”
The 4th version is in the public review and will replace v3 soon. This article compares the Software Requirements chapter, my domain of interest, between newer and current versions. And there is what to compare. But let’s go back to v3.
And there is not much there. The KA heavily relies on an older edition (2nd) of the “Software Requirements” by Karl Wiegers and just a few other well-known sources. And the chapter itself is about 18 pages long. The Guide should not provide extensive information about a particular topic but should give an overview and further references to study.
However, the provided information is insufficient to give an overview of such an essential piece of software engineering. Moreover, it struggles to offer a structured categorization of requirements types and a comprehensive overview of requirements practices.
I am not criticizing; I am expressing my feeling that not enough attention was given to that part of SWEBOK. And written in 2014, it quickly became outdated.
I read it for the first time in 2020, and RUP (Rational Unified Process) has already been dead for a while. I barely heard about practicing RUP in 2014 because Agile methodologies were on the hype train then (and claimed to be dead soon, too). A newer generation of IT folks has no idea what it is.
I could not recommend SWEBOK Guide v3 to start your journey to the requirements engineer or business analysis. Even at the moment of 2014, there were better sources and materials. This KA looks unarticulated compared to the further KAs.
The good news is that v4 has done everything right!
In 2024, I started revisiting the standards BOKs, researching some topics for future articles. For the sake of curiosity, I have looked into a draft version of SWEBOK Guide v4 ( 2024 Jan 16th Public Review Version). And I am surprised in a good way. The “Software Requirements” KA has been completely rewritten and extended.
I am not going to dive deep into reviewing each point. You can easily read the document and make your conclusion. And we need to consider that it is still not a final version, and some changes are expected. However, I don’t expect much will change: IEEE (Institute of Electrical and Electronics Engineers) folks and KA editors have done a great job.
Let’s see what v4 has done right compared to v3:
- Number of references
The KA is now 24 pages long and references 29 different sources, Compared to 9 references in v3. And I found a lot of unknown materials I would like to become familiar with. These sources give different perspectives on different aspects of the topic. There are still classical sources but with a newer edition: K. E. Wiegers and J. Beatty, Software Requirements, 3rd edition, and I. Sommerville, Software Engineering, 10th edition. But there are also more recent works, such as up-to-date ISO/IEC/IEEE standards.
2. Consistent text
Despite an increased volume and number of references, the text feels consistent, comprehensive, and easier to digest than its predecessor. Thanks to the editors who combined those pieces altogether.
3. Explanation of what Requirement means
The v4 has a better and more comprehensive Definition of Software Requirements, considering the complex nature of the definition itself.
4. Categorization of Requirements
Neither v3 nor v4 deal with such terms as business and stakeholder requirements. I wrote about the ambiguity between business and stakeholder requirements. So they decided not to mess with that.
Even though both versions define stakeholders, they do not introduce a specific requirements type. Stakeholders act as a source of requirements, and that might make sense.
Also, in v4, there is a line that software project requirements are sometimes called business requirements. It is arguable, but I am still processing and looking for references to understand the reasoning.
Overall, the Requirements categorization in v4 makes more sense than in v3.
5. Non-functional requirements
They are splitting non-functional requirements into Technical Constraints such as choosing a programming language, framework, database, and more traditional Quality of Service constraints.
6. Why Categorize Requirements This Way?
A section called “Why Categorize Requirements This Way?” provides a great explanation of the provided categorization. I like the phrase from there concerning non-functional requirements:
Large systems often span more than one subject matter area, or domain. As explained in [S. Tockey, How to Engineer Software, Hoboken, NJ: Wiley, 2019., c6], recursive design shows how non-functional requirements in a parent domain can become or can induce, functional requirements in a child domain.
I observed that one many times, but I read about it only there.
7. Derived Requirements
v3 mentioned “Emergent properties” and that some requirements come from different components dependent on the system architecture. The v4 explains that concept better with “Derived Requirements”:
to mean a requirement that was not made by a stakeholder external to the overall project but that was imposed inside the larger development team.
Here is an essential separation of the software and system requirements, as a system might mean something bigger that includes software.
8. Let’s talk about economics
The “Economics of Quality of Service Constraints” section is part of Requirements Analysis practices. That is frequently overlooked in business analysis materials: the costs of reaching some high level of quality might not be economically justified. And that is what we all should keep in our minds.
9. The Specification way
The “Requirements specification” section is greatly expanded. It asks a question to what extent the requirements should be documented and further covers the following approaches:
- Unstructured Natural Language Requirements Specification
- Structured Natural Language Requirements Specification
- Acceptance Criteria-Based Requirements Specification (acceptance test-driven development (ATDD) and behavior-driven development (BDD))
- Model-Based Requirements Specification
And so on…
There is an entire new section, “Requirements Management Activities,” that was not present before, and many other minor changes. As I mentioned, the Software Requirements KA has been completely rewritten. It reflects the current requirements, processes, and practices. However, it does not mention AI engagement in the requirements engineering. It may not be in v4, as we still need to elaborate on the methodology and best practices here.
But there is another question: Is ten years between versions of BOK or standard not too much?
I think it is. With rapid AI development, the landscape is changing too fast. It may fail the hopes the blockchain did after all the hype it had in 2017. But staying ten years in limbo is not an option anymore.
But anyway, I want to thank everyone who worked on the Software Requirements KA for doing a great job.
Take care,
Ilya
Originally published at https://ilyazakharau.com on February 11, 2024.
