Problems faced in the stage of Requirements Analysis
Filed Under Document, Requirements, Issues, SDLC, Development, Software | Posted on October 17, 2007
For a process that is so critical to the success of a software project, you would be surprised at the number of problems that can happen during the requirements gathering and analysis process. This must be the reason why Requirements Analysis is called the ‘make-or-break’ step of any project.
* Users don’t understand what they want or users don’t have a clear idea of their requirements: Possibly the most common problem in the requirements analysis phase is that customers have only a vague idea of what they need, and it’s up to you to ask the right questions and perform the analysis necessary to turn this amorphous vision into a formally-documented software requirements specification that can, in turn, be used as the basis for both a project plan and an engineering architecture.
* Users won’t commit to a set of written requirements: There will always be the feeling that such a list is not complete, and can cause immense heartburn for the requirements analysts
* Users insist on new requirements after the cost and schedule have been fixed: This may occur because as development progresses and prototypes are developed, customers are able to more clearly see problems with the original plan and make necessary course corrections; it may also occur because changes in the external environment require reshaping of the original business problem and hence necessitates a different solution than the one originally proposed. Good project managers are aware of these possibilities and typically already have backup plans in place to deal with these changes.
* Communication with users is slow: The users and the requirements analysts are from different working environments with a different pace and style of working
* Users often do not participate in reviews or are incapable of doing so: Especially when dealing with customers from the non-software industry
* Users are technically unsophisticated
* Users don’t understand the development process.
* Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
* Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
* Analysis may be often carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client’s needs properly.
What can be done ? There are some steps that cam be taken to get over some of these difficulties:
# Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.
# Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.
# Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.
# Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.
# Set milestones for each development phase beyond which certain changes are not permissible — for example, disallowing major changes once a module reaches 75 percent completion
# Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.
# Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection
# Take notes at every meeting and disseminate these throughout the project team
Leave a Reply
