Whether you are a business analyst, project manager, or software developer, at some point in your career you will most likely be asked to elicit requirements for a new initiative. There are several techniques to accomplish this including interviews, observation, surveys, job shadowing, brainstorming, and requirements workshops to name a few. All of these techniques consist of three basic elements: prepare, conduct, and follow-up. However, they do have differences – you should have an understanding of what they are and how they are best used.
Select which technique to use based on the following factors:
- Project scope and complexity.
- Cost and/or schedule constraints.
- Stakeholder availability and geographic dispersion.
- Team knowledge of the subject matter and overall development process.
My personal favorite technique is the Requirements Workshop. This is a structured meeting with the specific goal of capturing requirements. It is used to define, prioritize and hopefully finalize requirements for the new initiative that you’re working on. Requirements workshops typically last between one and a few days. They should also be a highly focused event that is let by a seasoned facilitator. Some benefits and disadvantages of the requirements workshop are identified in the following table:
|Get to a set of meaningful stated requirements in a short,|
Having the right stakeholders involved
Requirements are considered, discussed, and understood before going to final approvals
|There can be a lot of time, coordination and finances required. |
Getting the right resources in the same room, at the same time with the proper authority to speak on the subject matter.
You may have to run several workshops
If you’re looking for more detailed information about this, and other techniques used by BAs, there’s a great body of knowledge out there that can offer much more insight into what I’ve discussed above. It is called the Business Analysis Body of Knowledge, or BABOK. You can find it on the International Institute of Business Analysis IIBA websitesite
Tips that you may want to remember:
1. Requirements are as good as the sources you use to prepare. Strive to seek meaningful information regarding the subject matter. Some great places to look include: customers, users, internal and external experts/SMEs, industry benchmarks, etc.
2. Get the right resources scheduled for the meeting and get meaningful information to them before the actual session. Do some pre-interviews to gather valuable insight in the subject matter, as well as perspectives that you might not have considered.
3. Don’t forget the cost of conducting the workshops. Work with the project manager to ensure that you have adequately captured the costs. This includes areas such as facilities, time, reproduction, food and so on.
4. One of my biggest pet peeves is when a key resource sends their “designated hitters” to a workshop without giving them the capability to make decisions on their behalf. When this happens, the schedule can be prolonged because these representatives cannot act as the decision makers themselves. Get the word out early that if a key representative sends someone in their stead, they should also send them with the ability to speak for them.
5. Do as much in advance as possible and get information out to the team well ahead of the actual session. This allows team members to clarify any misconceptions, as well as offer a platform of information to work from. In this world there are two types of people: those who can create information from scratch, and those who can only modify information that they have in advance. Assume the people you are dealing with are from the second type.
6. Be careful about scope creep. Many analysts unwittingly add scope to an effort and don’t even realize it. Know the core business objectives and scope, and refrain from adding functionality that is not in the original approved boundaries. If you add scope, there must be additional funding and time to make this happen.
7. Run the workshop professionally and efficiently. Control the flow of the discussions and keep the participants focused on the specific and relevant topics. This means having an agenda beforehand, as well as using visual tools to assist in the discussions. Visual tools can include whiteboards, projectors, templates, etc.
8. Functional decomposition is a great way to organize. When dealing with requirements, it is very difficult to add structure to their organization. Try to get a list of requirements early, then break them down into logical groups at a high level. The intent of decomposition is to break big things down into small things. You can correct and improve the model as you move forward.
9. If you are discussing a scope that is best illustrated using a prototype, then by all means use a prototype. It allows the team to use this as a visual baseline for defining specific functionality. You’re not trying to sell the prototype, simply creating a model that can be altered as needed.
10. Finally, make sure you have a good strategy on tackling the workshop. Below is a representation of the things to consider before, during and after the workshop.
There are many tips, tricks, and techniques to these requirements workshops. What I’ve done in this blog is give you my perspective based on experience. Give them a shot, and build your own list. Good luck!