- The Need for Business Analysis
- Analyzing Business Needs
- Relationship Modeling
- Normalization
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Analyzing Business Needs
The business need has to be studied to tease out certain characteristics. These are roughly summarized as follows:
The business process, or what actually goes on in the business
The business rules, or what is allowed to happen, and what isn't
The business objects, the actual things that exist in the business
Put together, these things describe the goings-on within the business and in the business function you're trying to model. Some organizations have these things written down as formal procedures, whereas in other scenarios people just get on and do things; the procedures only existing in people's knowledge.
Whichever is the case, start by studying the information that's there by asking questions and forming a picture of what goes on.
TIP
In some cases, a database is commissioned so as to simplify or even completely change an existing process. You will need to distill out what needs to be done versus what is done.
You will often encounter a good deal of superfluous information. You'll need to take note of it, but distill it out of your model if it's not relevant.
Business Processes
Identifying business processes is often a good time for drawing a process flow of what you think is going on:
It helps you form a picture in your own mind of what's going on.
You can show it to other people who know the process and talk it through, reconfirming it to make sure that you have it right.
It may uncover missing links in your understanding, or even failings in the process as it's been described.
It provides a reference point to look back on as the project moves forward. By compiling notes and process diagrams as things develop, you have an audit trail of the development of your ideas and understandings.
A process diagram can be as formal as you want, created with special software, or can be a pencil-and-paper sketch. Figure 3.1 shows a simple process diagram.
)
Figure 3.1 A simple business process diagram.
Inherent in the language used to describe events in the process is the concept of transac-tions. A transaction is an essential part of the business process where a definable event occurs.
A business transaction may itself be comprised of smaller transactions. However, it may be important to carry out a transaction completely, or not at all.
For example, the system for an online store may dispatch the goods ordered and update the stock level, but not just dispatch the goods. In your process diagram, you will normally have such smaller events described, but it should be clear which of them are grouped together into transactions that must not be divided.
Because most electronic business systems and the Internet operate on a transaction basis, it is important to understand your business process as a sequence of transactions rather than any kind of real-time continuum.
Business Rules
When it comes to business rules, some things will be defined clearly, whereas many rules will be common sense. Rules declared by the business may come about because of business strategy, they may arise from local management decisions, or they may be in place because of legislation or other causes. Declared rules are the most easy to spot.
There are also "common sense" rules, which are present in an implied sense. With any kind of rule, never ignore the need to ask questions of the obvious, and look for clarification in what is obscure or complex. With implied rules, the need to ask questions is most important.
For example, the rule "customers' payments must be non-negative and greater than zero" might sound like a common sense rule for an ordering process.
But the statement must be questioned. If the answer is not clear, you need to understand the rule a little more, and perhaps ask some "What if?" questions.
For example, what would a negative payment mean, when applying the preceding rule? A negative payment from the customer would effectively be a refund, so to fully understand the scenario you need to find out how refunds are implemented.
And what of zero payments? Perhaps there's a "Buy one, get one free" policy, which under certain circumstances might mean that a zero payment would be allowed. Again, you must ask the question.
As with the mapping out of business processes, a paper and pencil (or even a suitable software package) is of great benefit for defining the business rules, whether they be declared or implied.
Business Objects
Business objects are the "nouns" or "things" of the system you're trying to model.
For example, a store with a product ordering system might have objects like these:
Products
Product categories
Customers
Purchases
Invoices
Credit card
Bank
Establishing the business objects is generally a little easier than establishing processes and rules, but make sure that you look out for both tangible things (such as products) and intangibles (such as purchases).
After you identify the objects, you need to study the characteristics of each. For example, an invoice might have the following characteristics:
Invoice number
Date of issue
Value excluding sales tax
Customer name and address
Value of sales tax
Value including sales tax
Putting the Picture Together
After you identify the business objects and understand the rules and processes that bind them together, a picture begins to emerge. With this picture, you can start to define the database application required to fulfill the need.
There's not a clear path for translating objects, processes, and rules into an electronic system, but business objects often translate roughly into database tables.
After all, relational databases were conceived to model business entities: each table often represents a business object, each column represents a characteristic of that object, and each row of data represents an instance of that object.
The business process you've described will to a large extent be implemented by the application software you specify. It will dictate what you have on each screen of the electroncic system and what information flows between which objects.
For example, "check the customer's credit card details" will typically be some form of query sent to the bank, and the outcome will be a screen telling the customer whether his card appears to be okay. Likewise the acceptance of the order may generate an email to the warehouseman to collect some products from the physical store.
The business rules will manifest themselves in several ways: they may influence the data types allowed in the tables (for example, a customer's name will be a text field, not a number), but will also dictate what's allowed by the application (for example, the application may check that a credit card number is a number, and not text).
Looking at the rules in relationship terms, they will dictate where there are one-to-one, one-to-many, and many-to-many relationships between business objects—and thus between tables. For example, there may be many invoices for a given customer (but each invoice has only a single customer), so in this sense the business rules look likely to govern our use of indexes in the tables representing these objects (namely, invoices and customers).