Jim Schardt’s Blog

Does your software/web application gain the benefits of Object Orientation (OO)? Well designed object-oriented applications exhibit high cohesion and low coupling. Small changes to requirements mean small changes to the code. Just because you use an OO language like Java,C#, C++ etc. does not mean your application benefits from object-orientation.
Continue reading…

Readers of this blog may have noticed a new feature in the column on the right side of the page. An icon that will take you to DevelopMentor’s blog aggregation site. There you can find other blogs related to software development. Below the icon are links to Concepts, Tools, and Type topic areas that readers of this blog should find interesting. Check it out.

As a contractor to DevelopMentor I teach, mentor, and develop course content on the topics I cover in this blog. If you need to further your education in software development (and who doesn’t in this fast paced world) consider what DevelopMentor has to offer.

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…

Thinking of your system / software / business unit as a black box is a great way of avoiding statements that are not requirements. Consider the statement, “R-1.1 The Payroll Department shall send the Summary Employee Report to the Accounts Auditor each Friday by 1600 GMT.” This requirement is for the “Payroll Department” system. The black box represents the entire Department. As a requirement for the Department the R-1.1 statement describes something (the Summary Employee Report) that goes from the inside of the black box to the outside, namely to the Accounts Auditor. We can experience and measure the report leaving Payroll no later than 1600 GMT on its way to the Accounts Auditor.
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.

What is the hardest thing to estimate on a remodeling construction job? I asked a friend of mine who happens to be a contractor in the building trades. Not surprisingly he said it was estimating the hidden elements of the job. (Hmmm… software is mostly hidden)
Continue reading…