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).
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).