Trawling for Requirements
5 comments Latest by g! Fri, 09 Jun 2006 07:46:28 GMT
This morning, Brian Ford and I headed over to Powell’s Technical Bookstore to pick up their one used copy of Code Complete, 2nd ed. While we both stood there reviewing the contents, I felt somewhat unsatisfied with the purchase that I was about to make. It then occurred to me that what I was looking for was quite different and while the programmer side of me felt the need to make the purchase, there was another void to fill. Requirements gathering, prototyping, use cases, and delivery are areas where I am really focusing a lot of my attention to. Brian and I discussed how Test-Driven Development solves some of the problems surrounding application development and Behavior Driven Development might pick up on some of that slack as well.. but what about the stuff that happens prior to sitting down to code these units of work? How do we define them? How do we extract meaningful requirements from the client and allow them to participate in a sign-off process where they confirm that they are confident that you understand what their problem is and that you have a clear picture of a solution? These are questions that I have been trying to answer for myself.
While talking with Brian during our walk to and in the store… a random Delphi developer that struck up a conversation with us about the Code Complete book we had in our hands and XP methodology. While listening to him, I noticed a book title, Mastering the Requirements Process, 2nd ed., which I picked it up and glanced at the table of contents and noticed the title for Chapter 5, “Trawling for Requirements.”
”...in which we drag the net through the work area looking for requirements, and discuss some useful techniques for doing so”
I was immediately drawn to the book at that point and decided to purchase up both books for the PLANET ARGON library. It’s written by Suzanne and James Robertson and published by Addison Wesley.
The book describes this figure with, “The overlap between Requirements Gathering and Systems Modeling varies as the development of the product progresses. Initially, very little modeling is done, and the majority of the effort focuses on gathering and verifying requirements. As development continues, the modeling activity expands to occupy a continually greater proportion of the effort.”
I’m really looking forward to diving deeper into this book and will share my thoughts on Requirements Gathering and how we’re doing it at PLANET ARGON. :-)
Isn’t this the purpose of user stories being written at the clients level of abstraction and then delivered in a tight code/release schedule (ala Scrum) so that the design is verified as quickly (and incrementally) as possible to ensure that you’re addressing the correct problem for the client?
jperkins,
Yes, that comes into play… but before you get to writing stories, you need to know how to extract the right information in order to build that story. Take the example of Client X shows up at your office and has an idea for a project that could take anywhere from 6-12 months to develop. While it’s always possible that they know how to help break it down to smaller iterations. Clients have lots of ideas and it’s our job to group them into meaningful collections of deliverables. A User Story doesn’t just manifest itself… well.. not usually. A client is sort of like an apple tree in that you need to shake it a few times to get some apples to fall from it. Throw away the bad apples and help collect the good apples that were the most eager to fall into the discussions. It’s also important to identify some of the most complex components of the system. Should you postpone solving them or move them up in priority?
I’ve got a reply started and it’s already too long to post to your comments, so I’ll email it later today. I know that you’re all going to be in town for RailsConf but have you seen: http://www.agile2006.org ? There looks like some potentially good stuff going on there.
Nice point and analogy, Robby. It is definitely true the the user story, use case, or any other product of a methodology does not neatly deliver itself to you. Often people seem to pose the idea to, “just apply tech X to the problem and voila”. Oh, if only!
One thing we’re really trying to refine is managing the communication to get just enough, but not too much, information to allow us to create a story, or use case, or whatever the artifact may be. If we are slave to a particular methodology, we either talk over the client’s head, or continually try to translate what the client is saying into an artifact of that methodology. This is an unsatisfactory process, hence our interest in really pushing our understanding in this area.
It’s plain hard to keep the client focused on one aspect of their application (they feel passionate about all the features) and still elicite a lot details necessary to get good stories or requirements.
One thing that strikes me about BDD: as Robby pointed out, there has to be a pretty well defined unit of something to which one can apply those techniques. But the thing I really like about BDD is the attempt to use language that keeps the focus on the behavior of the application. That keeps us well away from implementation details. I would like to see BDD develop the ability to be used on a spectrum from less-specific-and-more-forgiving (e.g. “x should do y” but with some fuzzyness around x, y, and ‘should’) to more-specific-and-less-forgiving. Admittedly, this is pretty vague at the moment, but I’ll be developing my ideas further. What I really like is the idea of a methodology that can use simple, human language with the client (whom we do not expect to be versed in XP, Scrum, or any other methodology) to develop expectations about behavior that can be refined right into the specific tests that a developer will use to craft code, without lots of (fault prone) translation into some other representation.
Through my experiences, the most crucial aspect of gathering requirements from stakeholders is understanding what problem is the client trying to solve?.. or what opportunity is the client trying to exploit?.. You know.. the OBJECTIVE!!
To get the right answer, you may need to ask the same question in different way. It’s often when a client comes to you.. me.. they are a little unsure of what the problem is.
Using “How” and “What” questions, leads to why answers. If you need more information, use “tell me more..” to drill down and extract that extra information.
Yes/No questions should be used for validating you understand the answer the client has given you and won’t gather anymore requirements.. except for “is there other requirements?”
After the interview.. I always follow up with the client, making sure that I have understood their requirements and needs correctly. Then go back.. talk to the project team and start writing those use cases.. story boards etc..
Just my two cents
g!