COORDINATION THEORY - Human-Computer Interaction and Management Information Systems: Foundations - page 110

Task-Resource Dependencies
Most tasks require resources, if only the effort of the actor performing the task, and an important
class of coordination processes manage the assignment of resources to tasks. Crowston (2003)
suggests four steps to such resource assignments: identifying the type of resources needed, iden-
tifying available resources, selecting the resources and making the assignment. Most work on
resource assignment (e.g., in economics, organization theory, or computer science) has focused
on the middle steps, that is, techniques for identifying or selecting available resources. By con-
trast, in the requirements analysis process the first step—identifying what resources are needed to
perform a particular task—seems equally important. Analysts can easily refer problems to one
another, but they must somehow first determine who should be consulted for a particular problem
based on the nature of the problem and the expertise and assignment of different developers. This
problem is exacerbated by the potential for dependencies among requirements (i.e., between the
products of these tasks), which increases the need for consultation.
Producer-Consumer Dependencies
A second major type of dependency is a producer-consumer dependency, where the output of one
task is the input to another. Malone and Crowston (1994) note that such dependencies often
impose additional constraints, in particular usability—ensuring that the output is of a form usable
by the next task—and transfer—ensuring that the output is available to the consumer when
needed. This type of dependency exists at a high level between the requirements process and fur-
ther downstream software development processes. Although there are some transfer problems—
e.g., making sure that the requirements are finished on schedule—usability seems to pose a key
problem. Indeed, at the highest level shown in Figure 7.4, the requirements development pro-
cess itself can be viewed as a coordination mechanism that ensures that the output of the
software development process is usable by the eventual customers for the system. Malone and
Crowston (1994) suggest alternative approaches to satisfying a usability dependency, including
standardization (i.e., producing the output in an expected form), asking the users, and participatory
design.
For the software developers who are the users of the requirements, the main approach to
usability appears to be standardization. Most companies have standards for the format and con-
tent of requirements documents to ensure that they are easily usable by software developers. For
the eventual customer of the software, though, a standard output is assumed to be unsatisfactory,
since the companies studied developed customized systems. Making the system usable required
the application of a lot of specialized knowledge about application domain (Walz et al., 1993), so
that members of requirements development groups were often experts in their fields. However,
gathering the information about the particular circumstances of the customer required consider-
able additional work.
Task-Subtask Dependencies
Third, some tasks are decomposable into subtasks. For example, the task of writing requirements
must typically be decomposed into units of work that a single individual can perform. A key issue
in any decomposition, however, is ensuring that the overall goal is satisfied by the performance of
the subtasks. Without such a check, it is easy for analysts to focus on their component of the system
and lose sight of the system's overall goals.