• Save
Product Development At Intel 2008 09 30
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Product Development At Intel 2008 09 30

on

  • 4,875 views

I created this presenentation using pubic sources to explain how product development and product management are done at Intel. The audience were the management and employees of my company. My goal was ...

I created this presenentation using pubic sources to explain how product development and product management are done at Intel. The audience were the management and employees of my company. My goal was to educate the audience on the possible ways we could do product management and development. I\'ve included hyperlinks to all the sources.

Statistics

Views

Total Views
4,875
Views on SlideShare
4,857
Embed Views
18

Actions

Likes
14
Downloads
0
Comments
0

6 Embeds 18

http://www.linkedin.com 6
http://www.slideshare.net 5
https://www.linkedin.com 3
http://info.arteris.com 2
http://webcache.googleusercontent.com 1
http://www.lmodules.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Product Development and Product Management at Intel

Product Development At Intel 2008 09 30 Presentation Transcript

  • 1. Product Development and Product Management at Intel PUBLIC DOCUMENT Kurt Shuler September 11, 2008
  • 2. The purpose of this presentation is to describe how Intel defines products and relates them to strategy.
    • All sources for this document are public sources
    • The purpose of this document is to inform the reader how one company performs the product development and product management functions. Other companies vary in how they do this and may use different terminology. However, most product companies follow a phase gate requirements and product development process as described here.
    • To illustrate how strategy and requirements become products, we focus on the first two phases of the Intel Product Life Cycle: Exploration and Planning
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Planning Production Development Exploration
  • 3. How is this presentation organized? 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Production Development Planning 3-5 yr ~1 yr
  • 4. Contents
    • Linking Strategy and Products
    • Exploration Phase
    • Planning Phase
    • Keys to Success
    06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products Product Development and Product Management Defined IPLC and the Strategy Process Balance Strategy and Tactics with ZBB
  • 5. What is Product Development and Product Management?
    • Product Development is the term used to describe the complete process of bringing a new product or service to market. There are two parallel paths involved in the product development process: one involves the idea generation, product design, and detail engineering; the other involves market research and marketing analysis.
    • Companies typically see new product development as the first stage in generating and commercializing new products within the overall strategic process of product life cycle management used to maintain or grow their market share.
    • Product management is an organizational function within a company dealing with the planning or marketing of a product or products at all stages of the product lifecycle.
    • The product manager is responsible for the whole line of software requirements management, defining products and releases with all internal and external stakeholders involved.
    06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 6. The Intel Product Life Cycle (a.k.a. the “IPLC”) has milestones with clear and measurable entrance and exit criteria… PRODUCT DOCUMENTS & REVIEWS Ship Release Approval (SRA) Product Discontinuance Approval (PDA) ROADMAPS Market Segment Analysis (MSA) Product Strategy Document (PSD) Source: Intel Quality Systems Handbook, Dec 2003, p. 5-3. Public document. BUSINESS INPUTS MILESTONES/ APPROVAL MEETINGS Internal Product Roadmap External Product Roadmap Product Overview Proposal (POP) / “MRD” Product Requirements Document (PRD) Design Specs and SoW Program Implementation Plan (PIP) Technical Product Specification (TPS) Product Readiness Review (PRR) Product ion Qualification (PDQ) PDT Postmortem Full Qualification (FLQ) Implementation Plan Approval (IPA) Development Investment Approval (DIA) Concept Approval (CA) 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Planning Production Development Exploration 3-5 yr ~1 yr Linking Strategy and Products
  • 7. … but it is only a part of the complete strategy-to-product picture. Source: Intel Quality Systems Handbook, Dec 2003, p. 1-8. Public document. 06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr 3-5 yr ~1 yr Linking Strategy and Products
  • 8. The PLC is easy to adapt to iterative development techniques like Extreme Programming and other methods of Agile development. Source: Erik Simmons, Intel Corp., Presentation, “Lessons Learned in Large Scale Process Improvement”, . Page 27. Public document. 06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 9. Defining products is a part of the continuous strategic planning process. Source: Intel Quality Systems Handbook, Aug 2006, p. 11. Public document. SLRP = Documented Strategy and Market Segment Analysis (MSA) PLBP = Product Strategy Documents (PSD) and Roadmaps 06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 10. Strategy, markets and business requirements tightly link to products. Sources: Intel presentation by Rudy Hacker, “Quality as an Information Systems Enabler.” Public document. Intel Quality Systems Handbook, Aug 2006, p. 11. Public document. Strategic Planning Product Development Business Strategic Objectives Market Segment Analysis (MSA) Product Strategy Document (PSD) Product Line and Technology Feedback With SLRP: With PLBP: POPs (“MRDs”) PRDs 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Planning Production Development Exploration Planning Production Development Single Product Life Cycle 3-5 yr ~1 yr Linking Strategy and Products
  • 11. Intel balances Strategic and Tactical Decisions using the IPLC and Zero-Based Budgeting (ZBB). Market Strategy Product Life Cycle MSA From SLRP: From PLBP:     PSD Roadmaps Zero-Based Budgeting (ZBB) Strategic Decisions Tactical Decisions 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Planning Production Development Exploration Planning Production Development Single Product Life Cycle 3-5 yr ~1 yr Linking Strategy and Products
  • 12. The Market Segment Analysis (“MSA”) describes Intel’s beliefs and vision regarding a market segment.
    • The MSA is created in concert with Strategic Long Range Planning (SLRP)
    • Market Segment Analysis (MSA)
    • Purpose:
    • Describes the vision for the market segment over the longest possible time horizon
    • Defines market segment requirements
    • Provides a basis for one or more PSDs
    • Key Contents:
    • Market segment within a Total Available Market (TAM)
    • Specific user profiles and usage models
    • Large scale market segment trends (size, growth, price points, buying patterns, etc.)
    • Business opportunity potential by usage model
    • Strategies and gap analysis
    • Usage model metrics (start, end, etc.)
    • Technology Roadmap (performance, capabilities)
    • Timing
    • Prior to PSD development, feeds into SLRP
    06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 13. Product Strategy Documents (“PSD”) derive from the Market Segment Analysis (MSA) and describe Product Lines.
    • The PSD is created in concert with Product Line Business Planning (PLBP)
    • Product Strategy Document
    • Purpose:
    • Translates an MSA into product line families that a business unit decides to pursue
    • Key Contents:
    • Product line families covered by the PSD
      • Intel’s desired position relative to competition
      • Product line characteristics (capabilities, ASP targets, volume, customer wish list)
    • Competitive analysis (SWOT, roadmap position)
      • Competitive advantages and product differentiation
      • Relationship with existing Intel products
      • Supporting technologies (goals, compatibility, etc.)
    • Timing:
      • Prior to POP / MRD development, feeds into PLBP
    06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 14. Internal and External Roadmaps graphically depict the product lines required to meet the business requirements in the PSD. 06/06/09 , Page PUBLIC DOCUMENT 3-5 yr ~1 yr Linking Strategy and Products
  • 15. The Exploration Phase is the first phase in defining an individual product.
    • Linking Strategy and Products
    • Exploration Phase
    • Planning Phase
    • Keys to Success
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase Process & Deliverables People and Roles DIA Milestone Approval
  • 16. The goal of the Exploration Phase is to get to DIA (Development Investment Approval).
    • There is thought, research, analysis and argument to get to DIA!
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase PRODUCT DOCUMENTS & REVIEWS Ship Release Approval (SRA) Product Discontinuance Approval (PDA) Exploration Planning Production Development Planning Production Development Exploration ROADMAPS Market Segment Analysis (MSA) Product Strategy Document (PSD) BUSINESS INPUTS MILESTONES/ APPROVAL MEETINGS Internal Product Roadmap External Product Roadmap Design Specs and SoW Program Implementation Plan (PIP) Technical Product Specification (TPS) Product Readiness Review (PRR) Product ion Qualification (PDQ) PDT Postmortem Full Qualification (FLQ) Implementation Plan Approval (IPA) Development Investment Approval (DIA) Product Overview Proposal (POP) / “MRD” Product Requirements Document (PRD) Concept Approval (CA)
  • 17. The Product Overview Proposal (“POP”, a.k.a. “MRD”) describes an individual product.
    • The POP/MRD does NOT contain any mention of implementation possibilities. It describes the why , what and by when , not the how or by who.
    • Product Overview Proposal (POP, a.k.a. “MRD”)
    • Purpose:
    • Describes the product vision, market, capabilities, and business opportunity
    • Key Contents:
    • Product business plan
    • Intended users and usage models
    • Product description
    • Key features and high-level product requirements
    • Timing:
    • After Concept Approval (CA), approved prior to DIA
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 18. Concept Approval is required prior to starting a POP / MRD. An MRD is required prior to DIA. 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase PRODUCT DOCUMENTS & REVIEWS Ship Release Approval (SRA) Product Discontinuance Approval (PDA) Exploration Planning Production Development Planning Production Development Exploration ROADMAPS Market Segment Analysis (MSA) Product Strategy Document (PSD) BUSINESS INPUTS MILESTONES/ APPROVAL MEETINGS Internal Product Roadmap External Product Roadmap Design Specs and SoW Program Implementation Plan (PIP) Technical Product Specification (TPS) Product Readiness Review (PRR) Product ion Qualification (PDQ) PDT Postmortem Full Qualification (FLQ) Implementation Plan Approval (IPA) Development Investment Approval (DIA) Product Overview Proposal (POP) / “MRD” Product Requirements Document (PRD) Concept Approval (CA)
  • 19. Many people perform many activities to create the POP / MRD and get to DIA. Success requires constant negotiation! * At a minimum, the Requirements Team consists of Product Management / Marketing, Engineering and Finance 06/06/09 , Page PUBLIC DOCUMENT What is Happening? Who is Doing it? Research Marketing, Engineering Prototyping Engineering Planning Program Manager Feasibility Analysis Engineering Understand Intel Channels, SLRP, PLBP and initiatives Requirements Team* Develop Business Plan, product vision, market window, etc. Marketing, Finance Define customers, users and usage models Marketing Create Revenue Forecast and ROI Marketing, Finance Create the POP (MRD) document Requirements Team Perform a Technical Review on the POP Requirements Team and others Communicate POP contents to broader team Requirements Team Conduct DIA meeting Requirements Team, Marketing, Engineering, etc. Baseline the POP (i.e. put under change control) Program Manager Exploration Planning Production Development Exploration Phase
  • 20. The Requirements Team can be segmented into three separate parts.
    • Product Marketing Engineer / Product Manager (Owner)
    • Development Engineer
    • Finance
    • Human Factors Engineer
    • Program Management
    • Quality Assurance Engineer
    • Test Engineer
    • Information Engineer
    • Sales
    • Legal
    • Customer Support
    • Localization
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 21. The requirements core team is created at CA and its members have these duties.
    • Product Manager (Owner)
    • Owns POP / MRD creation
    • Gathers market research
    • Analyzes competition
    • Indentifies target customers, users and usage models
    • Establishes market windows and timing
    • Creates product roadmap
    • Creates value proposition
    • Establishes business case and market basis
    • Establishes priorities
    • Verifies POP / MRD with customers and users
    • Reviews and assimilates customer data
    • Creates revenue forecast
    • Determines target product cost
    • Indentifies distribution channels
    • Development Engineer
    • Helps write use cases and features with clarity
    • Helps validate use models and features with customers
    • Represents technology
    • Creates prototypes
    • Assists in comparative / competitive analysis
    • Determines technical and schedule feasibility
    • Estimates timeline
    • Understands related Intel initiatives and required technologies
    • Finance
    • ROI estimation
    • Program Management
    • Resource and schedule estimation
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 22. The requirements team active and information contributors have these duties.
    • Quality Assurance Engineer
    • Assists in execution of IPLC-related processes
    • Assists in identification of quality-related features
    • Available as an inspection moderator, reviewer and facilitator
    • Test Engineer
    • Evaluates mapping of features to use models
    • Evaluates testability of use models and features
    • Reviews features for clarity and quality
    • Provides design-for-test requirements
    • Information Engineer
    • Assists in the writing of the POP / MRD (edits, reviews)
    • Application Engineer
    • Assists in the writing of the POP / MRD (edits, reviews)
    • Sales
    • Provides data and input in defining key features
    • Provides input on priorities, risks, and feasibility
    • Customer Support
    • Indentifies key features based upon call volumes
    • Provides customer info for use cases, environments, and profiles
    • Legal
    • Reviews legal documents and consults on legal issues
    • Localization
    • Consults on language, cultural issues, product timing and legal issues
    Active Contributors Information Contributors 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 23. The POP (MRD) has an Introduction, Business Case, and Product Overview.
    • POP (“MRD”)
    • Introduction
    • Open Issues
    • Strategic Overview
    • Market Overview and Rationale
    • Product Objectives, Success Criteria and Financial Data
    • Customers, Users and Usage Models
    • Product Vision and Key Features
    Introduction Business Case Product Overview 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 24. The requirements team uses many data sources to create the POP (MRD).
    • POP (“MRD”)
    • Introduction
    • Open Issues
    • Strategic Overview
    • Market Overview and Rationale
    • Product Objectives, Success Criteria and Financial Data
    • Customers, Users and Usage Models
    • Product Vision and Key Features
    SLRP and PLBP MSA, PSD and Roadmaps Current Market Data Financial Data Customer Elicitation and Research Internal Sources of Features (CRs and support data) 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 25. Here is sample POP (MRD) content.
    • POP (“MRD”)
    • Introduction
      • Establishes scope of document. Defines terms and abbreviations. Names core requirements team and extended team members. Includes references to other documents.
    • Open Issues
      • Defines open issues, owners, and plans for closure.
    • Strategic Overview
        • Summarizes the rationale for the existence of this project based on the MSA, PSD and roadmaps. Describes the business opportunity and our industry positioning.
    • Market Overview and Rationale
          • Reviews target market segments and reasons for pursuing this product. Defines internal and external position, competitive products, distribution channels, and market risks.
    • Product Objectives, Success Criteria and Financial Data
          • Defines the product’s objectives with measurable success criteria. Defines economic factors, revenue forecast and ROI.
    • Customers, Users and Usage Models
          • Describes the problems the customer is trying to solve and how this product will provide the solution. Defines the environment and users fo the system and how they will interact.
    • Product Vision and Key Features
          • Contains the product vision statement and key features. A typical POP / MRD will have 7 to 10 key features with 3 to 5 characteristics per feature. Includes the marked or business rational for each feature.
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 26. The objective of the DIA milestone is to seek further funding for the program. There are three possible outcomes.
    • DIA Milestone Objective: Seek funding for the program to do further planning (the PRD).
    • Possible Outcomes:
    Program Terminated  Go back to the drawing board Re-do / reschedule  Get more info to support a decision Approved  Begin the Planning phase (the PRD) 06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 27. The team uses the DIA checklist to review and discuss these items.
    • Review and discuss:
    • Business justification for product
    • Current and projected target market segment size
    • Fit with strategic business goals (SLRP / PLBP)
    • Targeted customers and user profiles
    • Product usage models and mapping of user tasks to product features
    • Key product features, benefits and value proposition
    • Preliminary estimates of product cost and pricing
    • ROI data and completive analysis
    • Review and discuss (cont):
    • Product assumptions and risks
    • Alignment within product family roadmap in PSD
    • Preliminary estimation of needed resources and schedule
    • Relative importance compared to other products
    • Examine the detailed plan to achieve Implementation Plan Approval (IPA):
    • Membership of the expanded Requirements Team and PDT
    • Pre-IPA deliverables indentified, including updates to POP / MRD
    • Realistic dates established for PDT formation and IPA based on resources and known risks
    06/06/09 , Page PUBLIC DOCUMENT Exploration Planning Production Development Exploration Phase
  • 28. DIA approved? Start the Planning Phase, create the PRD and go for Implementation Plan Approval (IPA)!
    • Linking Strategy and Products
    • Exploration Phase
    • Planning Phase
    • Keys to Success
    06/06/09 , Page PUBLIC DOCUMENT Exploration Production Development Planning Exploration Phase Process & Deliverables People and Roles DIA Milestone Approval
  • 29. After Development Investment Approval, the next step is the Planning Phase. Planning 06/06/09 , Page PUBLIC DOCUMENT PRODUCT DOCUMENTS & REVIEWS Ship Release Approval (SRA) Product Discontinuance Approval (PDA) Exploration Planning Production Development Planning Production Development Exploration ROADMAPS Market Segment Analysis (MSA) Product Strategy Document (PSD) BUSINESS INPUTS MILESTONES/ APPROVAL MEETINGS Internal Product Roadmap External Product Roadmap Design Specs and SoW Program Implementation Plan (PIP) Technical Product Specification (TPS) Product Readiness Review (PRR) Product ion Qualification (PDQ) PDT Postmortem Full Qualification (FLQ) Implementation Plan Approval (IPA) Development Investment Approval (DIA) Product Overview Proposal (POP) / “MRD” Product Requirements Document (PRD) Concept Approval (CA) Planning Phase
  • 30. There are six major steps required to complete the Planning Phase and get to Implementation Plan Approval (IPA).
    • Enlarge the Requirements Team
    • Gather detailed requirements
    • Write the PRD
    • Perform a Formal Technical Review
    • Develop an IPA presentation
    • Schedule and hold the IPA meeting
    06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 31. Many people work together on the PRD to get to IPA. Engineering is the author of the PRD. * At a minimum, the Requirements Team consists of Product Management / Marketing, Engineering and Finance Success requires constant negotiation! 06/06/09 , Page PUBLIC DOCUMENT What is Happening? Who is Doing it? Continued Prototyping Engineering Detailed Requirements Specification Requirements Team* Update information in POP / MRD as required Requirements Team* Write the PRD Engineering (author assigned at DIA) Establish requirements baseline Requirements Team* Perform a Formal Technical Review on the PRD Requirements Team and others (Engineering leads this) Detailed Project Planning All, with guidance from Program Manager Conduct IPA meeting Requirements Team, Marketing, Engineering, etc. Baseline the PRD (i.e. put under change control) Program Manager Planning Phase
  • 32. Doing detailed requirements and planning creates predictable results.
    • Which is better???
    Ensure Feasibility Commit Predictable Results Commit Try to Make it Work Unpredictable Results 06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 33. The Product Requirements Document (PRD) describes an individual product in more detail than the POP / MRD. Engineering leads PRD creation.
    • The PRD does NOT contain any mention of implementation possibilities. It describes the why , what and by when , not the how or by who.
    • Product Requirements Document (PRD)
    • Purpose:
    • Describes the standard product feature set and the requirements in sufficient detail to enable product planning, design, development and test .
    • Key Contents:
    • Review of intended users and usage models (from POP / MRD)
    • Product description (from POP / MRD)
    • Prioritized product features and requirements, described in detail
    • Timing:
    • Early in Planning Phase, approved prior to IPA
    06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 34. The PRD can evolve from the POP / MRD as a single document or as a separate document.
    • The single document solution:
    • Eliminates redundancy between the POP / MRD and PRD
    • Can simplify document maintenance because changes need to be made in only one place
    • Using two documents:
    • Allows sensitive data in the POP / MRD to remain internal when sharing the PRD with customers
    • Creates two shorter documents rather than one long one
    • Forces some overlap between the POP / MRD and PRD
    06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 35. This is what the single document POP + PRD solution looks like.
    • POP (MRD) + PRD
    • Introduction
    • Open Issues
    • Strategic Overview
    • Market Overview and Rationale
    • Product Objectives, Success Criteria and Financial Data
    • Customers, Users and Usage Models
    • Product Vision and Key Features
    • Feature List and Design Constraints
    • Product definition, SKUs
    • Functional Requirements
    • Non-Functional Requirements (-ilities)
    • Product / Engineering Constraints
    • Documentation Requirements
    • Internationalization Requirements
    • Sales, Marketing and Support Requirements
    • Legal Issues
    Introduction Business Case Product Overview Product Requirements 06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 36. How much detail is enough?
    • Product stakeholders must have enough information to do their jobs
    • Details must come from data and decisions, not guesswork or opinions!
    • These requirements must drive the product development effort at all stages
    • Consider using other documents as “children” to the PRD to capture details
    • Use “child” documents for any feature that requires another level of detail to implement correctly (APIs, UIs, hardware interfaces, etc.)
    • Maintain traceability between the PRD and any other “child” documents!
    • Key point: It’s not how big a document is that matters, it’s how fast the reader can find what she is looking for.
    06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 37. Be sure to cover the following during the PRD approval process.
    • Mapping of Key Features to requirements
    • Mapping of Release Criteria to requirements
    • Summary of requirements feasibility
    • Requirements related risks
    • Adequacy of the detail in the PRD
    • Stability of product scope
    • Criteria for making tradeoffs between requirements
    06/06/09 , Page PUBLIC DOCUMENT Planning Phase
  • 38. Keys to Success
    • Linking Strategy and Products
    • Exploration Phase
    • Planning Phase
    • Keys to Success
    06/06/09 , Page PUBLIC DOCUMENT
  • 39. 1. Plan the requirements engineering effort.
    • Without adequate planning, you assure poor results
    • Create realistic effort estimates – most projects underestimate substantially
    • Define your dedicated cross-functional team for your product, up front
    • Make sure the participants are given adequate time and training to participate
    • Be very clear on roles, expectations, and priorities
    • Be sure the PRD has an owner and is tasked to deliver it
    06/06/09 , Page PUBLIC DOCUMENT
  • 40. 2. Save time by making sure you know the right things early.
    • Who is the customer?
    • Who is the end user?
    • Who are the other stakeholders?
    • What is the product’s real reason for being?
    • What are the Key Features the customer and end user want?
    • How will you measure product success?
    If you can’t find a customer or end user, try to find people who can accurately represent them. 06/06/09 , Page PUBLIC DOCUMENT
  • 41. 3. Be sure that strategic planning information is accurate and available.
    • Avoid wasting valuable time at the beginning of the project locating or updating this information
    • Avoid costly rework caused by incorrect data or assumptions
    • Provide and accurate Product Roadmap
    06/06/09 , Page PUBLIC DOCUMENT
  • 42. 4. Capture written Use Cases to:
    • Understand and document customer needs
    • Evaluate architectures (including use of “future cases”)
    • Enable analysis, prototyping and design (UI, functionality, product testing, etc.)
    • Help validate product requirements with customers and end users
    • Use Case ID
    • Summary
    • Preconditions
    • Basic Course of Events
    • Postconditions
    • Alternate Paths
    • Exception Paths
    • Extension Points
    • Business Rules
    • Author, Date, Version
    06/06/09 , Page PUBLIC DOCUMENT
  • 43. 5. Involve the customer early and often via:
    • Product definition, User Centered Design, and requirements elicitation
    • Expert user testing and validation during prototyping and design
    06/06/09 , Page PUBLIC DOCUMENT
  • 44. 6. Write a requirements document that:
    • Is owned, written, and reviewed by a cross-functional team
    • Is more than a “features list” and identifies major uses, markets that drive key features, quality factors, etc.
    • Traces high-level business concerns to requirements
    • Is well written and understandable
    • Is subjected to rigorous validation and internal reviews
    • Drives the development process at all stages
    Explicitly identify the owner of the PRD who is responsible for seeing that it gets completed 06/06/09 , Page PUBLIC DOCUMENT
  • 45. 7. Be certain the requirements are written well.
    • Requirements must be Complete, Correct, Feasible, Necessary, Prioritized, Unambiguous, Verifiable, Consistent and Traceable
    • Use formal review or inspection on requirements
    06/06/09 , Page PUBLIC DOCUMENT
  • 46. 8. Actively involve the team to:
    • Ensure that a clear and common vision is communicated to all stakeholders
    • Provide feedback from stakeholders on the requirements
    • Perform technical reviews on the requirements
    06/06/09 , Page PUBLIC DOCUMENT
  • 47. 9. Manage requirements changes to be sure that:
    • Your defined process is followed at all times
    • The record of review and approval of changes is maintained to the end of the project
    • Changes are propagates to designs, project plans, test plans, etc.
    • Changes are promptly communicated to all stakeholders
    Requirements changes are managed as changes to the product’s Plan of Record (POR). 06/06/09 , Page PUBLIC DOCUMENT
  • 48. Summary
    • The Intel PLC is a requirements-based product life cycle and incorporates requirements engineering as a central concept
    • The main IPLC vehicles for requirements are the MSA, PSD, POP / MRD and PRD documents
    • The level of detail of the POP / MRD must be adequate to support the DIA milestone and justify funding to do the PRD
    • The PRD must be detailed enough to drive the planning, design, development and test efforts
    • Requirements must be established by a collaborative cross-functional team based on stakeholders’ inputs
    • Requirements are reviewed with stakeholders at DIA and IPA and are managed throughout the development phase
    06/06/09 , Page PUBLIC DOCUMENT
  • 49. Sources
    • Intel Quality Systems Handbook, Dec 2003, p. 5-3. Public document. http:// sunsite.rediris.es/pub/mirror/intel/Quality/quality.pdf
    • Intel Quality Systems Handbook, Aug 2006, p. 11. Public document. ft p ://download. intel .com/design/ Quality /iqsh. p df
    • Erik Simmons, Intel Presentation, “Lessons Learned in Large Scale Process Improvement”, . Page 27. Public document. http:// cpd.ogi.edu/Seminars05/ ErikSimmons Seminar06-09-05.pdf
    • Anabel Gawer, MIT PhD Thesis, THE ORGANIZATION OF PLATFORM LEADERSHIP: AN EMPIRICAL INVESTIGATION OF INTEL’S MANAGEMENT PROCESSES AIMED AT FOSTERING COMPLEMENTARY INNOVATION BY THIRD PARTIES. http://dspace.mit.edu/handle/1721.1/8956
    • Rudy Hacker, Intel presentation, “Quality as an Information Systems Enabler.” Public document. www.azgita.gov/tech_news/2005/8_23_05/ Intel %20-%20 Rudy %20 Hacker -%20QA%20 Presentation %20-%20082305.ppt
    06/06/09 , Page PUBLIC DOCUMENT