Software failures: It all started from the beginning.

source: https://www.pinterest.com/pin/194288171402864609/

Imprecision in the requirement analysis and specification is the root cause of many software engineering problems(Sommerville, 2016). According to the Software Engineering Body of Knowledge(SWEBOK), the phases in software development are requirement gathering, system design, implementation, testing and maintenance, and among all requirement gathering is the far most important. Bharathi stressed the essences of requirement gathering(which is also known as requirement engineering) in her study stating the importance of understanding problems in client terms by outlining the processes that must be followed for adequate requirement gathering when developing software which as follows:

1. Simple listings : Listing out all the requirement of the customers
2. Survey : performing on-site survey
3. interviews : engaging both one on one and group interview with the clients ,
4. Focus group: Talking to focus group especially in the product domains
5. Observation: Observing and noting things while doing the above..
6. Use cases analysis: and finally carrying out use cases of what to develop.

Sommerville (2016) defines requirement gathering as the process of gathering the software requirements from clients, analysing and documenting them. Requirement gathering are logically categorized as:

1. Must Have: A system cannot be operational without them
2. Should Have: These are the functionality that enhancing the systems
3. Could Have: The system can still properly function without these attributes in place
4. Wish List: These requirements do not map to the system objectives.

ask users this one question: If you have a magic wand and you can only wish for one thing, what would you have wished to change to make you work efficiently (to make your work easier) ?

For any successful software development, the first two should be focused on while the last two can be integrated during the software updates. Sommerville (2016) further elaborates the processes of requirement gathering journeys by using spiral diagrams, that for any software development project, requirement gathering is starting from business requirement specification, then carrying out the feasibility studies followed by user requirement elicitation, then user requirement specifications, after this, is software prototype to system requirement elicitation and next is system requirement specifications and modeling, when all these has been done, it will now be properly reviewed and documented.

Software requirement can be (1) functional such as user should be able to send report to management, user can check admission status etc, it can also be (2) non functional such as the quality attribute, the performance and scaling of the software, the security of the software etc (Mohapatra, n.d.; Sommerville, 2016).

Despite the importance of requirement engineering in software projects, the following are the problems associated with it as stated by (The Requirement Gathering Process — Challenges & How to Overcome Them, n.d.):

1. Success criteria is not defined clearly: in this case, stakeholders know they have a problem but not knowing what they want or how to state the problems in a clearer way or probably not knowing what they want. As a system analysis, sometimes, it is in your best interest to help your client understand his problems.
2. Stakeholders change their mind: this often happens from time to time. Either requirement was not earlier defined clearly, the best way to approach this is to be flexible and prioritize changes.
3. Stakeholders are not willing to speak up or they have been too expensive: this could be political reasons or people may be crucified for expressing their ideas or ranks may need to be broken. In this scenario, it is good to gain their trust and rapport, and dive into their languages as opposed to technical jargons. Learning their domain and listening more.
4. Stakeholders insist on a particular technical solution: this could be as a result that stakeholder did not understand the underline use cases of the software or have a premeditated solution in mind which may be difficult to change. What can be done in this case is to ask questions, such as, what benefit would it have if these features were implemented?
5. Stakeholders have conflicting priorities: When a new system is created, it is ideal for users from different ranks to have different opinions or views about the software. To solve this problem, it is advisable to have a designated authority to checkmate these conflicting ideas.

Sometimes during requirement gathering, most of the time stakeholders say less of what they wanted, going forward if you had wanted them to say more they could have imagined, ask them this one question: If you have a magic wand and you can only wish for one thing, what would you have wished to change to make you work efficiently (to make your work easier) ?