Category Archives: CMMi

CMMi | Project Delivery Approach, Mission Possible!

In this blog post we will discuss about the ‘Project Delivery Approach’, how we should make sure to deliver a project successfully to clients.

CMMi has its unique way of getting things done, and in Organizations, the smaller one on that…it becomes extremely difficult for people to understand and realize the importance of following process. So How do we do it?

Well, you got to make things easy for them. you have to make sure that it becomes part of their daily routine, without even making a change in what they have been doing. Believe me, in smaller Organization the work load a resource go through is massive, and hence asking them to fill in the CMMi docs, following deadlines, and deliver project on time…makes CMMi a absolutely No-No on their part.

Today we will talk about the Project Delivery Approach. This is a document which sums up the activity that every project should be doing, including what type of artifacts are required, and where to keep them! :)…yes, we’re going to unravel the mystery behind CMMi….Let’s get started!


This document describes the project and  summarizes the project delivery approach.  It is owned by the offshore Project Manager.  The objective is to describe the overall structure and control mechanisms used to govern the project at offshore.

Whether it is an Onsite-Offshore delivery model, or is completely Offshore delivery approach, this document takes care of every aspect involved in delivery

Once we are clear with the objective of the document,next comes is Client Overview.

Client Overview:

This is the place where you define a brief note about the client. The idea is to understand which client this document is going to be about, and what client business is.

Remember this document is not ONLY for the person who is going to make it, this makes round across the Organization in various departments! Hence every effort should be made to make sure it is easily understood, and communicate the language which is well understood with-in Organization.

In the next series we will go on and talk about remaining sections of PDA.

Leave a comment

Posted by on July 11, 2012 in CMMi


Tags: , ,

Technical Specification – CMMi

After having discussed in detail about the Requirement Development and Management, we are going to start with Technical Solution. But before we start with that, we would need to understand few terms:

What is Specification?

  • A software requirements specification (SRS) is a technical requirement document that describes in detail the externally visible characteristics of a software.
  • A SRS is not the same as a statement of user needs OR ‘Requirement docs’. The SRS says what the product will be.
  • The SRS can include Plain English text, structured text, diagrams, tables,rules, etc.
  • Parts of the SRS include:
    • Environmental requirements: OS, platform, interoperability, standards, etc.
    • Non-functional requirements: security, usability, efficiency, etc.
    • Feature specifications: precisely describe each feature
    • Use cases: examples of how a user accomplishes a goal by using one or more features

What is Design?

  • A design document explains the implementation that will satisfy the requirements of the SRS.
  • There are many aspects of the system that you need to design:
    • Division of the system into components
    • APIs and dependencies between components
    • Classes, attributes. operations, and relationships within each component
    • Data representation in the database or even files
    • Key algorithms and conditions that affect the overall design
  • Many notations are used in design
    • Plain English or structured English
    • Many types of UML diagrams
    • Pseudo-code, other diagrams as needed

What is the Difference Between SRS and Design?

  • The SRS describes precisely what the system will do.
    • It is based on customer needs
    • It defines stages for design and system testing
  • Customers should be able to review SRS and help validate it.
    • Validation of requirements means checking the written requirements against reality!
  • Design outlines how the system will work.
    • It is based on the SRS
    • It sets the stage for implementation as well as integration testing
  • Usually development team needs to review the design.

What Do They Have in Common?

  • Both SRS and Technical Design documents are technical documents that need to be precise.
    • At times the same notation is used for multiple purposes
  • Both need to be reviewed by stakeholders and defects must be corrected.

What Makes a Good Specification?

  • The 4-C’s of requirements states:
    • Clear: It should be understandable so that all stakeholders can participate in validation and developers know what to build and test
    • Concise: Short requirements are more understandable and maintainable. And, they often are more precise
    • Correct: Incorrect requirements will lead to major rework and reduced revenue.
    • Complete: Incomplete requirements also leads to major rework and last-minute schedule changes.
  • The specification should not bias the design or implementation.
    • Don’t get ahead of yourself, you will do design later, this is very important, and make sure you understand this!
    • Design details can make the SRS harder for non-technical stakeholders to understand
    • You may come up with better ideas for the design later but you should NEVER change the SRS unless your goals for the product change.
Leave a comment

Posted by on February 27, 2012 in CMMi


Tags: , , , , ,

Requirement Development – Iterative Model

What is Requirement Specification? What is Software Requirement? What is requirement Engineering?
Before we answer these questions on Requirement Management, and requirement Specifications, let’s talk about the following!
  1. A process is a description of how to accomplish a work activity
  2. A procedure is a set of steps for accomplishing the work tasks of a process
  3. A technique is the way an individual accomplishes a procedure

This is it that we have in Software development. How can you be a brilliant Software Developer! Ah, Amit, C’mon, you must have had lost your senses! We’re good developers / Testers, and Project managers!

Do you really think so, if you do, let me know how many items out of the mentioned below you follow while doing development!

  • Do you follow coding style guidelines
  • Do you follow code documentation guidelines
  • Do you really use debugging tools
  • Have you ever done your code being peer reviewed
  • Do you even know about testing strategies, procedures, and tools
  • Do you even know what periodic backups are
  • What isa version control system
  • Do you know how to use a defect tracking system
  • What isa design documentation tool
  • What is with requirements traceability tool
  • What do you know about project planning and tracking system

I bet most of you developing the code (and no offence here), would know at max about 2 or 3 of these. Reason, well primarily you don’t think that it is necessary OR it’s not your responsibility! Whatever is your reason, of you’re not following all the above you would surely be successful in your career BUT only in very short run!

Now here is a thing which we all should be aware of. Your project may follow the ‘Waterfall’ approach, BUT it is not necessary that during the requirement gathering phase too you have to follow the same model. You can always and in fact should always utilize various approaches for doing various activities of SDLC.

Here is how you should do Requirement Development using Iterative approach.

Requirement in an Iterative way!

Requirement in an Iterative way!

Now let’s talk about the Process flow for Requirement Development.

Why is it that my entire focus is on Requirement Analysis and not on other aspects of SDLC. Think about it! Majority of the time project failure is because of Improper Requirement Gathering—Yes, believe me, this is from experience!

Any available Software Projects workflow will have varied components, and requirement development is one of them.

Requirement Analysis Work Flow

Requirement Analysis Work Flow

Below mentioned is the COMPLETE detail on how Requirement should be done, following the requirement iteration flow!

Requirement Analysis - How

Requirement Analysis - How

Did I ever tell you what Requirement actually is?


Requirement is : The external (user) view of the system
                                                                              Which Includes
Functional requirements (what must the system do?)

                                                                              Which are

Prioritized as Essential, Desirable, Optional

and prioritized within categories, which also has

Quality attributes (how well must the system do it?)

                                                                              Which Includes
Safety, security, reliability, performance, throughput, capacities

Can also be prioritized
– e.g., security versus performance
• Usually apply to multiple (perhaps all) elements of the system
• Each operational requirement is tagged as “valid” or “design goal”

Simple isn’t it…Cheers! We will start with Project Planning Tomorrow!

1 Comment

Posted by on February 23, 2012 in CMMi


Tags: , , , , ,

Project Management Cycle – via pics!

Let’s learn Project Management easy way!

We have been talking a lot of stuff which was more ‘Textual’ in nature, and today let’s respect ‘A picture is more than thousand words’ – the phrase!

Now let’s see as to how each and every element is so very important for us. This way you’ll be able to align this with CMMi. And that is an essence to learning CMMi.

CMMi Supporting Process

CMMi - Supporting processes

By the way we have been discussing about processes! What exactly is Process?

There are three key factors in software engineering:

  1. People: numbers, skills, morale
  2. Process: This is a procedure for doing the work
  3. Technology: This is characterized by platform and domain

Good processes help people apply technology
Efficiently: without wasting time, effort, or
and Effectively: while obtaining the desired

What is a Process?

A process is a systematic way of doing things:

Systematic means any action which is teachable & repeatable

A model associated with a process specifies:

  • the work activities to be accomplished
  • interconnections among the work activities
  • the input work products on which work activities are based
  • the output work products produced by work activities
Waterfall Model

Waterfall Model


We will talk about these in detail, but today, please make sure to understand every aspect of each and every image attached here:

Engineering Processes

Engineering Processes


Leave a comment

Posted by on February 21, 2012 in CMMi


Tags: , , ,

Bi-Directional Traceability Matrix – CMMi

What is Requirement Tracebility Matrix?
Today Let’s talk about the requirements traceability matrix in a bit detail? Please realize that traceability matrix is among the few very important component associated with CMMi process areas.

What is Vertical and Horizontal Requirement Tracebility Matrix?

Requirements traceability is the ability to relate your requirements with one another and with aspects of other project artifacts. The primary goal for RTM is to ensure that all of the requirements identified by your stakeholders have been met and validated.

Building a System Out of its Requirements - Dy...

Image via Wikipedia

I personally feel that RTM is a great idea in quite a few situations.

Image via Wikipedia

There are two types of Traceability Matrix:

  • Vertical traceability is an aspect which identifies the origin of requirements (for example, customer needs) and follows these requirements as they evolve through your project artifacts, typically from requirements to design, to the source code with the help of which you implement the design, and then the test cases / test plan that validate the requirements.
  • Horizontal traceability identifies relationships among similar items, such as between requirements itself. This enables us to anticipate major problems, such as assuming two subteams implementing the same requirement in two different components. To understand this better,lets take a very easy example for creating a ‘Single-Sign-On’ functionality. the requirement here remains similar but you implement it across various platforms.Hence a traceability is often maintained bidirectionally: You should be able to trace from your requirements to your tests and from your tests back to your requirements.
In short and simple words if a requirement or any work product changes and it will affect some other work product, potentially affecting the value you deliver, then it’s probably something that should be part of requirement traceability matrix.
1 Comment

Posted by on February 16, 2012 in CMMi


Tags: , , , ,

How do they do it – Requirement Management – CMMi

All right, so this is it for learning, and now is the time for all of us to understand and see the implementation in real world.

The theme is based on ‘How do you do it’?

Let’s get started, believe me this is going to be a fun ride and the knowledge you all will have by the end of 10 days goes beyond your imagination!

Requirement Management:

<<This comes under Basic & Advanced Maturity>>

Whenever you sit for the requirement management, make sure to follow the below mentioned rules:

Problem you should solve – Requirements are managed and inconsistencies with project plans and work products are identified!

Objective should be – Your objective here is to explicitly ask your requirement owners about the meaning of each and every requirement they come up with!

Please describe how project personnel develop and understanding of the requirement? Do you also interact with requirement providers?

And the evidence you need to support this would be:

  • Statement of Work
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Use Cases
  • Minutes of meetings

    Good to provide

  • Acceptance criteria as part of SoW
  • Review and approval records of SoW
  • Requirement Reviews
  • Approval of SRS/Use cases

Problem you should solve – Obtain commitment to the requirements from the project participants!

Objective should be – You should surely have the documented evidence!

How do you obtain the commitments to the requirements from the resources associated with projects? Do you review / approve the requirements?

And the evidence you need to support this would be:

  • Project plan with resources allocated
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Requirements change request logs, with commitment (e.g., emails) and estimates of impact (e.g: functionality impact, interface impact, design impact, validation impact etc…).

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

How the changes to the requirements are managed? Whenever a change happens how do you manage that change? How do you assess the changes?

You should have the answer with following artefacts

  • Change Request
  • Evidence of Project Plan Update
  • System & Software Requirements Specification (SRS) / Revision History of SRS
  • Review records of SRS, Use Cases
  • Requirements Traceability Matrix (RTM).
  • Revisions to work products resulting from changed requirements.

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

Much of requirements management is change management. Tracking the status of project change requests is an eye-opener: how many of them are open and how many closed? How many requests were approved and how many rejected? How much effort was spent implementing each approved change?

You should have answer of all these, and the above mentioned document should give you proper answers on these.

How do you maintain the traceability between your requirements, plan, and work products?

You should have the answer with following artefacts

  • Requirements Traceability Matrix (RTM) / Both Horizontal & Vertical traceability
  • System & Software Requirements Specification (SRS)
  • Checklist associated with RTM

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit/Internal Audit reports containing issues related to traceability among requirements
  • RTM Review Records

How do you identify the inconsistency between the project plan and the requirements that you have identified?

You should have the answer with following artifacts

  • Review and approval records of project plan and its associated plans
  • Documentation which identifies that there is inconsistency between the project plan / work product / requirements.
  • CR against the requirements
  • CCB meeting which identifies that this change has a resource available.

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit / Internal audit reports
  • RTM Review Records

This should be good for now…will come up with another process area which will be RD tomorrow 🙂 Cheers!


Posted by on February 15, 2012 in CMMi


Tags: , , , , ,

CMMi – Requirement Development Part – II

With having answers of two very important questions on Requirement developments, lets get in to more detail, and understand how how to establish the product and product component requirements?

So my question to you would be:

What products do you deliver to customer? How do you establish these requirements?

The CMMi says “Establish and maintain product and product component requirements, which are based on the customer requirements”

Let’s understand as to what this mean, this is so critical that you may eventually end up getting surprised as to how detail a CMMi process can be when we talk about use of ‘specific’ words!

Now have a look at ‘Establish and maintain product and product component requirements”, now your question would be:

Well Amit, you know, Product Requirements are when we have documented the customer needs and I have performed the next step, interpreting and writing the technical requirements in three categories, which are mainly functional, non functional, interface…so what the hell is this product component requirement?

This is going to be a long post so bear with me, as this is the essence of entire project planning, if you master this aspect, we are good with any complexity of project!

Product Component:  In the CMMI Product Suite, a work product is a lower level component of the product. Product components are integrated to produce the product. There may be multiple levels of product components. I’m sure you all understand this, there is an example to follow this.

Product Component Requirements – The complete specification of a product component, including Look and feel, form, function, performance, and any other requirement.

Building a System Out of its Requirements - Dy...

Image via Wikipedia

Most of you must be having a smartphone…yeah, not like me, who is still with 1100 Nokia ;)…so, a smartphone as a product have got various product components, like the screen, the keypad, the battery, the AMOLED screen, well there are other too, but these one will do for this discussion!

Now each and every ‘Product component’ has got associated ‘Requirements’ which we call as ‘Product component requirements’

Now whenever you talk about a project, let’s take an example where in you have to come up with an eCommerce website, this website as a product, can be broken down in to one or more components. And then it is also possible to break down these components in to further sub-components.

I hope you have a clear understanding of product requirements and product component requirements..perfect!

Remember this is very important to have detailed quality requirement at this stage, the example can be:

  • Respond with in 1 second
  • System is available 99 % of time
  • Implement a change with no more than one staff week of effort
You need an SRS (System Requirement Specification) at this stage.

There is one important aspect in the RD process which talks about maintaining the ‘bidirectional traceability’, we will talk about that later.

Now very important question that comes up now is:

What components of the products are identified? How do you allocate the product requirement to components?

The intent of this practice is to make sure that the requirements for each product component (Remember AMOLED screens, battery etc.) are correctly specified (allocated).

You are still not in implementation mode, you’re only trying to make sure that requirements are properly allocated to their respective components.

So here at the product component level, you may have a mix of hardware requirements, software requirements, performance requirements, operational requirements, etc. The basic idea about requirement development at this stage is to allocate these different requirements to their respective components so you don’t implement a software requirement in to say operational or the other way round! 🙂

You need an RTM (Requirement Traceability Matrix) at this stage.


Posted by on February 11, 2012 in CMMi


Tags: , , , , ,