Types of Documents to Use in Business Analysis
Documents useful to business analysis can be many things in many formats, from actual printed documents to printouts of screenshots to websites and blogs containing company and department information.
Old doesn’t necessarily mean worthless. Even if a document is a bit long in the tooth, you can still use it as historical data and check to see whether the processes and data it mentions are still valid.
Reports, letters, and brochures
Any of these artifacts is a gold mine for understanding how a company implements its processes and enforces policies. Each document holds its own special secrets:
Reports: Aside from the actual data contained within it, a report tells you a lot about the audience for the report and the decisions the business makes based on the information. It also shows you how the data is sorted and whether it can be re-sorted.
Letters: If you need to understand the various questions a company handles and how it responds to them, look at the letters it produces. Look into the customer service area of a company, for example. Chances are that it has lots of standard letter templates it uses to interact with customers.
Brochures: Brochures are a great way to understand the products and services a company offers its clients. They also tell you a bit about how the company sees itself — or how it wants to be seen — in the world.
A company’s website can give you an invaluable look inside the organization. Not only do websites typically give you information about location, contact methods, and maybe even merchandise return and service call processes, but they can also tell you a lot about the company’s culture, values, and mission.
Spend a lot of time perusing the pages and taking notes: Is the website large or small? Is it text-based or photo-based? Does it seem to make a lot of information available to users, or does it encourage clients to contact the company for more info? What kind of image is the company presenting with its website?
You can learn a lot about a company by simply looking at how its program screens are laid out when it performs business operations. What data do its processes need? What fields is the user required to fill out? How about the labels on the screen? Are they built dynamically (such as to recognize a returning/logged-in user: Welcome, Paul)?
You need to understand where that data is coming from and how the screen builds it dynamically. Also, think about how the screen functions. What happens when buttons are pressed, or how do buttons get enabled?
Be careful of talking too much about the style of the screen too early. You need to understand the data, processes, and people who require access; then you can create a solution, which may be to continue to use the green screen or go over to a graphical interface.
Here are a couple of ways to document the key on-screen elements:
To document a screen layout, take a screen shot of it by pressing the correct keypad sequence for Print Screen and then save the file.
To save a whiteboard drawing of a screen layout, take a picture of the whiteboard; you can even use a smartphone!
Forms are very similar to screen layouts, only they’re on paper. If a domain subject matter expert states that he fills out a form in the operations, ask for a copy of the form.
Some forms even have boxes showing you how many characters you’re able to capture, so you have a starting point for capturing data field lengths. The forms may indicate which fields need to be completed and which don’t.
User procedure manuals
Business rules are probably contained in the user procedure manuals. By reading these manuals, you can understand how the user should complete a procedure.
Looking through user manuals doesn’t highlight only business rules. Business rules require data in order to perform their calculations or enforce their policies, so remember to gather and analyze the data, too.
System documentation, along with system architecture and interface documents, provides a lot of information about how everything works together. This data is especially relevant when it comes to your solution design because you can easily keep track of which systems your solutions are linked to and then understand the impacts of making changes based on stakeholder requests.
The information you get early on in the project helps you as you move through the project and put different solution options on the table.
Whether you ask stakeholders for the location of current system documentation or you go off and find it yourself on SharePoint, servers, or in the documentation library, you can discover that an awful lot of information already exists about current projects. Here are some documents containing information for review that you should keep an eye out for on your search:
Business requirements document (BRD): This record provides information on what the business needed for the particular system in which the BRD was created.
Interface agreements: These documents list the data fields contained in an interface with another system. They also may indicate the valid values used in the interface (for example, the interface may not use all the data fields available).
Scope diagrams: These diagrams show which parties and systems are involved in a particular project.
System architecture: Use these documents to see how various components of a solution link together to form a complete business system.
Functional requirements document (FRD): Also known as a functional requirements specification (FRS), the FRD shows how the business problem was solved.
User interface specification: This document shows the screens within the system, including expected actions when users mouse over a field, click on a button, and make selections within a screen.