Requirements Management

How to Ensure You Achieve What You Need from Your Projects

Mario Kossmann

• Publisher: Routledge
• Year: 2016
• Print ISBN:
  9781409451372
• eBook ISBN:
  9781317065739
• Topic: Business
• Subtopic: Business General
• Index: Business

Poor requirements management is one of the top five contributors to poor project performance. In extreme, safety critical or emergency-relief situations, failure to satisfy the real needs of the project stakeholders may well lead directly to loss of life or human suffering; other, more mundane, projects can also be severely compromised. Dr Mario Kossmann's Requirements Management looks at the process from the perspectives of both Program and Project Management and Systems Engineering, showing the crucial role of RM in both contexts. The author puts great emphasis on the human aspects of any project, which is also significant given that over-emphasis on technical or technological aspects at the expense of the human side is another major source of project shortfalls. The book offers illustrated examples of systems of different levels of complexity (one simple system, one complex, and one highly complex system) to help you categorize your own system and enable you to select the right level of formality, a suitable organization and a set of techniques and tools to carry out your requirements work. It includes a series of comprehensive checklists which can be used immediately to improve urgent requirements aspects. This is a practical and realistic guide to requirements management that provides a flexible, hands-on and innovative approach to developing and managing program, project and system requirements at different levels of complexity; read it and use the advice offered to ensure your projects can actually deliver, first time, without the need for costly and time-consuming rework.

PART I
Introduction to Requirements Management

1
Introduction

Chapter Summary

This first chapter answers some initial questions you may have, in particular why you should read this book and how you can use it most effectively and efficiently, depending on your own background and business context. This will help you to save time and focus on the most urgent aspects that you need to know about in your current situation. Then the chapter explains the nature, use and importance of requirements, and introduces the discipline of Requirements Management (RM).

Why You Should Read This Book

Most people will have had negative experience when they needed something but were delivered something else they did not need, or that did not fully satisfy their needs. Not getting what you really need usually leads to disappointment and frustration. In many business contexts this is likely to waste time and money, leading to delays, budget overruns and, in the worst case, project failure.

In some safety-critical or charity-related fields, not satisfying the real needs may well lead directly to loss of life and immense human suffering – for example, if the water distribution system for an overcrowded refugee camp was not properly specified, and as a result, an unsatisfactory system was purchased and flown into the crisis area.

In many cases, in particular in our private lives in more affluent and wealthy societies, the consequences may not be so dire, but people may still spend a lot of money on a new heating system for their house that does not really meet their needs, or they may purchase the wrong family car, or invest their bonus in the wrong holiday package for their family.

This book does not claim to be an academic publication. Rather, it is a practical and realistic guide for anyone who wishes to make his requirements explicit, in order to ensure that his needs are fully met – irrespective of the industry, the sector (public or private), the purpose of the organization (profit or not-for-profit), and the general context (work or leisure). The contents of this book are the results of a large variety of applied research, good practice, and hands-on experience across many industries.

How to Use This Book

This book directly addresses you as a reader and potential user of the proposed approach to RM. The assumptions taken would be that you are in a specific situation, in which (a) you as a ‘customer’ either have to make explicit what you need in order to make the right purchase decision, or to have something developed and made for you; or (b) you as a ‘provider’ will have to ensure that you have identified all customer requirements before you provide your customer with what he really needs.

In the former case, you may be looking for a new house or a car to buy; in the latter case you may be an architect or own a building company or car dealership.

Regarding your experience, you may have had negative experience with not getting what you really needed when you made a major buy decision, or you may be an experienced professional requirements manager or project manager, and you want to improve the way you develop and work with requirements.

In many business contexts, especially in the public sector including the defence sector, there are multiple standards that have to be followed in order to develop systems and conduct RM. This book will help you to improve the quality of your requirements and reduce the time to develop and maintain them, while following any mandatory standards.

Whatever your background, experience and business purpose, this book offers you flexible advice and guidance, depending on your own individual needs. If you start working as a requirements manager, you may want to apply the proposed approach in its entirety to your working context. On the other hand, if you already have a lot of experience with requirements, you will find specific parts of the book helpful to improve at least certain aspects of your current approach to developing and managing requirements.

Depending on your own context and experience, as well as your current activities and the necessary level of your own direct involvement in RM, we will look at three distinct types of situation, in which you may find yourself: you will either have sufficient time to go through the entire approach to RM in detail (Case 1), you may only have limited time to look at the proposed approach (Case 2), or you may be under a lot of time pressure and urgently need to get a grip on your requirements (Case 3).

In any case, you can always go back to this guide and revisit certain aspects you may have initially ignored because of the situation you were in. The book is structured in a way that allows you maximum flexibility in terms of how you use it over time.

CASE 1: YOU HAVE THE TIME TO LOOK AT THE PROPOSED APPROACH TO RM IN DETAIL

Please go through the entire book chapter by chapter. This will give you the best insight into the proposed approach to RM and prepare you well for any requirements related work you may have to do in your own context.

CASE 2: YOU HAVE ONLY LIMITED TIME TO LOOK AT THE PROPOSED APPROACH

You will find it useful to read the short chapter summaries at the end of this section (or at the beginning of each chapter) to have a quick overview and decide what seems to be the most relevant chapter for you to read in your given situation. Figure 1.1 provides an overview of the structure of this book in the form of a mind map. All chapters can be read in isolation or in a different order, if this is more helpful to you.

CASE 3: YOU HAVE NO TIME AND URGENTLY NEED TO GET A GRIP ON YOUR REQUIREMENTS

If you urgently have to look into any specific requirements issues and have no time to look properly at the proposed approach in detail, you can go directly to the appendices section of the book and pick the appropriate process checklist. These process checklists provide a summary overview of the recommended activities with their inputs and outputs, as well as indications as to who should participate in these activities.

Also, you could use the requirements quality checklist (for individual requirements) and the requirements document quality checklist (for sets of requirements) to evaluate the quality of your requirements as they are at the moment, and identify areas of needed improvement.

However, it is worthwhile to go through the relevant section of Chapter 5 that describes the phase of the RM process, in which you currently are. The beginning of the chapter gives an overview of the entire process that will allow you to identify the right section you should read. You might also find Figure 1.1 helpful to quickly spot the relevant parts of the book you should concentrate on in the light of your specific situation.

In any case, investing time to get a grip on your requirements will actually save you time, provide you clear visibility and better control over what is happening in your project, and give you a good chance of meeting the underlying needs of your project.

The main body of the book is divided into two parts: Part I is concerned with introducing key aspects of RM, giving an overview of the discipline and explaining why RM is of fundamental importance to the success of any project, whereas Part II is concerned with how RM can actually be put into practice in a large variety of business contexts of different degrees of complexity.

Within the first part, Chapter 1 introduces you to this book, answering some initial questions you may have, and provides some guidance on how to use the book depending on your individual background and context in order to help you save time and focus on the most relevant aspects you need to know about. Based on this introduction, RM is put into its wider context in terms of Systems Engineering (SE) and Project and Program Management (P&PM). Chapter 2 puts RM into the context of SE, defining what is understood by the term ‘System’ and by the SE approach, explaining why SE is important and what role RM plays as an integral part of SE. Chapter 3 puts RM into the context of P&PM, explaining the difference between projects and programs, defining the discipline of P&PM, explaining why this discipline is important and what role RM plays as an integral part of P&PM.

Figure 1.1 Overview of the contents and structure of the book

In the second part of the book about putting RM into practice, Chapter 4 describes essential human factors that should not be underestimated, since these will have to be properly addressed in order to successfully deploy a new RM process in any organization. Then Chapter 5 provides a detailed description of all aspects of the proposed RM process, followed by the description of RM techniques and tools that support this process in Chapter 6.

Although the above three chapters are written in generic terms, the underlying assumption is that the RM process as presented is to be used for the development of a complex or highly complex system. This means that for simple systems, many of the proposed activities will be much less time-consuming and the needed tools to support the process and manage the created data may be less sophisticated, since the data volumes can be expected to be significantly lower.

Chapter 7 explores the application of RM at different levels of system complexity, and provides detailed and graphical insights into three representative example cases. It will help you understand in what category of context you are yourself, and therefore allow you to select the appropriate level of detail and formalism of the RM approach that you should apply in your specific circumstances.

Finally, Chapter 8 concludes with a summary of the main recommendations of how you can implement the content of the book in your own environment and specific context.

Throughout the book, specific examples are used that offer concrete instances of what is described in more generic terms. This aims to enhance your understanding and make the book as helpful as possible for a large variety of readers, who may not necessarily have much experience in all areas covered by the book. Also, the following additional material is provided in the appendices of the book: a human aspects checklist (Dos and Don’ts), key process checklists for requirements development (RD) and requirements change management (RCM), a list of recommended RM tools, a requirements quality checklist, a requirements document quality checklist, as well as a mapping from the RM process workflows to the recommended techniques and tools that can best support them.

What Are Requirements?

For every project, there are usually several stakeholders, that is, people with a vested interest in the project and its outcomes. Each of these stakeholders has certain high-level needs that have to be satisfied by the project and its outcomes for the project to be successful. Some key aspects of these needs have to be elaborated in more detail and made explicit in order to influence the project in a way that the project and its outcomes actually satisfy these stakeholder needs.

Requirements are detailed expressions of specific aspects of less detailed stakeholder needs. They formalize relationships between the stakeholders or customers of a system, and the developers or suppliers of this system. A system here is defined as an integrated set of interacting elements – such as products, services, people, processes, hardware, software, firmware and information –that serves a defined purpose.

Requirements are most frequently expressed as textual requirements, but in some areas such as safety-critical software requirements, formal mathematical requirements or models may be used. Requirements can be descriptions of how a system should behave (functional requirements), or of an overall system property or attribute (non-functional requirements). Other requirements may be a constraint on the development process or project of the system development.

Depending on the business context, there are many different ways of how requirements can be categorized into different types. In the context of software engineering, Sommerville proposed the classification of non-functional requirements shown in Figure 1.2 [1].

Requirements are likely to be of different priority for a given project or program. This priority may be considered in terms of three categories of priority: ‘order winners’ or ‘essential’ requirements; ‘qualifiers’ or ‘important’ requirements; and ‘less important’ or ‘nice to have’ requirements.

The first category covers requirements that have to be satisfied in order to enable the system to stand out as superior over competitors’ systems. In cases where there is no competition between alternative systems, this level of priority means that the corresponding key requirements have to be satisfied for the project to be successful. The second category includes requirements that have to be met in order for the system to be even considered as a viable option or alternative. The third category includes requirements that do not necessarily have to be met by the system, although this would be desirable.

Figure 1.2 Classification of non-functional requirements (adapted from Sommerville, 2007) [1]

Over time, both the requirements themselves and their relative priority may change. This could be the case when specific user needs change or the market in general changes. However, there are two general types of changes: those that are brought about by changes of stakeholder needs, and those that are necessary because the requirements had not been developed to the right level of quality initially, that is, when corrective rework is needed to get the requirements right. The first type of change cannot be avoided and needs to be enabled in a systematic manner; but the second type of change has to be reduced as far as possible, since it causes additional, unplanned delays and costs, without adding any value to the system development.

There are a number of particularly volatile requirements that deserve special attention during the life cycle of a system; in particular, requirements around the interaction between subsystems that are to be integrated into one overarching system of subsystems. Often, when the system is designed at high level, some of the necessary subsystems are not designed or unknown at that time. Once these subsystems are integrated into the overall system, they may show a number of emerging, frequently unintended or at least unexpected properties.

In a business context, requirements are often developed and managed over time by dedicated requirements managers. In such cases, the requirements are not usually owned by the requirements manager, but rather by the people on behalf of whom the requirements manager develops and maintains the requirements. Requirements bridge the gap between the people who have a problem, that is, external and internal stakeholders, and the people who can design and build a suitable solution to the problems at hand. Requirements are also the basis of testing, qualification, risk management, as well as project and program management in general.

Who Needs Requirements?

Anyone who is about to enter or already is in a customer-provider-relationship potentially has requirements to request or provide a system of some sort as a solution to a given set of problems. However, the needed level of detail, granularity and formality of the requirements depends on the given context.

From the customer viewpoint, a large variety of individuals, teams or organizations across industries depend on requirements, in order to specify in detail what their needs are, be it in the private or public sector, within a pro...

Table of contents

• Cover Page
• Half Title Page
• Dedication
• Title Page
• Copyright Page
• Contents
• List of Figures
• List of Tables
• List of Abbreviations
• Acknowledgements
• About the Author
• Glossary
• Reviews for Requirement Managements
• PART I Introduction to Requirements Management
• II Putting Requirements Management into Practice
• Appendix A
• Appendix B
• Appendix C
• Appendix D
• Appendix E
• Appendix F
• Appendix G
• Bibliography
• Index