About this post: This guest blog was written by Brigitte Meijer, Information Analyst & Requirements Engineer at BmIT. She is a valued collaborator of ours who we regularly hire for consultancy. We have asked her to share her views on our recently released plugin, the XSD Viewer for Confluence. This is what she wrote:
We are currently developing webservices and an ebMS interface for a customer. This involves making a lot of XSD’s…
Previously we wrote the functional and technical documentation for these interfaces in MS Word, made tables explaining the elements by hand and used a development tool to create schematic images. This was a lot of work and it was very difficult to keep the XSD and the documentation in sync.
Well… I say NO!
A user story can be a perfect short description of the use case, but it does not contain all the details you need for implementing, testing and maintaining the software.
A use case describes the what of the user story in much greater detail. And as a requirements engineer, when writing a use case description, you are forced to make it thoroughly logical – with no open ends.
So… user stories are great to uncover the who and the why, but you still very much need use cases to describe the what.
User stories are just another way to gather requirements. It is certainly a recommended technique if you are working in an agile environment. User stories are becoming more and more popular.
So what are they?
Gathering requirements is not that simple. It can be a bit of a wild hunt actually! As I mentioned in a previous post, the challenge does not lay in detailing the perceived solution, but in uncovering the true problem… That said, your requirements should always enable your team to create software that is more than satisfactory to the stakeholders.
When designing and building a house it’s obvious you’ll ask the customer to specify what he (or she!) wants.
Making software is no different. You need to ask, ask, ask and then ask some more. It’s unlikely you’ll get answers to problems right away. You usually have to dig deep. So go ahead be annoying and ask “why” until you get to the root of the problem.