• Save
Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas
Upcoming SlideShare
Loading in...5
×
 

Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas

on

  • 5,722 views

"Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas" - Project World – Business Analyst World

"Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas" - Project World – Business Analyst World
- Vancouver 2007

Statistics

Views

Total Views
5,722
Views on SlideShare
5,712
Embed Views
10

Actions

Likes
8
Downloads
0
Comments
1

1 Embed 10

http://www.lmodules.com 10

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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…
  • good presentation and analyzing.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas Document Transcript

  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs quot;Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areasquot; Marko Wolf-Pany, P.Eng. Wolf- Project World – Business Analyst World Vancouver 2007 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 0 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf Pany, P.Eng.  Professional Engineer (P.Eng.), Ontario  B.Eng. Honours, Electrical Engineering, Carleton University  Software Engineering Institute (SEI) Software Capability Evaluation (SCE) Evaluator  CMMI / ITT Senior Manager, Accenture / Vancouver  Program / Project / Process Improvement Management Consultant  Director, Software Engineering Management  Program Manager -SEI CMM based Software Process Improvement (SPI) Programs  Member of the company’s Baldrige National Quality Program Steering Council  Director, Systems Engineering -Technical Authority responsible for all Information Technology (IT) Projects in Latin America  Project Manager / Technical Manager, Land (Army) Software Engineering Centre (LSEC), Department of National Defence (DND)  Member of the Software Engineering Process Group (SEPG) Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 1 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 1
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Agenda   Typical Problems During the Requirements Management - ReqM Software Life Cycle (SLC)  Specific Goal and Practices  Generic Goals and Practices  The Operational Framework  Requirements Development – RD  Specific Goals and Practices  CMMI® for Development, Version  Generic Goal and Practices 1.2 - August 2006  22 Process Areas – Alphabetical   Capability Levels vs. Maturity Levels Appendix A - The SEI Capability  Maturity Models 22 Process Areas – by Category  22 Process Areas – by Maturity Level  Four Categories of CMMI Process Areas Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 2 Management & Requirements Development Tuesday, November 6, 2007 Typical Problems During the Software Life Cycle (SLC) A Simple illustration Borrowed from: http://scott.yang.id.au/2003/08/software-development-life- http://scott.yang.id.au/2003/08/software-development-life- cycle/ Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 3 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 2
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Typical Problems During the Software Life Cycle (SLC) - 2/6   How the customers explained it How the Project Leader understood it Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 4 Management & Requirements Development Tuesday, November 6, 2007 Typical Problems During the Software Life Cycle (SLC) - 3/6   How the Analyst designed it How the Programmer wrote it Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 5 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 3
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Typical Problems During the Software Life Cycle (SLC) - 4/6   How the Business Consultant How the project was Documented described it Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 6 Management & Requirements Development Tuesday, November 6, 2007 Typical Problems During the Software Life Cycle (SLC) - 5/6   What operations installed How the customer was billed Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 7 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 4
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Typical Problems During the Software Life Cycle (SLC) - 6/6   How it was supported What the customer really needed Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 8 Management & Requirements Development Tuesday, November 6, 2007 The Operational Framework The operational framework describes the operational elements that govern organizational software development. The operational framework is shown in the figure below. Each component of the operational framework is described below. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 9 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 5
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs The Operational Framework – 2/3 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 10 Management & Requirements Development Tuesday, November 6, 2007 The Operational Framework – 3/3   Policies Standards   Organizational policies dictate the rules that Standards are the operational definitions of final govern operations. A policy statement usually is or interim organizational work products. used to enforce the use of organizational Standards constrain organizational processes by processes. A policy statement, therefore, setting acceptance criteria on the output of those constrains organizational processes by processes. identifying required or acceptable processes, or ways of doing work.  Processes  Procedures  A process is what happens in the organization to  Procedures are the step-by-step instructions for step-by- build products. Processes are constrained by implementing a process or a portion of a organizational policies and standards in that they process. Procedural information focuses on how must specify ways to develop products that to perform a certain task identified in the conform to organizational standards, in process. Processes are, therefore, implemented accordance with organizational policies. by specific procedures.  Training  Tools  Training addresses the knowledge and skills  Tools are any automated support needed to required to execute a process or use a implement a procedure. Tools, like training, are procedure. Training is used to support the use of used to support the use of processes and processes and procedures. procedures. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 11 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 6
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI® for Development, Version 1.2 “Improving processes for better products” CMU/SEI-2006-TR-008 CMU/SEI-2006-TR- ESC-TR-2006-008 ESC-TR-2006- August 2006 http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 12 Management & Requirements Development Tuesday, November 6, 2007 22 CMMI Process Areas Alphabetical Order By Acronym – 1/2  There are 22 process areas, presented here in alphabetical order by acronym:  Causal Analysis and Resolution (CAR)  Configuration Management (CM)  Decision Analysis and Resolution (DAR)  Integrated Project Management +IPPD (IPM+IPPD)[1] (IPM+IPPD)[1]  Measurement and Analysis (MA)  Organizational Innovation and Deployment (OID)  Organizational Process Definition +IPPD (OPD+IPPD)6  Organizational Process Focus (OPF)  Organizational Process Performance (OPP)  Organizational Training (OT)  [1] This process area has quot;+IPPDquot; after its name because it contains a goal and practices that are specific to IPPD. The material specific to IPPD is called an quot;IPPD addition.quot; All process areas with IPPD additions have quot;+IPPDquot; after their name. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 13 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 7
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs 22 CMMI Process Areas Alphabetical Order By Acronym – 2/2  Product Integration (PI)  Project Monitoring and Control (PMC)  Project Planning (PP)  Process and Product Quality Assurance (PPQA)  Quantitative Project Management (QPM)  Requirements Development (RD)  Requirements Management (REQM)  Risk Management (RSKM)  Supplier Agreement Management (SAM)  Technical Solution (TS)  Validation (VAL)  Verification (VER) Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 14 Management & Requirements Development Tuesday, November 6, 2007 CMMI - Capability Levels vs. Maturity Levels Continuous Representation Staged Representation Level Maturity Levels Capability Levels Level 0 Incomplete N/A Level 1 Performed Initial Level 2 Managed Managed Level 3 Defined Defined Level 4 Quantitatively Managed Quantitatively Managed Level 5 Optimizing Optimizing Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 15 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 8
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI Process Areas and Their Associated Categories and Maturity Levels – 1/2 Process Area Category Maturity Level Causal Analysis and Resolution Support 5 Configuration Management Support 2 Decision Analysis and Resolution Support 3 Integrated Project Management +IPPD Project Management 3 Measurement and Analysis Support 2 Organizational Innovation and Deployment Process Management 5 Organizational Process Definition +IPPD Process Management 3 Organizational Process Focus Process Management 3 Organizational Process Performance Process Management 4 Organizational Training Process Management 3 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 16 Management & Requirements Development Tuesday, November 6, 2007 CMMI Process Areas and Their Associated Categories and Maturity Levels – 2/2 Process Area Category Maturity Level Product Integration Engineering 3 Project Monitoring and Control Project Management 2 Project Planning Project Management 2 Process and Product Quality Assurance Support 2 Quantitative Project Management Project Management 4 Requirements Development Engineering 3 Requirements Management Engineering 2 Risk Management Project Management 3 Supplier Agreement Management Project Management 2 Technical Solution Engineering 3 Validation Engineering 3 Verification Engineering 3 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 17 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 9
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI Process Areas Process Management - Project Management Process Area Category Maturity Level Organizational Process Focus Process Management 3 Organizational Process Definition +IPPD Process Management 3 Organizational Training Process Management 3 Organizational Process Performance Process Management 4 Organizational Innovation and Deployment Process Management 5 Project Planning Project Management 2 Project Monitoring and Control Project Management 2 Supplier Agreement Management Project Management 2 Integrated Project Management +IPPD Project Management 3 Risk Management Project Management 3 Quantitative Project Management Project Management 4 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 18 Management & Requirements Development Tuesday, November 6, 2007 CMMI Process Areas – Engineering - Support Process Area Category Maturity Level Requirements Management Engineering 2 Requirements Development Engineering 3 Technical Solution Engineering 3 Product Integration Engineering 3 Validation Engineering 3 Verification Engineering 3 Measurement and Analysis Support 2 Process and Product Quality Assurance Support 2 Configuration Management Support 2 Decision Analysis and Resolution Support 3 Causal Analysis and Resolution Support 5 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 19 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 10
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI Process Areas – Maturity Level 2 Process Area Category Maturity Level Requirements Management Engineering 2 Project Planning Project 2 Management Project Monitoring and Control Project 2 Management Supplier Agreement Management Project 2 Management Measurement and Analysis Support 2 Process and Product Quality Assurance Support 2 Configuration Management Support 2 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 20 Management & Requirements Development Tuesday, November 6, 2007 CMMI Process Areas – Maturity Level 3 Process Area Category Maturity Level Requirements Development Engineering 3 Technical Solution Engineering 3 Product Integration Engineering 3 Validation Engineering 3 Verification Engineering 3 Organizational Process Focus Process Management 3 Organizational Process Definition +IPPD Process Management 3 Organizational Training Process Management 3 Integrated Project Management +IPPD Project Management 3 Risk Management Project Management 3 Decision Analysis and Resolution Support 3 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 21 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 11
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI Process Areas – Maturity Levels 4 & 5 Process Area Category Maturity Level Organizational Process Performance Process 4 Management Quantitative Project Management Project 4 Management Organizational Innovation and Process 5 Deployment Management Causal Analysis and Resolution Support 5 Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 22 Management & Requirements Development Tuesday, November 6, 2007 Four Categories of CMMI Process Areas Process areas can be grouped into four categories: Process Management Project Management Engineering Support Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 23 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 12
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Process Management Process Areas  Process Management process areas contain the cross-project activities cross- related to defining, planning, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes.  The Process Management process areas of CMMI are as follows:  Organizational Process Focus  Organizational Process Definition +IPPD[1] +IPPD[1]  Organizational Training  Organizational Process Performance  Organizational Innovation and Deployment  [1] Organizational Process Definition (OPD) has one goal that applies only when using CMMI with the IPPD group of additions. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 24 Management & Requirements Development Tuesday, November 6, 2007 Basic Process Management Process Areas jec ee n ’s tiv ds ob n io es d ss at Senior an roce aniz management Training for projects and p rg O support groups in standard OT process and assets Organization’s business Tra objectives inin gn eed Standard s process and other assets Standard process, work Project Management, environment standards, Support, and Engineering and other assets. OPF process areas OPD+IPPD Resources and coordination Improvement information (e.g., lessons learned, data, and artifacts) Process-improvement proposals; participation in defining, assessing, and deploying processes OPF = Organizational Process Focus OT = Organizational Training OPD+IPPD = Organizational Process Definition (with the IPPD addition) Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 25 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 13
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Advanced Process Management Process Areas Improvements Organization OID Co ata ove Cav d pr d st fro me sr iim m an m nt d piill s be ot ne ed Quality and process - f fit e performance objectives, measures, baselines, and models Quality and process - Project Management, performance objectives, measures, baselines, Support, and Engineering and models process areas Senior OPP Progress toward management achieving business objectives Co asur Process performance me om u e e and capability data mo s m n Ability to develop and deploy standard process Basic and other assets Process Management process areas OID = Organizational Innovation and Deployment OPP = Organizational Process Performance Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 26 Management & Requirements Development Tuesday, November 6, 2007 Project Management Process Areas  Project Management process areas cover the project management activities related to planning, monitoring, and controlling the project.  The Project Management process areas of CMMI are as follows:  Project Planning  Project Monitoring and Control  Supplier Agreement Management  Integrated Project Management +IPPD[1] +IPPD[1]  Risk Management  Quantitative Project Management  [1] Integrated Project Management (IPM) has one goal that applies only when using CMMI with the IPPD group of additions. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 27 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 14
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Basic Project Management Process Areas Status, issues, and results of process and Corrective action product evaluations; measures and analyses PMC Corrective action What to monitor Replan What to build Status, issues, PP What to do Engineering and Support and results of process areas Commitments reviews and monitoring Plans Measurement needs SAM Product component requirements, Supplier technical issues, completed product agreement components, and acceptance reviews and tests Supplier PMC = Project Monitoring and Control PP = Project Planning SAM = Supplier Agreement Management Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 28 Management & Requirements Development Tuesday, November 6, 2007 Advanced Project Management Process Areas Statistical management data selin ce e s, QPM n Risk exposure due to rma unstable processes Quantitative obj to statistically ectives, subprocesses obje ss perfo and tives, ba manage, pro composed, ject’s els and def ined process mod e Organization’s standard processes, Proc c s Identified risk work environment standards, RSKM and supporting assets Pro ject’ IPM+IPPD s co and rules IPPD ines mpo guidel Process Management Pr oj , an and ned process areas ec Risk taxonomies and sed t’s Pr ta rm g , a r parameters, risk da oj sh rfo in le an ec ar status, risk mitigation ce p e la n n o n s t d de ed Project’s defined per plans, and corrective p es s vis fo process and work fine io rm action L n environment an d pr ce Coordination, da oce ta commitments, and Product issues to resolve ss architecture for structuring Integrated teams for performing teams engineering and support processes Basic Project Management process areas Engineering and Support process areas IPM+IPPD = Integrated Project Management (with the IPPD addition) QPM = Quantitative Project Management RSKM = Risk Management Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 29 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 15
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Engineering Process Areas  Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. The Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering or mechanical engineering) can use them for process improvement.  The Engineering process areas also integrate the processes associated with different engineering disciplines into a single product development process, supporting a product-oriented process improvement strategy. Such a strategy product- targets essential business objectives rather than specific technical disciplines. This approach to processes effectively avoids the tendency toward an organizational “stovepipe” mentality.  The Engineering process areas apply to the development of any product or service in the development domain (e.g., software products, hardware products, services, or processes). Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 30 Management & Requirements Development Tuesday, November 6, 2007 Engineering Process Areas  The Engineering process areas of CMMI are as follows:  Requirements Development  Requirements Management  Technical Solution  Product Integration  Verification  Validation Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 31 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 16
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Engineering Process Areas Requirements REQM Product and product component requirements Product Alternative solutions Product components TS Customer RD PI Requirements Product components, work products, verification and validation reports PI = Product Integration VAL VER RD = Requirements Development REQM = Requirements Management TS = Technical Solution VAL = Validation VER = Verification Customer needs Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 32 Management & Requirements Development Tuesday, November 6, 2007 Support Process Areas  Support process areas cover the activities that support product development and maintenance.  The Support process areas address processes that are used in the context of performing other processes.  In general, the Support process areas address processes that are targeted toward the project and may address processes that apply more generally to the organization.  For example, Process and Product Quality Assurance can be used with all the process areas to provide an objective evaluation of the processes and work products described in all the process areas.  The Support process areas of CMMI are as follows:  Configuration Management  Process and Product Quality Assurance  Measurement and Analysis  Decision Analysis and Resolution  Causal Analysis and Resolution Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 33 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 17
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Basic Support Process Areas Quality and Measurements noncompliance and analyses issues PPQA MA All process areas Information Processes and needs work products, and standards, and procedures Configuration Baselines and items and audit reports change requests CM MA = Measurement and Analysis CM = Configuration Management PPQA = Process and Product Quality Assurance Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 34 Management & Requirements Development Tuesday, November 6, 2007 Advanced Support Process Areas CAR Process improvement proposals Defects and other problems All process areas Selected issues Formal evaluations DAR CAR = Causal Analysis and Resolution DAR = Decision Analysis and Resolution Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 35 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 18
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs “If You Don’t Know Where You’re Going, Any Road Will Do.” Chinese Proverb Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 36 Management & Requirements Development Tuesday, November 6, 2007 “If you don’t know where you are, A map won’t help.” Watts S. Humphrey “Father” of the capability maturity model (CMM) Software Engineering Institute Carnegie Mellon University Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 37 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 19
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Management - ReqM An Engineering Process Area at Maturity Level 2 Purpose The purpose of Requirements Management (ReqM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 38 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Manage Requirements Specific Goal and Practices  SG 1 - Manage Requirements  SP 1.1 - Obtain an Understanding of Requirements  SP 1.2 - Obtain Commitment to Requirements  SP 1.3 - Manage Requirements Changes  SP 1.4 - Maintain Bidirectional Traceability of Requirements  SP 1.5 - Identify Inconsistencies Between Project Work and Requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 39 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 20
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 1 - Manage Requirements  SG 1 - Manage Requirements  Requirements are managed and inconsistencies with project plans and work products are identified.  The project maintains a current and approved set of requirements over the life of the project by doing the following:  Managing all changes to the requirements  Maintaining the relationships among the requirements, the project plans, and the work products  Identifying inconsistencies among the requirements, the project plans, and the work products  Taking corrective action Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 40 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Manage Requirements SP 1.1 - Obtain an Understanding of Requirements  SP 1.1 - Obtain an Understanding of Requirements  Develop an understanding with the requirements providers on the meaning of the requirements.  Typical Work Products  1. Lists of criteria for distinguishing appropriate requirements providers  2. Criteria for evaluation and acceptance of requirements  3. Results of analyses against criteria  4. An agreed-to set of requirements agreed-  Examples of evaluation and acceptance criteria include the following:  Clearly and properly stated  Complete  Consistent with each other  Uniquely identified  Appropriate to implement  Verifiable (testable)  Traceable Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 41 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 21
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 1 - Manage Requirements SP 1.2 - Obtain Commitment to Requirements  SP 1.2 - Obtain Commitment to Requirements  Obtain commitment to the requirements from the project participants.  Typical Work Products  1. Requirements impact assessments  2. Documented commitments to requirements and requirements changes Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 42 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Manage Requirements SP 1.3 - Manage Requirements Changes  SP 1.3 - Manage Requirements Changes  Manage changes to the requirements as they evolve during the project.  Typical Work Products  1. Requirements status  2. Requirements database  3. Requirements decision database Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 43 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 22
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 1 - Manage Requirements SP 1.4 - Maintain Bidirectional Traceability of Requirements  SP 1.4 - Maintain Bidirectional Traceability of Requirements  Maintain bidirectional traceability among the requirements and work products.  Typical Work Products  1. Requirements traceability matrix  2. Requirements tracking system Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 44 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Manage Requirements SP 1.5 - Identify Inconsistencies Between Project Work and Requirements  SP 1.5 - Identify Inconsistencies Between Project Work and Requirements  Identify inconsistencies between the project plans and work products and the requirements.  Typical Work Products  1. Documentation of inconsistencies including sources, conditions, and rationale  2. Corrective actions Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 45 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 23
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Management - ReqM GG 2 - Institutionalize a Managed Process GG 3 - Institutionalize a Defined Process  GG 2 - Institutionalize a Managed Process  GP 2.1 - Establish an Organizational Policy  GP 2.2 - Plan the Process  GP 2.3 - Provide Resources  GP 2.4 - Assign Responsibility  GP 2.5 - Train People  GP 2.6 - Manage Configurations  GP 2.7 - Identify and Involve Relevant Stakeholders  GP 2.8 - Monitor and Control the Process  GP 2.9 - Objectively Evaluate Adherence  GP 2.10 - Review Status with Higher Level Management  GG 3 - Institutionalize a Defined Process  GP 3.1 - Establish a Defined Process  GP 3.2 - Collect Improvement Information Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 46 Management & Requirements Development Tuesday, November 6, 2007 Requirements Management – ReqM GG 2 - Institutionalize a Managed Process – 1/5  GP 2.1 - Establish an Organizational Policy  Establish and maintain an organizational policy for planning and performing the requirements management process.  This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.  GP 2.2 - Plan the Process  Establish and maintain the plan for performing the requirements management process.  This plan for performing the requirements management process can be part of (or referenced by) the project plan as described in the Project Planning process area. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 47 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 24
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Management – ReqM GG 2 - Institutionalize a Managed Process – 2/5  GP 2.3 - Provide Resources  Provide adequate resources for performing the requirements management process, developing the work products, and providing the services of the process.  Examples of resources provided include the following tools:  Requirements tracking tools  Traceability tools  GP 2.4 - Assign Responsibility  Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 48 Management & Requirements Development Tuesday, November 6, 2007 Requirements Management – ReqM GG 2 - Institutionalize a Managed Process – 3/5  GP 2.5 - Train People  Train the people performing or supporting the requirements management process as needed.  Examples of training topics include the following:  Application domain  Requirements definition, analysis, review, and management  Requirements management tools  Configuration management  Negotiation and conflict resolution  GP 2.6 - Manage Configurations  Place designated work products of the requirements management process under appropriate levels of control.  Examples of work products placed under control include the following:  Requirements  Requirements traceability matrix Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 49 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 25
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Management – ReqM GG 2 - Institutionalize a Managed Process – 4/5  GP 2.7 - Identify and Involve Relevant Stakeholders  Identify and involve the relevant stakeholders of the requirements management process as planned.  Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process.  Examples of activities for stakeholder involvement include the following:  Resolving issues on the understanding of the requirements  Assessing the impact of requirements changes  Communicating the bidirectional traceability  Identifying inconsistencies among project plans, work products, and requirements  GP 2.8 - Monitor and Control the Process  Monitor and control the requirements management process against the plan for performing the process and take appropriate corrective action.  Examples of measures and work products used in monitoring and controlling include the following:  Requirements volatility (percentage of requirements changed)  Schedule for coordination of requirements  Schedule for analysis of a proposed requirements change Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 50 Management & Requirements Development Tuesday, November 6, 2007 Requirements Management – ReqM GG 2 - Institutionalize a Managed Process – 5/5  GP 2.9 - Objectively Evaluate Adherence  Objectively evaluate adherence of the requirements management process against its process description, standards, and procedures, and address noncompliance.  Examples of activities reviewed include the following:  Managing requirements  Identifying inconsistencies among project plans, work products, and requirements  Examples of work products reviewed include the following:  Requirements  Requirements traceability matrix  GP 2.10 - Review Status with Higher Level Management  Review the activities, status, and results of the requirements management process with higher level management and resolve issues.  Proposed changes to commitments to be made external to the organization are reviewed with higher level management to ensure that all commitments can be accomplished. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 51 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 26
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Management – ReqM GG 3 Institutionalize a Defined Process  GG 3 - Institutionalize a Defined Process  The process is institutionalized as a defined process.  GP 3.1 - Establish a Defined Process  Establish and maintain the description of a defined requirements management process.  GP 3.2 - Collect Improvement Information  Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements management process to support the future use and improvement of the organization’s processes and process assets.  Examples of work products, measures, measurement results, and improvement information include the following:  Requirements traceability matrix  Number of unfunded requirements changes after baselining  Lessons learned in resolving ambiguous requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 52 Management & Requirements Development Tuesday, November 6, 2007 Requirements Development - RD An Engineering Process Area at Maturity Level 3 Purpose The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 53 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 27
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Requirements Development - RD Specific Goals and Practices  SG 1 Develop Customer Requirements  SP 1.1 Elicit Needs  SP 1.2 Develop the Customer Requirements  SG 2 Develop Product Requirements  SP 2.1 Establish Product and Product Component Requirements  SP 2.2 Allocate Product Component Requirements  SP 2.3 Identify Interface Requirements  SG 3 Analyze and Validate Requirements  SP 3.1 Establish Operational Concepts and Scenarios  SP 3.2 Establish a Definition of Required Functionality  SP 3.3 Analyze Requirements  SP 3.4 Analyze Requirements to Achieve Balance  SP 3.5 Validate Requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 54 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Develop Customer Requirements Specific Practices by Goal  SG 1 - Develop Customer Requirements  Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.  SP 1.1 - Elicit Needs  Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.  SP 1.2 - Develop the Customer Requirements  Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 55 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 28
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 1 - Develop Customer Requirements SP 1.1 - Elicit Needs Examples Of Techniques To Elicit Needs – 1/2  Examples of techniques to elicit needs include the following:  Technology demonstrations  Interface control working groups  Technical control working groups  Interim project reviews  Questionnaires, interviews, and operational scenarios obtained from end users  Operational walkthroughs and end-user task analysis end-  Prototypes and models  Brainstorming  Quality Function Deployment Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 56 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Develop Customer Requirements SP 1.1 - Elicit Needs Examples Of Techniques To Elicit Needs – 2/2  Examples of techniques to elicit needs include the following (cont.):  Market surveys  Beta testing  Extraction from sources such as documents, standards, or specifications  Observation of existing products, environments, and workflow patterns  Use cases  Business case analysis  Reverse engineering (for legacy products)  Customer satisfaction surveys Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 57 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 29
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 1 - Develop Customer Requirements - SP 1.1 - Elicit Needs Examples Of Sources Of Requirements That Might Not Be Identified By The Customer  Examples of sources of requirements that might not be identified by the customer include the following:  Business policies  Standards  Business environmental requirements (e.g., laboratories, testing and other facilities, and information technology infrastructure)  Technology  Legacy products or product components (reuse product components) Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 58 Management & Requirements Development Tuesday, November 6, 2007 SG 1 - Develop Customer Requirements SP 1.2 - Develop the Customer Requirements  SP 1.2 - Develop the Customer Requirements  Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.  Typical Work Products  1. Customer requirements  2. Customer constraints on the conduct of verification  3. Customer constraints on the conduct of validation Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 59 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 30
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 2 - Develop Product Requirements Specific Practices by Goal  SG 2 - Develop Product Requirements  Customer requirements are refined and elaborated to develop product and product component requirements.  SP 2.1 - Establish Product and Product Component Requirements  Establish and maintain product and product component requirements, which are based on the customer requirements.  SP 2.2 - Allocate Product Component Requirements  Allocate the requirements for each product component.  SP 2.3 - Identify Interface Requirements  Identify interface requirements. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 60 Management & Requirements Development Tuesday, November 6, 2007 SG 2 - Develop Product Requirements SP 2.1 - Establish Product and Product Component Requirements  SP 2.1 - Establish Product and Product Component Requirements  Establish and maintain product and product component requirements, which are based on the customer requirements.  Typical Work Products  1. Derived requirements  2. Product requirements  3. Product component requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 61 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 31
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 2 - Develop Product Requirements SP 2.2 - Allocate Product Component Requirements  SP 2.2 - Allocate Product Component Requirements  Allocate the requirements for each product component.  Typical Work Products  1. Requirement allocation sheets  2. Provisional requirement allocations  3. Design constraints  4. Derived requirements  5. Relationships among derived requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 62 Management & Requirements Development Tuesday, November 6, 2007 SG 2 - Develop Product Requirements SP 2.3 - Identify Interface Requirements  SP 2.3 - Identify Interface Requirements  Identify interface requirements.  Typical Work Products  1. Interface requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 63 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 32
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 3 - Analyze and Validate Requirements Specific Practices by Goal  SG 3 - Analyze and Validate Requirements  The requirements are analyzed and validated, and a definition of required functionality is developed.  SP 3.1 - Establish Operational Concepts and Scenarios  Establish and maintain operational concepts and associated scenarios.  SP 3.2 - Establish a Definition of Required Functionality  Establish and maintain a definition of required functionality.  SP 3.3 - Analyze Requirements  Analyze requirements to ensure that they are necessary and sufficient.  SP 3.4 - Analyze Requirements to Achieve Balance  Analyze requirements to balance stakeholder needs and constraints.  SP 3.5 - Validate Requirements  Validate requirements to ensure the resulting product will perform as intended in the user's environment. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 64 Management & Requirements Development Tuesday, November 6, 2007 SG 3 - Analyze and Validate Requirements SP 3.1 – Establish Operational Concepts and Scenarios  SP 3.1 - Establish Operational Concepts and Scenarios  Establish and maintain operational concepts and associated scenarios.  Typical Work Products  1. Operational concept  2. Product or product component installation, operational, maintenance, and support concepts  3. Disposal concepts  4. Use cases  5. Timeline scenarios  6. New requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 65 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 33
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 3 - Analyze and Validate Requirements SP 3.2 – Establish a Definition of Required Functionality  SP 3.2 - Establish a Definition of Required Functionality  Establish and maintain a definition of required functionality.  Typical Work Products  1. Functional architecture  2. Activity diagrams and use cases  3. Object-oriented analysis with services or methods identified Object- Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 66 Management & Requirements Development Tuesday, November 6, 2007 SG 3 - Analyze and Validate Requirements SP 3.3 - Analyze Requirements  SP 3.3 - Analyze Requirements  Analyze requirements to ensure that they are necessary and sufficient.  Typical Work Products  1. Requirements defects reports  2. Proposed requirements changes to resolve defects  3. Key requirements  4. Technical performance measures Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 67 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 34
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs SG 3 - Analyze and Validate Requirements SP 3.4 - Analyze Requirements to Achieve Balance  SP 3.4 - Analyze Requirements to Achieve Balance  Analyze requirements to balance stakeholder needs and constraints.  Typical Work Products  1. Assessment of risks related to requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 68 Management & Requirements Development Tuesday, November 6, 2007 SG 3 - Analyze and Validate Requirements SP 3.5 - Validate Requirements  SP 3.5 - Validate Requirements  Validate requirements to ensure the resulting product will perform as intended in the user's environment.  Examples of techniques used for requirements validation include the following:  Analysis  Simulations  Prototyping  Demonstrations  Typical Work Products  1. Record of analysis methods and results Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 69 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 35
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 1/7  GG 3 - Institutionalize a Defined Process  The process is institutionalized as a defined process.  GP 2.1 - Establish an Organizational Policy  GP 2.2 - Plan the Process  GP 2.3 - Provide Resources  GP 2.4 - Assign Responsibility  GP 2.5 - Train People  GP 2.6 - Manage Configurations  GP 2.7 - Identify and Involve Relevant Stakeholders  GP 2.8 - Monitor and Control the Process  GP 2.9 - Objectively Evaluate Adherence  GP 2.10 - Review Status with Higher Level Management  GP 3.1 - Establish a Defined Process  GP 3.2 - Collect Improvement Information Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 70 Management & Requirements Development Tuesday, November 6, 2007 GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 2/7  GP 2.1 - 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 requirements, and analyzing and validating those requirements.  GP 2.2 - Plan the Process  Establish and maintain the plan for performing the requirements development process.  This plan for performing the requirements development process can be part of (or referenced by) the project plan as described in the Project Planning process area. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 71 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 36
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 3/7  GP 2.3 - Provide Resources  Provide adequate resources for performing the requirements development process, developing the work products, and providing the services of the process.  Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product component requirements may be required.  Examples of other resources provided include the following tools:  Requirements specification tools  Simulators and modeling tools  Prototyping tools  Scenario definition and management tools  Requirements tracking tools  GP 2.4 - Assign Responsibility  Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 72 Management & Requirements Development Tuesday, November 6, 2007 GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 4/7  GP 2.5 - Train People  Train the people performing or supporting the requirements development process as needed.  Examples of training topics include the following:  Application domain  Requirements definition and analysis  Requirements elicitation  Requirements specification and modeling  Requirements tracking  GP 2.6 - Manage Configurations  Place designated work products of the requirements development process under appropriate levels of control.  Examples of work products placed under control include the following:  Customer requirements  Functional architecture  Product and product component requirements  Interface requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 73 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 37
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 5/7  GP 2.7 - Identify and Involve Relevant Stakeholders  Identify and involve the relevant stakeholders of the requirements development process as planned.  Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process.  Examples of activities for stakeholder involvement include the following:  Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces  Establishing operational concepts and scenarios  Assessing the adequacy of requirements  Establishing product and product component requirements  Assessing product cost, schedule, and risk  GP 2.8 - 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 of measures and work products used in monitoring and controlling include the following:  Cost, schedule, and effort expended for rework  Defect density of requirements specifications  Schedule for activities to develop a set of requirements Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 74 Management & Requirements Development Tuesday, November 6, 2007 GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 6/7  GP 2.9 - Objectively Evaluate Adherence  Objectively evaluate adherence of the requirements development process against its process description, standards, and procedures, and address noncompliance.  Examples of activities reviewed include the following:  Collecting stakeholder needs  Formulating product and product component requirements  Analyzing and validating product and product component requirements  Examples of work products reviewed include the following:  Product requirements  Product component requirements  Interface requirements  Functional architecture  GP 2.10 - Review Status with Higher Level Management  Review the activities, status, and results of the requirements development process with higher level management and resolve issues. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 75 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 38
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs GG 3 - Institutionalize a Defined Process Generic Practices by Goal – 7/7  GP 3.1 - Establish a Defined Process  Establish and maintain the description of a defined requirements development process.  GP 3.2 - Collect Improvement Information  Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.  Examples of work products, measures, measurement results, and improvement information include the following:  List of the requirements for a product that are found to be ambiguous  Number of requirements introduced at each phase of the project lifecycle  Lessons learned from the requirements allocation process Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 76 Management & Requirements Development Tuesday, November 6, 2007 Questions & Answers Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 77 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 39
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Appendix A  The SEI Capability Maturity Models  Capability Maturity Model® for Software (SW-CMM®) (SW -  CMMI-SE/SW/IPPD, Version 1.1, January 11, 2002 CMMI-  CMMI-SE/SW, Version 1.1, January 11, 2002 CMMI-  CMMI-SE/SW/IPPD/SS, Version 1.1, March 1, 2002 CMMI-  CMMI-SW, Version 1.1, August 19, 2002 CMMI-  CMMI Acquisition Module, Version 1.1, May 2005  Software Acquisition Capability Maturity Model®, (SA-CMM®), Version 1.03, (SA- March 2002  People Capability Maturity Model® (P-CMM®), Version 2, July 2001 (P-  The Personal Software Process SM (PSP SM), November 2000  Team Software Process SM (TSP SM) Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 78 Management & Requirements Development Tuesday, November 6, 2007 Capability Maturity Model® for Software (SW-CMM®) (SW -  The Capability Maturity Model for Software (also known as the CMM and SW -CMM) has been a model used by many organizations to SW- identify best practices useful in helping them increase the maturity of their processes  In 2000, the SW -CMM was upgraded to CMMI® (Capability Maturity SW- Model Integration)  The SEI no longer maintains the SW -CMM model, its associated SW- appraisal methods, or training materials, nor does the SEI offer SW - SW- CMM training Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 79 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 40
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI-SE/SW/IPPD V1.1 CMMI-  CMMI-SE/SW/IPPD V1.1 contains material that integrates systems CMMI- engineering, software engineering, and Integrated Product and Process Development (IPPD), and is an update to CMMI-SE/SW/IPPD V1.02 CMMI-  When compared to CMMI-SE/SW, CMMI-SE/SW/IPPD has the CMMI- CMMI- following differences:  two additional process areas covering IPPD: Organizational Environment for Integration (OEI) and Integrated Teaming (IT)  an enhanced version of the Integrated Project Management (IPM) process area that contains IPPD-related practices IPPD-  amplifications in some of the SE/SW process areas that address IPPD- IPPD- specific concerns Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 80 Management & Requirements Development Tuesday, November 6, 2007 CMMI-SE/SW V1.1 CMMI-  CMMI-SE/SW V1.1 contains material that integrates systems CMMI- engineering and software engineering, and is an update to CMMI- CMMI- SE/SW V1.02. Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 81 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 41
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI® V1.1 Model with Supplier Sourcing  The addition of supplier sourcing as a discipline included in CMMI models has resulted in the release of a CMMI model (CMMI-SE/SW/IPPD/SS, Version 1.1) (CMMI- that addresses all of the currently integrated disciplines:  Systems Engineering (SE)  Software Engineering (SW)  Integrated Product and Process Development (IPPD)  Supplier Sourcing  When compared to CMMI-SE/SW and CMMI-SE/SW/IPPD, CMMI- CMMI- CMMI- CMMI- SE/SW/IPPD/SS has the following differences:  One additional process area covering supplier sourcing best practices:  Integrated Supplier Management (ISM)  Amplifications in some SE/SW and SE/SW/IPPD process areas that address concerns specific to supplier sourcing  Informative material throughout the model, including chapters 1-6 and the appendices 1- Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 82 Management & Requirements Development Tuesday, November 6, 2007 CMMI® SW Version 1.1  This model, containing the software engineering discipline, is generally the same as the CMMI-SE/SW Version 1.1 model minus the systems CMMI- engineering amplifications  Although a vast majority of the material is the same, this model may better suit the needs of software-only organizations software- Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 83 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 42
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs CMMI® Acquisition Module (CMMI-AM) (CMMI-  The CMMI Steering Group and the Software Engineering Institute announce that the CMMI Acquisition Module (CMMI-AM) Version 1.0 (CMMI- has been released and is available for use by Department of Defense and federal government acquisition offices  Based on CMMI-SE/SW/IPPD/SS, the Acquisition Module is a CMMI- condensed form of CMMI designed to enable individual process improvement efforts within government program offices  CMMI-AM will also facilitate software acquisition process as now CMMI- required by law Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 84 Management & Requirements Development Tuesday, November 6, 2007 Software Acquisition - Capability Maturity Model (SA-CMM) (SA-  The SA-CMM is a capability maturity model for organizations that acquire or SA- procure software-intensive systems software-  It is used to assess their process maturity and help improve their software acquisition process  The SA-CMM provides acquisition organizations with guidance on how to gain SA- control of their software acquisition processes and helps them to  enhance understanding of software life-cycle activities in relation to system life- acquisitions  benchmark the maturity level of the organization/s acquisition process through assessment  improve the acquisition processes for software intensive systems  set senior management goals for improvement  enable prediction of potential acquisition process performance Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 85 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 43
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs People Capability Maturity Model® (P-CMM®) (P-  The People Capability Maturity Model (People CMM) is an organizational change model designed on the premise that improved workforce practices will not survive unless an organization's behaviour changes to support them  It was developed to guide systems and software organizations in attracting, motivating, and retaining talented technical staff  The practices in the model help an organization develop the workforce required to execute business strategies, characterize the maturity of workforce practices, set priorities for improving workforce capability, integrate improvements in process and workforce capability, and become an employer of choice  The primary objective of the People CMM is to improve the capability of the entire workforce  This can be defined as the level of knowledge, skills, and process abilities available for performing an organization's current and future business activities Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 86 Management & Requirements Development Tuesday, November 6, 2007 Personal Software Process (PSP)  The Personal Software Process (PSP) shows engineers how to  manage the quality of their projects  make commitments they can meet  improve estimating and planning  reduce defects in their products Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 87 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 44
  • Demystifying SEI CMMI Project World – Business Analyst Requirements Management & World - Vancouver - November 2007 Requirements Development PAs Team Software Process (TSP)  The Team Software Process (TSP), along with the Personal Software Process, helps the high-performance engineer to high-  ensure quality software products  create secure software products  improve process management in an organization Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 88 Management & Requirements Development Tuesday, November 6, 2007 quot;Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areasquot; The End Demystifying SEI CMMI Requirements Project World – Business Analyst World Marko Wolf-Pany, P.Eng. Wolf- Vancouver 2007 - 89 Management & Requirements Development Tuesday, November 6, 2007 Marko Wolf-Pany, P.Eng. 45