Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

An Agile Review of the Software Engineering Body of Knowledge (SWEBOK)

Update: The review period for the SWEBOK is over. It was very short (less than one month). Cem Kaner did an extensive review of SWEBOK.  Please also see Tom DeMarco’s comments on certification.  It is important that we have people watching out for things like this, and I encourage everyone to stay informed about the SWEBOK effort.  Please also see this post’s comments.


This is a review of the Guide to the Software Engineering Body of Knowledge, hereafter referred to as SWEBOK or “the guide”, trial version. This review will concentrate on the impact the guide would have on Agile processes. I highly recommend all software development professionals download and look over this guide. If we are to be held accountable for it, we must voice our concerns, opinions, objections, and commendations.

Assumed is a familiarity with agile methodologies. In particular, XP and SCRUM are heavily referenced.

Chapter 2: Software Requirements
The majority of this chapter is compatible with agile methods concerning software requirements.  In the Introduction, the authors state that “one of the fundamental tenets of good software engineering is good communication between system users and system developers” (SWEBOK, p. 9).  This is embodied in the Agile Manifesto “people over processes.”    Further, they state that references to particular tools, methods, notations, SPI standards, etc., do not imply an endorsement; they are used only as examples.  This means that you can still use agile methods and tools, as this review will show.
Section 2.1, “What is a Requirement?”, is devoted to defining what a requirement is and what it does and does not include.  This will be true regardless of the methodology (agile or not).  For example, one attribute a requirement has is a priority rating to enable trade-offs.  This is reflected in XP by letting the user decide the priority of a given user story if too much work has been scheduled for an iteration.  Similarly, in SCRUM, the development team only chooses the amount of work it can handle in a sprint based on a user-prioritized list (the SCRUM Backlog).
Section 2.3 is an “Overview of Requirements Analysis.” As part of the requirements analysis, “the requirements engineer has to learn a range of techniques for helping people articulate how they do their jobs and what would help them do their jobs better” (SWEBOK, p.11).  The guide states that many times it is necessary to provide some sort of contextual framework to focus requirements elicitation.  In agile methodologies this is easy; simply show the user the current working system.  The context cannot be more applicable (less abstract) than that.
It further states that conceptual models of the system help the analysis of system requirements.  At first glance, this smacks of a heavy process.  However, Scott Ambler proposes Agile Modeling as a technique to use models in an agile manner.  Further, the concept of XP’s system metaphor is a model, albeit a very lightweight one.  And while the guide discusses that both static (i.e., object model) and dynamic models (i.e., state diagrams) should be used, the “choice of which aspects to model is conditioned by the nature of the problem domain” (SWEBOK, p.12).  Once again the guide has left the door open for agility.
Another job of requirements engineers is to derive acceptance tests that will assure compliance with the requirements before delivery.  Sounds like XP’s user acceptance tests, although in XP the user creates them to avoid any undue influence from the system developers.  The guide should be changed to state that the derivation of acceptance tests should be done, but not specify by whom.
Section 2.4, Requirements Engineering in Practice, does a lot to explain and validate the delta between requirements engineering in an ideal world and requirements engineering as actually practiced.  The guide emphatically states that it is almost always impractical to implement requirements engineering in a linear manner, and that requirements engineering is an iterative process that spans the entire development life cycle.  It also recognizes the fact that requirements will change.  The only way to deal with this is to recognize that change is inevitable, and adopt measures to mitigate the effects of change.  This is the basis for XP’s short iterations, SCRUM’s month-long sprints, daily builds and smoke tests, continuous integration, etc.  This is what agile methods have been preaching for a while now.
Section 2.5, Products and Deliverables, would be the section where you would expect a heavy process to show itself in a multitude of required documents.  However, the guide goes with only two (2) fundamental documents: a system requirements document and a software requirements document.  The system requirements document “serves to define the high-level system requirements from the stakeholder(s) perspective(s)” (SWEBOK, p.13).  This is analogous to the XP user stories.  The software requirements document, on the other hand, details those requirements of the system requirements that will be handled by the software.  This corresponds to XP’s tasks.  In XP, user stories are created and given a rough estimate.  At the beginning of each iteration, user stories are broken down into tasks by the developers and the duration of the tasks estimated.  The tasks are the breakdown of a part of the system requirements document into a software requirements document.  Even though they are on index cards, it still fundamentally meets the notion of the “software requirements document.”  In fact, having them on index cards further meets the guide’s specification that “requirements documents must be structured so as to minimize the effort needed to read and locate information within them” (SWEBOK, p.13).  Some standard documents are mentioned, but the guide again states that they should be customized, if used, depending on the project’s needs.
Perhaps the most important part of requirements is that they can be traced and tracked.  Tracing means taking a software feature and tracing it back to the software requirement and the system requirement that caused it to be developed.  Tracing helps prevent developer “gold-plating.”  The agile concepts of YAGNI (You Aren’t Gonna Need It) and Test-Driven Development (TDD) force continuous requirements tracing.  For example, a user story is broken down into the tasks that will just barely satisfy the user acceptance test.  No provision is made to add things in case the customer might want something later.  TDD also forces the developers to write just enough code to make the unit test pass, again preventing extra code from being written.  Thus, any code can be traced back to the unit tests it makes pass, which correspond to the tasks that are from the user story, all of which satisfy the user acceptance test.  It forces a kind of continuous integration for requirements.  Tracking is making sure that all requirements are implemented (none are left out).  Tracking is measured by (in order from smallest to largest) unit tests passing, tasks being completed, user stories being completed, and the passing of the user acceptance test.  All of the testing also enforces the concept of requirements validation.  The user acceptance tests validate that the system satisfies the requirement as embodied in the user story.
In Section 3, the guide breaks down the topics for software requirements.  However, the authors strongly caution against inferring a waterfall-type process due to the proposed breakdown.  To help, the first topic is an overview of the other five, preventing a direct conversion to a waterfall process.  And the figure given shows a spiral method for the requirements engineering process.
The first stage in the process is requirements elicitation.  The guide states that this is “fundamentally a human activity and is where the stakeholders are identified and relationships established between the development team … and the customer” (SWEBOK, p.17).  This is definitely agile-compatible.
Although the guide pushes modeling, it reiterates that the software requirements topic does not seek to teach a modeling style or notation, but instead provides guidance on the purpose of modeling.  With the intent of modeling in mind, a decision can be made on whether to do it at all, use semiformal modeling such as whiteboards, or a formal diagram (i.e., UML, DFD, ERD).
Other Comments
The paper by Goguen and Linde, “Techniques for Requirements Elicitation”, in the recommended references section supposedly explores a different paradigm for understanding requirements engineering.  The authors promotes that the requirements engineering process is a social process whereby requirements emerge from discussions between the users and the developers.  With this being an IEEE paper, agile proponents should definitely check it out.
Also interesting to me is that the book Software Requirements by Karl E. Wiegers (now in its 2nd edition) was not in any of the references for the chapter.
Martin Fowler says in his bliki that “The requirements section concentrates on producing a comprehensive System Requirements Specification prior to commencing development.”  I do not see anywhere where the SWEBOK states this.  Most people might infer that requirements need to be complete before starting development because “waterfall thinking” is very much ingrained into software development culture, but it does not explicitly state this anywhere within the chapter.  If anyone can show me a reference to contradict this, please do so since I have not had a chance to read the entire guide yet (just through Chapter 2 so far).

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to An Agile Review of the Software Engineering Body of Knowledge (SWEBOK)

  1. Darrell says:

    Cem, I agree completely with you. This was written a while ago, and I have added significant experience in agile software development since then.

    I do not like waterfall processes either. The CMM in its conceptual level is basically sound. However, it is so easily abused into a sequential process that on the whole it does far more harm than good.

    More importantly, I think required certification of software developers is a very bad idea. I have updated this blog post to refer readers to your thoughts on the SWEBOK as well as Tom DeMarco’s comments here (http://www.systemsguild.com/GuildSite/TDM/certification.html).

  2. Cem Kaner says:

    I did an extensive review of the Testing section of SWEBOK. It is inappropriate to cite my non-comment on the Requirements section as a failure to find problems — I picked my battle (Testing) and focused on it.

    For the record, though, I think the SWEBOK emphasis on high levels of precision and verifiability of every requirement will naturally lead to a paper-rich (heavyweight) process and to premature overspecification.

    Additionally, while the authors of this section of SWEBOK point out that requirements will change, they emphasize a sequence in which requirements are collected and approved before code is written. Prototyping is OK, but implementation is not. It appears clear to me that the description is SWEBOK is incompatible with a methodology like eXtreme Programming (which collects requirements throughout the development schedule and starts generating code immediately, partially as a way of surfacing new requirements and needed changes to the ones that were previously (mis?)understood).

    The authors generally appear to favor the waterfall approach as an ideal and back away from that as a concession to pressures in the world.

    In contrast, many of us who come from a Human Factors background (and many others) favor an iterative approach — in principle, not as a concession — because we believe that (a) people will know less about the product early in development than at any time in the future and (b) systems have emergent properties that drive peoples’ understandings of them.

    As an attorney who has negotiated development projects, I would be delighted to have a set of requirements that are clear, unambiguous, correct, verifiable, specific, and complete — at time of contract signing. The SWEBOK shares that preference. As an engineer, I think that in all but the simplest cases, that preference is misguided.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>