RSS

CMMi – Requirement Development Part – III

11 Feb

So, what next…well lot of things still left in requirement development, and I guess you are enjoying every bit of this.

After coming up and deciding on every requirement, the components, and associating requirement with product component next in line for us is:

Now we need to analyze and validate our requirement, which give us variety of other question to answer:

How are Operational concepts and scenarios developed and maintained?

This would mean: During the requirement development phase, you should come up with various scenarios, all these scenarios should be augmented with quality attributes.

A scenario is typically a sequence of events that may occur during the use of the product or project, which is used to make needs of the stakeholders as ‘Explicit’. An operational concept for a product usually depends on both the design solution and the scenario.

You need to have FSD (‘Functional Specification Document’) at this stage.

Requirement Development - Engineering

Requirement Development - Engineering

The next question that arise at this level is:

How you define the functional requirements?

Definition of functionality, which is also referred to as “functional analysis,” is the description of what the product is intended to do. In simple terms what do you mean by Functional analysis, which will term as the “Required” functionality of the project / product. The definition of functionality can include the actions, sequence of those actions, inputs required for those actions, outputs, or other information that communicates the manner in which the product will be used.

You need to have FSD (‘Functional Specification Document’) at this stage. <<To be specific you should focus on IDD (Interface description document), and ICD (Interface Control document) which are part of your FSD>>>

Once we have functional specification document, next question we should ask from ourselves is:

How do you analyze whether the requirements are necessary and sufficient?

At this stage we analyze the requirement. We look at the design and talk about feasibility from requirement perspective, or which requirement affects feasibility.

You need to have Requirement Defect Report at this stage, supported by peer reviews comments, proposed requirement changes which will eventually have a change log.

Once we have identified and analyzed the requirement, this is the time for asking few more questions:

How do you analyze whether the requirements balances the user needs and constraints?

Make sure you’ve result of all the conversation, and proof of records showing analysis and negotiations of tradeoffs between requirement, cost, and schedule etc.

And now the last but not the least question:

How do you validate the requirement that your product will meet the user’s needs?

Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

At this stage be ready with Design docs, Simulators, Analysis etc.

Advertisements
 
1 Comment

Posted by on February 11, 2012 in Uncategorized

 

Tags: , , , , , ,

One response to “CMMi – Requirement Development Part – III

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: