How To Optimize Requirement Gathering And Drive Value For Clients

Quality assurance (QA) is never an afterthought at Axelerant. We believe that involving QA engineers early on in the project adds value to each stage of the software development life cycle (SDLC). 

We enable this by designing formal processes that enable greater QA oversight. Without these, we would be reinventing the wheel each time and miss out on the opportunity to optimize. 

We had an opportunity to demonstrate how QA involvement can make a huge impact on the total cost of ownership (TCO) of a project during one of our recent engagements. During this engagement, we introduced the concept of a query log in the requirement gathering phase. 

The query log is a document that allows us to collect queries from team members and request clarifications from the customer, making the requirement gathering phase more efficient and productive. We were able to work collaboratively, weed out repetitions, and make sure that stakeholders’ efforts were focused and helpful. This helped us build a more accurate and detailed picture of the customer’s requirements. 

How we built our query log

We created a simple and effective template using Google Sheets. You can use any tool of your choice. Our template had the following columns:

Document Name

With any project, there are usually multiple documents describing requirements, like functional specifications, design specifications, etc. Mentioning the document name immediately helps you to track back when needed.

Requirement ID#

A similar rule applies to requirements too. Even if the IDs are unique and use some nomenclature, mentioning requirement IDs is recommended to develop better linking between different requirements.

Component/Feature

It is a good practice to break the requirements into features or components at an early stage, because that gets you thinking about requirements from the end-user’s perspective from the very beginning.

Phase

This field should contain the value for the phase in which the query was raised. For example, the values here could be Requirement Gathering, Planning, Implementation, etc.

If, at a later point, you want to know the number of issues/bugs/ambiguities identified during a particular phase, this template can help you with that. Further, you can also provide some statistics around the cost involved in not getting things clarified in the early stages of the cycle.

Release Version

A project can span across multiple release versions, and this field too can be an important input to the statistics mentioned previously.

Description

This field should contain a detailed description of your query and where you need more clarity.

Status

Identify a set of statuses that work well for the team. It is important that this field stays updated so that it gets picked up for the next round of discussion within the team. We generally use the following statuses:

1. New (when a new query is logged in the sheet)
   1. Assigned (if it’s been assigned to someone)
   2. Invalid (if the query is invalid)
2. In progress (the person who is addressing it can mark it as in progress)
3. Done (when the query is resolved)

Assignee

This field contains the name of the person to whom the query is assigned. I’m sure that wasn’t difficult to guess ;-)

Query Severity

This could have values like Major, Medium or Minor. The rule to use the values is the same as that for defect severity.

Query Priority

This could have values like Urgent, High, Medium or Low. The rule to use the values is the same as that for defect priority. Use this field to its complete potential so that assignees can filter the query log using this column, and prioritized queries are addressed first.

Start Date

Mention the date on which the query was registered in the sheet, and not the date when it clicked in your mind. There is a difference ;-)

Query Resolution

This is the answer to the original query.

Resolution Date

Mention the date on which the query was resolved. The query can be resolved either on a call, via email or some other medium of communication. Although I would recommend that you ask the client to use the same sheet, even if they’re unable to, ensure that the query resolution date is entered after you have the resolution. While you populate this field, ensure that the actual resolution is entered in the Query Resolution field.

What’s next?

Here are some best practices we follow:

Before sharing the sheet directly with the client, we get on an internal call and discuss the queries among ourselves to look into the following:

1. Are there any duplicate queries logged?
2. Can some of the queries be answered internally within the team? This can be a possibility as each individual may have a different level of understanding.
3. Based on the internal brainstorming session, you might come up with more queries that you hadn’t thought of individually. Very soon, you will start experiencing the power of team brainstorming sessions.
4. Ensure that the sheet is up-to-date after the above steps are completed.

Pass on the filtered query log to the client. This helps with getting faster responses to queries because the list is already well filtered. It also helps to gain the confidence of the client because the work done already is evident.

Here is a link to a sample Query Log Template.