Hello all,

I'm a software tester in a small company.  When I first started the role, the requirements for the software that we had to build were quite well documented (they are provided by an external company).  Over the last year or so, the requirements have become less well documented and now have almost exclusively been replaced with wireframe designs and artwork (the software is heavily focused around user interfaces).  This has resulted in people interpreting the designs differently, resulting in lots of questions from all parties (management, developers and testers) which are not being documented, leading to all sorts of problems.

I'd like to introduce (or at least suggest) changes in our process so we can start documenting some of the requirements again.  We already carry out reviews so that's a good start, but I think we need to document the results of said reviews and turn these into formal requirements that can be tracked by all parties (including being passed back to the external design teams for verification) and continually updated as the development process continues.

Has anyone got any suggestions on techniques for gathering, but mainly recording requirements? 

Even as something as simple as creating a word doc and sharing that with all parties, but I’m wondering if there are any templates or other tools that would help in my situation.  Any hints or tips?

One of the problems is that being a small company with a  limited number of staff, the management won’t agree to pay much money (if any) for software, nor would they want something overly complicated that will take months to get up and running successfully.

Thanks for any advice.

This is the problem we have.  One party may well know the details, but if this is not communicated and documented in some way then the other parties don't know about the details which ends up in confusion a few months down the line when no one can remember where the requirements came from.

Hi pledgeX,

Your organization is definitely not the first to encounter this problem. And while a caution against over-documentation is good advice in general, as you noted it doesn't solve the problem you face of having insufficient documentation. Companies vary in the amount of decision-making given to developers regarding requirements - some let developers handle more of the details, while others keep ownership of most or all requirements fully with the business. Either way, it's important to have everyone on the same page as you've discovered - and to have a way to document and sign-off on whatever level of detail is substantive for your company.

There are definitely ways to document requirements to the level of detail needed within your company, that leverage and extend upon your existing processes (wireframes, team reviews & discussions, testing / UAT considerations, etc.) - so you don't have to invest a lot of time & money, and don't have to re-engineer all your processes. You can put together fairly simple Word documents that incorporate and build upon the wireframes, along with business & UI rules, any relevant workflow steps, UAT scenarios, etc. This type of document can then be circulated, reviewed, and signed off by all parties involved. Here is a link to a blogsite that describes the sections and content for this type of document:

http://pathfindersoftware.com/2008/11/what-makes-a-good-requirement-document-for-an-agile-project/

This blog post highlights both the need for streamlined documentation from an agile perspective, but also the need for detailed requirements (down to validation rules and messages). Let me know if this blog provides enough information for you to move forward, or if you still have additional questions.

Important note: If your business users are not currently involved in reviewing or approving wireframes, you can run into churn by having these included in your requirements for sign-off. Business can get hung up on trying to redesign the wireframes, instead of focusing on the actual requirements. So be prepared to manage this - it's important to ensure that everyone understands what the wireframes are (and are not)...

Sandy