CMMi – Process Area – Requirement Development – Part I

Well, this is going to be an exciting journey from today onward. Lot of real life examples, scenarios, and meeting inputs from behind those closed doors.

We’re going to talk about Requirement Definition in detail, and we will try and understand the importance of the RD process area as to how this effects our project and project planning. Everything is oriented towards one goal and that is ‘Deliverable’.

From now on you’ll have one liners like these, which may not have any sync to the topic being talked about but for sure is going to make it easy for you to remember!

Risk and contingency is the part of Project Management process during developing project on which is concerned.

So lets get started:

RD process area explains three types of requirements, and they will be customer requirements, product requirements, and product component requirements.

The two very important thing about any project is to make sure that they address the needs pertinent to different phases of life cycle, and at the same time they take care if various attributes of the project like reliability, and responsiveness to name two).

When we say ‘Development of Requirement’ that actually means the following:

1. We are eliciting, analyzing, validating and communicating the customer needs so that we can get a prioritized list of customer requirements, which constitute an understanding of what will satisfy stakeholders!
2. We develop the requirements for the entire life cycle of the project
3. We define the functional and quality requirements for the customer / client.

The focus is on to identify not only the product level requirements but also the specific design level requirements too.

So the very first question that we should have answer of:

How would you identify and collect your stakeholder’s needs, expectations, and constraints?

While doing requirement gathering the following objectives should be kept in mind:

Requirements Elicitation should talk about:
1. The problem associated with Scope.
2. The problems regarding understanding the complete requirements
3. The problems associated with the change (volatility) of requirement.

There can be various ways where by you can identify and collect the requirements, few of them are as:

• Use cases
• Business case analysis
• Brainstorming

And from the artifacts perspective, please make sure you’ve the following: Use cases, presentations, documents, clarification logs, issue logs etc.

Now comes the other question, which will be

How do you transform the stakeholder’s need in to customer requirements?

Now once you have gathered the requirements or needs from customer, then next step is to come up with a business requirement document.

The steps involved during this stage should include the following:

• Consolidate the various inputs from the stakeholders
• Obtain the missing information
• Resolve the conflicts while documenting the recognized set of customer requirements.

Never forget that there is often more to customer requirements than just “how the product should function” and those requirements also need to be elicited.

For example, a customer might “Require” that your product should be installed in their own network environment and validated there before it goes to full production system.

On the other hand, another customer might “Require” that you validate the product in a test environment that fully matches their own environment – that puts a lot of requirements on your test environment and architecture needs.

The verification and validation of customer requirements might include what customer data has to be used – and this can impact data management strategy as well as your test environment and architecture. Or this can also happen where in customer might not be willing to provide “real” data due to security issues, and then you would have to come up with a way to create, load, and manage enough data for testing purposes.

This is quite significant from planning and strategy perspective. All these details should go in to BRD, FSD, and clarification logs.

One of the most important thing that you will know once we move ahead is:

1. You should create a requirements baseline that does not change unless there is an approved change request.
2. Investigate, Impact, and Review all proposed requirements changes with the relevant stakeholders (approved or rejected), and
3. Only make approved changes to the baselined requirements and appropriately update the traceability

 

Related articles

• CMMi – Project Planning – Identify Risk (seeingfuture.wordpress.com)
• CMMi – Project Planning – Estimation (seeingfuture.wordpress.com)
• CMMi – Project Planning (seeingfuture.wordpress.com)