"System must be user-friendly" & S.M.A.R.T requirements.

I often write requirements statements or respond to requirements statements from tenders or RFPs. There are some things I have learned that may benefit other people that are involved with writing or responding in similar situations.

Available? Sure! (but through which type of interface???)

A common problem is the failure to indicate which requirements are to be met using which tools and available to which users. ?For example: which requirements are to be met using a locally installed Desktop application or which should be available via a web-browser app or which should be available on a mobile phone (or perhaps for some functions it should even be all three?)?

Available? Sure! (but through a tool for specialist super-users or through an intuitive simplified interface with only a few buttons?)

Further to this: if there is a long list of requirements then which functions should be accessible by specialist GIS personnel with technical knowledge using complex tools and which should be available to non-GIS personnel through ‘user-friendly’ interfaces? Often requirements statements do not specify which of criteria apply and is an area where there can sometimes be gaps between the requirement concept from end users and the answers given by suppliers.

Portable Devices? Sure! (but only some of the functionality and only on certain types of devices)

Sometimes in requirements lists there are statements similar to ‘the system must be accessible on portable devices’ to which a supplier sometimes responds with a statement such as ‘yes the system has portable device capabilities’. However, it is often unlikely that the ‘full system’ is available via mobile interfaces. The phrase ‘accessible on mobile devices’ can be interpreted in multiple ways (Fully/partially accessible? Primary user functions only but not admin functions? etc). There can also be significant differences between what is feasible on a tablet device compared to a mobile phone, in part because of the 'screen real-estate'.

To avoid issues such as those outlined above care should be taken to be SMART with requirements: i.e.

• Specific: which functions should be available through which interfaces and devices etc.
• Measurable: how will functions be tested in which interface
• Achievable: asking for functions that are not possible on a mobile phone screen is not advisable
• Realistic: asking for a method so that someone with no experience can to carry out a highly complex scientific process that requires years of training to understand may not be realistic
• Time-bound: when does a requirement need to be met? and/or how quickly should a function provide a result?