From the author of

From the author of

Application design has become a critical topic as the complexity of Windows
solutions increases. Historically, Visual Basic has had the reputation of being
a rapid prototyping tool, which led to a "design as you code" mentality.
As systems became larger, however, this mentality led to significant problems
with scalability and maintainability. Although many Visual Basic developers
have moved toward a more rigorous development methodology, the community as
a whole has not made enough progress.

My preferred design process is a variant of the Rational Unified Process (RUP),
which combines many object-based design methodologies into a whole. RUP encourages
both text and graphical modeling of the system before beginning the coding process.
In its commercial version, RUP is also supported by a set of tools available
from Rational Software. These tools help create the models necessary to successfully
define a system. I have used—and like to use—many of the Rational products,
but they aren't required to complete your design. You can easily use other tools
such as Visio or Microsoft Visual Modeler to create your models. In this article,
I summarize this development process.

Assessing Functional Requirements

The design of every system begins by recording exactly what's to be accomplished.
Often programmers—and even my customers—scoff at the notion of writing
everything down. Even now, many of them believe that a system can be defined
verbally in a single meeting. I have been known to turn down such projects rather
than suffer through the agony of shifting requirements. The best projects, however,
begin with a simple problem statement.

Problem Statement

A problem statement is a paragraph that describes exactly why the system is
being created. It clearly states the project's objectives and what problem is
to be solved. The problem statement should be free of technical acronyms. State
the problem in terms of the business objective, not the technical objective.

Gathering Requirements

When the problem statement is written, you are ready to create a list of functional
requirements. The list of requirements enables you to attain the next level
of detail in the design. Functional requirements are always a group process.
In this process, assemble everyone who has an interest in the project for group
meetings.

To identify the functional requirements for the system, work with the project
sponsor to identify all stakeholders. These stakeholders are then invited to
a series of meetings to discuss the project and its requirements. I refer to
these meetings as facilitated sessions because a knowledgeable mediator
who can keep the group on track guides the meeting, derives requirements, and
presses for buy-in. The purpose of the meeting is to create a list of functional
requirements.

After creating a list of functional requirements, place them before the group
on a dry-erase board or large sheets of paper. Now ask the group to prioritize
the list. Prioritization is done by using a simple A-B-C scheme. The group should
be asked to vote A, B, or C for each function listed. From this vote, the facilitator
will declare each function as A, B, or C based on the following definitions:

Priority

Definition

A

Absolutely required

B

Enhances the product

C

Nice to have, but not crucial

Obviously, various stakeholders will have different ideas about what requirements
are absolutely essential. However, the process demands that they convince others
in the room that the functionality is essential; otherwise, the group will cumulatively
vote for a B or even a C. This group ranking is critical for eliminating extraneous
features and constraining the scope of the project. We also see that stakeholders
are willing to accept the judgment of their colleagues in regard to the feature
set. This process leads to buy-in because each stakeholder has a chance to make
his case, regardless of whether he ultimately prevails.

Assessing Requirements

To aid in the assessment of the function list, create a new level of detailed
description. To arrive at the next level of detail, the project sponsor is asked
to identify domain experts for each feature on the prioritized list.
A domain expert is someone highly knowledgeable in the requirements for the
function. For example, the sponsor might identify a salesperson as the domain
expert for promotional features. Allowing the champion to identify domain experts
helps eliminate project enemies from the process. Everyone had a chance to be
heard at the initial meeting, but if isolating a person is required to ensure
success, this is where it happens.

For each feature rated A or B, define several options for implementing the
feature based on interviews with the domain expert. In these interviews, we
ask the domain expert to identify the ultimate solution for the problem, regardless
of cost and time; a middle-of-the-road solution that considers cost and time;
and a "bare bones" solution that will work in a pinch. The idea is
to give the sponsor a large menu of options from which she can assemble a system
that fits into her priorities, time, and budget.