When first starting an IT project, there are usually multiple ideas and suggestions about what is required. Often the project team will begin looking for a solution without first performing a thorough investigation of the problem and without asking the important questions “What is the problem?” “Why is this causing a problem?” “What is the effect on the users?” “Does this problem need to be fixed?” “What is the cost if a solution is not found?” Taking the time to answer these questions at the start of the process helps to clearly define the requirements for the project; an essential step to ensure that cost estimates and timelines are accurate, and that the project ultimately has a successful outcome.
Gathering this information is vital, but it can also be challenging as the problem often affects each of the stakeholders in different ways. What is optional data for one stakeholder might be required data for another stakeholder depending on the task being performed.
To ensure an accurate picture is obtained, the Business Analyst needs access to the various stakeholders. They can then become familiar with the stakeholders’ workflows and ask them questions. “What do you do?” “Why do you do this?” “What should change?” “What shouldn’t change?” “Is there a reason, why this must not change?” Once this information is gathered, it is documented and used to focus the stakeholders on the current process and to identify gaps that can be turned into requirements. If critical stakeholders are missed out of this process, user workflow is overlooked which can cause a delay in the project and additional unplanned costs.
Requirements gathering is an essential step in any IT project and ensures the solution implemented meets the needs of the people who will be using it.
The Business Analyst takes on the responsibility, in conjunction with the customer, to document the detailed requirements in a way that is easily understood by everyone involved in the project. This step is critical as it is where the majority of misunderstandings can easily occur. For example, a document can be misconstrued if the wrong terminology is used i.e. ‘Location’ instead of ‘Patient Location’. To minimise risk, a requirements template can be utilised to ensure all relevant areas are considered and a consistent layout is used.
For small projects, the requirements elicitation process can be undertaken via phone or email. If the project scope is changed or new requirements are identified, the quote or estimate document will be updated and re-issued. For larger projects, a document walk through is used to verify the requirements. This process can take one or more meetings before the document can be released for a formal review. It is essential the project decision makers are part of the document walk through meeting to ensure changes are approved based on the project scope and to make sure they are communicated to all the critical stakeholders.
Preventing misunderstandings when gathering requirements continued …
Sometimes, even with approved requirements, the changes implemented still do not meet the customer’s objective. This could be because assumptions were made, but not communicated or documented, resulting in an item being missed. Where possible, the requirements document should specify all assumptions, and list all items that are included or excluded to eliminate confusion. For example, ‘The new field will accept 6 alpha characters only. Numeric data will not be accepted.’ Additionally, it is also the responsibility of the reviewer to read and understand the requirements and to ask for clarification if anything is unclear so that the document can be updated.
Requirements gathering is an essential step in any IT project and ensures the solution implemented meets the needs of the people who will be using it. A Business Analyst can facilitate this process by documenting detailed and easy to understand requirements and promoting open communication between everyone involved in the project.
About Derryn Strong
Derryn Strong is a Business Analyst at Sysmex. Her previous roles have included software testing, training and project implementation.