Home > Articles > Process Improvement

📄 Contents

  1. 4.1 What You Will Learn in This Chapter
  2. 4.2 BOND Case Study Background
  3. 4.3 What Is a Gap Analysis and Why Is It Crucial for Agile Organizations?
  4. 4.4 Keys to Conducting a Gap Analysis for an Agile Organization
  5. 4.5 Example of "Potential Weakness" Against CMMI in an Agile Organization
  6. 4.6 Running Process Improvement like a Project
  7. 4.7 TWG Approach for Agile Organizations
  8. 4.8 Revisiting the Goal and Challenges on the Process Improvement Project
  9. 4.9 Alternative Practices and Tailored Agile TWG
  10. 4.10 Returning to the Peer Review Example
  11. 4.11 Tailored TWG Techniques and Lessons at BOND
  12. 4.12 Preparation Work for Running Agile TWGs
  13. 4.13 Packaging of Processes
  14. 4.14 An Agile Organizational Process Asset Structure
  15. 4.15 Process Asset Guidelines Used at BOND
  16. 4.16 Different Organizations with Different Process Asset Structures
  17. 4.17 Agile TWG Roles and Responsibilities
  18. 4.18 Effective Techniques to Run an Agile TWG
  19. 4.19 Separating the TWG Work from the Lead Offline Work
  20. 4.20 What Do You Do When You Find a Gap?
  21. 4.21 Answers to Common Questions When Running an Agile TWG
  22. 4.22 Do I Need a DAR Process?
  23. 4.23 Do I Need to Verify Everything I Develop?
  24. 4.24 Do I Need to Make Sure the Steps in My Processes Are in the Right Order?
  25. 4.25 Do I Need to Make Sure Process Descriptions Are Not Redundant?
  26. 4.26 Can Requirements Be Captured in an Email or PowerPoint Slides?
  27. 4.27 Do Requirements Need to Be Captured in Single "Shall Statements"?
  28. 4.28 Formalizing Informality
  29. 4.29 Summary
  30. 4.30 Summary: How Agile Helps CMMI
  • Print
  • + Share This
This chapter is from the book

4.26 Can Requirements Be Captured in an Email or PowerPoint Slides?

This might sound like a strange question, but it is not uncommon to hear it in Agile organizations that are just starting out with a CMMI process effort. First, the CMMI does not dictate the format requirements must be captured in, so on the surface, nothing directly prohibits email or Microsoft PowerPoint slides from being used to document requirements. However, when you look more closely at related expected practices and start asking a few more questions the CMMI expected practices will raise, a different picture often results.

For example, Requirements Management PA, SP 1.3 states:

  • Manage changes to the requirements as they evolve...

and SP 1.4 states:

  • Maintain ... traceability among the requirements and work products.

These expected practices lead to the following questions:

  • How do you manage changes to requirements as they evolve if your requirements are captured only in email or PowerPoint slides?
  • Are you going to update the PowerPoint presentation or email whenever changes are agreed to so the current set of accepted requirements is clear?

One of the reasons traceability is an expected practice is to ensure our testing addresses all requirements including any changes. For this reason I have always suggested to clients that, while you might not need a formal requirements management tool, you do need to have your requirements organized and managed in a way that supports the assignment of requirements identifiers to each requirement so that those identifiers can be used in a test document to ensure your testing is complete.

As you start to ask these questions that arise from using the CMMI to reason about your processes, most organizations, including those with an Agile culture, decide that email and presentation tools cannot adequately do this job. Some very small organizations, and organizations with products that have very stable requirements, might be able to survive with requirements communicated through these means, but most organizations quickly recognize the limitations of these mechanisms.

  • + Share This
  • 🔖 Save To Your Account