An Example of Different Kinds of Note Taking
The following example illustrates notes taken by two team members and shows how they are transformed into observations. Frequently notes contain information that affects more than one practice in one PA. As is usual, note-taking ability differs from one team member to the next. (In this particular example, this difference will not affect the outcome of the observations.)
Notes Taken by Team Member 1:
From Interview 1: Marketing works with the customer. They call in human factors specialists to help understand how the customer will use the system. The system engineers create system requirements, and the software engineers create software requirements.
From Interview 2: Although marketing works with the customer on our project, the system engineers also work with the customers and users. Prototypes are built, and the users are brought in to see if they can use them.
From Interview 3: On project 1, the system and software engineers review the customer requirements to create the system and software requirements and determine how the system will be used. On project 2, the software engineers deal directly with the customer and users. We have them review the way we think the system will be used. Project 3: The system engineer works with marketing to develop the system requirements. Marketing signs off on all system requirements and is involved in the detailed requirements Fagan inspections.
From the Project 1 Systems Requirements Document: Traceability matrix found to customer requirements, sign off includes customer and marketing.
Notes Taken by Team Member 2:
From Interview 1: Marketing works with the customer.
From Interview 2: System engineer creates requirements.
From Interview 3: Software engineer creates requirements.
Observation Statements Based on Notes
The following illustrates how mini-teams and assessment teams transform notes about strengths and weaknesses into observations keyed to practices in specific process areas. The examples involve two specific practices in the requirements management (Level 2) and requirements development (Level 3) process areas of the CMMI. Once completed, observations are placed on a PII worksheet.
1.0 Sample Observation Statements
For Requirements Development Process Area, Specific Practice (SP) 3.1 (Establish and maintain operational concepts and scenarios):
Observation RD 1: Marketing, systems engineering, and sometimes software engineering are responsible for defining how the systems will be used. On some projects, prototypes are created and human factors specialists are used. (Sources: Interviews 1, 2, and 4)
Observation RD 2: How systems will be used is found in system description or in requirements. (Sources: Project 1 System Description Doc., Projects 2 and 3 Requirements Doc. Section 4-9)
For Requirements Management Process Area, Specific Practice (SP) 1.1 (Develop an understanding with the requirements providers on the meaning of the requirements):
Observation RM 1: Marketing works with the customers. On some projects, marketing, system engineers, and software engineers work with the customers and users. (Sources: Interviews 1, 2, and 3)
Observation RM 2: Customer requirements are found in marketing specs (Sources: Projects 1, 2, and 3 and marketing spec)
2.0 Examples of Accurate and Inaccurate Observations Based on Notes
Accurate Observation RD1: Marketing, systems engineering, and sometimes software engineering are responsible for defining how the systems will be used and the operational scenarios. On some projects, prototypes are created.
Inaccurate Observation: Projects create prototypes to determine operational scenarios. Projects have traceability matrices. (Notes only indicate traceability matrix found for one project. The above statement is inaccurate because it implies a wider use of traceability matrices than what had been found in interviews and document review.)
3.0 Examples of Valid and Invalid Observations Based on the Same Notes
Valid Observation: The previous statement observation RD 1 was valid because all team members agreed that the previous statement was corroborated in three interviews.
Invalid Observation: The statement would not be valid if several team members didn’t have this information in their notes and had not remembered or heard what was said, or if interviews or documents did not corroborate that operational scenarios had been created.
4.0 Examples of Sufficient and Insufficient Observations Based on the Same Notes
Sufficient Observation: The observation RD 1 sufficiently covers the practices because it was heard from a broad representation of the organization.
Insufficient Observation: If only one interview and only one document had stated the preceding, the observation could have been found to be valid, but the practice would not be sufficiently covered because a broad focus of the organization is required.