Software requirement gathering and elicitation is an essential step in software engineering. There are times when some requirements do not match with other requirements, which hinders the developers’ ability to deliver user-driven software solutions. Such challenges arise often and are responsible for poor quality software solutions delivered to clients (Gambo and Taveter, 2021). Resolving such challenges calls for the consideration of all stakeholders to craft reliable specifications that address the interests and needs of all players.
Requirements specifically form the basis of software engineering and determine the specific outcomes of the project. To resolve the problem of mutually conflicting resources, engineers need to formulate a clear and concise requirement gathering protocol that is industry-independent. The resolution employs the phase resolution approach which emphasizes each step of the requirement gathering and elicitation as shown in the UML diagram below.
The steps are listed and elaborated below.
- Identify the relevant stakeholders.
Project stakeholders determine who the project should impact and their contribution to the project success should be valued. Project stakeholders vary from one project to another and depend on the project scope and nature. Each stakeholder will provide input that will be incorporated in the software requirements document, and later transformed into working software.
- Establish project goals and objectives.
Project goals and objectives describe what the project should cover and why. With the help of the stakeholders, the requirement-gathering team should be able to document the project goals and objectives which must be in line with the technology and user needs and expectations.
- Elicit requirements from stakeholders.
Requirement elicitation is the first important sub-process of the requirement gathering process. It entails asking stakeholders about their thoughts and expectations. The process can be achieved through questionnaires, interviews, or observation as different players perform their day-to-day activities in their respective domains.
- Document the requirements.
As the user requirements become clear during the elicitation step, they should be documented for future reference. The documented requirements should be neat and easily understandable to other developers.
- Confirm the requirements.
In this step, the collected requirements are reviewed with the help of all stakeholders. If expectations of different stakeholders conflict, the requirements are reviewed with the help of the respective players to come up with a common requirement or agree on a joint way forward.
- Prioritize the requirements.
The requirements should be prioritized depending on possible risks, urgency, dependency, and user expectations. Requirements that are needed earlier urgently like user interface templates and database models should be implemented first.
Reference
Gambo, I., & Taveter, K. (2021). Stakeholder-Centric Clustering Methods for Conflict Resolution in the Requirements Engineering Process. In International Conference on Evaluation of Novel Approaches to Software Engineering (pp. 183-210). Springer, Cham. Web.