The fact-finding stage in the Systems Development Life Cycle plays an extremely crucial role in the success of the overall proposed system. There are several fact-finding methodologies that can be employed. Usually, covering the current and historical requirements, interviews, questionnaires, prototyping observation, and Joint requirements planning (JRP). Incomplete requirements definition or assumptions on the part of the Analyst will most likely lead to the development of systems that are not user friendly or systems that do not contain full functionality.
It is therefore critical that the requirements defined are consistent and not contradicting or conflicting or ambiguous. Further, the requirements have to be completed by ensuring that they encompass all possible inputs or outputs. They should also be feasible and required (they are really needed and not created or assumed by the analyst). Systems requirements should also be accurate, traceable, and verifiable. It is very important to understand and accept that this process takes time, finances and that it can also be difficult and confusing, or frustrating.
It is common for inexperienced systems analysts to go straight into interviews or questionnaires at this stage. However, it is important to understand that describing systems requirements is not a simple task, especially on the part of the end-users. It is therefore required that the Analyst to uses the appropriate skills and techniques to extract requirements from users. It is also important to understand that many individuals find it hard to express their requirements.
Further, many users will not want their time to be wasted. This leaves the analyst with the option of adopting a systematic approach to the whole fact-finding process. The most popular strategy is to first investigate or research the existing material. The material could be documents, reports, and files. It is expected that the analyst will comprehend a lot without the need to meet staff members in person. Following the analysis of available material, the analyst can then observe the system in operation. This gives the analyst a real-time feel of the current system.
Now that the current material and system have been analyzed and observed, the Analyst can design a questionnaire that clarifies issues that were not properly understood. Thereafter, the analyst is expected to carry out interviews or group sessions. The interviews will be to clarify and verify any remaining or unclear and difficult issues that were not covered or could not be established by observation and analysis of available material. At this point, it is necessary for the analyst to let the end-user feel free while letting the topic move around. It is also important to avoid beginning with the features of the system but rather focus on their business and problems.
When appropriate, the analyst can mention a prototype or a relative example then they discuss it. This gives him/her the opportunity to catch their attention as well as an avenue to juggle their minds hence a chance to be informed on various issues for instance the most common problem with the former system. If the end-user is being given options, it is advisable, to begin with, the most obvious choices. It is also important to use their own words and shun leaving ambiguities unclear or unsolved.
The Analyst is also expected to use language that ensures that they are on the same page with the end-user and confirm that no issue is left unmentioned after a meeting. After the interviews, the analyst has the option of coming up with prototypes or examples that can be used to validate the requirements. These prototypes can further be used to find more requirements that may have been left out. After all the mentioned stages are followed, the Analyst is expected to carry out a follow-up to ascertain facts.
Basically, the reason for the fact-finding stage is to accurately establish the end user’s knowledge, process, and communication requirements for the proposed system. If little emphasis is put on the fact-finding process, it goes without saying that challenges will be encountered. First and foremost, it will be almost impossible to control the budget allocated for the project. There will be a high probability that the project will cost more than estimated. Moreover, it will be impossible to accurately predict the deadlines. If there are deadlines already set, failure to collect all the facts will result in delays and hence a late delivery of the project (system).
It is also obvious that end-user requirements will not be met. Dissatisfaction on the part of the end-user due to a missing functionality or a lack of user-friendliness may lead to the end-users protesting against it. It has been observed that end users can be very difficult to please. After production, an insufficiently researched system will be difficult to maintain or upgrade. The costs for such endeavors will also be excessively high. This system will also be unreliable. It will most likely have errors and downtimes that are uncontrollable. Lastly, the reputation of the entire project team will be tarnished without the need to know who specifically made a mistake. In summary, the impacts can be unbearable.
On the other hand, acquiring these requirements satisfactorily results in the development of competent systems that users are satisfied with, hence more productivity and more profits for the company. Therefore, it comes naturally that the project will cost as budgeted for, will be delivered on time, will meet user requirements, will be easy and cheap to enhance and maintain, will have minimal errors and the reputation of the project team members will not be at stake. It is however important to mention that the process is not as smooth as it sounds. Analysts will be faced with challenges from the beginning to the end of the phase at every activity. For instance, the available material may not be adequate for the analyst to come up with the initial or basic requirements. Again, there may be too much material for the analyst to be able to go through. This can prove to be a challenge in a situation where all the material is relevant and skipping may mean leaving valid factors or requirements.
On a different note, end-users can prove to be very unreliable in the sense that they do not know how to express their views, or in other terms, they do not have the skills to express what they want in the system. Other users will feel they are being disrupted while others will not really see the need for a new system. Do not assume though, these are the people who will complain loudly after the system is developed. The analyst will also have difficulty analyzing questionnaires. This is mostly because of the diverse views of the different users who serve at different positions in the company. Some suggested functionalities may also tend to be unrealistic, especially if the question is open-ended. Other users will fail to fill the questionnaires at all or hand them out incomplete. This then becomes a challenge to the analyst to analyze and define the real requirements.