1 / 69

GROUP MEMBERS

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

baby
Download Presentation

GROUP MEMBERS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GROUP MEMBERS MUHAMMAD USMAN KHAWAR BSEF08A008 MUHAMMAD TAYYAB ARIF BSEF08A009 MANAN AHMED BAJWA BSEF08A013 WAQAS DURRANI BSEF08M054

  2. Requirement Development

  3. 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

  4. CMMI & Specific goal I By: M.UsmanKhawar

  5. What is CMMI ? CMMI means Capability Maturity Model Integration Capability Maturity Model Integration (CMMI) models provide guidance to use when developing processes. CMMI models are not processes or process descriptions

  6. We Will Discuss Requirement Development

  7. Purpose / Objective The Purpose of Requirement Development is to produce and analyze: • Customer • Product • Product-components requirements.

  8. Activities of Requirement Development • 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.

  9. Types of Goals In requirement development we handle two types of goals • Specific Goals (SG) • Generic Goal (GG)

  10. 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.

  11. 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

  12. Specific and Generic Goals 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

  13. 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 .

  14. SPECIFIC GOAL I SG 1 Develop CUSTOMER Requirement

  15. 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

  16. 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.

  17. SUB-PRACTICES

  18. Sp1: Elicit needs Elicit 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

  19. 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

  20. Specific Goal II SG 2 Develop Product Requirement By: WAQAS DURRANI

  21. 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

  22. 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.

  23. SUB-PRACTICES

  24. Sp1: Establish Product and Product-Component requirements Establish and maintain product and product-component requirements, which are based on the customer requirements. .

  25. 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)

  26. Typical Work Products Derived requirements Product requirements Product-Component requirements

  27. Sub Practices • Develop 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.

  28. Sp2: Allocate Product Requirements Allocate the requirements for each product component. The Work Products Corresponding are : Requirement allocation sheets. Provisional requirement allocation. Design constraints.

  29. Sub Practices • Allocate requirements to functions. • Allocate requirements to product component. • Allocate design constraint to product component.

  30. Sp3: Identify Interface requirements Interfaces between function are identified. The Corresponding Work Productsare: • Interface requirements. The Corresponding Sub Practices are: • Identify interfaces • Develop the requirements for the identified interfaces

  31. Specific Goal III Analyze and Validate Requirements SG 3 By: Manan Ahmed Bajwa

  32. 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

  33. Description: • 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.

  34. SUB-PRACTICES

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

  36. Typical Work Products • Disposal concepts. • Use cases. • Timeline scenarios. • New requirements.

  37. Sub practices Define the environment the product will operate in, including boundaries and constraints. Review operational concepts and scenarios to refine and discover requirements.

  38. 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.

  39. Typical Work Products: • Functional architecture • Activity diagrams and use cases • Object –oriented analysis with services identified

  40. Sub Practices • Analyze and quantify functionality required by end users. • Analyze requirements to identify logical or functional partitions

  41. Sp3.3: Analyze requirements Analyze requirements to ensure that they are necessary and sufficient.

  42. Sub Practices: • Analyze requirements to determine whether they satisfy objectives of higher level requirements • Analyze requirements to ensure that they are complete and verifiable

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

  44. Typical work products: • Assessments of risks related to requirements

More Related