Requierementes Management

C

H A P T E R

1

Requirements Management

This chapter starts by defining the concepts of requirements and stakeholders. Then we describe what types of requirements can exist in a project. The relationships between these requirements are presented in the form of a pyramid. The concept of traceability is introduced (which requirement is derived from which). Characteristics of a goodrequirement are presented. Examples of problematic requirements are given, together with some guidelines on how to fix them. General steps in requirements management (RM) during the project lifecycle are shown. The main steps navigate through the requirements pyramid from top to bottom.

1.1

Definition of a Requirement and a Stakeholder

A requirement is defined as “a condition or capability towhich a system must conform.” It can be any of the following: • A capability needed by a customer or user to solve a problem or achieve an objective • A capability that must be met or possessed by a system to satisfy a contract, standard, specification, regulation, or other formally imposed document • A restriction imposed by a stakeholder Let’s define a concept of a stakeholder because this wordoccurs many times in this book. Usually the stakeholder is defined as someone who is affected by the system that is being developed. The two main types of stakeholders are users and customers. Users are people who will be using the system. Customers are the people who request the system and are responsible for approving it. Usually customers pay for the development of the system. It is important todistinguish between these two groups of stakeholders because sometimes requirements provided by both groups conflict. In most of these types of conflicts, customer requests take precedence over

3

4

Chapter 1

Requirements Management

user requests. In the travel agency website example used in this book, a customer is a travel agency owner, and the users are all the people who will be usingthis website through the Internet. Besides customers and users, many other types of stakeholders cannot be neglected. For the purposes of this book, we will call the stakeholder anybody involved in the system (either during development or after it is completed) and anybody who may have any requirement for the system. Here are some of the people who may be considered stakeholders: • Anyoneparticipating in the development of the system (business analysts, designers, coders, testers, project managers, deployment managers, use case designers, graphic designers) • Anyone contributing knowledge to the system (domain experts, authors of documents that were used for requirements elicitation, owners of the websites to which a link is provided) • Executives (the president of the company that isrepresented by customers, the director of the IT department of the company that designs and develops the system) • People involved in maintenance and support (website hosting company, help desk) • Providers of rules and regulations (rules imposed by search engines regarding content of the website, government rules, state taxation rules)

1.2

Requirements Pyramid

Depending on the format,source, and common characteristics, the requirements can be split into different requirement types. Here are some requirement types that are often used in projects: • Stakeholder need: a requirement from a stakeholder • Feature: a service provided by the system, usually formulated by a business analyst; a purpose of a feature is to fulfill a stakeholder need • Use case: a description of system behaviorin terms of sequences of actions • Supplementary requirement: another requirement (usually nonfunctional) that cannot be captured in use cases • Test case: a specification of test inputs, execution conditions, and expected results • Scenario: a specific sequence of actions; a specific path through a use case These requirement types can be presented in the form of a pyramid, as shown in Figure 1.1....