Evan Camilleri

When you start a new job, even if you are an expert with lots of experience in the domain in which you new employer work, you have to learn.  Sometimes the learning curve is small, sometimes long – in any case there is always a learning curve.  In a healthy environment, there is bi-directional learning process.  You will learn your new job, but you will also teach your experiences to your co-workers and employer.  Everyone has something to give back.  The same aspect can be also considered for an analyst who’s task is to gather requirements from a new client.  The learning experience is also two-way, since users do also learn, or will learn, from the analyst. [1] In order to explain the introduction of this blog better, let’s discuss a scenario: Dexter, our fictitious analyst, is assigned to analyse the stock control requirements of Store-n-Sell Limited, our fictitious client.  When Dexter meets Tony, the store manager for Store-n-Sell, Tony explains t...

Developing software solutions is no easy task.  It involves that the developer must understand the problem, know the technology and implement a solution – in the shortest time possible, possibly written with the latest technologies and methodologies and with the least amount of bugs and implemented in a user-friendly way, if possible requiring less training and documentation.  So, here comes the analyst. Requirements elicitation, or rather, the practice of obtaining the requirements of a system from users, customers and other stakeholders [1], is in itself a science and an art.  It involves understanding people, understanding the domain [2], understanding the technology, the flow of processes and the final usability of the solution.  I like to refer to an analyst as an artist who closes his eyes and sees the final picture ready; this time working and fully functional.  Once this is done, then it is a matter of communicating with the client, the final user, to be...