Requirements by User - NOT by Proxy

Software development is not an easy task. The process of development follows a path similar to manufacturing or construction but there is usually no tangible sense of progress for the users. Typical users of an application are not usually concerned with how a piece of software is created and the amount of work that goes into it. The user’s only concern is how that software will help them perform a task in a simple and repeatable manner. Software that doesn’t provide users this basic functionality will be rejected and the amount of work and time spent in its development will have been wasted.

In my opinion, the single most important gauge of quality in a software application is user acceptance. The best way to ensure that a user will accept a software application is to have the user design it. Too often development teams assume that a particular feature is wanted by a user. Business managers and software sales people make the same assumptions for different reasons. In this sense developers, business managers and sales people become proxies to a user and their needs. Each pass through the proxy can cause a shift the perception of how a feature should work.  This change of perception can (and often does) move the design of the feature away from its original path. Once that feature is implemented users often find that it does not meet their expectations and is therefore of poor quality. 

Typically, neither the development team nor the managers and sales people use the software that they design and build. Only the day to day user of a system knows what that system needs to do and the most efficient way to get from one point to the next. Good software can be created by listening to how users perform a task and modeling an application along that path. Great systems can be created by allowing developers direct access to an actual user of a system during the development phase. The development teams can then go directly to the user with questions and get immediate feedback. It is this direct feedback that will keep the project on the correct path to provide the quality product that the user expects. Often times, this feedback comes from the user in the form of a requirements document. This requirements document should be written from a user perspective and denote what is expected from the system for every point of interaction that is exposed. If an actual user of the system is not available to write or at least critique the document, a user should be provided that will create use case models of the result of an action. Developers should not rely on a proxy at this point, only an actual user of the system will provide an accurate account of how an action should play out.

In summary, only an actual user of the system can specify how that system should work. Development teams and other outside stakeholders can make incorrect assumptions in regards to a system’s requirements. These outside stakeholders are proxies and cannot accurately provide the guidance necessary to create what the customer (the system user) expects in all cases. Any deviation from what is expected by the customer will be seen as a fault in the systems quality. Requirements and guidance should come directly from the customer to ensure that the system fills its expected role.