Designing Visual Basic Applications Using the Rational Unified Process
- Assessing Functional Requirements
- Describing the System
- Creating the Paper Prototype
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.