Requirements Engineering

Thursday, 07. 7. 2011

I’m writing this on a plane from Glasgow to Amsterdam, from where I’m flying to Turin to oversee the final round of user testing with the MAXIMUS automotive group. I had intended to write the official evaluation plan or, to give it its full title; ‘D32: Final Evaluation Plan for the 2nd Prototype’. The problem is, I don’t appear to have saved the riveting ‘D28: Interim Evaluation Plan’ on my laptop, which I was going to use as a base, so I’m kind of screwed. Pity, because it’s a real page turner. The irony is that I wrote the part of the proposal specifying the need for these documents, so I have both myself to blame and myself to answer to.

Giugiaro studio in Turin

Giugiaro studio in Turin

The ‘art of requirements engineering’ has interested me for a while, both from a theoretical and practical perspective. The need for a formalised requirements gathering approach and methodology has always existed within software design, but it took a while for any structure to bleed into the rather more free spirited realm of web development. Skiers and Snowboarders if you like. Actually, I’ve always wondered if that analogy works or if it’s guff, but I’ve made use of it so many times the damage is probably done. Anyway, it was really during the 90’s that these two approaches seemed to converge. I’ve worked with a few low level developers who, after a pint or two of real ale (it’s always real ale with these guys… something about untarnished purity I think), one or two have confessed to me that they don’t actually see the need for ‘pictures’ on websites. Aye, you know who you are. So you essentially had the more scientificly orientated software development lads (and they almost always were lads) working with the more creatively orientated web developers (who weren’t always lads, the demographic was a bit like one of those private boys clubs that suddenly decide to let in girls. It takes a while for the old guard to get used to things). The dust has yet to settle, and as yet I don’t think there’s a blueprint. Maybe that’s no bad thing.

What’s great about working on European projects like IMPROVE and MAXIMUS is that the project partner responsible for defining the functional requirements is usually responsible for managing the testing of the completed or partially completed system with the users. That’s usually me. As a result, it’s possible to trace a requirement through the entire development lifecycle, from it’s conception during requirements elicitation, though development phases, integration and into UAT (User Acceptance Testing). This is unlike some of the larger IS/IT software developments I have been involved with where it’s fairly standard practice to have a dedicated testing department who’s sole reason for being is to provide regular report documents which serve to disappoint, confuse and impress in equal measure. I thought I was ok at Excel till I met those guys. Pivot table nirvana.

More recently I have become involved in agile development, which collects requirements in a slightly different way than more traditional BRUF approach (Big Requirements Up Front), and as a result necessitates a different way of testing and reporting. I’m going to try and cover that here, along with some of the methods I’ve development to capture and record the qualitative and quantitative requirements of web, software and IT projects.

Leave a Reply