Tag: Lean

Introduction

A typical SDLC project starts with a requirements-gathering exercise followed by an analysis phase. During the requirements analysis phase, a detailed study is done in order to identify the different pain areas that would be addressed by the software that would be delivered. Often we come across situations, or more appropriately, business scenarios, wherein the requirements are not clearly documented.  They are vague and do not provide any clarity as to what exactly is expected. This leads to ambiguity, and finally, a software that delivers everything except what the client asked for! Unfortunately, this discovery happens during the user acceptance phase. Defects are identified that inadvertently point to requirements that have not been clearly captured/documented. A standard reaction of the business users would be, ‘We thought that this was going to be delivered…it is an Implicit requirement!’ Once we hear this statement, a typical ‘passing the buck’ game starts between the IT department and the Business Users.

This situation could have been easily avoided if the Business Analyst had taken the efforts to identify the implicit requirements. A key responsibility of a Business Analyst is to define the Scope of the system that is going to be built, and in this process, ensure that the Explicit as well as Implicit requirements are clearly documented.

Understanding Implicit Requirements

Let us begin with understanding the difference between an Explicit and an Implicit requirement. Usually, the requirements that are stated by the business users in the different meetings and interviews are categorized as Explicit requirements. These requirements are the easiest to capture. They are usually supported by loads of Documentation, or for that matter, even a legacy system screenshot!

Implicit requirements are the hidden or ‘assumed’ requirements. Business users expect these to be delivered and hence may not feel the need to explicitly mention them in the business meetings. It could be challenging to actually define the scope as there is no clear-cut documentation or boundary available. The keyword here is ‘scope’. Let us try to understand this with a very simple example:

User requirement: 

Screen to capture the following employee details:

1. Employee number
2. Employee name
3. Department

Implicit requirement: 

1. Capture Designation as well

Since it is an Employee data capture screen, the business users would assume that there is a field to capture Designation as well. This would definitely be an Implicit requirement. But is it right to assume that this is the ONLY implicit requirement?

For instance, I can add a couple of other implicit requirements, such as:

1. Duplication check required on the ‘Employee number’ field
2. Should have the facility to Search for an existing Employee

Here is where the dilemma starts. Some Business Analysts would totally agree with my listing of implicit requirements, but I am sure there would be many others in the Business Analyst world who probably disagree. For instance, Search facility could be provided as a separate screen, and hence that would be a separate requirement altogether.

The key point here is to recognize that capturing the implicit requirement is more of a need than a luxury.

Another example would be in a data processing centre where the performance of a data entry operator is measured by the number of entries that have been done in the system. For example, consider a typical airlines scenario wherein millions of passengers travel daily. A data entry operator in such a scene would have to enter hundreds of passenger coupons in the system and his KRA or performance is measured on the basis of the number of coupons he enters in the system. In such a scene, the Business would need a system that would capture data quickly and in a highly efficient manner. Here, the implicit need is that the data capture form has to be designed in such a manner whereby the maximum data/information on the form can be entered using the keyboard rather than using the mouse. In other words, maximum information must be enterable using keystrokes rather than using the mouse.

If this implicit requirement is missed out, then we end up in situation where the data entry operator would never meet his KRA, and looking at the bigger picture, the airline would miss its SLA. This could lead to tarnishing the airline’s image and would ultimately impact its business.

Scope Control

If documented well, Implicit requirements can be used as an excellent tool to control the scope, which in turn will lead to lesser defects and finally a Satisfied Customer! But at the same time if the boundaries for the requirements are not clearly documented, it can be misused and will lead to Scope Creeps, huge defects and a Dissatisfied customer.

This leads us to the conclusion that the Business Analyst community would have to use certain proven methods to define and bound the scope. A cost-benefit analysis will be the ideal way to deal in this situation. There may be a scenario wherein an endless list of implicit requirements inadvertently increases the cost with no visible benefits. On the other hand, it is quite possible that by deciding to incorporate minimal implicit requirements, the client would reap huge benefits.

In a nutshell, in order to ensure that the implicit requirements are never missed out, we would need to take a step back and always try to understand what exactly the Business user is looking for and if we have really understood this need. To conclude, we Business Analysts do play a role of ‘the Truth Seeker’ and thus need to unravel what lies beneath, in our quest of understanding Business requirements!

Don’t forget to leave your comments below.

Aruna Parameswaran : A technical person with 12+ years of experience who moved into a Fucntional role by choice. Working as a Business Consultant with an IT organization and have led the Requirements phase of multiple implementation projects across geographies,primarily Asia-Pac and UK with some exposure to the US geography. Have spent the last 6 years specializing in the Life Insurance domain in the UK and Asia-Pac regions

The following is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning, written by the authors.                                    

Overview

Requirements management, like project management, is a discipline comprised of inputs and outputs, tools, and techniques, processes and activities, but just for the business analysis effort. Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. Get a quick introduction or refresher on this important topic.

We will briefly look at a few of the key ingredients in managing requirements, including what gets created during planning, documenting “good” requirements, traceability, and managing changes.

Planning

Two of the key outputs from requirements management are a planned and communicated approach to business analysis and a requirements management plan.

The business analysis approach. The approach that we take to business analysis work is primarily concerned with the type of framework, method, or methodology we use to capture our requirements. The approach is the cornerstone of our effort, and it determines how we go about collecting and managing requirements. It describes the processes we will follow and the templates, if any, that we will complete. the approach will probably be different for different methodologies  and frameworks. For example, prioritizing requirements on an Agile project is different from prioritizing them on a Waterfall project. In choosing an approach, we need to make sure that it’s communicated to all appropriate stakeholders and that they are onboard with the approach that will be taken.

The requirements management plan (RMP) describes how the business analysis work will be completed. It describes processes for how requirements will be documented, traced, prioritized, baselined, and changed. We might also think of the RMP as a collection of the plans that are used to manage business analysis. The RMP can be a formal set of documents with many subsidiary plans, such as a business analysis communication plan, business analysis risk plan, estimates for the business analysis work effort, and many more. This type of RMP might be appropriate for larger, riskier projects. On some smaller efforts the RMP can be an informal roadmap. In either case, it is subsidiary to the overall project management plan.

Documenting “Good” Requirements

Requirements documentation. Requirements are always documented, either formally or informally. Requirements might be documented as part of a detailed requirements specification, in the form of a short text known as a user story, or as part of one or several models, such as a business process, data, or use case model, or as a prototype or mock-up. There is no right way or wrong way to document requirements, as long as all the requirements are understood by everyone who hears or reads them–which means they need to be “good.”

What makes a Good Requirement?

In order for a requirement to be worth managing, it must be useful. To be useful, a requirement has to be understood by all key stakeholders. Sponsors and business subject matter experts need to know that the ultimate solution will solve their problem and meet their objectives. Developers need to understand how to design and build the final product. The testing staff needs to be able to find and remove any defects the product may have. Change managers (Human Resources staff, consultants, business managers, etc.) need to understand how the end product will affect the organization. If a requirement is not clear, some or all of the components that comprise the product could be defective. To that end requirements must be clear and unambiguous, consistent, complete, concise, and confirmed (validated and verified). They must also be testable and traceable. Here are some tips to make requirements “good.”

• Describe what is needed rather than how the need will be implemented.
• Use units of measure or specific words to reduce ambiguity. So, “less than five seconds” is preferable over “fast,” for example.
• Use a glossary to reduce ambiguity. As new stakeholders become involved over the life of the project, a glossary can prevent misinterpretations and increase productivity. It is also helpful to include an acronym reference list with the glossary for easy access to those acronyms.
• Keep sentences concise and simple in relationship to number of words and grammatical structure.
• Organize and group requirements into a hierarchical list, with high-level requirements broken down into sub-requirements as they are uncovered.
• Uniquely identify each requirement. Use a hierarchical numbering system (1.0, 1.1, 1.1.1, 1.2, etc.). Such a scheme can be used to more easily trace requirements (see below).
• Remove redundant requirements or clarify requirements that seem similar but are really unique.
• Use graphical models, diagrams, and prototypes where appropriate.

 Traceability

Requirements traceability is a structured way to keep track of requirements. Requirements are traced back to their source, to themselves as detailed requirements are discovered, and throughout the project. Tracing requirements back to their source is sometimes called backwards or upwards traceability and involves linking requirements to the identified business problem, business objectives, and project objectives. Figure 1 illustrates the concept of backwards traceability.

Figure 1 – Backwards Traceability 

Tracing requirements throughout the project is called forwards allocation or forwards traceability and involves documenting the linkage between the requirements and other requirements, and requirements to the design, development, testing, and deployment work products. Figure 2 illustrates the concept of forwards traceability.

 Figure 2 – Forwards Traceability

Requirements traceability aids requirements management by ensuring that each requirement:

• Adds value. By tracing each requirement, its value in helping the organization solve its problems and meet its objectives becomes apparent, thus helping the organization focus on doing all the right things and only the right things.
• Belongs in the approved scope. Requirements that cannot be traced do not belong in the project. Scope management is one of the biggest project challenges, so traceability is a useful tool in controlling scope.
• Is actually delivered at the end of the project or project phase. Once the right requirements have been identified and agreed upon, it is important to ensure that all the pieces needed to satisfy those requirements are designed, built, tested, and delivered.

Traceability also aids in determining impacts and interrelationships, so that:

• The cost of each requirement and requested changes can be more easily estimated.
• Testing coverage can be planned.
• Risks can be more easily identified, and a risk response plan developed.

Managing Changes

An important part of requirements management is handling changes. During requirements planning, processes to handle changes are established, including who requests changes, who authorizes them, and who vetoes them. The “who” might be an individual, or it might be some type of change control board. Once the change process is approved, it is necessary to follow it. The approved process depends on the business analysis approach taken, and might vary from project to project. For example, the process for handling changes on an Agile project might well be different from a traditional project. Regardless of what that process is, however, it must be communicated and agreed to by affected stakeholders.

Summary

We have looked at a few of the key ingredients in managing requirements. They included planning tasks of determining the approach and creating the requirements management plan, which needs to be appropriate for the business analysis effort. As we do the business analysis work, we document “good” requirements in the format and to the level of detail required for the project at hand. Finally, to help control the scope, we trace requirements and manage changes.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).