Top

Process: Requirements Definition

UXmatters has published 22 articles on the topic Requirements Definition.

Top 3 Trending Articles on Requirements Definition

  1. Defining Clear Product Requirements | Viewpoints for Design Reviews

    Ask UXmatters

    Get expert answers

    A column by Janet M. Six
    March 21, 2016

    In this edition of Ask UXmatters, our expert panel discusses two topics:

    Our experts first discuss how to elicit clear product requirements from stakeholders. Does the right approach differ for small versus large companies? Do product requirements capture the goals of stakeholders? Do requirements reflect the true needs of users? Do they establish a good understanding of technical constraints? How can you validate the assumptions behind product requirements? What kinds of research should influence the definition of product requirements? How should you balance the needs of users versus the business?

    Then, our expert panel considers some different viewpoints from which we can review design solutions: stakeholders’ business goals, the needs of users in various roles, and the feasibility or ease of implementation. On the other hand, focusing on one particular user’s needs during a design review can yield a greater number of insights. Considering different user-interface layers lets you structure your evaluation of a design solution. Plus, it’s important to consider the effectiveness of design artifacts as well. Read More

  2. Technology Acceptance Process: A Release Model for User Assistance

    User Assistance

    Putting Help in context

    A column by Mike Hughes
    July 19, 2009

    A theme I deal with a lot, both at work and in this column, is organizations’ asking user assistance (UA) developers to support more products with fewer resources. For UA developers who are experiencing a resource crunch, the obvious solution is writing less user assistance for a product than we would have produced in the past. (See my UXmatters column “Hockey Sticks and User Assistance: Writing in Times of Resource Constraints.”) But that still leaves the problem of how to write less and cover users’ information needs adequately.

    Everett Rogers’s seminal model of the technology adoption process [1], charted in Figure 1, suggests an approach that might let us put the proverbial 10 pounds of content into a 5-pound bag of writer capacity. Rogers noted that the phases of technology adoption correspond to its adoption by distinctly different classes of people, who accept new technologies at different paces. Read More

  3. Communicating Customer and Business Value with a Value Matrix

    December 15, 2008

    So, you’ve wrapped up your customer research, completed your personas, and have even written a few scenarios that show how users would want to interact with your brand new product. What’s next? What happens to the personas and scenarios once you’re ready to start requirements definition and design. Are you sure you’ve adequately communicated the type of system your users need to the Business Analyst and Interaction Designer on your team?

    If you’re like me, you’ve always felt something was missing once you finished creating your personas and scenarios. They communicate the heart and goals of the user, but miss out on a lot of details. And while it’s the intent of both documents to do just that, neither personas nor scenarios succinctly communicates to your business what features a product or service should have and why it should have them. Read More

Champion Advertisement
Continue Reading…

New on UXmatters