What I should look for in a software design document from verification and validation perspective?

Question

Hi

I have been given a design document to verify and validate (V&V). The document is filled with statements like "The module shall be capable of .....". In addition it contains use-case diagrams and sequence diagrams (only).

The actual software (supposed to be build) is a GUI front-end for several sub-systems which is in continuous communication with the back-end subsystems via query-response. When the response is received, actions in terms of display or user interaction takes place.

I feel that the document doesn't seem to address design (no design decisions and so on) and is far from having a good design. However

1. I am not really sure if my hunch is correct?

2. Based on the above scenario, if I have to suggest few essential elements that should go in any good design, what possibly it could be? or stated differently if I remove/ignore that design element in the design process the software is doomed to be poor quality.

I would be very thankful for responses.

Answer 1

Well, I guess I would start with the definition of the task you've been given.

To verify the design, you need to check that it meets the requirements. If you don't have a requirements document, that's going to be difficult.

To validate the design, you need to check that it meets the intent of the requirement (the needs of the customer/user/stakeholder).

In short, to verify: does it propose to do what it said would do?

To validate: does it do what it's supposed to do?

Answer 2

The simplest test I can think of is:

Is the information in this document (together with perhaps other, well-defined documents) sufficient to enable the person building the next work product to do so?

So the crucial thing here is: what's expected to happen next. Two possible examples:

• A developer writes some code. (On your description it doesn't sound like the Design doc is sufficient.)
• A detailed design document is produced. (This is a possible way of working.)

Possibly there is an informal understanding of how this application would be built. This could be the 98th such app that's being built so some details are just not written down but "everybody" knows how to do it. Or there is a standard approach to back-end integration, so we don't need to decribe how to do that here.

If any of those external information sources apply then I would hope to see a reference in teh document even if that reference is very terse.

Given those caveats at the very least I would expect to see these kind of things:

1). UI details. Screen flows, Standard screen contents and menus, wire-frames for each screen (or at the very least a list of fields. 2). Validation details and formatting. Especially any interesting error processing.

Then there is the question of the overal structure of the application. MVC? What componenets shall there be? Again, perhaps we just reference some known technique "Standard Struts App with JSP" but there does need to be at least some "how" material.

Finally how is the back-end connectivity to be done. Two aspects here: technology and specifics interactions.

It may be that you have an SOA, web services for everything, so the technology is well understood. Or perhaps for each back-end CICS, SAP, PeopleSoft ... there's a different technique. In which case these need to be described. Conceivably some integration code needs to be developed from scratch, in which case detailed design is needed.

Then whatever technologies have been adopted, there's still the question of exactly which "transactions" are used and how the data retrieved from the back-end maps to the screens.