I started working on the requirements for the krill application and decided I would take a minute or two to rant about the process of Defining Requirements.
Defining requirements can be done so many ways that it would be impossible for me to provide a universal template for this. What I will attempt in this post is just give some of my observations on this process so you can see where I am coming from.
Getting Together
It all starts with an agreement between the product owner (or business line) and the development team. The development team should have some basic approach to requirements gathering that can be used to coax the necessary information out of the product owner.
In my opinion, there is no replacement for a face-to-face meeting when initially defining a project's requirements. Getting all the right people in a room together is priceless.
Anyone who has ever sat on a conference call/live meeting for hours can attest to the fact that this really is not the same as meeting in person.
Meeting in person encourages participation and discourages mentally checking out. Sitting at your computer is far too much of a temptation to keep working on other tasks than many people can resist.
Doodles
I am also quite a big fan of the "doodle" approach to defining requirements. When I begin to think about a new application, I generally first imagine using this application.
I will then make doodles of the various pages of the application. These doodles can be done effectively on both paper or with some sort of wire-framing software.
On the doodle, I will write the business rules of that page off to the side. This will give you both a mock up of the screen, and the rules in one place.
If you have everyone in the same room, you can easily craft theses screen mock ups together on a whiteboard or flip chart.
As you beginning drawing these pages and connecting them, the developers and the product owners will begin to view the application in the same way. Having the same vision of the application is a huge accomplishment. Can you think of times when you finished an application only to have the product owner dissatisfied with the way it operates?
Why Not Just Write Use-Cases?
As a developer, every time I see a use-case my eyes will glass over.
Use-cases generally consist of a description of the page, a listing of fields, and some business rules.
The developer then needs to translate this information into some usable form before beginning any work. And what form does the developer usually translate it too?
That's right! A doodle! So why not just skip the Use-Cases all together and just start with a doodle?
They say a picture is worth a thousand words and in this case, that is true. I would trade a thousand word use-case for a doodle any day of the week.
What About the Management Types?
Once you have finished with all of the doodles, you can hand these off to a good technical writer and have them craft whatever document type the organization requires.
The developers then beginning planning the actual implementation off of these doodles.
Granted, changes to the requirements will be made by both the product owner and the development team in the initial phases (who am I kidding, all phases) of the project. How much easier is it to modify a doodle compared to some SDD/TDD doc? The answer is a lot.
Summing Up Defining Requirements
The bottom-line is, I believe that software engineering has gotten to be crazy over the years. Organizations have become obsessed with the documentation and formalization of every step of development to the point on insanity.
The product should always trump the process. This is what the Agile methodology is trying to emphasize. http://en.wikipedia.org/wiki/Agile_software_development
Please do not take my ranting as a plug for Agile. I believe, first and foremost, in getting back to basics.
Whatever method you choose, don't make it too complex. The process should walk that fine line between producing enough documentation and not driving the development team crazy.
Sounds easy, right?
Good post.
ReplyDeleteWhen we gather requirements for the design of a new clinical database where I work, we go through a similar process, minus the doodles. The vendor already as a validated system and we are providing requirements for configuration more that developing a new software app.
Still, gathering and agreeing on the right requirements is where most of our time in meetings goes as everyone has different ideas as to what is important for the final database.