Design Specification Tools

Design Specification Tools

Chapter 4 discussed specification formats that can be used to communicate information to both users and technical development personnel. Chapter 5 focused on the specific tools to create the logical equivalent. A diagram was used to show how an architect created a drawing for the user and a blueprint for the builder. This example was expanded to relate to the analyst:

In this chapter, we will focus on the process specification portions of the system, both from a user and a development perspective. The process specification is a component of every modeling tool.

Business Specifications

The ultimate purpose of the business specification is to confirm with the user the requirements of the system. In the picture in Figure 9.1, this confirmation is shown in the form of a prototype. Although this is the best way to confirm requirements with a user, there is always a need to have certain logic and flow documented in the form of a business specification. Chapter 5 presented the business specification in Figure 9.2 and defined it as a summary of the overall requirements of the system.

The business specification was written in a prose format so users could be comfortable with its meaning and intent, so that they could approve it. Although an overview like the one above is helpful, it is often incomplete and may not actually provide sufficient information for the user to approve. In order to provide more detail, the analyst should include the following components with many business specifications given to a user.

Functional Overview Sections

Functional overviews effectively take the business view a notch down in detail. A function can be considered a subset portion of the whole specification. For example, suppose a business specification was designed to handle order processing. Order processing would be considered the overall business specifi- cation goal; however, a subset function of the overall project could be picking order items from the warehouse. The subset description of the process is similar

Figure 9.1 Analyst interfaces.

Figure 9.2 Sample business specification.

to the general overview and simply puts the subset functionality into perspective using prose format. After each subset functional overview is completed, the user should have enough information to understand the requirements of the system. It is important that the analyst make every attempt to keep the general and functional overviews as short as possible yet accurate and complete. This may sound contradictory; however, users typically do not like to read long documents summarizing all the detailed events of a system. Although Figure 9.3 looks like an overview, it is focused solely on a subprocess called Discounts.

Functional Flow Diagrams

Wherever possible it is important to use graphical representations to verify the accuracy of a specification. A high level data flow is suggested to allow the

Figure 9.3 A functional business specification summarizing the requirements for a discount component of the entire business specification.

user to see a graphical representation of the overall requirement (see Figure 9.4). Analysts should be encouraged to educate users so that they understand simple modeling concepts and tools.

Screens and Reports

The business specification should also include sample screens and reports. The level of detail of the screens and reports will vary depending on the prototype tools being used and the available time framed that the analyst has to get user sign-off on the requirements. CASE can be used where screen and report interface are available (see Figure 9.5). Analysts should avoid CASE products that contain drawing capabilities as opposed to true screen and report generators. Today’s programming tools typically have prototype capabilities. The advantage here is that part of the development work is being accomplished during analysis and design. Using actual development tools during analysis and design is yet another form of Rapid Application Development (RAD).

Figure 9.4 High Level DFD. Although a DFD, it is designed at a very simple level to allow a user to confirm flow.

Figure 9.5 CASE screen design. The above screen was created in System Architect and contains connectivity to physical application products such as Powerbuilder.

Therefore a good business specification should include the following component documents:

Programming and Technical Specifications

Once the business specifications are completed and agreed upon by the users, the information must be mapped into a programming or technical specification. These specifications effectively provide all of the algorithms that are required by the functional primitive DFDs and STDs. That is, each functional primitive must point to a technical programming specification. This programming specification will define all algorithms which affect the process. The programming specification must also, however, point back to its original functional business specification as shown in Figure 9.6.

Figure 9.6 Relationship of specifications with DFDs and STDs.

Another way of explaining the relationship is to say that an overview business specification can have many functional business specifications. Functional business specifications can have many programming specifications and each programming specification should be associated with one or many functional primitive DFDs or STDs. The example of a technical/programming specification contained in Figure 9.7 initially appeared as Figure 5.11 of Chapter 5.

The programming specification in Figure 9.7 utilizes the pseudocode method discussed in Chapter 5 and provides the necessary information for a programmer to develop the application. Many IT professionals often feel the need for programmers to understand the business specification. If the program specifications are developed using the methods recommended herein, then there is no such requirement placed on the programming team. Good programming specifications stand alone, like a good blueprint that will allow a contractor to build a house without ever being part of the development and confirmation phases with the buyer. Programmers who can focus on the engineering issues rather than user requirements will be much more productive. Therefore, IT professionals who share both roles, that is, those with the title “Programmer/Analyst,” will always be susceptible to doing both system requirements and engineering development simultaneously. Doing both “as you go” poses a real danger in that the individual has to continually change hats without really separating the tasks. In addition, when the two tasks are combined it typically results in a longer development life cycle and one that has less quality because neither task is ever really completed. Furthermore, the skill sets of analysts tend to conflict with those of programmers. For example, analysts should enjoy interacting with users and need to develop skills that allow them to gather the information they need. Programmers, on the other hand, often are not comfortable with user interaction and are more focused on their technical knowledge of software and hardware products.

Figure 9.7 Technical/Programming Specification.

Screen Specifications

Another method of creating specifications, particularly when data flow diagrams and process diagrams are not used, is to create them directly from the screens themselves. This is usually accomplished by having two levels of screen processing specifications. The first type of specification is used to describe the functionality of the screen, especially as it relates to its execution options. The second type of specification relates to how the data elements on the screen are to be processed. By process we mean the business rules that govern how the data element is treated by the screen program. For example, a data element in one screen program may be used only in display mode and not allow its value to be modified. Yet in another screen, the very same data element may require modification.

Therefore, a screen specification has three components: (1) the screen itself;

(2) screen processing specifications; and (3) data element specifications. There should be one data element specification for every data element that appears on a screen. Good specifications will even use the same data element definition across multiple screen specifications just to ensure that there are no elements that are left undefined in any screen definition documentation.

Figure 9.8 shows a screen designed using Oracle Developer 2000. Figure 9.9 depicts the screen processing requirements. Specifically, the screen processing specifications provide a description of the purpose and functionality of the screen, as well as stating how each function button is to be handled by the program. Figure 9.10 is an example of a screen data element definition in which Vendor_No is used to fetch and display Vendor, which is the vendor’s name. Note that the form is designed to state specific information necessary for a programmer to complete development, including the domain of values of the data element, its definition in terms of processing, and whether the value can be added, deleted, or modified from the database.

Screens and Derived Elements

In Chapter 6, the handling of derived data elements in normalization was defined as a type of 3rd normal form failure. That is, derived data elements, commonly known as calculated fields, were eliminated as a stored attribute in an entity. However, screens often need to calculate and display these derived elements. For example, the screen in Figure 9.8 has a field called “ELC” standing for “Estimated Landing Cost.” This element is calculated, both for the season and for year-to-date. The calculations for “ELC Season” and “ELC YTD” are

Figure 9.8 GUI screen using Oracle Developer/2000.

Figure 9.9 Screen processing requirements.

defined in their corresponding Screen Data Element Definition forms as shown in Figures 9.11 and 9.12 respectively. Thus, every data element in the data dictionary that appears on a screen must have a corresponding Screen Data Element Definition form, regardless of whether it is a stored attribute in an entity or a derived element that requires dynamic calculation.

Problems and Exercises

1. What is the purpose of business specifications?

2. How do functional overview sections relate to the entire business specification?

Figure 9.10 Screen data element definition.

3. What is the use of a functional flow diagram? Which modeling tool is used?

4. What are the five most common components of the business specification?

5. How does the business specification relate to the programming specification?

6. How does the programming specification interface with DFDs and STDs?

7. Define the three components of a screen specification.

8. Explain the purpose of a “Screen Data Element Definition.”

9. What is the purpose of having “Screen Processing” instructions?

Figure 9.11 Screen data element definition for ELC season calculation.

Figure 9.12 Screen data element definition for ELC YTD calculation.

Mini-Project

The process specifications and GUI screens are part of the requirements of a contact management system. Based on this specification, design the ERD in 3rd normal form.