Requirements gathering is a critical, intricate, and time consuming process that lays a strong foundation for project success.
The decision to implement a new software system represents the client’s strategic planning to provide employees the tools necessary to maximize productivity and efficiency. The decision is not made lightly and there is a reasonable expectation to achieve a positive return on investment. The process to implement or customize a software system is much like building a house. Laying a strong foundation and following a good blueprint is essential in building a structure that meets and fulfills the vision of the owner. Requirements gathering is the process of building the foundation and developing a blueprint on which the rest of the software project will be built.
Requirements gathering is a critical, intricate, and time consuming process. The client’s project stakeholders must be committed to dedicating the necessary time and resources for the requirements process. Many people ask why so much time is dedicated to requirements gathering when it seems like a simple process. After all, the client’s users and management know the pain points in their day-to-day business process. The natural assumption is to simply speak with users to document what they collectively believe is “what’s wrong” with their current software system or business process. However, that is a flawed process. When a user communicates requirements to a consultant, it is through the lens of his or her experiences with the system. The specific experiences may or may not accurately represent a valid requirement or need. Additionally, each user will have differing abilities when it comes to accurately communicating a requirement to the consultant. As a result, some percentage of the respective details will get lost in translation. Unfortunately, the part that is lost in translation may be the most critical element of the requirement. This is why it’s critical to dedicate the time and resources to this phase of the project.
Following a few basic steps in the requirements gathering process will reduce risk factors that will impact the project after development has started.
- Work with the client to dedicate as much time as possible on requirements gathering. Schedule time to speak with as many users as possible and in varying roles within the organization (hands-on users and management users). However, make it a point to ask everyone a list of the same questions. Each user has their own experience and you may be surprised at the insight a user in one role has about a problem for users in a completely different role.
- Consultants are not mind readers and cannot incorporate solutions to unknown requirements. The client must be responsible for communicating all business needs and thoroughly engaging throughout the requirements gathering process.
- Don’t accept every answer as final. Ask the question of “Why” often. Asking “Why” forces a user to think about his or her specific requirement and provide a compelling understanding of the details to argue the validity of the requirement.
- Recommend assignment of a single person to lead the requirements gathering sessions. If multiple persons must be involved, then make it a point to have a single contact to coordinate and lead the effort. It is important that one person have a complete understanding of the totality of the requirements and business problems.
- Don’t rush the process. Shortcutting the requirements gathering process will lead to inadequate requirements. Inadequate requirements lead to an inadequately developed system.
- Provide the client the outputs of requirements gathering often. The client must be responsible for participating in the requirements process. Having the client review and provide feedback throughout the requirements process assists to verify requirements are being accurately documented and understood.
- No matter how much time is spent on the requirements gathering process, it is inevitable that a requirement may change or possibly get missed. The key is to accept this and work to mitigate factors that produce this scenario. Strive to always capture the best possible requirements but accept that 100% accuracy will rarely be achieved.
- Prioritize the requirements. Work with the client to rate each requirement. For example: go-live critical, nice to have, deferred. Prioritizing each requirement reinforces what the key requirements are for the system.
At the end of the requirements process, a generated requirements specification document is produced for the client to review. Depending on the project scope, the specification document can be very lengthy. The specification is an important document that must be reviewed before final sign off of the requirements. However, Azamba consultants can take the written requirements and build a visual representation for the client. Azamba utilizes modeling tools to create an HTML online prototype of the documented requirements and the output is a semi-functional visual communication of the specified functionality. For larger projects, an HTML online prototype is more relevant in communicating a visual of the finished project than a 100+ page written document. The assigned consultant will review the updated specification with the user and update accordingly based on user feedback.
Requirements gathering is a lot of work. Project teams can incorrectly describe requirements, make incorrect assumptions, and under estimate the time required for proper requirements gathering. Do not assume all requirements are valid requirements. Work closely with the project stakeholders to review often the outputs of the requirements gathering phase. Requirements gathering is a lot of work, but if done correctly the client and consultant have a comprehensive list of requirements that lay a strong foundation for success.