Boehm stated that validation was to ask if we are building the ‘right product’? Architecturally based software engineering activities support validation by mapping the functional and non-functional requirements to the overall design, system design(s), code design and implementation. These diagrams are attempting to construct the right architecture, to build the ‘right product’. The aforementioned are completed using diagrams including Use Cases, Sequence, Class, E-R, Data flows, Wireframes and Architectural Concepts and Overviews.
These diagrams take the system specification from the conceptual and high level, down to classes, objects and entities, which will lead to coding and development. They also overlay components, systems and software by employing, Use Case data flows. This detailed approach should help remediate the ‘impedance mismatch’ between design and code – a significant problem in IT.
This detailed documentation approach, allows validation to be done throughout the software-development-life-cycle-process and is present in developing Conceptual-Logical-and Technical Architectures. We do this to validate if the specification being built, really captures the customer’s needs. The various levels of diagrammatic detail need to fit into an overall logical-technical design. The chosen components or software will need to conform to this design.
Easterbrook, 2010 Textbook, Boehm’s model amended.
Validation can be a subjective process, using experience, patterns, case studies and informed by constraints (non-functional, budget, time). There are many ways to cook a chicken. There are likewise many ways to develop and architecture and system. For example, a client may be an ‘Oracle shop’ and all software, systems and servers should be designed and built on that premise. In this case, the various layers of diagrams may be different, than if the same firm issued a constraint that they are a ‘Microsoft shop’.
To understand what approach is best, validation should include activities such as requirements modelling, prototyping and user evaluation, based around technology-choice constraints, resource and skills, time and budget.
