Jim Schardt’s Blog

To avoid the “foreign language” feeling for users of a BI/DW system you must start with the decision makers. They are the ones who are going to use business intelligence profitably. They are the ones that turn the information in your data warehouse into usable knowledge. So, just talk to the users. It sounds so simple.
Continue reading…

Sometimes Decision Makers view the Business Intelligence system as if it were a foreign language. They took the training. They tried to get information out of the system. But they gave up because the terms
used in the interface between them and the Data Warehouse are not the terms they use to conduct business. For instance, the Manager of Sales is thinking, “Account.” To them account is a shorthand for customer account which embodies the name of the customer, and some sense of who that customer is. When they get to the BI system they see, “Party.” Party in this context relates to participants in a sales transaction, one of which is the customer. I say account you say party, let’s call the whole thing off.
Continue reading…

In my last post I talked about how requirements are really the stuff that goes in and out of your system, the black box. The “stuff” are things like data, documents, objects, requests, events, and when “this stuff happens. But what else constitutes requirements (stuff)?
Continue reading…

Input and Output of a Black Box

Once the boundaries for your system / software / business unit are defined as a black box, do not worry about what is inside the box. Focus on what goes in, what comes out, when this happens, and rules the box must follow. So just what can go into our come out of this box? As I gather requirements I look for data, requests, and events.
Continue reading…

After dealing with requirements in all sorts of shapes and sizes over the years I find the “black box” approach works well. For requirements, I think of any system as if it were a black box.
Continue reading…

So how do you define requirement? I was working with a large hospitality corporation when I was asked this question. The problem is that the notion of requirement comes in many forms. The definition seems to depend on what role you play in relationship to requirements definition – Customer, Business Analyst, Systems Analyst, Designer, Architect, Developer, Tester, etc. Wikipeidia describes requirement as a statement of what a product or service does. IBM’s Rational Unified Process describes different levels of software requirements. They also use related concepts like need and feature. The Internaltional Institute of Business Analysts contains a definition from the Business Analysts perspective in their BA Body of Knowledge.