Gathering requirements key to a successfulproject
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 thoroughinvestigation of the problem and without asking the importantquestions “What is the problem?” “Why is this causing a problem?”“What is the effect on the users?” “Does this problem need to befixed?” “What is the cost if a solution is not found?” Taking thetime to answer these questions at the start of the process helps toclearly define the requirements for the project; an essential step toensure that cost estimates and timelines are accurate, and that theproject 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 shouldchange?” “What shouldn’t change?” “Is there a reason, why this must not change?” Once this information is gathered, it isdocumented 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 andadditional unplanned costs.

“ Requirements gathering is an essential step in any IT project and ensures thesolution 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 waythat 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 consistentlayout 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
walkthrough 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 walkthrough meeting to ensure changes
are approved based on the project scope and to make sure they are communicated to all the critical stakeholders.

Sysmex Perspective Series

1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 notcommunicated 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 excludedto 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 readand understand the requirements and to ask for clarification ifanything is unclear so that the document can be updated.
Requirements gathering is an essential step in any IT project andensures 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 StrongDerryn Strong is a Business Analyst at Sysmex. Her previous roles have included software testing, training and project
implementation.

2Sysmex Perspective Series