email article printer friendly more resources

Secrets to Successful SQL Server Programming
Here's how to create the programs your users need.
by Buck Woody

November 1, 2004

You build custom cars for a living. One day, a guy walks into your shop and says, "Here's $30,000. Make me a cool, fast, light, and dependable custom car. I need it in three months. Can you do it?"

"Sure" you reply, and create a vehicle that by any measure is cool, fast, light, and dependable. The client returns and you show him your effort. You notice, however, that his expression falls when he sees it.

"OK," he says, "I'll try it." He comes back in a week, and tells you the car doesn't work.

You're shocked. "What's wrong?" you ask.

"I could only put three two-by-fours in the car, and I couldn't tow anything at all!"

Your response is, of course, that you didn't know he wanted to haul lumber and tow trailers.

Writing software is a bit like that. You might have all the information you think you need to start programming, you might be an expert in the language you write in, but not knowing what the users really need can torpedo your best efforts.

In this article, I'll cover what you need to learn to program using SQL Server. Some of the concepts I've mentioned before, but in this article I'll bring them all together, along with the other processes and procedures that you'll need to understand to create effective programs.

You won't learn everything you need to know to begin writing programs—I'd need a bit more room than just one article for that. What you will learn is the overall concepts to create programs in almost any language—and there are several you can choose from. Think of this article as a quick overview or primer on the development process.

Creating the Requirements
Often the assumption on the business side is that IT knows what it wants. The assumption on the IT side is that the business side has communicated everything it needs in the initial request. Unfortunately, without a formal process neither side sees the whole picture.

To begin, it's important to get the group that is making the request to present a formal, written document that describes everything it wants the program to do. This document should include business process models that show how the data moves from creation to presentation.

Business Process Model Notation (BPMN) is ideal for this kind of effort. It's a great tool that uses only four kinds of graphics—flow objects, connecting objects, swim lanes, and artifacts—and three basic shapes: circles for events, rounded rectangles for activities, and diamonds for branching and looping. It's intuitive and allows for a detailed description of business processes. Almost any graphical tool can create the shapes. You can find out more at the BPMN Web site (see Resources).

In addition, the document should describe what happens—not what forms are currently used. One of the biggest mistakes you can make as a developer is to "program" a current form. The form might not represent what is needed at all, and even if it did, paper processes do not necessarily correlate to electronic process automation.

There are many requirement document templates available on the Internet. The one you choose should at least include these elements:

• Overview
• Purpose
• Objectives
• Current process steps
• Steps to be automated
• Features
• Functional requirements
• Performance requirements
• Security requirements
• Data disposition requirements