Chapter 3. Introducing the Project

You're sitting in your office, surfing the . . . I mean, reading up on the latest technology issues most pressing to software developers. You're minding your own business, when boom, someone walks up to your desk, and offers to pay you money to write them a program. It happens every day, all over corporate America; and sometimes it just makes me sick.

But enough about my health problems. This desk-hovering somebody informs you that you must develop a software application, possibly a database application with a user-friendly interface. Although the feature set will be specified by the primary users, you, as the lead (or only) programmer, will design, document, develop, and deliver discs dripping with distinguished, dazzling, and dynamic digital . . . um . . . software. (Darn.)

Well, that's what happened to me. A client of mine had a large collection of books that needed to be organized as a traditional library. Seeing that I was a reasonably codependent software architect, the client asked me to develop some software to manage the books and such. Out of this request came the Library Project.

As you read through this chapter, you will have to keep my day job in mind. I write custom Visual Basic applications for small- to medium-sized organizations. Most of the projects are sized so that I can complete them by myself, including all design and documentation requirements, in less than a year. All of my projects involve a "key user," one personor sometimes a very small groupwho speaks for the user community. These projects also involve someone who has "signature authority," a person authorized to pay for the project, or decide on its continued existence. This individual may be the same as the key user.

If you were developing, say, a replacement for Microsoft Word, you would likely lack a "key user." To obtain the specific requirements for the project, you may have to conduct general user interviews with dozens of user candidates. Or you might create a "virtual user," a fictional person who represents your intended target audience. Whichever method applies to you, the general discussion in this chapter should guide you to the happy conclusion: a design document that you will use to build the application.