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. Object oriented modelling, discussed in the next chapter, can also be of assistance.
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.
• Better system: Knowing the subtleties of the domain will help ensure that the solutions you adopt will more effectively solve the customer’s problem. You will make fewer mistakes, and will know which procedures and standards to follow. The analysis will give you a global picture of the domain of application; this will lead to better abstractions and hence improved designs.
• Anticipation of extensions: Armed with domain knowledge, you will obtain insights into emerging trends and you will notice opportunities for future development. This will allow you to build a more adaptable system.
It is useful to write a summary of the information found during domain analysis. The process of organizing and writing this summary can help you gain a better grasp of the knowledge; the resulting document can help educate other software engineers who join the team later.
We suggest that a domain analysis document should be divided into sections such as the following:
B. Glossary: Describe the meanings of all terms used in the domain that are either not part of everyday language or else have special meanings. You must master this terminology if you want to be able to communicate with your customers and users. The terminology will appear in the user interface of the software as well as in the documentation. You may be able to refer to an existing glossary in some other document, rather than writing a new glossary. The section is best placed at the start of the domain analysis document so you can subsequently can use the defined terms.
C. General knowledge about the domain: Summarize important facts or rules that are widely known by the domain experts and which would normally be learned as part of their education. Such knowledge includes scientific principles, business processes, analysis techniques, and how any technology works. This is an excellent place to use diagrams; however, where possible point the reader for details to any readily accessible books or other documents. This general knowledge will help you acquire an understanding of the data you may have to process and computations you may have to perform.
D. Customers and users: Describe who will or might buy the software, and in what industrial sectors they operate. Also, describe the other people who work in the domain, even peripherally. Mention their background and attitude as well as how they fit into the organization chart, and relate to each other. These people may become users.
E. The environment: Describe the equipment and systems used. The new system or extensions will have to work in the context of this environment.
F. Tasks and procedures currently performed: Make a list of what the various people do as they go about their work. It is important to understand both the procedures people are supposed to follow as well as the shortcuts they tend to take. For example, if people are supposed to enter certain information on a form, but rarely do, this suggests the information is not useful. Tasks listed in this section may be candidates for automation.
G. Competing software: Describe what software is available to assist the users and customers, including software that is already in use, and software on the market. Discuss its advantages and disadvantages. This information suggests ideas for requirements, and highlights mistakes to avoid.
H. Similarities across domains and organizations: Understanding what is generic versus what is specific will help you to create software that might be more reusable or more widely marketable. Therefore, determine what distinguishes this domain and the customer’s organization from others, as well as what they have in common.
Be careful not to write an excessive amount of detailed information. It is a waste of effort to duplicate the original source material; your domain analysis should simply include a brief summary of the information you have found, along with references that will enable others to find that information.
No serious software project should be undertaken without a sound domain analysis; a good knowledge of the domain of application considerably increases your chances of success. Many of the most successful software products have been developed by people who were actively working in the domain before they became software developers – such people have a better feel for what is really needed.
Once software engineers have a good grasp of the domain, they can move on to requirements analysis, which includes defining the problem to be solved and what software will be created to solve it. However, domain analysis should never really end: Software engineers have the responsibility to continue improving their understanding as development proceeds. An extension to the system added for a subsequent release will often merit a domain analysis of its own sub-domain.
Example 4.1: Outline in one paragraph the information you would need to gather in order to perform domain analysis for the airline reservation system.
You would attempt to learn as much as possible about such things as how airline flights are scheduled; how fares are set and structured, and how ticketing and booking works in the customer’s airline and other airlines. You would study how the various people in the airline reservation business, including travel agents and airline employees, do their jobs; what existing reservation systems are capable of doing and how they work; and what laws, regulations and other rules govern the industry. You would study the functionality of competing reservation systems. You would also study the transition that has been happening from booking of flights by travel agents, to on-line booking of flights by the passengers.
Example 4.2: Imagine you are performing
a domain analysis in order to develop a new and better telephone response and
dispatch system for medical emergencies. The system will be used by operators
and paramedics who respond to calls to the emergency number 911 (in North
America) or 999 (in the UK). Summarize the information you would expect to
learn. Structure your answer using the categories of information we suggest for
a domain analysis document.
A. Introduction. The domain is ‘Medical Emergency Dispatch’. You already know that the motivation for the domain analysis is to develop a new system that would improve upon existing systems. You would want to record the qualities that are valued in such systems; these presumably include accurate guidance to the paramedics, fast response time, flexibility, and, above all, saving lives.
B. Glossary: Much of the special terminology for this domain will be medical in nature, but there will also be terminology related to communications equipment, emergency vehicles and rescue equipment.
C. General knowledge about the domain: You should obtain statistics about the calls received and the types of cases handled; this will help you determine the level of performance the system must achieve. Other examples of information to learn include: What are the different categories of emergency situations, and how is each handled? How are addresses described (it is critically important that no mistake is made when communicating an address to an ambulance driver)? How do dispatchers decide whether police, fire-fighters or other special services should also be dispatched?
D. Customers and users: In this domain, everyone, including operators, drivers, paramedics and doctors in hospitals, has a clearly defined role. You should understand the knowledge they possess and what they need to learn during the process of handling an emergency. You might discover that some dispatch workers are opposed to the introduction of any new software – they might have developed considerable skill with the existing methods, and fear a new system will render their skills redundant, or even put them out of a job. Knowing this fact, you can take actions to address their concerns and thus avoid any political problems.
F. Tasks and procedures currently performed: The procedures that are currently used by dispatchers and paramedics will help you decide the functions that you have to implement. These procedures are normally very well defined so that they can be followed without any decision-making delay even in a major crisis. Examples of procedures include: How decisions are made about which ambulance to dispatch to which address; how dispatchers ambulance drivers decide upon a route, especially when traffic is heavy or blocked; how priorities are established in a disaster, when there are not enough ambulances; how communications are established among the dispatcher, the paramedics and doctors in hospitals; and how records of each call are logged. The study of these procedures will help you identify what aspects can be improved and how the software will become an asset to your customer. You will also have to learn about any standards that may exist, so the software can conform to them.
G. Competing software: You might discover that there is widely-used and well-respected emergency management software on the market. You might come to realize that you have little chance of economically developing something that would be as good. In such a case, you would propose that your customer buy the widely-used software. On the other hand, you might find that the market is under-developed, with many opportunities for a product like yours to excel. With extra effort you might be able to create a generic, rather than a custom product, and sell it to many different municipalities.
H. Similarities across domains and organizations: The task of dispatching ambulances could be generalized as the problem of allocating the closest resource to a consumer. You might therefore consider developing a generic framework for this aspect of the problem.