Building an effective requirements plan


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building an effective requirements plan

  1. 1. Building an effective requirements plan Discover the basics of requirements planning Skill Level: Introductory S. E. Slack ( Author and Business Transformation Consultant Freelance Writer 16 Sep 2008 There's no single, perfect way to build a requirements plan. This article looks at the key items business analysts should consider when managing projects. I have great respect for business analysts. They are the unsung heroes of many projects I've worked on, and they frequently wind up working late nights and long weekends that most people are never aware of. It's a thankless job in many ways. Successful business analysts are highly organized because they are constantly asked to produce documentation and other information at the drop of a hat. The best business analysts can quickly tell you what's broken, how to fix it, and how to test it. They do it with the help of a solid requirements plan that lets them easily see all those things and more. In my article, "Requirements planning: overlooked and undervalued" (see Resources), I defined requirements planning as the tedious piece of a project that involves eliciting, documenting, analyzing, communicating, tracking, validating, and verifying all the requirements that everyone thinks should be part of the project. While I told you a lot about what was involved in planning requirements, I didn't tell you exactly how to craft that final requirements plan. This article specifically focuses on how you can do that. Requirements plan basics Beyond the most obvious aspect of requirements planning (tracking what everyone thinks should be done), a requirements plan helps ensure that a project stays within Building an effective requirements plan © Copyright IBM Corporation 1994, 2008. All rights reserved. Page 1 of 8
  2. 2. developerWorks® scope, on budget, and on time. It also helps people understand the types of documentation and training materials that must be created, and it serves as a basis for software design and testing. A great requirements plan helps identify inconsistencies in a project, too. Some people refer to a requirements plan as a requirements management plan, by the way. I'll stick with requirements plan in this article, but the terms are interchangeable. A requirements plan typically contains at least the following basic elements: • An introduction, which explains the purpose of the plan (This can also be a simple scope statement.) • An overview of the players on the requirements management team • Requirements documentation • The approach that will be used for the project (for example, a phased approach) • Change control procedures • Exception procedures • A traceability approach to help determine where and how design is meeting requirements • An impact analysis overview, which should include instructions to help identify the implications of any proposed changes and any system elements that might be affected by the potential changes • The resources and tools to be used for requirements management • Who will maintain the plan and how it will be maintained • An appendix that includes any required forms that should be used The following sections explore several of these key elements to make sure you understand them and how they are used in a requirements plan. Some elements—such as the appendix—are self-explanatory, so I won't delve into them here. Change control and exception procedures Before I began working on process management projects and information technology (IT) deployments, I had no idea of the amount of detail involved in them. Frankly, I was bored out of my mind when I was assigned to attend a change control board meeting twice weekly on one project. My role was to follow all the approved changes so that I could then include them appropriately in end-user education and communications. Building an effective requirements plan Page 2 of 8 © Copyright IBM Corporation 1994, 2008. All rights reserved.
  3. 3. developerWorks® After a few weeks, however, I began to see the reasoning behind not just change control but exception procedures too. It was mind-boggling how often a subteam would make the determination that a change was required without consulting anyone else on the project team. They meant well, of course, but they would bring change requests to the meeting with no clue that the same change had already been explored and denied, for instance, two months earlier. Someone on the subteam just thought it was a good idea, so the team focused all its energy on that small change to the exclusion of its assigned work. Had the change control board not been in place, I can only imagine the chaos that would have overtaken the project. It's essentially a method for reining in mutinous workers who can't—or won't—see the big picture. That comment applies to exception requests, too—I've seen far too many requests that come from teams so caught up in their own issues that they have given no thought to how an exception for them might detrimentally impact another team or, worse, end users. It's critical, then, that the business analyst set in motion simple yet clear change control and exception procedures in the requirements plan. Get the appropriate executives to not only sign off on the procedures, but to enforce them. A mutiny is difficult to manage, but it's much more complicated when executives decide to ignore the procedures designed to suppress the rebellion. Give bottom-line facts to your executives (for example, "For every change we make, it will add XX to the final cost of the project.") so they will be more inclined to listen to their heads than hearts when a favorite employee begs to be exempt from the procedures. In your requirements plan, be clear about when the board will meet and how costs related to changes will be applied to the project. In addition, spell out the factors that the board will take into consideration as it makes a decision. Factors can be things such as: • Asking the requester to outline the expected benefit of the change • Determining how the change will affect the project schedule • Determining how the change will affect the project cost • Verifying how the change will affect work distribution on the project • Determining whether or not the change can be included in a later phase of the project • Any other items that you deem relevant to making a decision You must also be clear in your requirements plan about how accepted changes and requests will be communicated to the project team. There's nothing worse than being part of a project team and feeling like you have no clue about what's really happening on the project. Show the team the respect it deserves by creating a Building an effective requirements plan © Copyright IBM Corporation 1994, 2008. All rights reserved. Page 3 of 8
  4. 4. developerWorks® system to communicate changes after every change control board meeting. Use an intranet; send out a weekly memo, whatever. Just communicate! Requirements traceability In any project, you need the ability to relate primary requirements to one another, as well as to other project work products such as source code, diagrams, or documents. This process is called requirements traceability. For the most part, this particular aspect of a requirements plan is most useful in verifying that stakeholder requirements have been met and validated. Business analysts need to be careful with traceability: It can quickly turn to quicksand in a project due to all the potential for minutiae and nitpicking. Now that you've been duly warned, take a look at the two basic types of requirements traceability: vertical and horizontal. Vertical traceability shows the origin of items, then tracks the items as they evolve through requirements to design and testing. Horizontal traceability outlines the relationships among similar items (between requirements, for example). Both methods help you foresee problems, such as a requirement being tackled by multiple teams or a requirement that isn't being addressed at all. Traceability is—or should be—maintained in a bidirectional manner too. In other words, your requirements should be traceable to and from tests. Traceability is clearly important—knowing that multiple teams are tackling the same problem with competing designs, for example, can help eliminate redundancies and cost inefficiencies. And a traceability matrix is clearly needed when you have to comply with specific regulations. But if you've ever created a traceability matrix, you know there's an awful lot of work involved in it. A simpler approach to traceability is to assign a unique number to every requirement, then use tools that automate the tracking process by matching the unique number and referencing it during testing and through source code. Modeling tools such as IBM® Rational® RequisitePro® automate the process and manage all that tracing for you so you can print out matrices for anyone who just can't live without one. I don't mean to disparage traceability matrices, but face it: Requirements change, and on some projects they can change multiple times in a single day. Even if you're working on a process framework that mandates the creation and maintenance of traceability metadata, such as Capability Maturity Model Integration (CMMI), you can still use an automated tool that lets you get home in time for dinner a few times a week. If someone's pushing the matrix on you and no regulatory compliance issues exist for your project, push back. There's just no reason to make life difficult when you can take advantage of technology to trace requirements. Impact analysis Building an effective requirements plan Page 4 of 8 © Copyright IBM Corporation 1994, 2008. All rights reserved.
  5. 5. developerWorks® Knowing what's going to happen before it does is a benefit to any project manager. That's why a requirements plan needs to spell out the potential risks involved in the project. An impact analysis shows which parts of the organization are dependent upon the success of the project, which ones will be detrimentally impacted by failure of the project, and how the organization as a whole will function with or without the project's completion. In other words, what happens if the project gets yanked or is only partially completed? Things to include in the impact analysis might be (but are not limited to): • Hard costs linked to failure as well as to success, such as increase or loss of profits or anticipated overtime during project overruns • Soft costs, such as customer satisfaction numbers • Safety issues • Compliance issues Don't get nebulous with an impact report. Use straightforward facts and include numbers wherever possible. Executives are big on numbers. They're far more likely to understand and sign off on something they can quantify than something they have to think about how to explain to their peers. Requirements management tools Most business analysts don't want to deal with source code and difficult programming; they just want to manage the requirements quickly and easily. One of the simplest requirements management tools on the market is Rational RequisitePro. I don't say that because I'm writing for IBM; I say that because it's a tool that uses a document-based method that most business analysts will find familiar, yet it has database capabilities that can handle requirements traceability and impact analysis. If you're not familiar with this tool, see the Resources section for a link to more information. There are open source tools, too, that you might want to look into if you have strict budget considerations. These are typically developer-based, but if you have fairly decent technical skills you might be able to use open source tools quite well. Open source software is useful in many ways, but primarily because it's inexpensive and internal administrators can look at the source code quickly to determine what's wrong if something's not working correctly. Testmaster, for example, is an open source test case management tool that is compatible with Linux®, Apache, and PostgreSQL. It lets you gather requirements, manage testing procedures, study results, and handle defects or other issues that might arise. Building an effective requirements plan © Copyright IBM Corporation 1994, 2008. All rights reserved. Page 5 of 8
  6. 6. developerWorks® Summary In closing, keep in mind that a requirements plan should help you on a project, not make your life more difficult. If what you're doing seems terribly cumbersome and forces you to constantly rework data or manipulate it to get the answers you need, then the planning tool you're using is not the right one for you. Try different methods and tools until you find one that simplifies the work for you. Life's too short to let a requirements plan keep you up at night. Building an effective requirements plan Page 6 of 8 © Copyright IBM Corporation 1994, 2008. All rights reserved.
  7. 7. developerWorks® Resources Learn • Read "Requirements planning: overlooked and undervalued" (developerWorks, September 2008) to learn more about the requirements cycle and role of the business analyst in requirements planning. • Learn how to create and maintain requirements with Requirements Management Using IBM Rational RequisitePro (IBM Press, 2007) by Peter Zielczynski. • Learn more about Rational RequisitePro. • Check out The Rational Edge, the e-zine for the Rational community. • In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena. • Browse the technology bookstore for books on these and other technical topics. Get products and technologies • Download an impact analysis checklist. • Download a free trial version of Rational RequisitePro. • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational, Tivoli®, and WebSphere®. Discuss • Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture. • Check out developerWorks blogs and get involved in the developerWorks community. About the author S. E. Slack S.E. Slack is a writer and author with more than 10 technology books to her credit. She resides in Colorado with her family. Her latest title on the shelves is Windows Vista: Home Entertainment with Windows Media Center and Xbox 360 (Microsoft Press, 2007). Her next book will be PowerPoint 2007 Graphics and Animations Made Easy, to be published by McGraw-Hill. Building an effective requirements plan © Copyright IBM Corporation 1994, 2008. All rights reserved. Page 7 of 8
  8. 8. developerWorks® Trademarks IBM, the IBM logo,, DB2, developerWorks, Lotus, Rational, RequisitePro, Tivoli, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Building an effective requirements plan Page 8 of 8 © Copyright IBM Corporation 1994, 2008. All rights reserved.