You are a member of the software development group in your organization, and you
ID: 3697124 • Letter: Y
Question
You are a member of the software development group in your organization, and you were asked to gather requirements for an upcoming project. The software will be a self-service Web portal for employees to access and modify their employee benefits and payroll deduction information, view their pay stubs, and request time off. The end users will be all the employees in the company. Some of the potential users are familiar with computers and software, and others will have limited experience with computers.
Based on your knowledge, experience and ideas, describe how you will gather requirements for the new software. Include at least 2 sources of requirements information in your plan.
Discuss the potential problems you might encounter during the requirements-gathering process and how you would deal with the issues.
Explanation / Answer
The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.
The process to gather the software requirements from client, analyze and document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.
It includes-
Feasibility Study-
This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.
Requirement Gathering-
If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
Software Requirement Specification-
SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.
Software Requirement Validation-
After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly.
Problems encounter during the requirements gathering process-
Resistance in sharing information: In some cases, information will not be forthcoming. These users will regularly attend your workshop but it will take a mammoth effort to make them talk. At the other end of the spectrum, there are users who make your life difficult by bombarding you with loads of documents.
Irregular attendance:
This happens when key users attend one session and then skip a few in a row. Suddenly, they appear and start changing the course by asking/changing things that were frozen during their absence. Or worse still, they want you to start from where they left.
A set of users keeps on rotating, and a user who is present today may be gone tomorrow. There is inconsistency in attending the workshop.
Accountability for decisions:
There may be instances in which the current business process needs to be changed or modified to make it more efficient. The users may all be in consensus but none will volunteer to approve it. Or, there could be situations where the elicitation process may reach a dead end if certain decisions are not taken.
Resolving user conflicts:
This could take two forms:
Conflict between the business analyst and the users:
Conflict between users:
Real needs vs. perceived needs:
Sometimes it becomes difficult for business users to distinguish between a real need and a perceived need. A perceived need is always a little tricky as it may be a workaround/temporary solution for the problem and not the problem itself!
Changing needs:
Time and again, we have faced this, and there is always a dilemma as to whether a BA should accommodate or ignore the change.
note- the above explanation can help to answer the given question.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.