introduction

1

Stakeholder needs and system requirements represent the views of stakeholders, customers, acquirers, and users relating to a specific problem or an opportunity; these requirements provide a solution to a particular problem in the business environment. Salado (2021) notes that disparities in these requirements can contribute to the application and conceptual inconstancies due to the poor formulation of the requirements. Stakeholder needs and system requirements can be captured in different ways; therefore, different methods were used to accommodate diverse sources. First, the requirements were captured through brainstorming workshops; these workshops involved meeting people virtually or in person to draw out, discuss, explain and come up with ideas to solve the problems by creating something new. The other formal process used were the interviews and questionnaires; all stakeholders were involved in various discussions, and those who could not avail themselves received questionnaires. The feedback from these interviews and responses from the questionnaires were crucial in the elicitation process. They were successful, and the information provided was crucial for the system requirements.

System requirements include requirements that must be present for a system to work smoothly and effectively; they can be software or hardware. The system's needs were established through stakeholder consultation; during the brainstorming workshops, the developers proposed system requirements that would improve the functionality of the current system. This proposal was passed to the stakeholders through interviews and questionnaires and approved. Therefore, the system requirement was a technology push; the business has been operating on an outdated technology which has been slow and ineffective. The functional constraints and data requirements have been below the minimum recommended configuration. Thus, the system was operating on software dependencies, and necessary upgrades were significant to keep it up and to run.

In software engineering, requirements are evaluated in the software development process. The users' needs were successfully translated into engineering specifications by considering functional and non-functional requirements. Demands from users and other stakeholders are translated into engineering specifications because they represent their desires. However, some problems may arise if the managers are responsible for representing the users and other stakeholders. The significant issues that arise are the managers can provide completely wrong requirements because they have never been users. Secondly, the solution may not be helpful to the user if it was designed to provide a solution that works for the managers. Lastly, market research can be detrimental if the manager does not involve the actual users in addressing their needs. However, in this case, the users were involved in every stage of the requirements. Their responses were crucial in addressing the problems.

The needs of the users and stakeholders were translated into engineering specifications because the solutions were blended into user experience and stakeholders' feedback. The purpose of engineering-specific solutions is to create end-user solutions and reduce the possibility of the problem attributed to the software. The business sends representatives to the real users and stakeholders and observes how the system works and relates to their environment. These visits aim to ensure the success of stakeholder and user-driven projects; when the people interact with the system and observe the users, the feedback from these observations provides an engineering perspective on the possibility of bias and takes care of practices that would not be captured in the questionnaires. Thus the requirements were successfully translated into “engineering-speak” because the information collected was first hand and it directly related to the users and stakeholders. They impacted the performance of the system and access to the services, which translated to the need for improvement of the system.

Requirements gathering defines software requirements because every project has requirements. The most significant steps are requirement elicitation, requirements documentation, and requirements understanding. The requirements were well-managed because the goals and objectives were established early. A framework is substantial; although the managers might think they do not need the objectives, there was an urge to write them down and have the stakeholders sign off on them; lack of framework would affect the future decision-making process. Secondly, data gathering was effectively managed through transparency in the documentation of the requirements. Stakeholders and users can understand the requirements, but the biggest question is how you know the needs. The transparency ensured everyone was on the same page and fostered buy-in sense throughout the project. The right stakeholders and users were engaged in the requirements gathering. However, these people were not the decision-makers in the project, and their buy-in was significant in the project's success. Throughout the systems engineering process, the requirements gathering prevented "scope creep" by avoiding forcing users and stakeholders to use a system designed without their consent. A project is more likely to fail if the users are omitted because their ingredient is crucial in the systems engineering process.

Business requirements played a crucial role in managing the requirements gathering; the essential step was to ensure the administration focused on the business requirement and not the tools. Adapting the system engineering to the user was more important than worrying about producing the system. Therefore, listening and gathering requirements was the first step, then the gaps between the stakeholder’s and user’s needs were identified later. The requirements are about "what" and not "how"; therefore, the user's needs are more important than the means of achieving because users represent the most significant portion of the stakeholders.

Reference

Salado, A. (2021). A systems‐theoretic articulation of stakeholder needs and system requirements. Systems Engineering, 24(2), 83-99. https://doi.org/10.1002/sys.21568