I’ve struggled quite a bit with trying to define what are the appropriate level of requirements necessary to begin coding an application. Back in my days at Andersen Consulting their methodology dictated a very formal process, the deep V. As you went down into the V requirements started off with a problem statement, then a scope statement, then functional requirements that were translated into a technical design and at the bottom of the V, implementation occurred based on the technical design. Going back up the other side of the V were testing steps meant to test the documents at their level on the other side of the V.
The Andersen waterfall looked great on paper and off I went on my projects comforted that the V would lead to straightforward project design, implementation and testing. What I found was this did not occur. Maybe if requirements had not changed the waterfall would have worked, and maybe it did on many projects were this was the case. On the projects I worked on, however, this wasn’t the case.
The situation I encountered often back then, and still today, is that requirements fluctuate. Not only do requirements flucatuate but it’s only after implementation begins that they really begin to fluctuate. I would find myself frustrated, pointing a the V diagram, and protesting that these issues should have already been decided. Slowly I have started to realize that many decisions are not made until implementation begins because it is only then that stake holders start to see their system taking shape. They rethink decisions they made before they had an actual UI to play with or data on reports. Based on actual things to look at stake holders refine their thinking and even out right change their minds. What I have come to accept is that this is how the process really works with any sort of application that is heavily UI driven. Agile development processes have taken this to heart, and I’m sure if Andersen Consulting still existed today (actually it does it’s called Accenture now) they’re process would reflect a far more iterative process that more readily allows for requirement changes.
The one tool that I have embraced that helps to reign in fluctuating requirements for applications that are heavily UI driven is storyboarding. After having written many very long functional requirements documents that almost no one ever read I came across an article on storyboarding (http://en.wikipedia.org/wiki/Storyboard). What I came to realize is that wordy and very long functional requirements documents mean very little, but pictures are worth 1,000 cross referenced bullet points. By using story boards I could walk the stake holder more fully through what my team was planning on creating for them. The stake holder could have their image driven epiphanies on paper, instead of after thousands of lines of code had been written. It’s amazing how many fields that weren’t in a functional design document get caught when someone sees a picture of form and realizes there is a piece of data they want there that has been overlooked.
I don’t think storyboarding is a magic bullet and to address the reality of fluctuating requirements I have also embraced a more Agile approach then I was taught back in my Andersen days. I believe storyboarding helps mitigate requirements fluctuation to a significant degree, and also allows for the expectations of the stake holder and the development team to be synchronized earlier in the process, further mitigating project risk. Below is a process I came up with for a company I consulted for. It was an attempt to blend a somewhat waterfall requirements analysis with iterative development. The goal was to allow enough of a waterfall driven requirements approach to be able to effectively estimate the project cost. We were trying to avoid committing to projects we had underestimated when we and the stake holder unknowingly had different conceptions on what we were building. In the process I added storyboarding as a formal step. Storyboarding is an output of a much less formal functional requirements document. The process did not work out as I had hoped as we could not get the stake holders to work through the requirements processes, so now I struggle with refining the higher level requirements approach. We’ll see where I go from here.
