machinespace = the networked information space of ever-increasing complexity that humans have to interact with.

August 24, 2004

user requirements = business requirements ?

The Reader might be interested in perusing a previous article titled "UI design myths revisited" dated 08/23/2004, particularly Myth # 10, to gain additional context regarding this posting. Also, for definitions of terms used here, please refer to the machinespace glossary in the August 2003 archive.

...For some reason, there is a myth that has been persistent for years - that somehow an user's requirements for an application or a web site is somehow different from all the other functional and non-functional requirements. UI designers and Usability gurus have done their bit in making these "user requirements" sacrosanct and somehow different from the vulgar system requirements demanded by the business.

User requirements are no different from any other requirement - because they define the needs of a human user, it is even more important that user requirements be stated along with the rest of the requirements, and describe what it is that the user will need from the application in order to effectively fulfill their personal and business goals. After all, the user ultimately will function as an integral part of the business system, providing inputs, requesting outputs and making decisions based on their interactions with the rest of the system components.

Users are usually the "control" components of a business system, and as such, trade-offs need to be negotiated with the other components during function allocation based on the designers knowledge of the user's strengths and limitations in terms of experience, skill, workload, work environment, physical condition, etc. From a systems perspective, an application or product is "User Friendly", "Usable" or provides a "Positive User Experience" if a FAVORABLE balance is negotiated with the other components, and "Unusable" if the balance negotiated is UNFAVORABLE to the human components of the system.

Most user requirements are in some way related to the functionality, since the user is trying to fulfill a business need through the use of the application's functionality - ie, user needs usually build upon the basic business need for the specified functionality. For example, if there is a business requirement to be able to print a document from an application, the functional requirements usually define what the print function needs to be able to do in order to satisfy the business need - ie, should be able to stop and start printing, preview and zoom, specify printers, specify paper etc etc.

The usability/user requirements further builds upon the functional requirements by adding specific requirements for the user to be able to access & control each of the Print function features for the application to be truly useful to the user and fulfill the business needs. Thus, there is a close relationship between usability requirements, accessibility requirements, functional requirements and the underlying business needs. In fact, many cases, they are the same.

A lot of the confusion arises from an analyst mistakenly mislabelling a PERFORMANCE requirement as a Usability requirement. Performance requirements are of 2 types - system performance and user performance. System performance can be stated in terms of hard numbers - ie constraints on load time, data base access etc. User preformance is most often stated as a usability goal, such as target time to perform a task, number of errors etc etc. But these are NOT usability requirements - they are Performance Requirements that the system and its users have to meet in order to satisfy a Business requirement.

It should be understood that Business Requirements (i.e., the ultimate reason for the initiation of a project or service) are not necessarily limited to being something to do with the "core business" of the company - Business Requirements can encompass Operational requirements, Legal Requirements, Security Requirements, Performance Requirements, User requirements and of course, Accessibility requirements which, strictly speaking, are a sub-set of the user requirements.

Depending on the needs of an Organization at any given time, ANY requirement can be elevated to be a Business Requirement. For example, if a Company decided that it was going to mandate Section 508 of the Disability Act (Accessibility) compliance as a general company policy for all applications built in-house or purchased from vendors, then Accessibility becomes a Business Requirement.

What remains to be defined is the extent of the functionality that is needed to comply with the new Accessibility Business Requirement i.e., should the application support ALL disabled users or does it need to accommodate only the Visually handicapped users? Does it need to accommodate impaired motor skills or hearing disabilities? etc. These decisions can be made based on the actual need, ie, number of business users in the company that suffer from a disability, and the kinds of disabilities that exist within the organization.

It would make no business sense for a company to expend a large amount of resources and effort to make an application Section 508 compliant for visually handicapped users if there are no such users in their customer base. Thus the functional requirement could just be limited to accommodating a hearing impaired users and motor skill impaired users.

(note: the foregoing is just an illustrative example, so don't jump on me if the above hypothetical company makes a business decision to save money by making an application partially accessible. heh heh).

copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.


Post a Comment

<< Home