I'm listing a few different methods that you can use to extract requirements from clients. In my previous post I talked about understanding the situation you are facing: the nature of the project, the urgency and the availability of knowledgeable resources. These factors will determine which methods are more suitable for your situation and what combination you will employ. By using your experience and factoring in the magnitude of your project, you will be able to estimate how many sessions you will need for each method.
Prototyping
Good for user interfaces.Good for allowing visualization with clients.Clients focus in on the details and look and feel. This is a good thing when creating functional specifications but not very good for getting high-level business requirements (i.e., understanding the general business purpose and objectives.)Clients may develop expectations that final product can be developed quickly since the prototype was developed rapidly.Observation
Good way to see and understand the existing workflow and processes that are used. Particulary helpful if the process is only known by the end-user.End-users have a tendency not to behave how they normally would or feel that they may be being scrutinized.BrainstormingGood for faciliation and idea development.Easy to lose focus and start going off on tangents.Requires lots of different people.Requires follow-up meetings to refine.Interviewing Short daily sessions are less distruptive to the lives of clients but take longer to reach end of job.Inversely, longer half-day to full day sessions are very distruptive to clients day jobs but you can finish faster.My next post will be concerned with setting expectations for your clients as to the production of requirement deliverables.
I'm listing a few different methods that you can use to extract requirements from clients. In my previous post I talked about understanding the situation you are facing: the nature of the project, the urgency and the availability of knowledgeable resources. These factors will determine which methods are more suitable for your situation and what combination you will employ. By using your experience and factoring in the magnitude of your project, you will be able to estimate how many sessions you will need for each method.
4 comments:
A recent posting on Tyner Blain talks about this topic as well. It is always good to see the approaches taken by others.
See if you can leverage and build upon them.
On his blog Seth Godin wrote, If you use a prototype to try to persuade someone of an idea, be careful...
An interesting take and worth reading. A response to Seth's post can be found on metacool.
Follow this link to Tyner Blain for some interviewing tips.
One thing I’d add to this is that customers need to understand the importance of helping to clearly define the software requirements up front. It can make all the difference in the success of their project. Our job as the consultant doing the requirements gathering is to help manage the process for them. Part of that involves educating the client on how they can help with requirements gathering. There are a number of critical elements that the client has control over that can make or break the success of gathering accurate requirements. We have a two-part series on this topic that you might be interested in: Requirements Capture: 10 Keys to a Successful Software Development Project - Part 1 and Requirements Capture: 10 Keys to a Successful Software Development Project - Part 2.
Post a Comment