Skip to content

Business Analysis

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:

Pre-interview tips for Junior Business Analysts

Cover

Recently I was looking for a Junior Business Analyst to join my team. I considered candidates with little or no experience in IT. And that was an excellent experience for me. For the first time in my career I:

  • wholly owned job requirements for the position
  • made a final decision to hire someone or not
  • was not doing the tech part of an interview
  • interviewed Junior-level specialists.

It is different from interviewing a Middle or Senior BA. You can discuss various topics with more experienced professionals: practical cases, challenges, techniques, recent articles, etc. But that is hardly applicable for the Juniors as they can share only their background and knowledge of theory with the ability to apply that in practice, at the very least.