I use the term domain to mean the range of relevant things for a given matter. For example, I call the set of business processes, actors, devices, and rules that surround an application the application area. First, it contains real-world phenomena. Second, it contains the concepts that stakeholders use. Third, it contains the constraints and assumptions that shape system behavior.
I focus on practical views of a domain. For example, I use domain story models to capture how actors interact with devices and artifacts. In addition, I use domain story telling to provoke discussion. Thus, I gather stakeholders who know how the business operates. As a result, I improve the shared understanding of the business process. Moreover, I keep the technique simple. For instance, a board and sticky notes can be enough.
I also connect domains to models. For instance, I can express context diagrams with SysML block definition diagrams. In particular, I use stereotyped blocks for the system and its actors. Therefore, I model the structure of the system and its conceptual entities. In addition, I use UML sequence diagrams to model dynamic interactions in the domain. Consequently, I represent function, flow, state, and behavior.
I relate domains to requirements. For example, I distinguish domain requirements from system requirements. Specifically, they describe properties that must hold in the real world around the system. For example, a property might state that all aircraft respond to radar interrogation. If that property fails, then a system requirement may not be achievable. Therefore, I check domain assumptions early and often.
I map real-world phenomena to system-observable phenomena. For example, I map the real-world fact “car is not moving” to wheel-sensor pulses. Then, I translate a domain requirement about engaging the parking position into a system requirement: the gearbox control shall enable parking only if no wheel pulses arrive. Thus, I make domain facts useful for design and testing.
I pay attention to domain assumptions. For example, I assume that a radar is not jammed by an attacker. In addition, I assume that aircraft fly within certain altitudes. If these assumptions do not hold, then system requirements may fail. Therefore, I document these assumptions clearly. Moreover, I link assumptions to the rationale of requirements.
I link domains to stakeholders. For example, I identify who provides domain knowledge. Then, I trace requirements back to those stakeholders. In addition, I record conflicts and plan resolution. Consequently, I keep requirements elicitation focused and effective.
I keep language simple and unambiguous. For example, I create a glossary to capture domain terms and meanings. Next, I review the glossary with stakeholders. Finally, I update the glossary as I learn more.
In summary, I treat a domain as the context for a system. Therefore, I study its phenomena, its actors, its models, and its assumptions. As a result, I produce clearer requirements and better system designs.