A Full Software Development Lifecycle Testing Project - Software Testing: Testing Across the Entire Software Development Life Cycle - page 215

design of the representative components is on track, the developers design the re-
maining components.

13.4.3 Logical Design Static Testing

How do you go about static testing the application logical design? Because we now
have a basis for logical design, namely the requirements, the static testing approach
is cross-validation.
First, we validate the logical design against the requirements by asking the fol-
lowing kinds of questions.

• Does every component of the logical design correctly represent its referenced

requirement in the use cases?
Are there logical design components that do not reference requirements? If so,
why have these components been included in the logical design or, conversely,
did we miss some requirements?
Does the logical design make sense in the context of the overall scope and
purpose of the application?

•

•

An example of the fi rst bullet can be demonstrated by comparing the simple
menu structure requirement in the use case suite supplemental requirements with the
user interface design menu/screen hierarchy. The simple menu requirement implies
that the completion certifi cate action screens should be found immediately behind
the main menu. The proposed menu/screen hierarchy locates the completion certifi -
cate action screens behind a secondary menu behind the main menu. When asked to
reconcile the two approaches, the development leader replies that the new secondary
menu structure for completion certifi cate action provides economies of main menu
screen real estate without any expected decrease in ease of use.
If this design change caused the completion certifi cate clerk to revisit unneces-
sary menus many times during the workday, then the longer screen navigation path
would not offset the main menu real estate considerations. The developers expect
the completion certifi cate clerk to navigate the menus once at the beginning of the
workday and stay in the completion certifi cate data entry screen most of the day.
Therefore, this interface design change does not really confl ict with the overall ar-
chitecture goal of a simple menu structure.
Second, we validate the requirements against the logical design by asking the
following question.

• Have all requirements been represented by at least one logical design com-

ponent?

As with requirements static testing, we will expect a few user interface design static
testing defects to be discovered. These defects must be corrected in the documenta-
tion and retested before the Design stage can be considered completed. The com-
pleted, verifi ed logic design is the next documentation step that represents the “S”
in SP RAE.