Who Decides the Project Requirements? ~ by : Niilesh A Raje

Article had been published earlier with the International Institute of Business Analysis (IIBA) headquartered in Toronto, Canada and Better Projects , Australia

                             Every Project Has Requirements 

I am sure most of us would agree that “Every Project Has Requirements”. Every time a new software application is being developed explicitly or implicitly there is always a ‘Business Analyst’ (BA) from the project team who performs the role of requirements gathering for every software project. While some requirements are crucial to the application others are considered to be gold-plated luxuries.

Determining the project requirements is vital in developing successful software as they form an agreement between the IT team, the customers and various stakeholders on what features are absolutely essential to be delivered in the new system.

Requirements just don’t come from one source but multiple stakeholders. In this article I would like to touch upon some key pointers which are essential and indispensable for business analysis. What each stakeholder’s view is when it comes to determining software project requirements and who owns them?

Requirements Stakeholders

From the above figure it is evident that software requirements just don’t come from the customer. Requirements come in from all directions which include: Customers, Business Analyst, Pre Sales Team, Project Manager, Development Team and QA team. It’s imperative that one identifies at the beginning of the project who takes the ownership for defining the project requirements. If this is not resolved in the early stages of the project then the ownership falls on the vendor or the requirements later then form to be a part of change request.

Customers: Are They Always Right

Anyone who derives direct or indirect benefit from a product or service offered is a customer. It’s not necessary that the customer may be always right. However, the customer has a viewpoint and one must understand and respect customer’s viewpoints rather than forcing other stakeholders to determine among the customers who may not necessarily agree with conflicting project requirements.

As a software customer one would be primarily responsible for the following activities:

1. 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.

2. 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.

3. 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.

Customer needs to prioritize what requirements are crucial and critical to the project. Requirements, which are vital, need to be delivered on priority whereas those that are good to have features can be delivered phase wise. Customers have to understand that not all requirements can be given at the same time. Phase wise delivery would be ideal.

Business Analyst: Catalyst for Requirements

The Business Analyst holds the primary responsibility to elicit, analyze, validate, specify, verify, and manage the real needs of the project stakeholders, including customers and end users. The requirements analyst serves as a catalyst between the customer and the software development team and is responsible to bring all the stakeholders to a common level of understanding.

A Business Analyst would serve as an agent and views requirements from the following angle:

1. 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.

2. 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.

3. 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.

4. 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.

Pre Sales Team: Before Development Starts

Requirements given by the pre sales consultant many times conflict with what the developers think and they could build. The problem here is only a high level input is provided from the consultant having not much visibility of the product to be developed.

A Pre Sales Consultant would usually view the project requirements from the following angle:

1. 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.

2. Pre sales are also responsible to respond to prospective customer questions and observations. They educate customers and prospects understanding the benefits of the product.

3. Provide help in giving feedback to stakeholders regarding the product features and functions and ensure that the product offered best matches the customer needs.

4. 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: A Quantitative Analysis

   

Project Manager’s view to invest more efforts of the project plan for software development rather than giving adequate time frame for gathering software requirements. Project manager’s view requirements by doing a quantitative analysis and its associated impact on the project plan.

Some of the challenges faced as far as requirements go from a Management View as are follows

1. 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. 

2. 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.

3. 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.

4. 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.  

Development Team: Requirements to code

Developers are those members of the community who are more inclined as well as responsible for writing and coding individual programmes from specific requirements.

After review they interpret written business requirements and technical specification documents and perform coding.

1. 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.

2. 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.

3. 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.

4. 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.    

  

QA Team: A benchmark of quality

Well-defined project requirements should enable the QA team to develop accurate test cases to verify the functionality under consideration. It is vital that the testing team be involved in the project from the requirements elicitation milestone.

The quality team views the requirements from the following aspect.

1. 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.

2. 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.

3. 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.

Some times very little time is given for the testing team to test the solution. In case the project is running behind schedule the testing milestone may be not given due importance.

Conclusion

From the above it can be seen that different stakeholders interpret project requirements in different ways. Each one of them is right in their very own way and each one of them has their viewpoints from their own angle. For the success of the project what is more important is to have all the stakeholders of the project brought to a common level of understanding and work in synergy. It's better to identify in the early stages of the project who from the customer's end would take business decisions on project requirements so as go ahead smoothly with the next planned project activity.