This is a guest blog from Sarah Maddox, a technical writer, author and blogger at Atlassian. See her original blog post here.
Want an XML schema viewer in Confluence wiki? You got it. 
Avisi have developed two nifty macros to display an XML schema (XSD) in tabular and graphic format on a Confluence page. The XSD Viewer is a new add-on for Confluence wiki, and the Avisi developers are keen for input from technical writers and others interested in XML schemas.
I have been working in Scrum teams for quite some time now, and I am a big fan of the method. One thing I always wondered about however is why product owners seem to change their minds so often after a sprint delivery.
The last few months I got the chance to experience Scrum from the product owner’s side and it really confirmed the value of the method to me and also taught me a valuable lesson…
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.
Documenting an XML Schema Definition (XSD) can be a tiring process. You first load a file in an XSD viewing tool like XMLSpy, you then make screenshots of the areas of the definition you want to display and finally, you paste them into your documentation. Of course you have to repeat the entire process whenever the file changes in any way.
Avisi prides itself on being a cutting edge development organization so we felt strongly we needed to find a solution to this problem. Since we use Confluence as our documentation platform we chose to build a Confluence plugin: the XSD Viewer for Confluence.
The job of a requirements engineer is to find out what people need as opposed to what they want. Customers however don’t buy what they need, they buy what they want.
If your goal is to sell sofware solutions that solve the real needs of your customer (and it should, if you are in for a long term relationship) make sure you are armed for the battle against the want. You start with a disadvantage, but if you resist, ultimately everyone wins.
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.