Part of successfully designing and maintaining a high tech system is having a strong top down vision. In the absence of vision nobody has a clear idea of what belongs and what doesn’t.
"It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them." Steve Jobs, quoted in BusinessWeek (25 May 1998) cross ref. (link)
THE USER AND REQUIREMENTS
Understanding the requirements process. An overview of the need for requirements and how they can be gathered and managed for systems development.
If you have a product or if the product is still just a concept you must be able to answer the question: “what goal does the user attain by using your ‘offering’ or product?”
INTRODUCTION
Why do we need to talk about requirements? Aren’t requirements usually self-evident? Are the really valuable requirements obvious or easily captured?
Product management needs to be grounded in a disciplined approach to managing high tech design and development. The product or project manager, right down to the programmer, must be able to answer the question "how do I know when I'm done?" However requirements may may not capture a clear or coherent statement of the problem we need to solve. Requirements can state outwardly perceived problems but in ways that are value laden and suggestive of remedies (perhaps as band-aids) rather than as simple statements of issues that could be addressed in . In these cases requirements encroach on design and may result in the worst aspects of incremental change. (Foote and Yoder, 2000).
Identifying the real problem is often the problem (Curtis et al., 1988). The requirements process is therefore more often a process of mutual discovery; uncovering and discovering the need and use for a high tech system.
Three simple questions offer a revealing insight into the maturity and capability of the organization:
- Show me a statement of the requirements your product delivers?
- How were the requirements gathered?
- From where does each requirement originate?
User requirements and analysis is often considered to be the starting point for the systems development process but it is rarely a straightforward process of transforming a list of requirements into a product. It is more often a process of intervention and change that impacts “personal and group efficiency, effectiveness, job satisfaction and the quality of working life.” (Mumford, 1985) Edith Mumford suggested that the best possible approach for design teams is to involve users with the developers as part of the requirements capture and design process. To create a situation where user requirements can be clarified and defined in the absence of solving underlying technological considerations. Requirements definition should therefore focus on user problems and needs before looking at current tasks. Identify the goals before looking at the minutia of the current list of tasks undertaken to overcome or satisfy the goals.
AN UNDERLYING THEORY OF REQUIREMENTS?
Why have a requirements process and what are its distinctive aspects? In an ideal world the developer and the user would communicate directly and perfectly. The user would be able to perfectly articulate some need, the developer would understand the need and be able to create and deliver it. However in the real world our understanding of needs and ability to communicate them is imperfect. In addition, in the real world, there isn’t a one to one correspondence between users and developers. A successful product may have hundreds, thousands, if not millions of users (Figure below, a). Conversely a product development team size may be anywhere between five and a hundred people (rarely more). The more users there are the less likely all their various needs can be articulated, communicated, implemented and satisfied. The more users there are the less likely the developers can interact and communicate with them on a one to one basis. The immediate role of an analyst may be quite simply to buffer or manage interaction and communication between users and developers.
The challenge of such a role is its potential to further distort the process of communicating between users and developers (Figure below). But simply adding an analyst to the equation doesn’t address the core challenge of large user communities interacting with small developer communities (Figure below, b). Consider the following three cases as ways of organizing interaction between users and developers. Case I (Figure below, I) corresponds to direct communication between developer and user, case II (Figure below, II) to the business analyst as a buffer between and two, and case III (Figure below, III) to open communication between developers and selected users. The solution to addressing large user communities is to select a representative subset of users and work with them (Figure below, c). As a general rule of thumb we could assume the number of representative users will be of the same size (or order or magnitude) as the size of the analyst/developer team (Figure below, d). The risk with a product requirements document is that it lies between the user and the designer; its use may both communicate and mis-communicate. The key to success is to selectively enable direct interaction to clarify and validate both the requirement and its delivery.
The ETHICS approach
There are many requirements management frameworks most of which are basically templates and checklists for gathering and recording a variety of user-oriented data. Mumford's ETHICS framework is a useful approach to organizing participative problem solving initiatives for systems development. The acronym is also intended to convey that an ethical orientation is also necessary to allow and enable the analyst to contribute to good systems design resulting in increasing “the positive factors and eliminate or reduce the negative factors” (Mumford, 1985) for user interest, effectiveness, job satisfaction and commitment. Mumford's ETHICS approach to structuring systems requirements specification consists of question challenges and resolving activities.
The risk however with a requirements gathering process cast in this format is that it can expand into an open-ended discovery of a range of problems that weren’t previously articulated. You quickly loose yourself in changing, evolving goals. This is amplified by users awareness of the coupling between requirements and design. They understand fully that implementation of new technology impacts and challenges the target organization. New IT alters the day-to-day organization of work, job satisfaction and corporate mission. Impacts and challenges may be both positive and negative thus Mumford’s emphasis on the ethical treatment of people. In this case changing people’s tasks and responsibilities is predicated (and made valid) on the basic assumption that the exercise is to produce changes that improve the conditions, effectiveness and satisfaction of work.
METHODS FOR GATHERING REQUIREMENTS
The end result of any process of requirements capture should be a body of raw data (interviews, statements, recordings, diagrams, images, documents, objects). The requirements are a distillation of that data as lists, categories and descriptions that are wherever possible, traceable back to its originator or source for validation.
Contemporary methods for gathering and managing requirements range from formal negotiated approaches like ETHICS to informal (though still negotiated) processes evident in newer Agile methods (Cockburn, 2002). New methods for organizing systems development such as Extreme Programming (Beck, 1999) and Scrum (Schwaber, 2004) create distinctive roles for the customer or product owner at the heart of the development process (Figure below). Kent Beck popularized the idea that a development team needs an ‘on-site customer.’ Ken Schafer asserts the need for a ‘Product Owner,’ someone who speaks for the customer authoritatively and with ownership. Scrum’s insistence on a product owner is essential as the process is driven by value and therefore it is crucial to identify the person who is responsible for the product’s ROI and who is therefore responsible and accountable for decisions such as what the requirement is and which requirement to deliver first. The ideas of an on-site customer and a product owner are designed to simplify the communication process between users and developers. However they say little if anything about how to choose the users, communicate or interact with them.
Interaction Design (IxD), which has grown in popularity among HCI/CHI designers, directly addresses the methodological challenge of gathering requirements from user communities. Interaction design positions the role of the interaction designer rather than ‘analyst’ as the central figure bridging the gaps between users and developers. A more open interpretation of the role of Analyst or Requirements Analyst is anyone who is involved in requirements gathering and analysis. Various business titles could be applied to the same role: Product Manager, Marketing Analyst, Researcher, Interaction Designer, etc.
Product requirements can be thought of as a rather unique kind of shopping list, a shopping list written by (more often on behalf of) the user, and written for (usually by) the developer to deliver (Figure above). Taking the analogy further the requirements shopping list is for a shop where the shelves are initially empty because the things the user wants haven’t been made yet. Alternatively there may be something on the shelf that approximates what the user wants but it’s not quite right and needs to be customized. To compound this seemingly odd situation we may also find that product requirements may be written (created) by someone who is neither the customer (user) nor the designer (developer). In this situation those charged with requirements capture have a lot of responsibility and power to influence the design process. Product requirements lie between the user and the designer and act as a communication device between the two. The requirements document is merely a representation of a potentially unbounded set of product requirements therefore the process used to create the representation is perhaps more significant that the document itself.
METHODS FOR ELICITING REQUIREMENTSMethods for gathering requirements from user communities at the early stages of systems development will usually consist of research and data gathering methods that are more exploratory and interpretive that conditional/quantitative (Cooper et al., 2007). After all, you won't know what questions you need to ask or the relevant information until you have undergone a process of open-ended learning and discovery.
A similar categorization of methods attuned towards requirements gathering is presented by Moggridge (2006). Specific methods are indicated for specific situations. Observational and recording methods are indicated when requirements or needs are initially unknown, latent, unvocalised, or problems of physical ergonomics etc. Survey, focus groups and expert opinion are useful for situations where explicit opportunities exist. Conversely the research method may be indicated by the size of the group being addressed. Statistical techniques are essential for assessing large markets or populations of users. Interpretive methods allow the researcher identify and explore concrete cases of use and associated goals.
THE RISKS OF REQUIREMENTS PROCESSES
Requirements are distillations of information, selective presentations of potentially vast unbounded wish lists and issues. The person charged with requirements capture has the power to influence the design process and therefore has a responsibility to carefully record and preserve the data from which selection is based. Creating and managing requirements involves discriminating and selecting information. It carries an onus to be truthful, fair, accurate, factual and impartial. Research data should wherever possible be preserved and indexed so that requirements can be traced back and associated with the users or situations they were generated from.
The task of requirements gathering is all the more difficult because what is learnt was previously unknown or unarticulated. A requirement is often tentative and uncertain. Furthermore, the statement of a requirement does not necessarily equate with its solution. Requirements may be functional and concrete (the product does X, Y and Z) or they may be non-functional and abstract (the product is fast, easy to use, secure). Requirements capture demands a level of attention and rigor to data gathering, storage, management and presentation equivalent to that of academic research. Whenever possible data should be verifiable, traceable, reproducible, and useful. Raw data is the body of evidence and material necessary for reasoned decision-making in the design process. It is no coincidence therefore that many of the methods and techniques for gathering and analyzing data are derived from academic research methods. Among these research tools qualitative research methods have achieved particular prominence in the technology design community (Cooper, 2004, Cooper and Reimann, 2003, Moggridge, 2006).
The value of qualitative research techniques is that they both complement quantitative methods and enable access to information that is impossible to capture via quantitative approaches. More importantly, qualitative research methods involve the researcher analyst directly with the user community and open the possibility for gestalts and insights that quantitative assessment may overlook.
CASE: A vignette on the value of qualitative research (Cooper et al. 2007)
“In one particularly illustrative example, we were asked by a client to perform a user study for an entry-level consumer video-editing product for Windows users. An established developer of video editing and –authoring software, the client had used traditional market research techniques to identify a significant business opportunity in developing a product for people who owned a digital video camera and a computer but hadn’t connected the two yet.
In the field, we conducted interviews with a dozen users in the target market. Our first discovery was not surprising – that the people who did the most taping and had the strongest desire to share edited versions of their videos were parents. The second discovery, however, was quite startling. Of the 12 people whose homes we visited, only one person had successfully connected his video camera to his computer, and he had relied on the IT guy at work to set it up for him. One of the necessary preconditions of the success of the product was that people could actually get video onto their computers to edit, but at the time it was extremely difficult to get a FireWire or video capture card functioning properly on an Intel-based PC.
As a result of four days of research, we were able to help our client make a decision to put a hold on the product, which likely ended up saving them a considerable investment.” (Cooper et al., 2007)
CONCLUSIONS
Contemporary ideas of user-driven adaptation, technology-in-use, and situated use imply that high tech development efforts remain in a perpetually unfinished state. IT, ICT and high tech products more generally are constantly being adapted for use by developers as they observe or become aware of users exploring and adapting technology to fulfil their own needs. We might think of the process of modern product development as being in a kind of constant surveillance with the producer or developers receiving a steady stream of reports from the market place, to try to better understand everyday use as well as user driven innovation. This open-ended orientation to technology requires both developers and users to be agile, as each creates conditions of possibility for shifting the meaning and functions of technology. Such agile approaches assume that technology is typically not used in isolation but that it becomes embedded in users’ everyday practices and lives. These processes of appropriation are creative processes of identifying novel forms of use or shaping the conditions of use.
REFERENCES
