Starting right

Abstract

Writing good requirements takes time and practice, and, even with all the new tools designed to help you, it will not happen overnight. You need a clear and organized mind, excellent communication skills, and good people skills. This paper will teach you how to minimize misunderstandings around requirements and will provide you with a “light” requirements document template so you can start your project right.

Introduction

Project success is more likely to happen when a project begins well. Effective requirements discovery, analysis, and documentation practices are key factors to achieve this. On many projects, requirements are often not documented in detail at the start of projects or at all. For some reason, the thought is that spending sufficient time on requirements gathering and creating a “requirements document” will just slow things down.

As a result, there is an abundance of misunderstandings concerning expectations, project scope, deliverables, and many more things. Missed schedules, cost over-runs, restarts, are some of the results of not establishing requirements clearly upfront. Determining requirements that satisfy the actual customer needs at the start of the project greatly enhances the chances for project success. Requirements are the foundation to both the product life cycle as the project life cycle.

Requirements: The Foundation of the Project

What is a requirement? According to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—Fourth Edition (Project Management Institute [PMI], 2008): “a requirement is a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectation of the sponsor, customer, and other stakeholders” (p.437). In plain English, requirements describe the characteristics of the project's end product.

It is crucial to make sure these descriptions are specific, measurable, and written down in understandable language. Unclear or incomplete requirements are the main cause of project failure. In the list of reasons for cancelled projects by The Standish Group (Standish Group, 2006), incomplete requirements and changing requirements are in the top 10.

Since requirements describe the project's end product, they are the foundation of your project. Requirements are the main driver of the scheduling and budgeting process. Spending time to clearly and concisely describe the requirements and manage them throughout the project life cycle will:

• -    Increase project success,
• -    Improve customer satisfaction,
• -    Limit rework,
• -    Improve product quality,
• -    Trace functionality to customer needs, and
• -    Make change manageable.

Inaccurate requirements descriptions will lead to cost and schedule over runs and potentially unusable project products. Fixing inaccurate requirements later in the project life cycle can be extremely expensive. Exhibit 1 shows the relative costs of fixing requirements defects in different phases of the project (Department of the Air Force, 2003).

Exhibit 1: Relative costs of fixing requirement errors

The communication gaps that exist between the business team and the technical team often increase the complexity of getting a clear understanding of each requirement in terms that all parties agree with and can understand.

Requirement Management Basics

Requirements management involves establishing and maintaining agreement between the customer and the technical team on both technical and non-technical requirements. This agreement forms the basis for estimating, planning, performing, and tracking project activities throughout the project. Since during the project life cycle changes and unforeseen needs will emerge, requirements management is an iterative process. The ultimate goal is to satisfy customer expectations while minimizing the risk of schedule and cost overruns. Key activities include:

1. Defining—gaining clear understanding of what the customer needs,
2. Recording—storing, linking, and versioning requirements for prioritization and control,
3. Selecting—prioritizing and selecting the requirements to be delivered first, and
4. Controlling—managing changes.

Defining

The objective of defining requirements is to describe the characteristics of the end product while minimizing confusion. The focus should be on what the real customer needs not on solutions. Overall users are relatively poor at envisioning the details of a project's end product. They have even more trouble to correctly perceive how it should operate in their environment until they actually use it. Storyboards and use cases are a way to help the user visualize the end product. The best tool for describing requirements and to minimize confusion is SMART. Every requirement should be:

• -    Specific
  • To make a requirement specific get answers to: Who? What? Where? When? Which? Why?
  • Avoid ambiguous words like the following: obviously, clearly, certainly, some, several, many.
• -    Measurable
  • Establish concrete criteria per requirement so that at the delivery of the requirement it is clear if the requirement is met or not.
• -    Agreed-to
  • Use plain language so all stakeholders can understand and agree to the requirement. Avoid acronyms and technical jargon.
• -    Realistic
  • Make sure it is technically feasible and physically possible within the project boundaries (time and budget).
• -    Testable
  • Ability to test a requirement.

An excellent skill to have and use during this phase is reflective listening: Ask the right questions to understand the need, repeat back in SMART language what you think the need is, and have the other party agree or correct the statement.

Recording

The objective of recording requirements is to store the requirements in such a way they can easily be prioritized and rated, for example, for business value or risk. The idea behind selecting a tool to record the requirements is that the tool in question facilitates the process and makes it more effective without complicating it. A tool should at least:

• -    Be accessible by all stakeholders,
• -    Present information clearly,
• -    Keep information securely,
• -    Maintain versions,
• -    Record links between items,
• -    Provide clear reporting, and
• -    Be easy to use.

Selecting

The objective of this activity is to have the customer prioritize the requirements and the technical teams give a highlevel estimate per requirements. Together the teams select the highest priority requirements to be delivered first in a specific time frame. Any new requirements, including defects, will again be prioritized by the customer and added to the overall repository. The goal is to facilitate changes that will pop up during the project life cycle. It is important to re-educate the business team that when requirements are added or changed other requirements will need to be dropped from the project scope so the overall project budget does not expand. This is also the time to validate that the requirement is complete, correct, and unambiguous.

Controlling

Traditionally the goal has been to minimize, if not prevent, requirements changes as to not affect the project budget and schedule. This has created a culture of the business asking for anything they can think of but not necessarily need since it is so hard to change requirements later on. The problem is that no matter how much time and effort is spent on having all the requirements fully defined at the beginning of the project, it is a given that requirements will change during the project. Changes are caused by:

• -    Improved understanding of the original requirement,
• -    External changes in the marketplace or legislation, and
• -    Internal changes like the organization's strategy.

People are not very good at predicting and describing clearly what they want. This guarantees requirements will change later on in the project so there is a need for a streamlined, flexible approach to requirements change management (Ambler, 2009).

“Light” Requirements Document

A requirements document is not a design document. It should state WHAT the system should do rather than HOW it should do it. It is an official written agreement between the business and technical teams that first should clearly define what the business objective of the project is. A project without a clear business objective is doomed to fail. The minimum information that should be covered in a requirement document is:

• -    Section 1 – Introduction
  • Purpose – Why are we doing this?
  • Stakeholders – Who cares?
  • Terminology – What is the definition of the terms used?
• -    Section 2 – Overall Description
  • Vision of solution – What is in scope and out of scope?
  • Risk analysis – What could impact the project?
  • Dependencies – What interactions are there to other systems?
  • Assumptions - What assumptions have been made?
• -    Section 3 – Requirements (SMART)
• -    Section 4 – Appendix

Instead of listing all the requirements in the document, Section 3 should refer to the central database where the requirements are stored. Remember, the goal is not to write a perfect requirements document, it is to deliver a working project that meets the needs of the project stakeholders in a timely and cost effective manner (Davis, 2005).

Keys to Successful Requirements Management

Gathering and agreeing on requirements is the key to a successful project. It is a balance between spending too much time and money on identifying all possible requirements and starting the project without understanding the requirements. Since requirements for sure will change during the project life cycle, it is more important to implement a streamlined, flexible approach to deal with the changes than to try to lock down the requirements at the start of the project. Several studies have shown thatthis evolutionary (iterative and agile) approach is more effective than the “big bang” approach (Ambler, 2009). The focus is on selecting the top priority requirements that add the most value to the organization and deliver those in increments.

Exhibit 2: Effectiveness of development paradigms (Ambler, 2009)

A successful requirement management process (Young, 2006):

1. Is a collaborative process between the business and the technical team through the whole project life cycle;
2. Uses proven requirements definition techniques such as case workshops and prototyping;
3. Utilizes an evolutionary approach to development and implementation of product features;
4. Has a streamlined, flexible approach to deal with requirements changes;
5. Uses an automated tool to store and maintain information about the requirements; and
6. Has the ability to trace requirements through the product life cycle.

The requirements themselves should be:

1. Written in SMART language,
2. Stored and accessible in a central location, and
3. Prioritized and rated.

The quality of your products depends on the way the product meets the customer's expectations. These customer's expectations are being captured in the form of requirements. Therefore, by improving the quality of the requirements you improve the quality of your products.