Form

Form is perhaps not normally considered a non-functional requirement but given the common parlance "form-v-function" and principle of "form-follows-function" the general direction seems to be that form is counter to function and therefore in IT terms is a non-functional requirement.

So specified in requirements terms, form may refer to:

Accessibility - For which the first port of call should be the w3c Web Accessibility Initiative. I have to shamefully admit to knowing very little about accessibility. Partly because I cannot draw for toffee and leave the graphical design to others though this isn't a sufficient excuse and I should try harder... Suffice to say, my common bugbears are:

1. Requirements for accessible maps (GIS - I have never seen a graphical map on a website that is accessible to the blind).


2. Forms where the focus jumps around fields like fleas on my dogs back.


3. Lack of clarity on which fields are required.

Device compatibility - There was a time when every naff corporate website sported a couple of icons at the bottom indicating best viewed with "Netscape Navigator 4" or "Internet Explorer 5". These have thankfully mostly disappeared, though (and I won't name names) there are many corporate intranet systems which still sport these badges of shame. More recently clients are trying to withdraw from defining browser requirements - partly because of the variety out there today and partly because by the time the system is ready the world would have moved on and they could be faced with what may be a significant "change request". Fair enough really. My personal preference is to target Firefox and Internet Explorer using HTML5 - if you can get these two to work then you'll probably find Chrome, Safari, Opera etc. all work fine. It's not always the case of course and some of the more esoteric HTML5 features have poor support across browsers (e.g. "range" input type). Include in this a greater variety of client devices (tablets, smartphones, phablets etc.) and the need to conform to standards; for developers of sites and devices/browsers themselves, becomes even stronger.

Graphical design - As I said, I can't draw for toffee - there are others that can do that. I really have very little to say on the subject but have found some colour scheme tools which have been fun to play with but yielded virtually nothing of benefit to any site I've developed. I personally find most satisfaction in simple layouts and visualisation where the design is driven by the data (e.g. the mighty Stellarmap.com). However, from an implementation perspective it irks me when developers out of ignorance or laziness don't use the correct tools to layout designs - using <table/> instead of <div/> and the such like. There's no need for it and it causes problems for screen readers such as JAWS, can affect the quality of search engine results and detracts from attempts to develop the semantic web. More recent trends in website design aim to respond to the capabilities of the client to provide a better experience for users on a diverse range of clients. Fortunately the tools to attack these issues are available in HTML5, CSS3 - common problems will be met by common solutions.

So in a way Form can be boiled down in essence to compatibility. Compatibility with the technology of the web, compatibility with the client device and compatibility with the wetware on the other side of the keyboard and screen.

From a requirements perspective you should be able to define all of these - Who's the audience? What sort of devices need to be supported? How do you want to be found on the web?

From a solution perspective you have the tools available to make this happen.