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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC