OhPauleez // Paul deGrandis

In a previous post I motivated the need for validation within a process.  To briefly recap:

 

Verification is pointless if no process is in place for validation.

Spending time¹ proving your solution operates correctly before you have sufficiently proven you have a viable solution is a waste of resources.  Additionally, validation isn’t just to ensure you’re delivering on a promise to your client, but also a process to enrich yourself and your team.  Your design decisions must be informed by hard evidence from case studies and your own metrics.  Validation ensures these decisions are correct.

There is very little cost in adopting validation into your process and you should only Lose Weight exercise validation to the extent you are confident in your solution.  The following are various methods to validate pieces of your project.

Requirements

Requirements elicitation and specification is difficult given that software engineering is a Wicked Problem.²  The problem gets exacerbated when there is no clear pathway for validation.

The simplest way to validate requirements is express them as use cases, be them in free text, formal specification text like Z, or graphical as is the case with UML.  Use cases can run through system behaviors and characteristics, ensuring the system is expressing all desired functional and nonfunctional requirements.  Viewpoint resolution ³ can aid in the validating requirements as well as validating the uses cases themselves.  That is, collecting and modeling use cases and requirements from multiple stakeholders with differing viewpoints of the system.  Using state-based, composable use cases⁴ will also provide validation for free while you’re specifying your requirements.

Sometimes it’s easier to express specifications as UI mockups.  Also various agile methodologies have tailored ways to specify requirements.  Decide what is best for your team and process, just make sure you’re seeking “the right thing.”

When in doubt, seek feedback.  If you’re still in doubt, leave it out.

User interfaces and experience

Creating a mockup and running potential users through documented use cases is the easiest way to validate user interfaces and experiences.  Using paper prototypes⁵ allow for instantly creating, modifying, and tailoring interfaces until the user’s expectations are well-documented and met.

User interfaces and experiences should always be continuously validated  and evaluated during creation using something like Nielsen’s Usability Heuristics.⁶  You can conduct live usability tests as a final validation once usable, interactive interfaces are created.⁷  Constant stakeholder involvement will guarantee the interface is valid.

When in doubt, seek feedback.  If you’re still in doubt, leave it out.

APIs, Services, and Libraries

API use cases are essential for the usefulness of the API and its validation. They are easiest realized in code and simple to construct.  Coding to the API before it’s written allows you to easily model the ideal interaction and use of the API.  It helps to delineate the API’s role in state management as well as its defined public behaviors, and does so before you even spend resources implementing it.  Show the potential use case to as many developers as possible and have them give you detailed feedback.  Ask them to tell you what they think each action does, and offer you one more action they’d expect the API to provide that isn’t demonstrated in the use case.

Once the API is implemented, the validation use case becomes a well-documented example of ideal usage and a potential functional test.  Users of this API will recreate and model their usage after the use case example used to validate the API.⁸

When in doubt, seek feedback.  If you’re still in doubt, leave it out.

Architecture

Software architecture is interesting in that it’s often initially built from the requirements validation process.⁹  The upfront piece of architecture takes all the possible use cases of a system that define the functional and nonfunctional requirements, and organizes them into components and connectors of various composed architecture patterns.  We then move to the obvious, how do we know we have composed the correct architecture for the requirements?

First, determine if the system was designed using a sound strategy such as analogy searching,¹⁰ literature searching,¹¹ or morphological charts.¹²  Next, the system must be correctly balanced between Occam’s razor and Einstein’s razor.  That is, the simplest architecture that meets all requirements is likely the best choice, but its simplicity should not add additional constraints on the system or its implementation.  The validity of an architecture is finally determined through evaluation methods, not unlike user interfaces.  These methods will be described in a later post, but the curious reader can search through Google Scholar or read Software Architecture: Foundations, Theory, and Practice.  Additionally, if you describe your architecture using an Architecture Description Language,¹³ it is likely that you get some form of validation for free.

When in doubt, seek feedback.  If you’re still in doubt, leave it out.

There is little cost to yourself, team, or process to validate solutions as they are being developed.  Doing so will make your solutions more robust, spare resources from pursuing less than ideal solutions, and increase your teams ability to consistently deliver performant, correct, and valid products.

1. I’m using time here as a universal resource we all have to manage.  The lack of validation affects all resources: time, money, personnel, technology, etc. [↩]
2. Wicked Problems – “incomplete, contradictory, and changing requirements that are often difficult to recognize.” [↩]
3. Requirements Validation Through Viewpoint Resolution [↩]
4. Requirements validation with enactable models of state-based use cases [↩]
5. paper prototyping – involves making all the UI components on cut out pieces of paper.  You then arrange the “components” on another piece of paper that mimics the screen view.  Paper prototyping has many advantages over mocking up in Photoshop or with HTML.  You can find some tips at User Interface Engineering [↩]
6. See Nielsen’s Heuristics [↩]
7. Silverback is a GREAT application for performing usability tests on OS X [↩]
8. There is a wonderful Google tech talk on How to design a good API by Joshua Bloch.  Many of the lessons in the talk can be applied to most solutions and interfaces. [↩]
9. Occasionally the initial architecture is extracted or recovered from a system that has already been implemented [↩]
10. analogy searching involves using architectures from solutions in other fields that have analogue problems which map nicely to your problem domain [↩]
11. literature searching is no more than standing on the shoulders of giants.  It involves searching through scholarly journals and architecture books to identify architectural styles that can be applied to your problem [↩]
12. morphological charts are constructed by identifying all the primary functions of the systems and the means to achieve them.  You then start selecting from the various means until you fulfill all requirements in a compatible way.  Further abstract these into documented styles where necessary [↩]
13. An Architecture Description language or ADL, is a strict and often formal way to construct, document, and describe architectures.  They are often special-purposed for certain classes of systems and rigid in use.  Extensible ADLs are a semi-formal way to describe an architecture.  Something more formal than UML, but easy to describe and easily extended to new systems and styles.  I personally like xADL 2.0 as an architectural language – see ArchStudio4, a lightweight graphical editor [↩]