1 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association

Practical Report: CMMI Requirements Development (RD) and Requirements Management (REQM) Process Areas in an Agile Environment
Ahmed Mahdy Senior Software Engineer and Agile Coach, Raya Process Improvement Consultant aamahdys@gmail.com Marian Tadros Quality Expert and Consultant CMMI SEI-Certified Lead Appraiser Marian_tadros@hotmail.com

Abstract
The Capability Maturity Model Integration (CMMI) has been broadly used for benchmarking the organizations maturity and process capability throughout the world. CMMI model is very reach with its goals and practices that come from real projects experiences to support the organizations. However, some times the way it is implemented, consulted and may be appraised put it in the wrong shape and wrong perception. Changing the mindsets is a big challenge to reset the direction of CMMI implementation toward its right way. We believe this corrupted culture of CMMI implementation is the main reason behind attacking Agile as a methodology for CMMI implementation. The nature of their rapid market change can no longer accept heavyweight plans, requirements specification, change requests, contract negotiation, and other documentation. Moreover, the rapid change in information technology has increased the frustration more. Using lightweight processes that invite to customer collaboration over contract negotiation and working software over comprehensive documentation is one of the main characteristics of agile methodologies that have been adopted to tackle this challenge. Agile development methods and CMMI are often perceived to be at odds with each other. In fact, its not challenging to embrace both to dramatically improve business performance if we think out of the box by not expecting certain work products and when we look for the value and understand the purpose of CMMI practices rather than the evidences for the appraisal. This paper clarifies how Agile and CMMI work together in brief, and focuses on the implementation of Requirements Development and Management process areas in agile organizations based on a real and practical experience in Agile CMMI successful projects.

Why Agile and CMMI Together?

Based on a practical experience in many CMMI appraised companies, I can commit that agile mindset comes to save the purpose of CMMI by controlling the know-how to be driven by the value.

2 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association Key Principle Agile Values are sustainably valued if they are managedi through a Process Improvement Model which should be leading to a value-based implementation. Unfortunately, not all organizations understand and implement this key principle which directly represents and reflects the real intent of building this model [1], see figure 1.

[Figure 1] Relationship between Agile and CMMI from Implementation perspective, and how they are correlated

From this figure, my recommendation for embracing both by starting with establishing Agile mindset and ensure that the teams are ready to collaborate and focus on value, then apply CMMI model by achieving the intent of the model. However, it is not easy to achieve Agile CMMI in one project and one team (sometimes, I call it the managed valuable model) and remember that it is a very interesting challenge to seek the best improvement that adds to the business of your organization. And a further interest comes when your improvement cycle and history are managed through a Process Improvement Model such as CMMI.

Why not easy!?

It is not easy because we as industry used to follow best practices from other companies. Unfortunately, I see this word best practices as a marketing word more than a practice-based one, I prefer best practices with its context. Many of CMMI-accredited organizations used to take the examples, sub-practices, typical work products, and others exactly as mentioned in the model without understanding the value behind them!

3 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association Inside these organizations, after few days of implementation, we found them ignore practice by practice till we find the organization doing things regardless of what they are mentioning in their process documentation. To the Quality Managers of such organizations: You brought CMMI to your organization, and you are leading them to early failure beside unexpected bad morale in your teams! Thats why, it is not easy, and it needs your direct involvement with all users or stakeholders of every practice.

What Do We Mean By Agile CMMI Practice?

Agile CMMI Practice (ACP) is the practice (or way of doing activity) that achieves the Specific Practice (SP) in CMMI Model if and only if this practice achieves at least one of Agile Values and Principles [2] without violating any of them. Given that CMMI model defines the Alternative Practice as a practice that is a substitute for one or more generic or specific practices contained in CMMI models that achieves an equivalent effect toward satisfying the generic or specific goal associated with model practices. Alternative practices are not necessarily one-for-one replacements for the generic or specific practices.

In 7 Steps: How To Achieve Agile CMMI Practice?

1. Make sure of your senior management adoption, 2. Discuss the policy and process improvement project vision by reaching consensus with all stakeholders about the vision and goals of this project, 3. Specify the process areas in scope (i.e. what?), 4. Meet the users (actual implementers) of each practice in the selected process areas, 5. Explore ,with the implementers, all possible valuable ways of doing these practices which do not violate any of Agile Values and Principles, 6. Consolidate the output from users to reach the way of implementing the selected process areas and implicitly its practices (i.e. how?) 7. Inspect and adapt (i.e. process improvement cycle is always active)

Difference Between Convey And Preserve Information

Convey Information Why? Transfer information within your team members for alignment and having the same understanding of this information. It depends on the case you have, thats why Agile is human-centric, you choose the best way for conveying information in your case. And do not forget that one of Preserve Information Store information for further references, reviews, reuses and organization history. Also, it depends on the case. Usually, people prefer using different types of documentations project management tools, document management systems and we prefer using a

How?

4 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association Agile principles is the most efficient and system that supports your files configurations effective method of conveying such as version history details. information to and within a development team is face-to-face conversation*2+, however, if there are rigid constraints in achieving this way, move to the next communication way which invites interaction within team members. This encourages you to achieve the first step of SAMI (Sidky Agile Measurement Index)[6], it is a 5-step value-based roadmap to agility and designed to help guide organizations seeking to become more agile. Each of SAMIs 5 steps (Collaborative, Evolutionary, Integrated, Adaptive and Encompassing) aims to instill a new value in teams and organizations.[7] When? In every time the team members In all legal and formal communications. And communicate any information regarding when you want to ensure commitment and the project understanding of any information or responsibilities with either the customer or project team members.

Important Prerequisites Before Open The Process Areas

The remaining part of this paper mainly assumes that: you know and understand Agile scrum and XP practices, you understand REQM and RD Specific Practices, a project/task management tool is (or will be) used in your organization, you perform User Acceptance Testing (UAT) at the end of your release, if you do not apply Test Automation or Test Driven Development (TDD), there is a release stabilization to perform system and regression testing, user story, beside its being a valuable feature to the customer, it can be a non-functional requirement [4][5], and all requirements are represented in user stories.

Agile Requirements Development (RD) Process Area

The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
SG 1 Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

5 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association SP 1.1 Elicit Needs Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
Agile CMMI Practice (ACP) All customer meetings for gathering the requirements: Gathering of High level stories, External Chartering (sometimes called Customer/project Kickoff), Scope of Work, Release and Iteration (or Sprint) stories. SP 1.2 Develop the Customer Requirements Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. Agile CMMI Practice (ACP) All customer meetings for gathering the requirements: Gathering of High level stories, External Chartering (sometimes called Customer/project Kickoff), Scope of Work, Release and Iteration (or Sprint) stories [3]. 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. Agile CMMI Practice (ACP) Release and Iteration stories. SP 2.2 Allocate Product Component Requirements Allocate the requirements for each product component. Agile CMMI Practice (ACP) Release/Iteration Planning and Stories; by grouping the related stories for each product component. SP 2.3 Identify Interface Requirements Interfaces between functions (or between objects) are identified. Agile CMMI Practice (ACP) Project (iteration and release) stories. 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. Agile CMMI Practice (ACP) Project team discusses the user stories and its business acceptance tests (sometimes called Business Acceptance Criteria) with the business analyst and/or the customer directly (if business analyst only, the business analyst has to discuss and confirm these user stories and acceptance tests.

6 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association SP 3.2 Establish a Definition of Required Functionality Establish and maintain a definition of required functionality.
Agile CMMI Practice (ACP) After reaching consensus and alignment with the customer regarding the user stories (project features and non-functional requirements), communicate them to the team, and preserve them in a maintainable documentation. SP 3.3 Analyze Requirements Analyze requirements to ensure that they are necessary and sufficient. Agile CMMI Practice (ACP) Each user story includes business acceptance tests which are subjected to testing during the iteration, the comments of your customer in iteration demo if possible, and UAT feedback. These check-points of requirements sufficiency, significantly, decrease the uncertainty of the target value to the customer (i.e. reaching what the customer needs more than what the customer wants). From high level view: the kickoff meetings that include the main goals of the project support this practice. SP 3.4 Analyze Requirements to Achieve Balance Analyze requirements to balance stakeholder needs and constraints. Agile CMMI Practice (ACP) Each user story includes business acceptance tests which are subjected to testing during the iteration, the comments of your customer in iteration demo if possible, and UAT feedback. Meeting the stakeholders in kickoffs, demos, planning and status review meetings help you balance the needs and constraints. SP 3.5 Validate Requirements Validate requirements to ensure the resulting product will perform as intended in the user's environment. Agile CMMI Practice (ACP) Each user story includes business acceptance tests which are subjected to testing during the iteration, the comments of your customer in iteration demo if possible, and UAT feedback. Meeting the stakeholders in kickoffs, demos, planning and status review meetings help you validate your customer requirements (i.e. make sure that the requirements you are developing are your actual customer needs, and accordingly, the project meets your customer expectation. One of the four agile values [2] is Customer Collaboration over Contract Negotiation which means collaboration in understanding the requirements as well.

Agile Requirements Management (REQM) Process Area

The purpose of Requirements Management (REQM) is to manage the requirements of the projects products and product components and to identify inconsistencies between those requirements and the projects plans and work products.
SG 1 Manage Requirements

7 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association Requirements are managed and inconsistencies with project plans and work products are identified.
SP 1.1 Obtain an Understanding of Requirements Develop an understanding with the requirements providers on the meaning of the requirements. Agile CMMI Practice (ACP) All planning meetings (Project, Release, Iteration and even daily standup meetings), and we prefer that the business analyst role (or customer representative) should be involved in such meetings at least on iteration level; this ensures that the team members have the same understanding of requirements as the customer does. Moreover, iteration demos are key practice for understanding customer requirements. SP 1.2 Obtain Commitment to Requirements Obtain commitment to the requirements from the project participants. Agile CMMI Practice (ACP) According to our experience, we encourage agile practitioners to pay more attention to this practice. And as we used to say, do your way of taking commitment from both customer and project team members but make sure that this way is effective when the situation goes to any kind of conflict. One of the ways is using formal emails or even audio/video recording with your customer, and for project team members the way should be more smooth such as project/task management tool, standup meetings, iteration plansetc. SP 1.3 Manage Requirements Changes Manage changes to the requirements as they evolve during the project. Agile CMMI Practice (ACP) In your project/task management tools, differentiate between the first (original) requirements and other further changes even by labeling them. Try to make the view easy to be tracked (i.e. building a reportable system; for example, in anytime after one year of production in a project, you can know what the changes are, their status, their relationships with each other and with the first requirements)

SP 1.4 Maintain Bidirectional Traceability of Requirements Maintain bidirectional traceability among the requirements and work products.

Remember that the intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source. Requirements traceability can also cover the relationships to other entities such as intermediate and final work products, changes in design documentation, and test plans.[1]
Agile CMMI Practice (ACP)

8 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association Without this practice, most probably you will fail in managing your software projects especially medium/ large projects. Your requirements should be in one body with all other elements (test cases, architecture, tasksetc) see figure 2 , and make sure that user stories, architecture, business acceptance tests, test cases, technical tasks, bugs, and project plans are all traceable and connected. An easy way to do that is using any agile project/task management tool (there are a lot of open source and commercial products that will serve you).

SP 1.5 Identify Inconsistencies Between Project Work and Requirements Identify inconsistencies between the project plans and work products and the requirements. Agile CMMI Practice (ACP) You rarely find inconsistencies in one body see figure 2 below:

9 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association

Figure [2] Requirements Traceability Body

Conclusion
It is not only possible to embrace both agile and CMMI, but also it is easier and proven practically. The paper is not supposed to show your organizations best practices, the fore mentioned practices may not work in your organization. However, inspect and adapt to reach the most appropriate practice that adds the best possible value to your organization and your customer. Also, because agile mindset supports CMMI model intent, we found an easy implementation that we cannot work without.

10 Annual 10th CMMI Technology Conference and User Group | National Defense and Industrial Association
Bibliography [1] CMMI for Development Version 1.2, SEI- CMMI Product Team, August 2006 [2] Agile Manifesto, http://agilemanifesto.org , September 2010 [3] Sree Yellayi, Ahmed Mahdy, Application of Project Management areas from CMMI model in an Agile development th environment, NDIA 9 CMMI Technology and User Group, November 2009 [4] Wiegers, Karl E.. Software Requirements, Second Edition. Microsoft Press. ISBN 0-7356-1879-8, 3003 [5] Young, Ralph R. Effective Requirements Practices. Addison-Wesley. ISBN 978-0201709124, 2001 [6] Greg Smith, Ahmed Sidky, Becoming Agile: in an imperfect world. Manning, 2009 [7] ElMohanned Ahmed, Ahmed Sidky, "25 percent Ahead of Schedule just at step 2 of the SAMI" agile, pp.162-169, 2009 Agile Conference, 2009

i Managed: meaning that the values are maintained, measured, evaluated, improved and controlled.