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 1: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 10: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 12: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 2: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 12: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

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC