Using the UML to capture business requirements lends a tremendous benefit to everyone on the database team, including the data analyst, database administrator, data modeler, and any others who work directly or indirectly with the database.
By using the UML as a common language among the analysis, development, and database teams and working together to understand the requirements and create the use case models of the business, you can best learn how the business works and what type of information needs to be captured. Data is the most im portant artifact of the majority of organizations that exist today. It includes most financial, customer, employee, and product information along with a variety of other information that allows a business to continue to work on a daily basis.
In many organizations, business analysis is done without at least consulting the database community or even taking the data into account. This is a recipe for disaster. Without working closely with the database community when building enterprise architectures, you cannot effectively model and understand the business. The database teams need to participate in the capture of business requirements and the process of understanding the current and potential future business goals to be sure that what the group believes is needed by the business can be accommodated by database services. We have seen many system requirements built and even applications begun fail because the database team's view was never considered. Having all teams participate from the beginning ensures that every point of view is considered. This does not mean that 40 people must gather in a room to come up with requirements; however, each stakeholder in the project should be represented. The involvement of each team in understanding the business processes will allow each one to suggest ways to build the architecture for the system to solve the business problems that are uncovered. Not having all necessary teams involved will cause a breakdown of communication and the development of an architecture that doesn't meet all parties' needs.
For database designers, working on a project this early in the system life cycle may be an unusual experience. Therefore, the focus of business modeling must be kept in mind at all times. How does the current business function? How does your customer want the business to function in the future? (Whether the customer is the actual end user of the system being built or the business people in your company who are responsible for having the system built for that end user, or both, depends on the structure of your business.) At this point, the emphasis is on the business processes and not the hardware, software, and manual operations that will implement these new processes. This poses a dilemma for the designers. Since we must understand the current business, people will naturally discuss the current business in terms of existing hardware, applications, and databases with which they are familiar. This type of discussion has an important place in business modeling, but we must not allow it to redirect the team away from the key question: What must the new system do? How the system will perform its functions is determined much later during the design phase.
The analysts should approach business modeling as a cooperative effort among themselves and the business people. This usually will take the form of meetings to elicit the needs of the business. Joint Application Development (JAD) sessions help the group understand the business. JAD is the process of bringing project participants together in structured group brainstorming sessions to define requirements, gather essential information, and make critical decisions. JAD results in faster discovery and enhances analysis and decision making by uncovering the information needed from various points of view. In this process, individuals or groups sit together and have an open, free-flowing discussion of ideas, which requires detailed note taking and modeling of some of the discussion on the fly.
Often there will be much heated discussion among the business people about what the business really does and how the various functions are performed. This is not to be discouraged. This is not an indicator that they don't understand the business. It is more likely they've never had to explain all the intricacies in detail before. Let the discussion continue awhile before you refocus the meeting. You don't want to build the wrong system just to avoid some temporary discomfort or embarrassment.
Set the expectation that many short meetings will be needed to refine the business model. In fact, to make the most of the business people's time, you may choose not to do any modeling during these sessions. You may just gather as much information as possible and do the actual modeling later. This often depends on whether the business people are amicable to the idea of modeling. Don't try to model the entire business in one meeting. In fact, it is unlikely that you will need to model the entire business at all, unless you are tasked with Business Process Reengineering. Business modeling is more focused and narrower in scope. As you proceed with your modeling many questions will arise. Your models will change greatly as your understanding of the business needs evolves. Be assured that this is normal, but sometimes it disturbs those in charge. You need to get long-term buy-in from the business people for this process to be successful.
Your goals for business modeling are varied. You should strive to understand the existing business. You may or may not choose to model the existing business. In this case study, the goal is automation of the existing paper-based records system; therefore, knowing the existing business is important. You must understand the business needs that are driving each specific development project. Those needs will drive the development of the new business model. The information you elicit in the brainstorming sessions should provide you with ample knowledge to create a conceptual data model. The conceptual data model will contain the key data entities, their names, their relationships with each other, and possibly some critical attributes and/or candidate keys.