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

m_anst
m_anst
What Does Success Look Like? I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescripti...
0 Responses
Mariya Kotsupalova
Mariya Kotsupalova
They say the best criteria of Business Analyst’s success are a happy customer (business) and a happy engineering team. But what does it mean? How can we break down happiness and measure it? These are precisely the questions my 8 BAs team and I tried to answer this year. The result was a surprisingly efficient pair of surveys we developed and ...
0 Responses
Rajesh-N
Rajesh-N
Explore the Benefits of RPA's Adoption Across Segments In the past few years, we have seen steady growth in Robotic Process Automation (RPA). It gathered momentum in 2019 and became a hot topic in IT and business circuits in 2020. The power of process automation will be felt even more strongly, propelling its adoption as a replacement f...
0 Responses






Copyright 2006-2020 by Modern Analyst Media LLC