It is vital to use the software requirements elicitation process when developing a system, because if it’s not followed the end product will not be right for a client and the end-user. That is a waste of the client’s money and resources, and the software development team’s time, not to mention, aggravate the customer. It would be bad if this happens. Using the software requirements elicitation process eliminates errors, and inadequate software. That’s why it’s so important.
The interaction between the client and/or stakeholders and developers is where the development team finds out what the client/stakeholder’s needs are for the software they are to develop. They would ask a serious of questions to determine how to begin the project and if there is already an existing system. There would be a series of questions asking what their customer (end-users) would need to conduct their transactions. The questions would determine what kind of software and interface will be needed for the client/stakeholder’s business. This interaction with the client/stakeholder is conducted in a serious of interviews(Software Productivity Center Inc, n.d.).
The interaction between the developers and end-users consist of finding out if the software techniques are appropriate for the end-user by conducting interviews, developing a prototype for the users to test, and by asking for surveys to be completed once they used the prototype. The results of these tell the developer if there are any improvements to be made to the prototype and if it’s adequate for the end-users to use. The end-users provide feedback about how easy the system allows them to perform a task and if the steps and directions are easy to understand (Software Productivity Center Inc, n.d.).
The most common technical issues that occur during a developer and end-users interaction is when the system has too many errors when trying to complete a transaction/request, when it takes too long to complete a transaction/request and when there are too many steps to take to complete a transaction/request. The goal in making adequate and productive software is to design it where it takes as less steps as possible to complete transactions/requests, with no errors and it goes very quickly. The end-user must be left with the impression that they will be pleased to use the software again because their experience was good. This is why it is crucial that a developer makes a prototype of the software and have the end-users test it. They would then ask the end-user questions about their experience using the prototype through interviews and surveys. Once the developer has proper feedback from the end-users, they can then tweak the prototype to correct any issues for the final product (Wiegers, n.d.).
The 4 steps of the requirements engineering process are as follows (cs.umd.edu. (n.d.):
- Feasibility study – this is when a developer determines if a system will contribute to a company’s needs and objectives by finding out if a system can be done by their budget, and can be integrated into a present system (present technology etc.) if one already exists.
- Requirements elicitations and analysis – This is when methods are used such as interviews, observations, existing system examinations, design sessions, software tools, end-user surveys, and end-user focus groups are determined to make an analysis to design a software that is adequate.
- Requirements specification – this is when requirements state what a system should do and how a design would describe how it does it to include how it would inter-operate with any existing systems.
- Requirements validation – This is when it’s validated through testing that the client/stakeholder and the end-user is satisfied with what the system is supposed to do before the final software is done.
References
cs.umd.edu. (n.d.). The requirements engineering process. Retrieved October 7, 2013 from http://www.cs.umd.edu/~mvz/cmsc435-s09/pdf/slides5.pdf
ModernAnalysis.com. (2010, July 07). An overview of requirements elicitation. Retrieved October 7, 2013 from http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1427/An-Overview-of-Requirements-Elicitation.aspx
Software Productivity Center Inc. (n.d.). Software requirements elicitation checklist. Retrieved October 6, 2013 from http://ecee.colorado.edu/~swengctf/standalone/handouts/RequirementsElicitationChecklist.pdf
Wiegers. Software requirements 2. (2 ed.). O'Reilly. Retrieved October 7, 2013 from http://wow.coursesmart.com/9780735618794/firstsection