Defining and Managing Requirements: a Framework for Project Success and Beyond Requirements Are Critical As Project Managers Try to Control Project Failure Rates

RG Perspective

Defining and Managing Requirements: A Framework for Project Success and Beyond Requirements Are Critical as Project Managers Try to Control Project Failure Rates

Conventional wisdom says you will never reach  Get at the true requirements your destination if you don’t know where you’re  Enforce tracking and management of going. However, all too often, that’s exactly how requirements throughout the life-cycle projects are implemented, most often as a result  Allow for a structured approach to the of the business and technical staff being unable to review and approval process communicate their needs to each other. This  Contribute to future projects so that communication gap usually occurs early in a valuable assets are not lost project, and the negative impacts manifest Each of these four critical success factors is themselves throughout the entire life-cycle. discussed next. Extensive re-work, scope creep, missed deadlines, low morale, and required features being dropped Critical Success Factor #1: Eliciting from product releases are just some of the issues the True Requirements that are costly and can be traced back to a The key to uncovering real requirements (and by fundamental lack of understanding of the business that we mean those that meet true needs) is needs. three-fold. You must have an efficient and For the project manager, unclear requirements are effective process to guide the way requirements the cause of mounting frustration throughout the are gathered and documented; your process must life cycle. Everything may seem fine – goals were include an architectural structure for capturing set, the team was built, all the necessary tracking requirements information so that all parties and management tools were in place, technology understand what they are trying to document; the was selected, requirements gathered and signed process must emphasize the use of models as a off, and the development staff was off and coding. mechanism to gather the information and Then it starts to become apparent everything communicate with all stakeholders – the sponsor, wasn’t fine after all. Faced with unclear the subject matter experts, and the developers. requirements, a development staff has two The process you follow should provide a solid options; either go back to the business and gain a foundation for gathering, documenting, and better understanding of its needs, or implement maintaining requirements, and should eliminate best-guess. These “false starts” are time- the communication gap between IT and the consuming for both staffs. Requirements may business. This can best be achieved, we feel, by also be uncovered that result in a significant re- using communication tools and techniques that evaluation of work effort (usually more, not less). both IT and the business understand, including Implementing best-guess will post-pone the issue visual models. These models, while detailing until later in the life-cycle; at user acceptance complex business processes and system behavior, testing it will become apparent to the business are not themselves complex to understand or that they are not being delivered what they paid create; thus the business is as comfortable for. Obviously, these are both situations the participating in their creation and review as is the project manager will want to avoid. IT staff. So what can be done? To prevent risk of failure, The emphasis on using models to elicit the project manager should incorporate practices requirements is in contrast to processes and tools that: that would have you build requirements by extracting text statements from documents. It is true that some requirements – particularly initial

1 Defining and Managing Requirements business objectives – lend themselves to text Critical Success Factor #3: statements. And text statements are also a good Structuring the Review Process way to capture operational requirements such as Review and approval of requirements can be the number of users that must be supported, or cumbersome and difficult to control. To be the necessary levels of security. successful, the project manager must be able to But process requirements, functional make review assignments to users or groups of requirements, user interaction requirements, and users and track comments that have been made. information requirements can best be understood It may seem obvious, but performing review using models. It might take several pages of text cycles via the web clearly has advantages over to describe the process of, say, taking an order. paper-based approaches. Your approach should Even then, you risk missing some key business include sharing and review of the information via rule or forgetting to document the necessity for the web. In that way, you can support any using a particular piece of data. For these kinds of number of reviewers in any number of locations. requirements, a visual approach is preferable to a Critical Success Factor #4: Moving written one. If you’ve ever been part of a building Beyond the Project – Reuse project and reviewed architectural drawings, you’ll know exactly what we mean when we say that Once a project is complete – that is the visual models are superior to text descriptions. requirements have been realized – then what? Typically, there’s some kind of documentation, but Critical Success Factor #2: Tracking that’s it. But if your process has reuse as one of and Managing Requirements its embedded disciplines, you can reap many Once you’ve gathered requirements, you need a advantages beyond the project close date. In process for tracking them and managing changes this way, your process can provide support for to them as they go through the design and continuous business improvement – not just one development phases of the life cycle. It’s a given project at a time. that there will be changes over the life of a Reuse of project artifacts can serve multiple goals. project, especially for complex or lengthy projects; The most obvious is that the requirements why not plan for them? The process you follow artifacts serve as documentation of the delivered should incorporate techniques to meet this goal. functionality. If an enhancement is requested, the First, you must be able to track the status of each requirements artifacts can be used to perform requirement. Is it approved, or only under impact analysis and to judge the appropriateness, review? Second, you must be able to trace the cost, and complexity of implementing the request. requirements from the origination through to their The second goal is to provide a jump-start to development. What was the business objective subsequent projects. For example, the that caused this requirement to be stated? How deliverables generated from understanding and will this requirement be realized? Third, you must modeling the claims process can apply to other know the impact of a proposed change. If this projects that touch the claims area. Finally, the change is accepted, what other requirements will models developed for a project can become input be affected and do these also need to change? to developing an architecture of information that Finally, you must know the history of requirements can be shared enterprise-wide. changes. How was this requirement initially stated, when did it change and why? To fulfill these four important critical success factors, you need two things: first, a defined

2 Defining and Managing Requirements process for the requirements lifecycle; second, a Understanding the business process provides a requirements definition and management tool (or context for all other project work. It can help set of tools) to make the process practical. discover business policy and business rules that may be appropriate for a rules engine. It also Let’s talk about the process first. uncovers “process rules”, that is, those rules that A Defined Process for the Requirements Life outline when things should occur and in what Cycle order. Finally, business process understanding There are many methodologies out there, yet helps you identify the pain points and the most are missing some crucial component: they opportunity areas that a technical solution could aren’t model-based, or they don’t address the address. critical task of managing requirements throughout (I) Identify Critical Requirements. the life cycle, or they don’t include a mechanism Follow a systematic approach to identifying the for the review and approval process. Look for a requirements that the business deems important. comprehensive, complete, repeatable, and Use repository-based tools to capture the teachable approach that can be used for many requirements and develop the architecture types of projects, including ones focused on: (sometimes called the “meta model”) so that users  Building and managing enterprise of the process know exactly what needs to be architectures documented, where it needs to be documented,  Understanding and improving business and how it needs to be documented. The meta processes model provides a template structure that makes it  Changing organizations easier to gather information, to build relationships  Developing new systems or enhancing among the information, and to produce project existing ones documentation based on the information.  Exploring new technologies (N) Navigate the Deliverables.  Developing new product offerings Architect the business analysis and requirements There are four basic principles of a good approach deliverables so that they can be used in many that can be summarized by the acronym “L-I-N-K”. ways through the life of a project and beyond. Following these principles leads to requirements For example, use cases and data models can be that link the business side of the house with the IT transferred to an object-oriented development tool side of the house. to jump-start the design effort, or they can be (L) Lead with Business Understanding. transformed into testing scripts. The business Never launch a requirements effort without first policy and business rules identified can be understanding the business process that the separated from other deliverables and used in solution will be supporting. The first goal is to development of a rules engine. The process flows prevent the wrong solution from being developed can be exported to the business process and to ensure the solution meets real needs. management language (BPML) and used for Even in what seems at first to be a system business process management efforts, or they can development project, it’s possible that what really help drive workflow rules. System requirements needs to be changed is the process itself, or that a can generate user acceptance test scripts. simple technology change such as a scanning capability can bring significant improvement.

3 Defining and Managing Requirements

(K) Keep and Manage a Requirements Finding the Right Process Architecture Repository System. The processes and methodologies that are Store all the deliverables created during business outlined in books and on web sites contain process analysis and requirements analysis in a important and useful information. Yet they all repository. Having requirements artifacts in a have a critical drawback: they cannot take into repository means those artifacts can: account what is happening in your organization or the problems you are trying to solve.  Be shared with all project participants and We at RG have developed a methodology too, published on the web. which we call LINKProcess™. At its core,  Be tracked – what they trace from and to, LINKProcess™ encompasses best practices and their change history, their status. approaches that take advantage of our twenty-  Jump-start subsequent work. The next years of experience and use of tools. Even so, time a system enhancement is we’re advocating that each organization needs its contemplated, you already have the own methodology which, while based on the best requirements that represent the current thinking and best practices of experienced system to start your work. practitioners, is tailored to fit your organization’s  Provide information to an Enterprise style and needs. Architecture Repository. Each project Steps to Get There: produces deliverables – for example, business process maps – that are Initiation: The first step is for someone in the company assets and therefore are organization to recognize the need for change. candidates for updating your company’s Perhaps there’s been a reorganization of Business Enterprise Architecture. Your responsibilities; perhaps the last project did not process should include steps to support succeed as well as had been hoped; perhaps there and manage this critical aspect of the is a desire for new tools. Whatever the work. precipitating event, the organization has made a decision that the process for understanding the The process should include a standard set of work requirements for a new system must be improved products and deliverables for each life-cycle and documented, so that it can be repeated, phase. This ensures that each project is analyzed measured, and taught. to the appropriate level, and that no important component is overlooked. As requirements are Assessment: With the basic goal of the gathered, they are modeled and captured in a organization in mind, you assess where things repository that stores the visual models and all the currently stand. This involves understanding how project business and system rules. As the processes are currently carried out, since we modifications to the project occur during want to build on what already works. You also development, the requirements in the repository need to understand the roles that are played, as can be updated. Therefore, at the end of the well as those roles that aren’t currently being project, the repository serves as an accurate performed and should be added, and you need to representation of the delivered functionality. evaluate the types of projects the organization does.

Defining and Managing Requirements

Planning: This step involves forming the core incorporate tools that provide support for three team that will work on tailoring the process and areas: communication and collaboration; determining the details (for example, meeting structure, rigor, and completeness; and times and stakeholders). traceability and relationships. Developing a Meta Model: A requirements life Communication and Collaboration: cycle process has two main purposes. The first is An effective requirements approach requires clear to provide guidelines for accomplishing work. The and consistent communication among business second is to outline the artifacts (definitions and analysts, users, developers, testers and other models) that must be understood and captured stakeholders. This sharing of information enables and to structure how those artifacts should be meaningful collaboration and improves the quality organized into deliverables. A meta model and accuracy of requirements. provides the necessary structure for classifying and organizing what is significant. Structure, rigor, and completeness: Documenting the Approach: This step may Requirements definition is not as simple as pulling take the most time in developing your process, as statements out of thin air or blindly repeating the it involves core team meetings to hash out what wishes of users. Developing meaningful roles should participate in what activities and how requirements necessitates a sophisticated level of those activities should be sequenced. The analysis, which requires the use of models, deliverable is a set of business process models. diagrams, and other business analysis artifacts to gain an in-depth understanding of the users' and Trying the Approach: In the ideal world, the stakeholders’ needs. newly documented approach would be tested out on a real project. The knowledge earned by Traceability and relationships: performing pilot project work and by having the Few requirements or business analysis artifacts opportunity to challenge or validate the process offer sufficient detail alone. It is the combination and its guidelines provides real-world practical of artifacts and their relationships to one another ideas for improvement. that provide the complete view of a system that is Reviewing and Revising the Approach: At required for the later stages of the software the completion of the pilot project, the team development lifecycle. should take a few days for review and debriefing. To support these three needs, organizations What worked well? What should be discarded? should introduce software tools that support the What was not clear? Was the order of tasks the full requirements lifecycle while catering to the best it could have been? Any lessons learned specialized needs of the business analyst. The need to be documented and incorporated into the implementation of a specialized business analysis written methodology. tool can decrease the overall time needed for Incorporating Business Analysis requirements development, increase requirements Tools to Support the Process quality, and minimize rework. In addition to having defined requirements The most popular requirements definition tool processes, you need to identify mechanisms to today is actually Microsoft Word, although it was improve the efficiency and effectiveness of those never intended to be one. For years, business processes. An important piece of the solution is to analysts have depended on standard office

Defining and Managing Requirements

productivity software--Microsoft Word, Excel, and Requirements management tools are effective PowerPoint--as tools of their trade. Overextending when used within organizations with a mature and forcing these tools to perform tasks for which requirements process and skilled business they were never designed limit our productivity analysts. Unlike requirements definition tools, and generally do more harm than good. requirements management tools do not improve the quality of the requirements during elicitation There is a better way, but navigating the myriad but maintain the requirements during subsequent business analysis tools to find the right solution phases of the SDLC, resulting in fewer overlooked can be difficult. By understanding the types of requirements and a tighter integration with other tools that exist, identifying your organization's project artifacts. constraints and needs, and knowing what traits to look for, you can make an informed choice for Requirements collaboration tools: your organization. There are few, if any, tools that focus simply on Business Analysis Tools 101 collaboration (although software such as SharePoint could be said to fulfill some The majority of software products for the business collaboration needs), but the ability for analyst can be broken down into several distinct stakeholders and developers to review and categories based on functionality and the comment on requirements deliverables and products' places within the requirements lifecycle. models is an important component for success. Requirements definition tools: Some requirements definition tools and some Software products designed to aid the business requirements management tools are beginning to analyst in the elicitation and documentation of incorporate a review and commenting capability. requirements are considered requirements Hybrid tools: definition tools. This category includes computer- Some business analysis tools contain functionality aided software engineering tools, visualization supporting requirements definition, requirements products, and business process modeling management, and in the best case, requirements software. These tools are used during the collaboration. Functionality may or may not be as planning and requirements analysis phases of a mature in hybrid tools, but these tools provide project. Requirements definition tools provide a cost savings and allow users to perform their work means to link IT and the business through in a single environment. standard languages, such as UML, or through the development of visualizations. These tools are Each type of tool has a different purpose and adept at documenting several views of the features suited to it. When selecting a tool, decide candidate system, and some support the standard where your organization needs to improve and architecture frameworks, such as Zachman, select the tool suited to that area of improvement. DODAF, and TOGAF. Selecting Your Business Analysis Requirements management tools: Tool Once requirements have been defined, A robust, repository-based tool solution that requirements management tools pick up where supports modeling, collaboration among definition tools left off. They store requirements in stakeholders, requirements traceability, and a single location, allow you to view relationships integration with testing and application between requirements, and track changes. development is ideal, particularly with respect to

Defining and Managing Requirements

moderate- to high-risk projects. However, Simplicity and the user experience: organizations and projects vary in maturity and Business analysts use Word, Excel, and complexity. To evaluate a tool, consider the traits PowerPoint for one reason: They offer a positive both of the tool and of your organization: user experience. Any new business analysis tool Organizational maturity: should provide the same. The user interface must be easy to navigate and relatively intuitive. Be honest and evaluate the maturity of the Commonly used functionality should be easily business analysis practice within your accessible. Look to minimize the number of mouse organization. Conduct an assessment of your clicks that a user will need when performing organization using a business analysis maturity common tasks. model, which will offer insight into the level of complexity that your organization can support. Information accessibility and reporting: Implementing an overly complex solution will slow Ease of compatibility and widespread use is a tool adoption. Instead, select a tool that provides reason the Microsoft Office suite has continued to the functionality that your organization needs and be used for business analysis work. Consider tools can support now, but one that also will grow with that allow users to access and share information you over time as business analysis maturity easily either through a shared repository or increases. For organizations at a starting maturity through reporting capabilities that generate level, selecting a requirements definition tool will documents in commonly accessible formats such be far more effective than a requirements as RTF or HTML. management tool. Cost: Scalability: The cost of tools varies greatly. Some are Your organization will take on projects of different available as free downloads; others can cost up to sizes, and not every project needs a full business $10,000 a license. Evaluate the cost and benefit of analysis tool solution. Tools range in complexity each tool, focusing on the features your from solutions for large advanced projects to organization needs and the relative cost of each back-of-the-napkin documentation tools. An ideal feature. Beware of hidden costs of tool solution should scale to meet your project's needs. implementations. Additional features, software Life Cycle Integration: add-ons, hardware upgrades, and training and support can add to the upfront cost of purchasing The majority of the work performed by the software. business analyst is undertaken during the early phases of a project, but that work influences all Selecting a business analysis tool is no easy other phases of the SDLC. A business analysis undertaking. However, by understanding the type tool--particularly requirements management of tool you require, your organization, and what to tools—must be capable of supporting activities look for, it is possible to make an informed within the entire SDLC by providing the ability to decision that will benefit your organization. trace work done during development, testing, and implementation back to requirements. If a tool cannot provide support across the SDLC, its usefulness is diminished.

Defining and Managing Requirements

The Benefits of a Defined Requirements Life Cycle Process Supported by Requirements Tools For the business, a well-thought-out and well- defined requirements life cycle process ensures that the business process and business need drives project results. This alone would make it valuable. But when combined with repository tools, the business also reaps benefits by being able to re-use process definitions and business requirements as a way to start the next project, or as part of an enterprise architecture. For IT, a well-defined requirements life cycle process can shorten development time because it prevents false starts (you know what the business wants before you start designing) and minimizes change requests. Even more important, IT can be confident that the solution they develop will meet real business needs. For the project manager, the requirements life cycle process provides exceptional benefits throughout the life-cycle – minimizing risks while providing a central framework for describing what’s being proposed, developed, and delivered. A consistent, controlled approach means that there are clear expectations on how requirements are uncovered, communicated and maintained, as well as guideposts for major activities and tasks.