I define customer as a person or an organization that receives a system, a product, or a service. In most cases, I treat them as stakeholders. However, I distinguish between client and end user. For example, a client may order a system. By contrast, the end user receives the finished system. Therefore, when the same organization orders and receives the system, I use the term customer in requirements engineering contexts.
I count receiving as buying, being provided with, or obtaining for free. Thus, I include free provisioning and gifts under the term customer. Also, I make clear who the recipient refers to in each requirement. For example, I ask whether the requirement addresses one recipient or many. Consequently, I avoid ambiguous statements such as “all customer data” without limits.
I apply this definition in requirements elicitation and analysis. First, I identify the intended recipient. Then, I analyze how the recipient interacts with the system. Finally, I resolve ambiguous statements by rewriting the requirement. For example, in a library system, stakeholders asked for “the ability to change all customer data.” I asked clarifying questions. Specifically, I asked whether customers could change other customers’ data. The answer clarified scope. Therefore, I rewrote the requirement as: “The library system shall provide each customer with the ability to change his or her registration data.” In this way, I limit the data set and the reference to the correct person.
I use customer information in models and data structures. For example, in a simple class model, I represent Customer, Order, and Book as classes. Accordingly, I show that the buyer places one or more orders. Thus, I model multiplicity: one customer places one or more orders. In addition, I model associations between Order and Book. For instance, an order must contain at least one book. Therefore, I use the class model to prevent miscommunication.
I also choose the RE process based on project context. If an organization orders a system and pays for it, I select a customer-specific RE process. In that case, I focus the RE process on the customer-supplier relationship. By contrast, if the organization develops a product for a market, I choose a market-oriented RE process. Then, I design requirements to match target user segments. Specifically, I consider these criteria:
- I pick customer-specific RE when the system will be used mainly by the ordering organization, stakeholders are identifiable, and the customer wants a requirements specification suitable for a contract.
- I pick market-oriented RE when the system targets a broad market, prospective users are not individually identifiable, and the product team drives requirements.
I warn about common requirement mistakes. For example, I avoid incomplete conditional structures. Instead, I explore all relevant conditions. Furthermore, I avoid unclear quantifiers about customers and their data. As a result, I write precise requirements, identify the correct customer, and limit the data and actions the person may perform. Consequently, I reduce misunderstandings and support clear contracts and designs.