Requirements analysis

Discussion articles

  • 5 things to know about users
    The user's intentions, context, knowledge, skills, and experience are the essential things that every designer needs to know. Techniques like contextual inquiry, persona development, and mental model analysis can make or break a team's design efforts.

  • 13 common objections against user requirements analysis, and why you should not believe them
    Sim D'Hertefelt outlines some common objections to doing user research and provides some defense against them.

  • Accessibility in the analysis phase
    It is most effective and efficient to incorporate accessibility from the very beginning of a project. When accessibility is only addressed late in product design, it can be very costly to make required design changes. Incorporating accessibility early in the project increases the potential positive design impact, and decreases the time and money required to design accessible products. This chapter provides information on setting usability goals, user analysis, workflow analysis and understanding accessibility issues.

  • Apprenticing with the customer: a collaborative approach to requirements definition
    It is the relationship between designers and customers which determines how well the design team understands the customer problem. This includes not only the overall relationship between design team and customer community, but the individual, minute-by-minute process by which a single designer works with a single customer to understand their work. It is by understanding each person in the context of their work that the team comes to understand the whole work problem.

  • Are useful requirements just a fairy tale? (and why an IA should care)
    Why should an information architect care about requirements when it’s not his or her job to collect or create them? It comes down to simple math: it’s been my experience that a blurry definition of what a project needs to accomplish leads to a lot of extra work for the IA. So much extra work, in fact, that revisions end up taking much more effort than helping the team nail down useful requirements earlier in the process.

  • Build it so they will return
    If you want the users to understand the product, you must first understand the user. Understanding about the users and their needs is central to any successful product.

  • Consolidated assessment: a user-research approach which integrates our best tools into a single session
    There are several research tools at our disposal for understanding user behavior. But how many times do we get the chance to spend as much time on research as we think is required? Combining techniques is one way to increase efficiency and still collect meaningful information.

  • Crafting a user research plan
    Every piece of user research is part of an ongoing research program, even if that program is informal. However, making a program formal provides a number of advantages: It gives you a set of goals, a schedule that stretches limited user-research resources, and results when they’re needed most. It also helps you avoid unnecessary, redundant, or hurried research.

  • Crafting a user research plan: part 2
    The most difficult part of setting up a schedule for your user research plan is integrating it into the existing development system.

  • Design research: why you meed it
    Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? Many products fail because of a lack of design research. Without first performing the proper research, you may come up with a product that fits neatly into a target market, but you won't create one that satisfies users, or sells.

  • Effective design research: analyse goals first
    Many designers of technology-based products spend a lot of time working on task analyses - detailed step-by-step evaluations of how a person should (or could) best accomplish a particular task. By focusing only on conducting task analyses, however, the resulting design work is usually nothing more than tweaking an existing set of tasks.

  • Finding the right users
    If you’re using the eenie meenie method to select users for your research, perhaps it’s time you tried something a little more scientific. There is no such thing as sound user research without an airtight user-selection process behind it. No matter how good the observation and analysis, it’s all for naught if you’ve studied the wrong people.

  • Getting creative with specs: usable software specifications
    Building architects don't have to think much about what the actual deliverables are to contractors and their clients, because their industry has traditions and standards for blueprints, balsa wood models, and computer-generated renderings. As user interface consultants, we have to think about this anew for every project.

  • How long does customer data stay fresh?
    You want to use your resources wisely. Don't get data before you need it, but don't get blindsided by changes in the market.

  • Information needs analysis
    Analysing users' information needs can help you select the most appropriate components to use in your information architecture.

  • Investing in requirements analysis
    In my experience as a usability engineering consultant, requirements analysis is still often a hard sell. My goal in this article is to demonstrate the importance and payoff of investing in usability requirements analysis tasks by providing real world examples of the results of investing - or not investing - in this part of the usability engineering lifecycle.

  • Making your design real: the form and behaviour specification
    This article discusses how a detailed specification of the form and behavior takes the guesswork out of product development.

  • Not all websites are alike
    Where web projects differ is in the planning they require before production begins. What a website must accomplish determines the kind of planning effort it requires.

  • Requirements gathering essentials
    There is no silver bullet, no one answer, no perfect approach method or technique to requirements gathering. Developing a good requirements document is about giving your project the best chance of success. To do so, you must reduce the risk of common mistakes that arise from a lack of communication or understanding. Keep this in mind as you gather your requirements, and the documentation--and project as a whole--will have the best chance of success.
    (Martin Bauer)

  • Requirements gathering: lose your ego and ask away
    Do any of the following prevent you from asking more questions? You are: afraid you might appear incompetent or uninformed; assume you already know all there is to know about the system you're developing; uncomfortable with the skill of questioning. If you can answer "yes" to any of the items above, you may be putting your intranet system development project at risk.

  • Selling user research to the reluctant
    Researching the users of your product is extremely important in making it more popular, more profitable, and more compelling. But companies make products, not user research teams. A company needs more than data about its users; it needs to be able to take that knowledge and act on it. Unless the benefits and techniques of user-centered design and research are ingrained in the processes, tools, and mind-set of the company, knowledge will do little to prevent problems.

  • Uncovering users in your own organisation
    "One of the most overlooked areas to inform user interface considerations is within our own companies. Corporate resources are seriously undervalued and underused, but are at our fingertips. As a first step, we should determine where usability issues are already being documented within our organizations and where they could be used to inform our design decisions."
    (Lyn Rampoldi-Hnilo)

  • Understanding organisational stakeholders for design success
    User-centered design professionals pay special emphasis to one type of stakeholder--the users of the system--arguing that user experience needs to be carefully crafted to satisfy user needs. While understanding user needs and goals is certainly necessary, it is often not sufficient for producing a successful design. A design must meet the business needs of the company, and must be supported by disparate members of the management team, in order to be actually implemented.

  • Understanding your web audience
    Although there are lots of elements to consider when designing compelling Web experiences (writing style, look and feel, information organisation--to name just a few), there is one 'knowable' element that can be used to appraise the rest: audience. A detailed understanding of your target audience provides you with an effective metric by which to evaluate all your design decisions.

  • User focus in enterprise software
    The current economy has CIOs sharply focused on real ROI from business software investments. Enterprise software vendors can no longer rely on software design practices that keep users in the periphery. Using so-called best practices, domain experts, and requirements that don't come from actual end user work practice leads to software that delivers limited value.

  • Using a floor plan as a metaphor for design
    Systems need to support the work of the customer or end user. Teams need a design representation to explicitly reveal how well the system supports the customers' work. The User Environment Design offers that representation, and serves as the basis for requirements and specifications.

Research articles

  • User requirements analsysis: a review of supporting methods (PDF)
    Understanding user requirements is an integral part of information systems design and is critical to the success of interactive systems. However, specifying these requirements is not so simple to achieve. This paper describes general methods to support user requirements analysis that can be adapted to a range of situations. Some brief case studies are described to illustrate how these methods have been applied in practice.