Author: Sandeep Mehta

Purpose of this article

The article describes the importance of stakeholders in the requirement management process. Many times, project requirements are defined and the execution phase starts, but there is still a missing link. The missing link is the disconnection between:

• The requirements being executed

and

• The expectations of the stakeholders.

The product delivered at the end may not result in the solution the customer has in mind. The Project Manager thinks, although he did everything according to the requirements document, what did he miss? To find the answer, read below.

Requirement Analysis and Communication

The project manager or requirements analyst gathers the initial requirements from the client. He or she then starts developing the architecture/design etc, and creates a framework so that the development team can start working. The important thing is that, it is essential that requirements are checked with the client on a regular basis.

The Requirements Analyst / PM should keep on asking the client at each stage, if there are any changes in the requirements. What happens is that when requirements change, the client is also not aware in advance.

When the client understands that, the requirements need to change, he rushes to the contractor with a new set of requirements. This can also be towards the conclusion stage of the project and then it becomes extremely difficult to complete on schedule.

Good requirement analysts visit their clients, communicate, and discuss their requirements in great depth. By doing so, a number of times, it soon becomes evident to the client that, he is missing something; he crosschecks and finds that, there is more to the requirements. The shortcomings are identified well in advance and work becomes much smoother. The total effective time spent is much less compared to the earlier case.

Types of Requirements

The requirements vary with the type of stakeholder e.g. the requirements can be categorised as below

1. Business/Functional requirements
2. GUI requirements
3. System requirements
4. Design (Technology) requirements
5. Coding standards requirements
6. Operation requirements
7. Database requirements

The Missing Link

The missing link is the question,

“Who creates the requirements?”

For example the original requirements start with the business need. GUI requirements are specified by the end user. The table below gives a typical scenario for above requirements.

Stakeholders Involvement

If stakeholders are not involved at the right stage, the product developed will not be as satisfactory, as required. It is often said that the stakeholders should be involved at the beginning of the project. It is very important that, the stakeholders are involved especially in the inception and elaboration stages. If the vital stakeholders are ignored at any stage, the project fails miserably.

The above table shows who the implementers will be. If implementers take up the role of the requirement specifier then, it will be easy to implement the requirements but still the application developed would turn out to be a waste of efforts. Also if the requirements are specified without carrying out proper analysis, again it will be a disaster.

Requirements Validation

The analysis should be backed by the data and investigations. It is very easy to say that, technology “A” is fantastic but, if the claim does not have sufficient data and evidences showing the benefits of the technology, it will not serve the purpose.

For example, if the requirement is high speed of update and the technology offers maintenance efficiency but fails to offer the operation efficiency, the final product would be a dead application.

Other Stakeholders in Requirements

Other stakeholders may be the project execution team, QA team etc. The overall requirement specification will bring out:

• What is to be done?
• Why it is to be done?
• How it is to be done?

The Requirements Process

The process of gathering the requirements is very crucial. If the correct requirements are collected, 40 % success is achieved. If the problem is well understood, providing a solution becomes an easy step.

A typical transformation from basic requirements to the complete set of requirements look like the diagram below.

Regular Meetings and Documentation

It is important to have regular meetings with the stakeholders and involve them till the requirements are finalised. Take the review of the requirements end document. An independent analyst, who is not involved in creating the requirements, should do the requirement review.

A proper review process should happen followed by the approval of requirements. The construction phase should follow only after the review and approval to save any rework. However, many a time small change requests happens during the construction phase, which must be given due consideration. These change requests should not deviate from the scope of the project. The requirement specification documents should be revised accordingly.

Requirements Management and Simulation Tools

One can automate the process of capturing the requirements through tools like Rational RequisitePro.

Also any simulation tool can be used to validate the look and feel for the end users and other stakeholders. Various scenarios can be evaluated and prototypes can be created very quickly before finalising the requirements. These prototypes can be provided to the stakeholders and their feedback is taken to incorporate the new requirements, or to remove defects early. This will also relieve the development team of a lot of rework. These tools also create the initial use case documentation from the prototypes.

All these should be version controlled for an effective documentation process. For tools like Rational RequisitePro, it can be in built feature.

Test against the Requirements

The QA/Testing team should take the requirement documents and cross check the application against the requirements. They should identify the defects and hand them over to the Development team and Client team for removal of the defects. Defect tracking should be done through Defect Logs. Before the final User acceptance testing and rolling out to production, all the defects should be removed and closed.

Summary

The article describes what we typically miss during specifying the requirements. It is very important that, we give due weight to the actual users and analysts when creating the requirements. The technical team should not play the role of requirement specifier.

However, the technical team can propose solution based on the client’s needs. The solution should be backed by proper historical data or proof of concept and evidences, if available. The selection of alternatives should be left to the end client. The domain knowledge and the functional knowledge plays a vital role in specifying the requirements. Overall, the article describes, how to bring stakeholders involvement into the project life cycle.

Author

The author is currently working as a Service Delivery Manager in a company known as, Case Consulting Group in Mumbai. He has worked at client sites to ensure a successful go-live for many projects. He also has lead teams to achieve the set goals and has experience in both, software and core industries. Sandeep has dealt with a lot of requirement management in Software as well as hard-core engineering companies. He has communicated with all types of stakeholders having varying backgrounds, skill sets and capabilities to a achieve successful implementation.

Copyright Project Perfect