GROUP MEMBERS

Post on 24-Feb-2016

45 views 0 download

Tags:

description

GROUP MEMBERS. MUHAMMAD USMAN KHAWAR BSEF08A008 MUHAMMAD TAYYAB ARIF BSEF08A009 MANAN AHMED BAJWA BSEF08A013 WAQAS DURRANI BSEF08M054. Requirement Development. CONTENTS. CMMI - PowerPoint PPT Presentation

transcript

GROUP MEMBERS

MUHAMMAD USMAN KHAWAR BSEF08A008

MUHAMMAD TAYYAB ARIF BSEF08A009

MANAN AHMED BAJWA BSEF08A013

WAQAS DURRANI BSEF08M054

Requirement Development

CONTENTS CMMI

REQUIREMENT DEVELOPMENT

SPECIFIC AND GENERIC GOALS

SG1: Develop CUSTOMER Requirement

SG2: Develop Product Requirement

SG3: Analyze and Validate Requirements

GG1: Institutionalize the defined Process

M.USMAN KHAWAR

By:

CMMI & Specific goal I

What is CMMI ?CMMI means Capability Maturity Model Integration

Capability Maturity Model Integration (CMMI) modelsprovide guidance to use when developing processes. CMMI models are not processes or process descriptions

We Will Discuss

Requirement Development

Purpose / Objective

The Purpose of Requirement Development is to produce and analyze:

Customer

Product

Product-components requirements.

• Elicitation , analysis , validation , communication and constraints .

• Collection and coordination of stakeholders needs

• Development of the life cycle of requirements of the product

• Establishment of the customer requirements

• Establishment of initial product and product component requirement.

Activities of Requirement Development

In requirement development we handle two types of goals

Specific Goals (SG) Generic Goal (GG)

Types of Goals

Specific Goals(SG)A specific goal is such a type of a goal that incorporates an action plan that outlines. How you will achieve the goal.

Performance measure that tells you how to evaluate the goal.

Generic Goals (GG) These are such types of goals which are required model components that apply to all process areas.E.G. Train the people Assign Responsibility Plan the Process

In requirement development phase we will deal with the following specific and generic goals:

SG1: Develop customer requirements

SG2: Develop product requirements

SG3: Analyze and validate requirements

GG3: Institutionalize a defined process

Specific and Generic Goals

Practice To Goal Relationship

Every goal we set is carried out by some practices that we have to follow to achieve the goal , we desire for . This intact a specific relationship between goals and the practices to be followed .

SPECIFIC GOAL ISG 1

Develop CUSTOMER Requirement

SG1: Develop customer requirements Stakeholder needs , expectations , constraints and interfaces are collected and translated into customer requirements.Practices to be followed :

Elicit Needs

Develop the customer requirements

Description

The needs of the stakeholders are the basis for determining customer requirements

An iterative process is used through out the life of the project to accomplish these objectives.

A surrogate is involved for customer to represent their needs and help to resolve conflicts.

SUB-PRACTICES

Sp1: Elicit needsElicit stakeholder needs , expectations , constraints and interfaces for all phases of the product lifecycle.Eliciting : identifying additional requirements, these are not provided by customer.Some examples of techniques to elicit needs

Brainstorming Market surveys Beta testing Usecases

Sp2: Develop the customer requirements

The various inputs from the customer should be gathered

The conflicts must be solved in documenting the recognized set of customer requirements.

The customer requirements will include needs , expectations and constraints with regards to verification and validation

Specific Goal IISG 2

By:

WAQAS DURRANI

Develop Product Requirement

Develop Product Requirements

Customer requirements are refined and elaborated to develop product and product –component requirements.

Practices to be followed : Establish product and product components

requirements Allocate product –component requirements Identify interface requirements

Description Customer requirements are also analyzed with the

development of the operational concept to derive precise sets of requirements called product and product-component requirements.

Derived requirements arise from constraints, consideration of issues, selected architecture and design.

The requirements are re-examined and the preferred product concept is refined.

SUB-PRACTICES

Sp1: Establish Product and Product-Component requirements

Establish and maintain product and product-component requirements, which are based on the customer requirements..

Description

Customer requirements may be expressed in the customer’s terms or non-technical description.

Product requirements are the expression of customer requirements in technical terms.

Example : Solid-sounding door(Non- technical) Might be mapped to size, weight, fit and resonant

frequencies ( technical)

Typical Work Products

Derived requirements

Product requirements

Product-Component requirements

Sub PracticesDevelop requirements in technical terms for product and

product-component design.

Derive requirements from design decisions.

Establish and maintain relationships between requirements for consideration during change management and requirements allocation.

Sp2: Allocate Product Requirements

Allocate the requirements for each product component. The Work Products Corresponding are :

Requirement allocation sheets. Provisional requirement allocation. Design constraints.

Sub Practices

Allocate requirements to functions.

Allocate requirements to product component.

Allocate design constraint to product component.

Sp3: Identify Interface requirementsInterfaces between function are identified. The Corresponding Work Products are:

Interface requirements.The Corresponding Sub Practices are:

Identify interfaces

Develop the requirements for the identified interfaces

Specific Goal IIIAnalyze and Validate

Requirements SG 3

By: Manan Ahmed

Bajwa

SG3: Analyze and validate requirements

The requirements are analyzed and validated and definition of the required functionality is developed.

Practices to be followed Establish operational concepts Establish a definition of required

functionality Analyze requirements Analyze requirements to achieve balance Validate requirements with comprehensive

method

Analysis provides us the needs of the stakeholders and the constraints of the product.

The objectives of the analysis are to determine candidate requirements for product that will satisfy stakeholders.

Description:

SUB-PRACTICES

SP3.1: Establish Operational Concepts and scenarios Establish and maintain operational concepts and

associated scenarios.

Typical Work Products

Disposal concepts. Use cases. Timeline scenarios. New requirements.

Sub practices

Define the environment the product will operate in, including boundaries and constraints.

Review operational concepts and scenarios to refine and discover requirements.

Sp3.2:Establish a definition of required functionality

Establish and maintain a definition of required functionality.

The definition of functionality includes actions, sequence , inputs or other information that communicates the manner in which the product will be used.

Typical Work Products:

Functional architecture

Activity diagrams and use cases

Object –oriented analysis with services identified

Sub Practices

Analyze and quantify functionality required by end users.

Analyze requirements to identify logical or functional partitions

Sp3.3: Analyze requirements

Analyze requirements to ensure that they are necessary and sufficient.

Analyze requirements to determine whether they satisfy objectives of higher level requirements

Analyze requirements to ensure that they are complete and verifiable

Sub Practices:

Sp 3.4 Analyze requirements to achieve balanceAnalyze requirements to balance stake holder needs and constraints..

Typical work products:

Assessments of risks related to requirements

Sub Practices:

Use proven models , simulations and prototyping to analyze the balance of stake holder needs and constraints.

Perform a risk assessment on the requirements and functional architectures.

SP3 + Generic Goal

By:

Muhammad Tayyab Arif

SP 3.5 : Validate requirements with comprehensive methods.

Validate requirements to ensure the resulting product will perform as intended in the user’s environments using multiple techniques as appropriate.

Typical work products:

Record of analysis methods and results.

Sub Practices:Analyze the requirements to determine the risk that might

be faced by the resulting product.

Explore the adequacy and completeness of requirements by developing product representations and by obtaining feed back about them from relevant stake holders.

Generic Goal IIIGG 3

Institutionalize the defined process

GG1: Institutionalize the defined process

The process is institutionalized as a defined Process.

Commitments to be formed(cop)When we are following generic goals we make some

commitments that we have to ensure at the end of the project so that customer gets satisfaction.

Establish an organizational policy

Establish and maintain an organizational policy for planning and performing the requirements development process.

This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component and validating those requirements

Establish a defined process

Establish and maintain the description of a defined requirements development process.

Plan the process

Establish and maintain a plan for performing the requirement development process

Provide resources Provide adequate resources for performing the requirements development process , developing the work products and providing the services of the process

Requirements specification tools Requirements tracking toolsPrototyping tools

Assign responsibility

Assign responsibility and authority for performing the process, developing the work products and providing the services of the requirements development process.

Monitor and control the process

Monitor and control the requirements development process against the plan for performing the process and take appropriate corrective action. Examples:

Cost , schedule and effort

Defect density of requirements specification

Review the activities ,status and result of the requirements development process with higher level management and resolve issues.

Review status with higher level management

HENCE REQUIREMENTS ARE DEVELOPED

Prepared By

Innocent Devils

There is an answer to every Question

ANY QUESTIONSANY QUESTIONS

ANY QUESTIONS

ANY QUESTIONS

ANY

QUES

TION

S