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.
Continue reading »
I have often experienced that the discussion “should we write user stories or use cases?” arises when a new project are about to start. I have also asked the question myself quite a few times. There is no right or wrong answer to this question, it all depends on the nature of the project and organisation. Personally I like to write both user stories and use cases for the projects that I am involved in.
To be able to understand why and how lets first take a look at the differences between a user story and a use case.
Continue reading »
We have entered 2010 and I am now actually enjoying (a lot of people are complaining) the cold and nice winter weather in Oslo (20 degrees Celsius below freezing). I have had a hectic start on this year preparing the start up of a large national project. This is very exciting and I find this a promising start on 2010.
2009 was the year that I started this blog. It has been interesting writing the posts and communicating with my readers. I have also learned a lot in 2009 and I will for sure continue writing posts on topics I find interesting.
To summarize 2009 I will list my top ten posts in 2009. This list is created based on visitors stats and my own rating of the posts (there are always some posts that you are more proud of and have spent more time writing than others).
Continue reading »
Today I started writing use cases for a software development project that are using Scrum. I have written plenty use cases for projects earlier so I thought that this would be a nice task to do on a Friday. I grabbed a good cup of coffee, sat down, listened to Me first and the gimme gimmes on my headset and started writing.
Suddenly I started thinking; this can not be in the spirit of agile development. I had started writing very detailed use cases with a lot of text and description. I turned to my colleague sitting beside me, he’s found of agile development and we often discuss the subject, and asked him what he thought about the use case I had started writing. Then the discussion on how to write use cases for agile projects started…
I really enjoy discussing subjects like this (hopefully my colleague enjoys it too). Learning by discussing is in my opinion the best way to learn or maybe learning by failing is even better, but that’s more painful. OK, anyhow let’s get back to the use case.
He suggested writing really small use cases with as little description as possible: Continue reading »