Requirements Summary

In this series we have provided an overview of requirements management, a description of the requirements management plan and its components, and some tips on how to negotiate for realistic time frames that include just enough time for the appropriate amount of requirements management.

Before we conclude, we need to make some important distinctions among terms that are sometimes used interchangeably. These distinctions are important, since they are not only invaluable for requirements planning, but also help clarify roles and responsibilities.

A Few Key Terms

The following are some terms which, when clarified, will aid in requirements management:

Project Management and Requirements Management.

Project management focuses on delivering the end product within constraints, such as time and cost. Project management includes the entire effort to produce the end result, of which requirements management is a part.

Requirements management focuses on defining the features, functions, capabilities, and characteristics of the end product, ensuring that they are defined completely and correctly.

Business Analysis and Requirements

Business analysis is the work of producing requirements. Business analysis can be performed in one project phase or many.

Requirements are the end result of completed business analysis work. Again, they describe the features, functions, characteristics, and capabilities of the end result of the project.

Projects, Products and Solutions.

Project. Endeavor or undertaking that produces a unique end product, service or result.

Product. We are using the term as it is defined in the PMBOK® to mean the end result of the project.

Solution. There can be both business and technical solutions. The business solution is defined by the sponsor and business subject matter experts. The technical solution, if there is a technical component to the project, is defined by the technical subject matter experts. After requirements have been defined, they are turned into a solution to the business problem that needs solving.

Life Cycles, Methodologies, Approaches

Life cycles describe the phases that take the project from its inception to its end. While it can be used to describe products (for example, the life cycle of a new pharmaceutical drug), concepts (life cycles of safety), or of living things (fleas and flowers), we are going to think of a life cycle of the project. Project life cycles are important, because they need to be managed.

Methodologies define how to get from the beginning to the end, usually through prescribed processes and templates. Frequently, phases and phase names are provided, as well as tasks to be completed within each project phase. The methodology may or may not prescribe multiple phases for completing business analysis.

Approaches are like “hybrids,” not quite life cycles and not quite methodologies. Examples are agile and Waterfall. Proponents of certain approaches often refer to “methods,” such as agile methods or SCRUM.

Summary of Requirements Management

Below are activities that need to be performed, either formally or informally, with a great amount of rigor or with practically none. They are closely aligned with the BABOK, version 2.0 but, since that document has not been published, we have avoided specific references to the Knowledge Areas. These are processes that need to be performed, regardless of the methodology or approach used.

Planning Business Analysis

These are the set of activities included as part of planning the business analysis phase, or phases, of a project. Whether planning for a new process, new or enhanced software, a new bridge or a feasibility study, deliverables and tasks must be identified, planning processes must be identified or created, roles and responsibilities must be agreed on, metrics established, and a plan for communications, formal or informal, must be created. Although not all project life cycles include a formal phase(s) for business analysis, the activities that comprise business analysis need to be taken into account.

As described in the series Overview, one of the key deliverables is the Requirements Management Plan, which is a set of documents that can be expected to change over time. The subsidiary plans that comprise the Requirements Management Plan are executed and updated at different points during business analysis.

Elicitation

This set of activities includes gathering stakeholder requirements and ensuring that their needs have been understood. Effective elicitation requires the ability to ask the right questions, listen to and synthesize responses, and record customer requirements. These skills are required for effective project management as well. Finally, elicitation tasks include determining elicitation techniques that are appropriate for the project.

Enterprise Analysis

In a nutshell, this process includes tasks to recommend, which projects to undertake by completing feasibility studies and cost benefit analyses. Once projects are undertaken, recommend the product scope.

Analysis

This set of activities includes the progressive elaboration of requirements from highest level to subsequently lower levels of detail, as more becomes known. Its purpose is to ensure that the business needs are truly understood and that requirements are defined completely and correctly. The requirements need to be elaborated in enough detail so that business clients are satisfied that their needs will be met, and the development team can create the end product or service.

Solution Assessment and Validation

This knowledge area describes how well the solution, or end product, solves the stated business problem and meets the approved requirements. This knowledge area includes activities related to making sure the end product matches the stated requirements, and is closely related to Quality Management.

Requirements Management and Communication

This set of activities involves the packaging of requirements to provide the level of documentation agreed upon in the Requirements Communication Plan (Business Analysis Planning and monitoring), taking into account the various audience preferences for format, level of detail, and frequency of communication. It also covers the handling of conflicts and issues. Finally, this knowledge area describes managing changes to the product and version. Because changes have to be managed across business analysis, it relates not only to Communications Management, but also to Integration Management.

Below is a matrix summarizing the interrelationship between the knowledge areas for Requirements Management, as shown in the BABOK, and project management, as framed in the PMBOK.

                 Integrating Requirements Management and Project Management

Final Words

In summation, requirements management, whether done formally or informally is a vital aspect of project management. Without the requirements management plan, the overall project management plan is incomplete. Taking the time to plan and manage requirements will lead to a better end product and increases the chances of having satisfied stakeholders.

In addition, if we revert to when requirements were not managed, we can expect to see the cost of projects and defect repair, as well as scope creep continue to increase. However, if we spend too much time on requirements management, we are at risk of creating a burdensome process that will delay the project. It is important, then, to apply an appropriate amount of requirements management rigor to our projects to ensure that we have:

• Thought about the approach we will take 
• Identified the business analysis deliverables
• Developed a requirements schedule
• Planned for requirements communications
• Clarified important roles and responsibilities
• Communicated our plan to our sponsor, ensuring an understanding of the requirements management plan and its importance

This care will help all stakeholders in planning their time and encourages their active participation on the project.

References
Ambler, S. (last updated March 3, 2007), Agile Modeling, retrieved on January 7, 2008, from http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm

Davis, A. Just enough Requirements Management Part 1, retrieved on January 7, 2008, from http://conferences.codegear.com/article/32301.

IEEE Standard 610,

1990,International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.

Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

Once again we have a mix of the latest part of a continuing series requirements management plus plenty of other new and interesting contributions about the business analysis world – what’s going on now and what to look for in the future – that are sure to give you something to thinks about. Plus we have an update about what’s new at the IIBA. And, of course, our bloggers are back, including one new one.

• I Don’t Have Time to Manage Requirements: My Project is Late Already! Part III. In this, the third in their series, Elizabeth and Richard Larson discuss the appropriate requirements management process for different projects; too much can be as bad as too little. 
• Creating Motivation through Discovery. Richard Lannon talks about the importance of motivating people. He says it’s all about asking the right questions, listening and understanding – and then taking the appropriate steps. 
• Will the First CBAPs Be a Credit to the Profession? Well Will You? Marcos Ferrer bills his blog as one of the world’s shortest blog. But he puts a very important question to all CBAPs. We hope you’ll answer him! 
• The Cost of Validation. New blogger, Jonathan Malkin takes a look at how much is invested in developing systems but often nothing to ensure the system works, yet, as he points out, Solution Assessment and Validation is an important area in BABOK.
• IIBA Launches Computer Based Testing of the CBAP Exam and a Letter from the President September 2008 are two important information pieces from The IIBA section of this site.
• Defining Roles in the BA Life Cycle. Terry Longo asks if a single BA can be skilled in all aspects of the solution life cycle. He thinks single BA ownership makes sense but finding the right individual can be tricky – but not impossible.

Also don’t forget to check out our webinars and the Business Analyst Times book shop. And let us know what you think about this edition of BA Times.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]