Requirements Management Using IBM® Rational® RequisitePro®
- 1.1 Definition of a Requirement and a Stakeholder
- 1.2 Requirements Pyramid
- 1.3 Traceability between Requirements
- 1.4 Characteristics of a Good Requirement
- 1.5 An Overview of the Requirements Management Process
- 1.6 Summary
This chapter excerpt from Requirements Management Using IBM Raional RequisitePro presents the RM process from the point of view of created requirements and documents.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 good requirement 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 to which 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 word occurs 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 to distinguish 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 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 using this 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:
- Anyone participating 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 is represented 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)