Domain analysis is the process by which a software engineer learns background information. He or she has to learn sufficient information so as to be able to understand the problem and make good decisions during requirements analysis and other stages of the software engineering process. The word ‘domain’ in this case means the general field of business or technology in which the customers expect to be using the software.
Some domains might be very broad, such as ‘airline reservations’, ‘medical diagnosis’, and ‘financial analysis’. Others are narrower, such as ‘the manufacturing of paint’ or ‘scheduling meetings’. People who work in a domain and who have a deep knowledge of it (or part of it), are called domain experts. Many of these people may become customers or users.
To perform domain analysis, you gather information from whatever sources of information are available: these include the domain experts; any books about the domain; any existing software and its documentation, and any other documents he or she can find. The interviewing, brainstorming and use case analysis techniques discussed later in this chapter can help with domain analysis.
To perform domain analysis, you gather information from whatever sources of information are available: these include the domain experts; any books about the domain; any existing software and its documentation, and any other documents he or she can find. The interviewing, brainstorming and use case analysis techniques discussed later in this chapter can help with domain analysis.
As a software engineer, you are not expected to become an expert in the domain; nevertheless, domain analysis can involve considerable work. The following benefits will make this work worthwhile:
* *Faster development*: You will be able to communicate with the stakeholders more effectively, hence you will be able to establish requirements more rapidly. Having performed domain analysis will help you to focus on the most important issues.
...
...
@@ -130,8 +130,8 @@ As a software engineer, you are not expected to become an expert in the domain;
[.notes]
--
* Illustrates meaningful conceptual classes in a problem domain.
* Is a representation of real-world concepts, not software components.
* Illustrates meaningful conceptual classes in a problem domain.
* Is a representation of real-world concepts, not software components.
* Is NOT a set of diagrams describing software classes, or software objects and their responsibilities.
* Existing procedures, standards documents, software, and user-manuals: where these do exist, they should be consulted. But keep in mind that procedures as written often do not reflect the actual operations. User-manuals for existing systems are a rich source of information. They act as a key input to * reverse-engineering an abstract model of a system; and therefore, of a business.
* Observation and interviews: actual observation of procedures at work, combined with interviews with the persons involved in these procedures. Techniques such as CRC cards can be very effective at eliciting information on as-is processes.
* Existing relational or E-R models: these provide a quick start on the terminology and some of the candidate object types in the business. However, due to the mores or normalization and the exclusive focus on stored data, these models can often be considerably simplified to build a type model. Where used, triggers and stored procedures often encode many business rules.
* Existing batch-mode systems: often those late-night Cobol batch jobs encode critical sets of business rules. Many of these rules can be captured as time-dependent static invariants on the type model (the batch-job cuts in to make sure no objects will be in violation of these invariants, come sunrise) or as effect invariants, of the form “any time this thing has changed, that other thing must be triggered”.
* Feedback from prototypes, scenarios, models: as always, any “live” media pro- vides very valuable feedback and validation of models being built. For example, storyboards, prototypes of UI screens, CRC-card based scenarios, and model walkthroughs, can all be used.
* Existing procedures, standards documents, software, and user-manuals: where these do exist, they should be consulted. But keep in mind that procedures as written often do not reflect the actual operations. User-manuals for existing systems are a rich source of information. They act as a key input to * reverse-engineering an abstract model of a system; and therefore, of a business.
* Observation and interviews: actual observation of procedures at work, combined with interviews with the persons involved in these procedures. Techniques such as CRC cards can be very effective at eliciting information on as-is processes.
* Existing relational or E-R models: these provide a quick start on the terminology and some of the candidate object types in the business. However, due to the mores or normalization and the exclusive focus on stored data, these models can often be considerably simplified to build a type model. Where used, triggers and stored procedures often encode many business rules.
* Existing batch-mode systems: often those late-night Cobol batch jobs encode critical sets of business rules. Many of these rules can be captured as time-dependent static invariants on the type model (the batch-job cuts in to make sure no objects will be in violation of these invariants, come sunrise) or as effect invariants, of the form “any time this thing has changed, that other thing must be triggered”.
* Feedback from prototypes, scenarios, models: as always, any “live” media pro- vides very valuable feedback and validation of models being built. For example, storyboards, prototypes of UI screens, CRC-card based scenarios, and model walkthroughs, can all be used.