July 1, 2001
Defining requirements is an important part of the web development
process. There are various types of requirements that are used throughout
the various lifecyles of a web project including:
- Business requirements
- technical requirements
- project requirements
These requirements help define the necessary processes and components
that are needed for the project to be successful
Lets take a further look at how requirements play a
role in web design development lifecyle.
Business requirements defined
These requirements define the project scope as it relates to the
business process. Without a business requirement, the project scope
and direction can remain unclear. These requirements are broadin
scope, and are used to help provide project direction at a high
level. They help define the business purpose of need for the technology.
- Identify business need. This justifies and explains the reason
why the technology is needed. A web development project might
explain the need as follows:
In response to customer demand, and increased pressures in our
competitive environment, the development of a company extranet that
will allow us to conduct business with suppliers, customers and
employees. Extensive interviews and research with customers, and
an analysis of the competitive environment has established a need
for such a web presence.
- Define users of the technology. A web site might have a variety
of users such as employees, customers, potential customers, and
researchers. The user groups should be narrowly defined, rather
than with broad user categories.
- The interaction between the business, its employees and its
customers in how they relate to the applied technology.
- The intended behavior if each user group in relation to the
technology. For example, how employees will use the technology
on the job. An extranet web site might define the requirement
as service employees will use the site to communicate with suppliers
regarding the status of unresolved technical and delivery issues
for all product shipments. This system replaces the Customer Service
Inventory Planning and Status system
- Tangible benefits to each user group.
Example: using the web site, staff will be able to reduce order
processing by 20% while reducing training costs by 42% within 14
Why requirements alone aren’t enough
Even if you’ve created good requirements,there is no guarantee
your design will be usable. One of the biggest challenges in today’s
development process,is the intersection of various players who participate
throughout the project. In many cases, decisions are made by teams,
whose input carefully considers all the many needs and requirements.
There are several things that can go wrong during the implementation
- The company is to develop a web site that’s easy to update,
and provides a uniform experience to all users.
In the above example, a good design process would consider the
usability impact of this request, and determine the best way to
achieve it. However, if the designer doesn’t consider the usability
impact, a less desirable solution could be implemented. For example,
to create a uniform experience, you could simply design for a particular
screen resolution, such as 800x600. In addition, the site maintenance
requirement is met, since the designer can create a single page,
rather than multiple pages for each screen resolution. So, the designer
slaps down a note at the bottom of each page warning users “this
page looks best at 800x600”
This approach puts an unnecessary burden on the user to change
their screen resolution just because the designer thinks so. Without
checking with a usability expert upfront, the design is implemented.
Even if this usability problem is identified after the design, its
too late in the process to change the error. Even though the business
requirement is fulfilled, it produces an undesirable result that
can create a poor user experience.
- Create awareness among all users regarding the site’s features
and functionality to encourage user.
- The site will be fully functional by December 11.
Armed with these requirements, it becomes apparent to the project
manager that a particular functionality will not be operational
by the time the site is implemented. So, to fulfill the above requirements,,
a “sample” functionality will be presented on the site, to create
user awareness, until it becomes operational within the next few
This sounds just like an old “under construction” signs that whets
the users appetite, but offers them nothing. But this is worse,
since it looks more like an advertisement that wastes valuable screen
real estate which could be used elsewhere. Although the business
requirement is met, it is done at the expense of the user.
Here are recommendations to avoid such problems:
- Involve a usability expert upfront during the development and
interpretation phases of the business requirements.
- Don't assume that just because you have created a business requirement
based on the business needs, your design will be successful. A
good business requirement understands both the business need,
as well as the user need.
- Give the usability expert the authority to challenge business
requirements that appear to fly in the face of well known usability
principles .Sure, usability testing will identify such problems
after the design is implemented. Too often usability testing is
used as a crutch to solve the problems that could have been identified
during the initial planning states
- Make sure that you are careful in developing these requirements,
by conducting user task analysis. This will help you better understand
how the userstasks are integrated with these requirements.
- Don’t use usability testing only as a way to solve all usability
defects. Good planning by identifying user needs can go a long
way in helping develop a usable product.