Analyst / Programmer? Four Questions you Should be Asking!

Are you a Business Analyst, System Analyst, Test Analyst or Programmer? These are four (4) fundamental questions you should be asking when making or testing changes to existing software.

Interestingly these four questions apply equally to every role, each from their own unique perspective.


In general the questions around how the solution currently works is asked and confirmed first by each role player, followed by the questions and answers around the change required.

Interestingly I have seen many analysts / developers try to spec, change or test a solution without thoroughly understanding how the existing system was put together in the first place – often due to incomplete requirements, overzealous deadlines, lack of skill or just plain laziness. Without this basic understanding, the journey to a successful implementation becomes fraught with unknowns and often results in rework, frustration and errors.

The more complex the system or change the more likely the risk of failure if the current terrain is not understood. Imagine trying to implement a new exit strategy on an aircraft when you don’t know where the existing exits are or how they operate (system set 1) – never mind the devastating impact on air pressure when exits are opened (system set 2 dependency). No one would make it out of your solution alive!

Each role player is required to assess each question from their perspective and ensure that the questions have been answered adequately. Is the proposed solution the best possible option – with the lowest risk and highest reward? Has the requirement been adequately specified to allow for accurate coding and testing?

All of this ensures that the solution is developed and tested in the most optimal manner and that all stakeholders can be identified and managed when it comes to implementation – including the handling of solution failure and ongoing support. Any gaps in logic or requirement need to be raised to ensure that the integrity of the solution can be maintained. Risks should be highlighted and alternative solutions considered where necessary.

All of this of course relies on COMMUNICATION across teams, divisions and suppliers. A topic that will be covered in a future article!

Go Well