Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Requirements gathering and documenting
Previous Previous
 
Next Next
New Post 6/3/2013 2:10 PM
User is offline pledgeX
2 posts
No Ranking


Requirements gathering and documenting 

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.

 
New Post 6/4/2013 11:57 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Requirements gathering and documenting 

Hi:

My opinoin:  Some data flow diagrams (including a Context Diagram), a few ERD's, and maybe some screen shots is all most projects need.  The details can be handle in conversations between developers.

Why DFD's?  Answer:  Per the BABOK, the major task at hand is not so much identifying standalone requirements as it is documenting the essential interrelationships between them.

Don't fall victum to a "big-hunker" Word or Excel document effort.   

 

 
New Post 6/4/2013 1:02 PM
User is offline pledgeX
2 posts
No Ranking


Re: Requirements gathering and documenting 

 Tony Markos wrote

The details can be handle in conversations between developers.

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.

 
New Post 6/6/2013 3:22 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Requirements gathering and documenting 

Hi:

This sounds like a classic case of having a bunch of detail level,  non-integrated, implementation oriented requirements.   What you need is just the opposite:  Higher-level, integrated, business oriented requirements.    That forms the overall requirements framework around which you can organize what you currently have  into something that is understandable and provides usable traceablity.  

 

 
New Post 6/14/2013 1:13 PM
User is offline Sandy
74 posts
8th Level Poster




Re: Requirements gathering and documenting 

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Requirements gathering and documenting

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 



Upcoming Live Webinars




 

Copyright 2006-2021 by Modern Analyst Media LLC