• Functional requirements are the features your product will have, in terms of the functions, actions, and behavior it will support. For example, some functional requirements for a word processor would be that it support bold and italic type, that it allow documents to be printed, and that it allows images to be embedded in documents.

• Non-functional requirements are performance or quality constraints that are general or “cross-cutting” in nature. Non-functional requirements address areas such as performance, security, stability, capacity, and scalability. For example, an e-commerce website might be required to serve 100,000 users concurrently and provide a response time of 2.0 seconds or less.

The scope of your product and project is defined by the set of requirements that need to be implemented. Without careful management, additional wishes and demands will continually be added to the project’s scope. This phenomenon, known as scope creep, will threaten your ability to deliver on schedule.

Requirements should be stated in concrete, measurable terms whenever possible. For example, rather than stating that “the product must be easy to learn”, which is subjective and unprovable, you might consider a phrasing that lends itself to objective testing, such as “95 percent of users will be able to successfully process a standard passport application after the two-day training session”.

Some requirements are “definitional”: they result from, and form part of, your definition of what the purpose and market positioning of your product is. Other requirements need to be elicited from your users and other stakeholders.

End users are the people who will use the product in a hands-on manner a day-to-day basis.

The buyer is the person (or committee) who makes the final decision to purchase the product.

For enterprise software such as a call center management application, executives make the decision to purchase and install the system, but these executives usually never operate the software themselves.

Similarly, educational computer games for young children are not purchased by the kids themselves. Children may influence the purchasing decision, but it is the parents or other adults who buy the product.

Products purchased as gifts are another example of where the buyer is not the end user.

So while user experience design and usability testing must focus on the needs of the end users, your product must also simultaneously appeal to the potentials buyer, or it will never sell. Market research to understand buyers’ expectations and concerns is important and can strongly influence the scope and design of your product.