How Much Detail Should We Go Through in a Requirements Review Meeting?

A reader asks:

How much is too much information to go over with the users? Would you go over technical details with users in a requirements meeting? Such as, if there were additional requirements pertaining to a technical implementation of updating mail server, changing AD roles/groups retrieved etc…

I would think this would be overkill, but at the same time would not want them to later say, ”We were not told about the new server migrations.”

Warren’s answer:

Largely, in a requirements meeting, you won’t have the details you are concerned about the stakeholders’ understanding. The common purposes of a requirements meeting are: to elicit requirements, to confirm requirements, to resolve any conflicts between requirements, and to acquire requirements sign-off.

To further clarify types of requirements, you generally have 2 overall buckets or requirements:

  • Functional Requirements – these are requirements of how a solution should behave when completed, they identify necessary capabilities, and qualities the solution must have to provide value to the stakeholder.
  • Non-Functional Requirements – These requirements describe stakeholder needs that do not relate to the primary function of the solution. For example: in a software solution security, needs would generally be a non-functional requirement because it doesn’t contribute to the primary purpose of the solution, but is still required.

On occasion, you may require a 3rd bucket of data requirements if you are dealing with large amounts or particularly sensitive data.  Lots of analysts also choose to break the non-functional requirements into smaller more manageable sections like security, and storage requirements sections.

There are a couple of general rules to keep in mind when determining the level of detail you should discuss with any audience.

  • The audience’s potential understanding of the detail you are providing – If the audience does not have an in-depth understanding of the technology that you are describing, then trying to teach the details during a meeting will derail your meeting and cause your audience to lose sight of the point you are trying to make.
  • The purpose of the meeting – If you have gathered your audience together to present a solution or design, with the purpose of gaining their support, then, getting into too much detail could cause you to run out of time without you having gained the necessary approval for your solution or design.

In a previous technical project I worked on where the goal was to upgrade the clients operating systems from MS Windows XP to MS Windows 7, the a very technical stakeholder had specific points that they felt were right for the requirements discussion, but were much too detailed.  One particular point was how the group security policies needed to change and the details of how the policies would change.

If we, as a group, had let this discussion get down into the level of detail this particular stakeholder was looking for, we could have been in that room for days.  Instead we had a 5 minute focused discussion about the top level points the stakeholder wanted to address regarding the group security policies, and agreed that the actual details of implementing the changes and its potential effects were much better suited for a further analysis meeting where we could bring in the neccesary subject matter experts.  The 5 minute focused disscusion ended with the group documenting a high-level non-functional security requirement which would drive the detailed discussion about solution design later.

Similarly to the situation I found myself in above, in your example of upgrading a mail server, activities like changing Active Directory roles or groups would fit better as part of the solution design with the project team and technical specialists.  It is ok to briefly address the stakeholders concern if they bring it up, but keep the discussion high level and out of the minute details.

In an effort to provide full disclosure to the project stakeholders, it may be the right decision, when presenting the solution, to list the detail of having to change the Active Directory roles or groups, but it should be presented as a single line item without getting into the detailed discussion about it.

More on Review Meetings

For more information on how to run a good requirements review meeting, check out these articles:

How to Conduct a Requirements Review

How to Get Meaningful Sign-Off Without a Walk-Through

How I Take Meeting Notes and Facilitate the Discussion Without Driving Myself Crazy

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Tanya Buchanan, CBAP says

    To original reader – Warren’s comment of the purpose of the requirements review meeting is very valid. If you hope to walk out with a clear understanding of the business need and what the stakeholders will approve, then walking through the requirements highlighting how the document explains the business need and the impact to the business stakeholders will be very important. The business sponsor/stakeholder(s) can’t approve requirements they don’t understand which goes to Warren’s other point of knowing your audience. Directors and above may want the highlights of the major business-impacting changes while the SMEs and End Users may want more information about screen or process changes.

    To address the “technical” aspects of the requirements, your primary audience should be the “consumers” of your requirements – technical types like architects, DBAs, developers, etc – which may require a separate meeting, without the business stakeholders present. It may seem redundant, but each audience wants to get something different from the meeting and don’t [usually] care about the other stuff.

    As good BAs, we need to consider who we are talking to and understand their point of view for “what matters to me.” If you can make the separation and schedule meetings accordingly, you may start hearing people say “thank you for staying focused on what I care about” or “thank you for communicating what I needed to know before I approved the requirements.” It’s a more pleasant outcome than “geez, I didn’t understand any of that technical stuff” or “boy, I really didn’t need to sit through that manual process change discussion.”

    Good luck in your future review meetings.


    • Warren Abrey says


      Thank you for expanding on the ‘Know your Audience’ point, I find this particularily lacking in alot of presentations and meetings where the facilitator or presentor speaks to their knowledge level, not neccesarily the collective knowledge of the room. Because as Business Analysts we tend to find ourselves leading meetings and presenting solutions, we need to ensure that the audience gets the most benefit and is as engaged as possible.


  2. Lesley Brown says


    I think you covered it quite well. In a nutshell, keep the requirements review within the audience’s technial knowledge leve. To your point, if you go to far into detail about technical specs, you run the risk of losing the entire review meeting to a disscussion about technology and not requirements.


Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.