How a business analyst moves from business documents to software design

As a business analyst, I'm always asked how I get from (a) having absolutely nothing but a project charter or mission statement to (b) having a complete design of a software system. People are amazed that just by talking (and working together) we can build a terrific computer software system that meets their needs.

One of the techniques a business analyst uses -- either consciously or unconsciously -- is a process I refer to as "semantic analysis". What this refers to is the process of breaking down the things people write or say into software objects (classes) and/or database tables. This process is something we normally do in our brains, and I try to teach it formally to get programmers and analysts to understand what they're really doing.

As a training exercise, I teach business analysts and computer programmers to review business documents like a project charter or mission statement, and highlight the nouns and verbs as they go along. In many cases the nouns become "objects", and the verbs become "attributes" of those objects. (Of course it's more difficult than this, but this is a great starter exercise for new students.)

A simple business analysis example

As a short example of this semantic analysis technique, let's imagine we meet a new customer, and we're given a mission statement that begins like this:

"Our company will create the best pizza the world has ever seen. We will have the freshest toppings, grown right here in Alaska, terrific crust and cheese, and we'll serve a few other items like breadsticks and soft drinks. We'll serve our customers by delivering fresh, hot pizzas to even the most remote locations in Alaska."

From even a simple statement like this we can easily find some nouns, and these nouns might turn into software objects or database tables:

  • Company
  • Pizza
  • Toppings
  • Breadsticks
  • Soft drinks
  • Customers
  • Locations

Anyone who has ever had a pizza knows that a pizza can have one or more toppings, so there's clearly a relationship there. In Java code this relationship might be coded like this:

public class Pizza 
{
  private List<Topping> toppings;

  // more code here...
}

With a database like MySQL, we'd start to define a database table like this:

create table pizzas (
  id int unsigned auto_increment not null,
  // TODO we have a relationship with toppings
  // TODO define other attributes
  primary key (id)
);

Given a larger and more real mission statement, we'd probably also find many verbs and adjectives that further describe these objects, so we'd create those as attributes in our objects and database tables.

For the purposes of this article, let's assume that based on further conversation, and a knowledge of business in general, we also quickly learn:

  • The Company has Employees.
  • Employees have roles like Order Entry, Pizza Maker, Delivery Person, Store Manager, and so on.
  • Employees get paid by the Company, either hourly or on a salary basis.
  • Customers create Orders, and Orders have Line Items.
  • The Company has Stores (or Locations).
  • Stores have inventory, and that inventory is reduced by certain quantities whenever and Order is created.

Once again, all of these statements that we learn from the project stakeholder and team members can be turned into computer code. By now we can define an Order that looks like this:

public class Order 
{
  private List<LineItem> lineItems;
  private Customer customer;
  // define orderTotal
  // handle taxes
  // handle inventory reduction
  // registerUsed
  // employeeWhoTookOrder
  // much more ...
}

and an early guess at an Employee looks like this:

public class Employee
{
  private List<Role> roles;
  private Date startDate;
  // TODO handle salary information
  // TODO part-time or full-time
  // much more ...
}

I'm not attempting to create anything like a complete design at this time, I'm just trying to define what I know, and also leave placeholders or "To Do" items for things I don't yet know. Those To Do items become questions in our meetings.

As you can see, even with simple discussions we can quickly begin defining the objects and attributes of a software system. (These objects and attributes also help us determine the "size" and cost of a software system, but those are topics for future articles here.)

Summary

I hope this article has helped demonstrate this technique of "semantic analysis." In summary, by semantically analyzing the project documents given to us, and by using our knowledge of software systems and business, we quickly moved from nouns and verbs to creating an object model that describes the business processes at hand.

Of course in the real world a business analyst will run into much more complicated scenarios (a pizza at Papa Johns, for instance, actually consists of two halves), but as an introductory tutorial, I hope you can see how a business analyst begins to move from business project documents and discussions into software requirements and design.