I define Client as the person or organization who orders a system, product, or service to be built. In requirements engineering, I treat the Client as a primary actor. First, it often acts as a stakeholder. Second, it often drives the decision to start development. However, it does not always equal the Customer. For example, the Client may commission the work. Meanwhile, another party may receive or use the delivered product. Therefore, I always distinguish Client from Customer in specifications.
I model Client in diagrams and in text. For instance, I can model it as an abstract class. Consequently, I create specializations such as Company and Person. Thus, I capture the common properties and the variations. Alternatively, I can model it as a non-abstract class. In that case, I allow the creation of objects without specifying Company or Person. Moreover, I can define generalization sets to group different specializations. For example, I might group contact kinds and contact types with constraints. In addition, I document whether an abstract generalization represents each specialization or not. Otherwise, stakeholders may misunderstand the intent.
I keep the Client’s goals and problems central. Often, Clients describe solutions instead of goals. Therefore, I ask targeted questions. For example, I ask what problem the Client wants to solve. Next, I clarify the desired outcome. Then, I map outcomes to measurable requirements. Because Clients sometimes remain unsure, I propose variants. For instance, I present solution A (simple and fast) and solution B (richer but costlier). Furthermore, I explain trade-offs in effort, cost, and time. As a result, the Client can choose a variant that matches their priorities.
I use Client input to drive domain and application development in product lines. First, I collect commonalities. Second, I capture variability. Consequently, developers can derive specific products from reusable artifacts. In addition, I define selection and combination rules. Otherwise, teams might produce inconsistent product variants. Therefore, I document dependencies and constraints for variant selection. Likewise, I include optional requirements to reflect Client choices during elicitation.
I address ambiguities proactively. Although Clients may assume I know their context, I verify assumptions. Thus, I reduce the risk of misunderstood requirements. I document who acts as the Client, who acts as the Customer, and who holds decision power. Moreover, I record roles, responsibilities, and acceptance criteria. Finally, I ensure the specification makes a clear distinction between the Client’s desires, the Customer’s needs, and the system’s users.
In short, I treat the Client as the commissioning party. I model Clients clearly; I separate Clients from Customers; I elicit goals before locking solutions; and I offer variants when Clients are unsure. Therefore, I improve clarity and reduce rework. Consequently, I increase the chance that the delivered product meets the Client’s real needs.