preload
Jul 02

When planning/starting a software project (probably other projects as well) you are often provided a list with requirements written by the customer. It is now your job and responsibility that you meet all the requirements. Not only do you need to meet the requirements you also need to meet the requirements in a manner so that the customer agrees that the requirements are met. How can you increase the possibilities for this to happen?

First you need to make sure that you and the customer understand the requirements equally. It is quite easy to interpret the requirements, the hard part is to interpret the requirements correctly (according to the customer). What you need to do is to systematic go through each requirement and describe, with your own words, the functionality you associate with the given requirement. When this is done you must present your functional description to the customer and make sure that you both have the same and good understanding of the requirements. This might be time consuming, but it is worth the time.

Requirement interpret gone bad

You have now ensured that you understand your customer’s needs and you know what functionality the customer expect to get delivered. These needs and functionality will naturally change during the project and that is OK, you have a great fundamental for absorbing and acting on changes when you have a clear view of the original proposed functionality.

Next step is to make sure that the developers and architects know what functionality you are about to develop and how this can be technically implemented. It is time to start writing Use Cases. When writing use cases you extract use cases from the functional description you wrote earlier. It is OK to start of with writing large use cases and make sure that all major functionality are covered with use cases. Now it is an good idea to start splitting your use cases into smaller and more specific use cases. While doing this it is also smart to identify common/general functionality and place this in other use cases. You can now refer to this use case from other use cases when you need to describe this kind of functionality. You can read more about how to write use cases in a previous post I wrote on this subject: Writing use cases for agile (Scrum) projects.

When this is done it is always a good idea to take an extra look at your functional description making sure that this is now covered by use cases.

At this point I would start to place the use cases in my preferred project tool: JiRA GreenHopper og ScrumWorks. I am using agile development methodologies so I would populate my project backlog with the use cases. Each use case would be represented by one backlog item. You can now start adding tasks to each backlog item (use case) identifying all tasks that needs to be done before a use case is fulfilled.

When you have all use cases as backlog items with tasks attached you can start estimating each task. Since each task is very specific and small the estimate for each task should be pretty accurate (if estimated correctly, but that is another story). When all tasks are estimated you should be provided with a accurate number for the whole project.

It’s now time to bring the customer back into the loop and present the project backlog and prioritize the backlog items together.

If you succeed in the steps explained above you should be able to deliver the project with the correct functionality to your customer on time and at the estimated cost.

Follow me on twitter @PerOla

Share & enjoy
You can subscribe to my comments feed to keep track of new comments.

3 Comments to “Working with requirements and use cases”

  1. Fred says:

    Hi mate,

    i dig this article and your article on user stories. Do you have anything articles on business requirements? Essentially I am comparing methods and also types of documentation. In particular itemising requirements etc. This can be done by user stories but how is that transposed to business requirements document (if at all).

  2. Hi Fred, I am glad that you found the articles useful.

    I do not use business requirements document in any of the projects I am involved with at the moment. I usually focus on getting the system requirements right and ensure that the client have the same interpretation that I have.

    I will then create a system solution proposal based on the requirements mentioned above. And the system solution can be abstracted to more technical use cases.

    Anyhow I like best to focus on user stories and then create technical use cases based on the user stories.

  3. Adeniyi says:

    I am not sure if you get your comment at SoftwareMill we have chegand the rules and that’s why I am saying about Agile Company. What I have presented is official dogma of and Ken Schwaber so it is the Scrum

1 Pingback to “Working with requirements and use cases”

  1. […] This post was mentioned on Twitter by Per Ola Sæther. Per Ola Sæther said: New post: Working with requirements and use cases http://tinyurl.com/365v84j […]

Leave a Reply

Subscribe to my comments feed

Subscribe to my feeds Follow me on Twitter
DZone MVB