Over fifty years ago, Peter Naur stated that computing is a human learning activity. (I’m paraphrasing.) An example of this insight is that you may start a project with one set of requirements and that you may end the project (or timebox or release) with another (probably related) set of requirements. Requirements happen at the start and at the end of a project and anywhere in between. Agile methods popularized this idea, but it clearly hasn’t stuck everywhere.
One place where it has not stuck are student theses. Somewhat miraculously, the requirements for an engineering thesis at my professorship are often clean, understood upfront, and completely fulfilled at the end of the thesis. Not only is this unrealistic, it also misses an important learning opportunity for the student: To understand that software development is a learning experience and that you better include this efficiently into your process.
Student theses (as written documents) aren’t going away anytime soon, so I’m now requiring that students make this learning experience explicit in their thesis. A typical engineering thesis has these components: (1) Introduction, (2) related work, (3) requirements, (4) architecture and/or design, (5) implementation, (6) evaluation, and (7) conclusions. The evaluation section is where the miracle typically happens: It shows that all initially stated requirements were fulfilled.
Introducing requirements as a work result as much as architecture and implementation, students can now choose between one timebox (the whole six months that a thesis typically takes) or many (shorter) timeboxes (more agile, if you will).
If a student chooses one timebox, the requirements section of the thesis is to show the original requirements, as understood at the beginning, and this needs to be documented using an appropriate protocol. Then, the evaluation section starts with a tabular overview that qualifies the initial requirements as on-point, relevant, or dropped/wrong. In addition it contains newly discovered requirements. The main part of the section then evaluates to what extent on-point and relevant requirements as well as the newly discovered requirements were implemented. The reasons for dropping a requirement are also to be discussed.
If a student chooses agile time-boxing, that is, a larger but shorter number of development increments, they get to describe all requirements upfront, including those they dropped along the way, including their dependencies and evolution. The evaluation section then goes over these requirements and explains if and how well they were implemented or why they were dropped. The reason for presenting all requirements upfront is to allow referencing them in the architecture and implementation sections of the thesis.
We don’t have experiences with this new format yet, but I’ll surely report about it. So stay tuned!
Leave a Reply