I have participated in many peer reviews, be it for gap analysis, requirements, or proposals.  I have seen a few them go awry for numerous reasons.  Here are a few tips that I picked up while attending these peer reviews:

1. Leave the egos at home – There was one gap analysis that was four of us in one room for three months hashing out the best and worst of three complex financial management systems.  It was already a tedious and stressful job trying to figure out which features to place in the new system.  The process became ten times as hard because of two individuals who though his system was the best, and that he was the only expert.  Honestly, leave the egos at home.  When you are thinking about how great you are or the system you represent, you are not being open enough to take in other people’s suggestions, which can be detrimental to designing a new system.

2. Don’t continuously interrupt - Sometimes allowing people to ask questions during someone introducing a topic is the worst thing to do.  You usually get sidetracked with other conversations that you really don’t address the discussed topic.  I found it best to allow someone to say his/her part, and then ask any questions you have afterwards.  It gives them time to touch on everything that he/she wants to talk about, and you are able to have useful questions at the end.

3.  Don’t belittle others’ ideas or questions - I’ve been around some people who will smirk or say some sarcastic comment if a person says something that they deem “stupid.” Peer reviews are usually times to brainstorm ideas.  Therefore, this is one of the only times that I will agree that no question (or idea) is stupid.

Further Reading:

• 15 Areas to Think About When Writing Non-Functional Requirements
• How to Gather Requirements and the Documentation to Help You Do It
• Questions to Ask Yourself When Collecting and Writing Security Requirements
• How to Write an Effective Functional Use Case