Managing Requirement

 

Collect Requirement

It is essential for all the stakeholders of the project to have a unique image of the project objectives and the solution to achieve the project target. It sounds straightforward to create project requirement for what customer need, yet it is difficult figuring out what they say they want and what they actually need. Incorrect facts being offered by customer, omission, inconsistency and misplaced requirement cause error in identifying what customer need. Customers not willing to commit time to help you gather and document their requirement make the situation even worse and does not any help representing a clear solution to achieve the project goals. Generally, the information needs to be collected from the customer through an elicitation process. Once we know what customer needs, we will want to make sense of it and come up with a clear and unambiguous solution so that the expectation of key stakeholders are met.

International Standard to develop Project Requirement

The Institute of Electronics Engineer (IEEE), Project Management Institute (PMI) and International Institute of Business Analysis (IIBA) has developed standards and guidelines about preparing project Requirement in a broad range of industries. Experts from all over the world have collaborated and contributed in a fair manner to reach consensus for each standard.  Some typical requirement- development activities are:

–       Requirement Elicitation (Gathering information)

–       Requirement Analysis

–       Requirement Specification

–       Requirement Validation and Management

Brief explanations of the activities are given below

• Gathering information

The first step would be to investigate and identify the key stakeholders to understand who should participate in elicitation process. Some stakeholder has great impact and influence on the final requirements. Once the key stakeholders are identified and prioritized, the next step would be to apply elicitation techniques to collect information. One-on-One or Group-Focused meetings are examples by which the information is collected. Interviews with right people are also a practical way to collect requirement, however, it helps if we send the entire questions list to the interviewee before the interview so that the person has more time to prepare.

Detailed and simple questions like ‘Why is there a production problem?’, ‘Who told you about this?’, ‘Where do you send that information’ or ‘What is your interest, concern, and needs for this project?’ can be asked from the interviewees but whatever the questions are, it is crucial to have a strategy how we are capturing the information.

Are we writing a note by hand or writing on a tablet? Are we going to validate what we captured by asking a question like ‘Here is what you said and what I received? Is that right?’.

• Analyzing Requirement

In elicitation, process information is captured while in Analysis we’re making sense of it. In elicitation we’re receiving from the stakeholders the stated requirements, the things they say they need, however, in the analysis process we’re analyzing and deriving the real requirements for what capabilities we’re actually going to implement in our solution. We are figuring out what customers actually need.  It is like saying ‘let me think about the input and do something with it. We can think about ‘What other questions do I have? Is the captured information conflicting? Is it correct?’ It is done through an iterative process and we need to review the collected requirement, again and again, to come up with the realistic Requirements.

• Specifying Requirement

The purpose of technical writing is to help a specific audience to know what they need to do, to let the understand something to decide and generally provide the project member with a reliable and accessible source of information. In order to write the requirements, the formality and levels of details should be first defined and if the organizations do not have a methodology for doing so, we may want to use document templates for content and structure. Well-structured and clearly documented requirement enable us to understand a large amount of information in a minimum number of requirements. The requirements must be specific, correct, unambiguous, traceable, prioritized, consistent, modifiable and testable.

For instance, instead of writing ‘The location of the site must be acceptably far from the residential area’, which is an ambiguous requirement, it is suggested to state ‘the site must be constructed at least X meters away from the nearest residential area’ with X being our measurable index.

• Validating Requirement

Validating project requirements is performed through the project life cycle and is accomplished by presenting requirements for review and approval and managing conflicts or issues with the requirements. Validating requirement means, analyzed requirements are being quality checked to ensure that they’re correctly defined, ready for formal review and validation by your customers, checked against the documented specifications, and are complete and correct.