Every Project Has Requirements
- Customers at times believe that the analyst or the member from the development team should already know what the customers need. Defining business requirements is not the ownership of the customer but the project team.
- It would be ideal if the analyst is given the pulse of the current systems and processes coupled with existing documents to educate them about customer’s business concepts and terminology.
- Customers usually don’t find it significant to invest time with the project team for requirements gathering or elicitation activities. Sometimes customers get so busy with their key responsible areas at work that they usually don’t give justice to the requirements gathering activity and the requirements gets captured just on assumptions.
- Apart from requirement gathering, interviewing the users they would be responsible to create prototypes or wire frames to demonstrate a non-working model to the customers. Customer can get a fair idea looking at the wire frames how the proposed solution would look like.
- For any queries or concerns towards any aspect of the planned project activity it is appropriate that a BA defines a clear process in identifying the key points of contact in the project engagement with proper escalation mechanism.
- Business Analyst (BA) analyses, documents, manage and presents the project requirements for review and approval to the customer in a most comprehensible manner. Analyst should communicate to the customer in the early stages of the project the standard templates and requirement management tools they would adhere to in order to document the requirements specifications.
- For a BA getting a requirements sign-off would mean a formal agreement with the project stakeholders, stating that the contents of the requirements document, as drafted, are complete to the final projections and that there are no open issues left to be addressed. It is an expression of the output of requirements gathering to all those concerned with the project.
- They conduct requirement analysis and pre-assignment studies at customer’s location by giving product demonstration and walkthroughs to prospective clients, resolving pre-sales issues and handling questions differentiating our product from other competitors.
- Pre sales are also responsible to respond to prospective customer questions and observations. They educate customers and prospects understanding the benefits of the product.
- Provide help in giving feedback to stakeholders regarding the product features and functions and ensure that the product offered best matches the customer needs.
- Once a particular product is successfully implemented the pre sales view the project requirements in identifying sales opportunity for the product, prepare proposal documents and market the same in competitors market falling under the same vertical or domain.
- Project Manager would
view requirements in terms of the cost of the resources involved and the
time frame it would take to implement functionality
in line with the defined standards and control processes.
- Requirements serve as the baseline for a successful project design. Project Manager should ensure that the resource who would be dealing with requirement gathering should have some hands on experience in requirements engineering practices and that the same is well understood and well communicated.
- Project Managers have to ensure that as and when one incorporates new project requirements is the project team able to still stick to their original schedule as per the available resources. If not then they should immediately renegotiate on project commitments wherever there is a change in the requirements.
- Managers need to thoroughly review the project documents prepared by the analysts and should there be a discrepancy they should communicate the same in the early stages of the project itself otherwise it would result only in re-work and detrimentally effecting the on going project delivery.
- Developers view the requirements from a technical angle in terms of data dictionary, tables, user interface, reports formats, integration etc. When questions like these are raised during the time of requirement gathering they witness a total disconnect because not at all business users are technically educated. Discussions like these only dilute the interest level of the conversation.
- Ambiguity in requirements results in waste of time and developers end up developing a solution, which does not meet up with the customer’s requirements.
- Developers at times end up giving more than what is required by the customer in an attempt to please them with “gold plated” functionality. One should deliver only what has been asked for and anything extra that is delivered should be given only with prior customer approval.
- Some features required by a customer may have technical limitations and the turn around time required to implement the same may also be quite high. Certain new requirements can detrimentally effect the performance of the existing functionality. To avoid such cost of re-work a requirements stakeholder should respect the developer’s view of the requirements.
- What ever may be the requirements the quality team would view for the following key attributes which includes the system’s performance, response time, handling load, transactions of the system and much more.
- After studying the business requirements and review of the specifications the testing team starts with planning, designing, and executing tests cases for features that need to be released upon customer’s requests.
- Where developers may have developed in one way the testers expect the product to behave differently from what the developers have developed as per acceptance criteria.