AN APPLICATION OF THE 5-S ACTIVITY THEORETIC
REQUIREMENTS METHOD
Robert B. K. Brown, Peter Hyland, Ian C. Piper
Centre for e-Business Applications Research (CeBAR), University of Wollongong, c/o SITACS Bldg3,
University of Wollongong, NSW 2522 Australia
Keywords: Requirements Analysis, Software Architectures, User Modelling, Activity Theory.
Abstract: Requirements analysis in highly
interactive systems necessarily involves eliciting and analysing informal
and complex stakeholder utterances. We investigate if Activity Theory may provide a useful basis for a new
method. Preliminary results indicate that Activity Theory may cope well with problems of this kind, and
may indeed offer some improvements.
1 INTRODUCTION
One of the most crucial aspects of highly interactive,
multi-user, organisational systems is the interface.
The Human Computer Interaction (HCI) community
has not adopted rigorous Formal Methods with open
arms (Paterno, 1996). However, the HCI community
has widely adopted Usability Engineering
approaches (Corporate Solutions 2006), such as
Nielsen’s (1994), which offers considerable
formality. There remains, however, scope for user
interface (UI) design to adopt a theoretical
framework to enhance consistency across the whole
design and development lifecycle.
A theoretically-consistent framework from initial
co
nceptual elicitation to evaluation of the finished
product may prove useful. Since the aim of UI
design is to produce interfaces that assist users to
carry out their day-to-day activities, particularly in
an organisational setting, a psychological and
sociological theory could be a serious candidate for
the informing theoretical framework. We suggest
that Activity Theory (AT) would be a useful
framework and could serve as the basis for an end-
to-end system analysis and design method for highly
interactive, multi-user system
s. In this paper, we
present an AT-based analysis and design method
(called the 5-S Method) and a preliminary test
example, used to test the method and explore the
suitability of AT.
2 SCOPE
This research focuses on highly interactive systems
(Brown, 2005) where the UI itself underpins a large
proportion of the system’s functionality. AT is an
appropriate theoretical framework for highly
interactive systems for three reasons: 1) it is
focussed on understanding real life activities, 2) in
its classic formulation it provides a method of task
decomposition and 3) in its latest versions it has
been used to describe networks of inter-related
activities. Because AT provides a mechanism for
describing networks of goal-directed human activity,
it could be useful in understanding those systems
that have many users, with multiple roles, whose
activities are highly interrelated e.g. most
organisational information systems.
Table 1: An Extended Activity Theory Taxonomy.
AT
layer
Doing Facilitator Driver Product Protagonist
4 Activity Network System Agenda Process Group
3 Activity Tool/ScreenSet Motive/Object Outcome Subject
2 Action ~ Screen Goal Transaction Actor
1 Operation Switch Condition Change Operator
151
B. K. Brown R., Hyland P. and C. Piper I. (2006).
AN APPLICATION OF THE 5-S ACTIVITY THEORETIC REQUIREMENTS METHOD.
In Proceedings of the First International Conference on Software and Data Technologies, pages 151-158
DOI: 10.5220/0001316401510158
Copyright
c
 SciTePress

So the scope of our research is to develop an AT-
based analysis and design method specifically for
highly interactive, multi-user, information systems.
The concept of an Activity Network and the task
decomposition inherent in AT i.e. Activity > Action
> Operation, allows the proposed method to focus on
many different levels of the interaction process. At
the higher levels i.e. Activity Network and
individual Activities, the method would support
more experienced designers who could draw on their
own experience to provide solutions to lower level
design issues. At the lower levels i.e. Action and
Operation, the method would guide neophyte
analysts and designers, even to the selection of
suitable widgets. So, while our method is at times
highly prescriptive, it is also intrinsically flexible,
allowing analysts and designers to select those parts
of the method which are appropriate to their level of
expertise.
3 ADAPTING AT
AT identifies an Activity as the smallest meaningful
task carried out by a human subject. Vygotsky states
that all human Activity is carried out by a Subject,
using physical or psychological Tools to achieve
some Object which may result in a physical
Outcome (Vygotsky, 1978).
Engström (1987) expanded the conception to include
a social context. Figure 1 shows the seven node
Engström matrix.
To adapt AT to a system design role, it is necessary
to shift focus to the facilitating Tool(s) of an
Activity, as these Tools include the computer system
to be specified. Ultimately, the analyst is seeking to
identify and describe some common set of Tools, at
least part of which resides in the Tool node of each
member Activity in the Activity network, thus
describing a useful computer system.
Figure 1: Engström’s Activity Matrix (Engström, 1987).
Leont’ev (1978) proposed a three layer hierarchic
structure: Activity, Action and Operation to
represent different levels of intellectual
“engagement” of the Subject, with an Activity
requiring deep engagement while an Operation is
virtually autonomic. Kuutti (1991) included a fourth
and topmost abstraction: the Activity Network,
being that related cluster of Activities that are
carried out by a community of Subjects working on
some common task or process.
As described (Brown, 2006), we have extended the
AT taxonomy to avoid confusion between the four
layers. This extended taxonomy is shown in Table 1.
English lacks a common collective noun for the
abstract notion of ‘verb’, so we employ an atypical
definition of ‘Doing’ in the singular (OED). The
collective terms ‘Facilitator’, ‘Driver’, ‘Product’ and
‘Protagonist’ were adopted for other AT aspects.
4 AN AT ANALYSIS AND DESIGN
METHOD
The 5-S method elicits and decomposes stakeholder
utterances, in accordance with AT principles.
Starting at layer 4, the Activity Network is
identified, layer 3 then identifies Activities. Layer 2
identifies Goal driven Actions and layer 1 atomic
Operations. Conditions which drive Operations are
then mapped to Switches, a term we employ
generically for UI elements. These are recomposed
and grouped into the following UI structures:
1. System: The computer tool(s) which best facilitate
the Network of Activities.
2. Station: Activities grouped according to Roles
within the stakeholder organisation.
3. ScreenSet: Groups of Screens associated
4. Screen: Interface groupings of Switches closely
related to Actions within the Activity.
5. Switch: Unitary elements of the UI.
Careful analysis of the requirements gathered at each
layer should permit recomposition of the Facilitators
at each layer until ultimately a System (the most
abstract Facilitator) is described. The description of
the System would, for all practical purposes, form a
feasible, defensible and consistent Requirements
Specification.
As Figure 2 shows, the 5-S workflow passes
downwards through the AT layers from abstract to
refined, before passing back up through the layers in
recomposition. The boundaries of the seven phases
are porous in both dimensions.
Horizontally, there are links between the
decompositional analyses at any given layer and the
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
152

guidance they give to the recomposition in the
upwards pass. Vertically, each of the phases tends to
confirm the results of the previous, and yield
candidate solutions to the next.
Starting at the most abstract fourth layer, 5-S elicits
clues from stakeholders to the Activities. This
requires some degree of iterative consultation akin to
Business Process Modelling, which serves to
confirm and amalgamate the Stakeholders’
consensus view of the process in hand.
Further details of AT and the informing principles of
our method have been presented elsewhere (Brown,
2006).
Figure 2: The 5-S Workflow Concept.
5 TEST EXAMPLE
To facilitate easy access to genuine stakeholders and
a general familiarity with the Group, Process and
Agenda (Table 1), a routine academic process was
chosen for the test example, namely: “Academic
Administers an Assessment Task”.
This matched the scoping of the project and could be
designed and built by neophytes using common
graphical user interface (GUI) elements.
This Process involved Academics who each direct
one or more Tutors. Academics design assessment
tasks for Students to complete. The Tutor(s) may
distribute, collect and mark them. The Academic
must collate and centrally register the results.
To investigate the methods ability to cope with
different interpretations of Process, two different
Academics were interviewed, together with Students
and Tutors of each.
6 PRELIMINARY RESULTS
To explore the suitability of AT in Requirements
Analysis, we have run the method as it exists against
the test example described above. We present below
an indicative selection of preliminary results in the
early phases of the method.
6.1 Phase 1 – Activity Network
An Activity Network is a related set of Activities
which contains and describes the hierarchic
component Doings of a Group Process.
We are interested in the requirements for a System
that best Facilitates the Group Process. This System
comprises computer based Tools which Facilitate
and in some instances Automate the Group Doings.
To this end, we are interested in those Activities
whose Tools could include some element of the
System. The user interfaces of the included
computer based Tool(s) define a boundary surface
for the conceptual space where the System resides.
Activities whose Tool nodes do not connect to this
surface are not considered.
During initial elicitation, this System does not yet
exist and iterative consultation with the stakeholders
is advised prior to automating or altering any Doing.
These early phases comprise a Business Process
Modelling (BPM) exercise. Interestingly, Martins
and Daltrini (Martins 1999) have observed that AT
precepts are compatible with Yu’s i* BPM method.
Table 2: Phase 1 Elicitation Questions.
1
What is the purpose of the Process?
(Agenda – layer 4)
2
Who is involved in this Group?
(Subjects – layer 3)
3
What classes/roles of people are involved?
(Roles – layer 4)
4
What does this Group do?
(Process – layer 4)
5
What do each of these people/classes/roles
intend to achieve? (Object – layer 3)
6
What do each of these people/ classes/ roles
produce? What is their result?
(Outcome – layer 3)
7
Why do each of these people/classes/roles carry
out their Activity?
(Motive – layer 3)
As the scope of the System remains unknown, in the
early Phases of the method, heuristics are required
by which to accept or reject Activities from the
AN APPLICATION OF THE 5-S ACTIVITY THEORETIC REQUIREMENTS METHOD
153

Activity Network and its Process before the System
can be described.
In this informal analysis, commonalities of several
forms between Activities are identified. Generally
these are neither necessary nor sufficient conditions.
Commonalities we specifically examine include:
People: A Subject in one Activity may be the same
person as the Subject in another.
A Subject of one Activity may be a Community
member of another. It is also important to
understand Roles played by individuals, subsets of
whom have a part-whole relation with the Subjects
of identified Activities.
Motive/Object: if several people express the same
Motivation or Object, then they are likely to be
Subject members of the one Activity. If these are
consistent with a group Agenda and contribute to
some group Process, then membership of the
Activity network may be strongly indicated.
Outcome: The outcome of one Activity may become
a Tool or Rule of another. One Activity may
determine the Subject of another (Vrazalic, 2004).
We conduct elicitation of these informal diagnostic
characteristics using Phase 1 questions shown in
Table 2. Actual interviews are somewhat flexible of
course, and these questions serve more as a
guideline than as any kind of script. Collection and
analysis of these Phase 1 indicators necessarily
generates a list of strong candidate Activities, to be
confirmed in Phase 2.
Our preliminary results include:
Agenda: Students must demonstrate their learning
and skills by completing indicative assessment tasks
to a measurable standard without cheating.
Subjects: S1 Academic; S2 Student(s); and S3
Tutor(s). If Subjects are in a part-whole relationship
(eg: some differences between an Activity
conducted by a single Tutor, or by the Group of
Tutors), there are three likely consequences:
Firstly, if the Doing of the Subject subset can be
conducted in the absence of the rest of the Subject
group, then the Actions within the Activity must be
designed to allow for some or all or the Subject(s) to
conduct the Doings individually as required.
Secondly, If the Doing of the subset must be
conducted in the absence of the rest of the Subject
group, then the Activity needs to be split into two or
more, one in which the Activity is conducted by the
entire Subject group, other(s) conducted by some
subset of the group.
Or finally, it may be necessary to create an entirely
new Subject, consisting of some part-whole subset
of the previous Subject group (and possibly others),
essentially a new Role, for this Activity and/or
related Activities.
Roles: Subject Co-Ordinator, the highest appeal,
records grades etc; Expert Authority, who set
assessment, define questions, define answers; Head
Tutor, a possible liaison between lower grade tutors
and the Academic; Normal Tutor, who distributes,
collects, possibly marks and reports; Low-Grade
Tutor, who only distributes and collects, no marking;
and Student, who must complete assessment on
time, without cheating.
Table 3: Candidate Academic Activities.
Subject 1A (S1A) = Academic A
S1A.01 Create assessment questions
S1A.02 Post assessment questions to FTP site
S1A.03
Post assessment questions and marking
guide to Tutors
S1A.04
Field clarifications from Tutors and
Students
S1A.05
Pre-process combined answers from all
submitting students
S1A.06
Facilitate negotiation of marking scheme
with Tutors
S1A.07
Conflate all marks from Tutor(s) to a
Spreadsheet
S1A.08
Anonymize Spreadsheet to PDF
document
S1A.09 Upload PDF to FTP site
S1A.10 Field student appeals and complaints
S1A.11
Transfer Spreadsheet totals to new
Spreadsheet for personal archiving
S1A.12
End of semester processing of totals to
Campus Administration system.
Subject 1B (S1B) = Academic B
S1B.01 Create assessment questions
S1B.02 Create marking guide
S1B.03
Distribute assessment questions and
marking guide to Tutor(s)
S1B.04
Distribute hardcopies of Assessment
questions to Students in lecture class
S1B.05
Field clarifications from Tutor(s) and
Students
S1B.06
Conflate marks from Tutor(s) to personal
archive Spreadsheet
S1B.07 Upload marks to central Website
S1B.08 Field Student appeals and complaints
S1B.09
End of semester processing of totals to
Campus Administration system.
Identification of people, motives and outcomes
informed the choice of individuals to be interviewed.
Interviews with Academics A and B, and some
Students and Tutors of each produced candidate
Activities. Different individuals expressed different
personal interpretations of the process, which
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
154

resulted in multiple sets of responses. Table 3 shows
the candidate Activities elicited from the Academics.
The System is being designed to facilitate the Group
Process and so iterative elicitation of stakeholders is
required to reduce these two sets to a single
consistent list of Activities. This occurs in Phase 2.
Except in so far as their effects are reflected in the
Division of Labour, description of Roles plays no
direct part in AT, and as such the term does not
appear in our extended AT taxonomy. Whilst in this
example eliciting Roles proved necessary for a
consistent Activity list, it may not always be
necessary to elicit Roles simply to move on to Phase
2. We anticipate however, that a clear mapping of
the coincidence of Roles in Subjects will prove
necessary for recomposition into System
Requirements in Phase 7. Further, there may be
times during decomposition of Group Doings that an
analyst is tempted to restructure the Group Process
by collapsing or conflating Doings. Consideration of
Roles however should reveal that some near-
equivalent and seemingly repetitive or redundant
Doings probably must be retained for reasons of the
Agenda and the Group’s cultural-historical structure.
6.2 Phase 2 – Activities
The primary unit of analysis in AT is the Activity
itself, usually visualised as the seven node Engström
matrix (Figure 1). For our purposes we specify what
each node contains for a systems design context.
SUBJ: the Subject is the group or individual who
conducts a particular Activity. An individual can be
the Subject of any number of Activities, which
indicates that individuals’ unique organisational
Role.
Table 4: Academic Activities.
Subject 1 (S1) = Academic(s)
S1.01 Create assessment questions
S1.02 Create marking guide
S1.03
Make assessment questions available to
Students
S1.04
Distribute assessment questions and
marking guide to Tutor(s)
S1.05
Field clarifications from Tutors (S3) and
Students (S2)
S1.06
Conflate all marks to a personal archive
Spreadsheet
S1.07 Advise Students of marks
S1.08 Field Student appeals and complaints
S1.09
Semester processing of totals to Campus
Administration system.
COMM: the Community comprises all other parties
involved in transactions associated with the Activity.
Subjects of one Activity are often Community
members of another, as the Network of Activities at
layer four indicates that the Activities are related, if
only by use of some common Tool.
Table 5: Student Activities.
Subject 2 (S2) = Student (s)
S2.01 Get assessment questions
S2.02
Submit assessment answers and validate
submission
S2.03 Check marks
S2.04 Appeal results
Identification of the Community indicates how the
UI elements of the System need to be grouped, such
that all parties have the appropriate capability to
interact and conduct their normal transactions.
TOOL: the Tool(s) comprise all physical, virtual and
psychological facilitating mechanisms used by the
Subject and or Community members. Tools include
not just sophisticated artefacts and softwares, but
also seemingly mundane facilitators such as clocks,
telephones, notepads and personal conversation. The
analyst must consider all Tools, as the final System
may subsume, imitate or compliment any number of
them.
RULE: the Rules node for our purposes contains
primarily Temporal constraints, including ordinal
ranking of Actions where appropriate.
DivLAB: the Division of Labour for our purposes
contains primarily Deontic constraints. Issues of
obligation, permission, denial and the like, indicate
‘who does what’.
OBJ: the Object is crucial analytical node for
classical AT, but for our purposes may be conflated
with the driving Motive. It effectively contains that
which the Activity hopes to achieve.
The identification of Objects in early phases of
elicitation serves as strong indicators that Activities
have been identified. Ultimately, Activities are
defined and differentiated by these Motives.
OUT: The Outcome node contains that which
actually results from the Activity. Classical AT pays
strong attention to the tension between Object and
Outcome. For our purposes the Outcome can contain
interesting linkages. As observed by Kuutti (Kuutti,
1991), the outcome of one Activity may appear in
any node of another: in RULE as a Temporal
constraint, in DivLAB as a Deontic constraint, in
TOOL as some process, device or document, in
SUBJ or COMM as some individual whose Role has
changed or most interestingly, in OBJ as a new
AN APPLICATION OF THE 5-S ACTIVITY THEORETIC REQUIREMENTS METHOD
155

motive which thus can instantiate a whole new
Activity.
In our test example we elicited different candidate
Activities from two Academics, their Tutors and
Students.
Since the Role(s) played by different members of S1
are equivalent, we assume that there should be a
consistent common set of S1 Activities. We returned
to the individuals and produced a consensus Activity
set which is shown in Table 4. Achieving consensual
agreement is not a deterministic process however,
though by following AT principles it was possible to
facilitate negotiations by presenting all options
within a common framework.
Some Activities have been subsumed into others, for
example S1A.06 “facilitate negotiation of marking
scheme with tutors” becomes simply one means of
achieving S1.02 “create marking guide”. Other
Activities may have been relegated to the Action
layer.
Should it prove impossible to produce a consensus
Activity set, then perhaps there has been some
confusion regarding Roles. The Activity Network
needs re-examination and perhaps a new category of
Subject(s) is required. Thus, following AT principles
prompts and facilitates resolution whenever analysis
fails to capture the Group Process properly.
By a similar process a consensus Activity set was
produced for the Students and Tutors. We present
the Student Activities in Table 5.
Table 6: Node Entries for Activity S2.01.
“Get assessment questions”
SUBJ
Student enrolled in correct course
COMM
Academic &/or Tutor of that course
OBJ
Obtain a correct and complete version
of the assessment questions
RULE
• Assessment questions only become
available after notification.
• There may be a deadline after which
the questions become unavailable
DivLAB
• Only a Student enrolled in that
course should be able to obtain the
assessment questions
• The Academic or Tutor must
provide notification on time
• The Academic or Tutor must
provide a correct and complete
version
TOOL
• Some means of receiving
notification
• Network account and/or ID card
• Networked access
OUT-
COME
Student now has a TOOL and the
RULE and DivLAB details for Activity
S2.02
Each Activity can be represented on an Engström
matrix. We tabulated the Activity details, and details
of the sample Activity S2.01 “get assessment
questions” is presented below in Table 6. Observe
that until the System has been designed, the TOOL
node can only reflect currently used or speculative
Tools.
The OUTCOME reflects that this Activity is linked
to another in the Activity Network. Whilst not
shown here, DivLAB constraints in Activity S1.01
“academic creates assessment questions” required
that the assessment contain correct instructions and
deadline information for the Students. According to
AT, the actual Outcome may be quite unexpected
and final deployment of the System may produce
variance.
6.3 Phase 3 – Actions
Actions are Goal driven Doings, subsidiary to
Activities. The Actions comprising any one Activity
should all serve the Motive of that Activity, just as
Activities of one Subject must fulfil that Subjects
Role.
Examining Activity S2.01 ‘get assessment
questions’ we identified Goal driven component
Actions. These are identified in Table 7.
Table 7: Actions for Activity S2.01.
“Get assessment questions”
Subject 2 (S2) = Student (s)
S2.01.01
get notification of assessment questions
availability
S2.01.02 get assessment questions
S2.01.03 get supporting materials
Observe that Action S2.01.02 ‘get assessment
questions’ has the same name as the parent Activity
S2.01. Despite appearances, this is not an
inconsistency, as AT tracks the protagonists
cognitive involvement. Actions are of a lower order
than their parent Activity. The analyst must
however, be careful in situations of this kind and
keep the nomenclature convention in mind.
Wherever possible, it is better to describe Activities
by their Motives, and Actions by their Goals.
6.4 Phase 4 – Operations
As Phase 4 marks the turnaround from
decomposition to recomposition it attempts to
specify a Switch of the proposed System for each
Operation that involves the System.
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
156

Utterances from Students of Academics A and B,
indicated different Conditional Operations, shown in
Table 8. One set follows a manual process, the other
an online process.
Some confusion arose in negotiating common
Operations. The utterances “I go to the right lecture
class” and “I go to a networked computer” initially
seemed to equate. Asking ‘why’ questions, revealed
otherwise. Going to the correct lecture class in fact
functionally equates with going to the correct course
sub directory after logging on to the network.
Table 8: Candidate Operations for Action S2.01.02.
“get assessment questions”
Subject 2A (S2A) = Student of Academic A
S2A.01.02.01 go to networked computer
S2A.01.02.02 logon to FTP network
S2A.01.02.03
go to appropriate sub directory for
the correct course
S2A.01.02.04
go to the appropriate sub directory
for the correct assessment task
S2A.01.02.05
download, copy or print out the
assessment questions
S2A.01.02.06
check assessment question
document for completeness and
correctness
S2A.01.02.07 logoff
Subject 2B (S2B) = Student of Academic B
S2B.01.02.01 go to correct lecture theatre
S2B.01.02.02 collect assessment questions
S2B.01.02.03
check assessment question
document for completeness and
correctness
S2B.01.02.04
ask clarifying questions regarding
the assessment questions and/or the
constraints they impose
S2B.01.02.05 leave the lecture class
While some Operations are subsumed, dropped or
added, others were outside the scope of the System.
Operation S2.01.01 had no initial equivalent for S2B
however, Academic B decided that it was a useful
feature, and agreed to impose this Condition.
Operation S2B.01.02.04 was removed and migrated
to Activity S2.04, now expanded and associated with
all Student-to-Academic/Tutor communications.
Common Operations are shown in Table 9.
Even after the System is deployed, not all Doings
will invoke its use. Numerous technical,
psychological and mechanical Tools are available.
By our definition however, at least some Doings of
each member Activity will invoke the System. Our
aim is to capture and describe these as System
Requirements.
Table 9: Operations for Action S2.01.02.
“get assessment questions”
Subject 2 (S2) = Student (s)
S2.01.02.01 establish identity
S2.01.02.02 select correct course
S2.01.02.03 select correct assessment
S2.01.02.04 download/Copy/Print assessment
S2.01.02.05 verify assessment
S2.01.02.06 leave
Table 10 shows Phase 4 identified Conditions and
maps them to UI widget Switches. Operation
S2.01.02.01 can be achieved by a System Logon
Doing. For our purposes, complex multi-part GUI
widgets such as a FileSave dialogue, are deemed
atomic by their near universal adoption.
Operation S2.01.02.03 ‘select correct assessment’
implies exclusive choice from a finite number of
pre-set options. Accordingly a Radio Button panel or
a Pull-Down Menu may be suitable.
Several standard Switches may be suitable and the
choice would reflect the personal leanings of the
analyst (and/or stakeholders). The analyst should be
confident that the design would be functional,
appropriate and feasible at least, if not necessarily
elegant.
Table 10: Operations and Switches.
Operation Switch
S2.01.
02.01
establish identity to
the system
LOGON widget
S2.01.
02.02
select correct course
Radio button or
Drop down menu
S2.01.
02.03
select correct
assessment
Radio button or
Drop down menu
S2.01.
02.04
download, copy or
print
assessment
questions
FileSave and/or
Copy-Paste function
and/or
Print widgets
S2.01.
02.05
verify correct
assessment
questions
Task switch to local
system
S2.01.
02.06
leave LOGOFF widget
6.5 Later Phases - Recomposition
The Switches identified in Phase 4 will be composed
into Screens in Phase 5. Screens and Actions are
closely related but there might not be a 1:1 mapping.
We do however expect that ScreenSets will have a
1:1 mapping to Activities.
Leont’ev (Leont’ev, 1978) predicts that familiarity
and expertise leads to Doings dropping down the
hierarchy. After some experience, we could able to
AN APPLICATION OF THE 5-S ACTIVITY THEORETIC REQUIREMENTS METHOD
157

short-cut some of the more perfunctory mechanisms,
as our own Actions became Operations. This
interesting confirmation of AT also indicates that the
method will ultimately serve both as a prescriptive
toolset for the novice and an informing framework
for experienced practitioners.
The analyst however, should collect data in
decomposition that serve for the recomposition
phases (see Figure 1). Roles help inform Phase 7;
the Motives of Activities help compose ScreenSets
in Phase 6. Temporal and Deontic constraints,
recorded in the RULE and DivLAB nodes, indicate
of how UI elements should best be collected, shared
and sequenced to facilitate the Group Agenda.
7 CONCLUSIONS AND FUTURE
WORK
Our method shows potential to be a systematic and
prescribed process with a solid theoretical base. We
believe it will elicit meaningful Requirements from
stakeholder utterances without requiring the analyst
to have a deep knowledge of Activity Theory.
Whilst mechanisms, heuristics and tools are still
being refined, preliminary findings indicate that an
AT based method can be an excellent match for
complex multi user Doings. We are satisfied that AT
can indeed underpin a design methodology for
systems within our scope. There is indication that an
end-to-end AT based method may have some
advantages over some current tools and methods.
Method components for the recomposition phases
and for final evaluation are beyond the scope of this
paper, and will be demonstrated in future papers.
A normative evaluation study of the 5-S method for
a real-world system design scenario will be
conducted as soon as the method components have
been fully described. The evaluation will appear in
future publications.
REFERENCES
Brown, R.B.K., Hyland, P. & Piper, I.C., 2005. “Eliciting
and Specifying Requirements for Highly Interactive
Systems using Activity Theory” Proceedings of
INTERACT’05, Rome, Italy.
Brown, R.B.K., Hyland, P. & Piper, I.C., 2006. “5-S, an
Activity Theoretic Requirements Elicitation Method
for Multi-User Systems”. International Transactions
on Systems Science and Applications ISSN 1751-1461
Corporate Solutions. “Usability Engineering” online
article. http://www.consult-me.co.uk/csc-usability-
engineering-page.htm last accessed 10/Feb/2006.
Engström, Y., 1987. Learning by Expanding: an activity-
theoretical approach to developmental research,
Orienta-Konsultit Oy, Helsinki, Finland,
Kuutti,K., 1991. Activity Theory and its applications to
information systems research and development, in
Nissen, H.E., Klein, H.K., & Hirsheims, R. (Eds)
Information Systems Research: Contemporary
Approaches and Emergent Traditions Elsevier
Science, Amsterdam
Leont’ev, A.N., 1978. Activity, Consciousness, and
Personality, Prentice Hall,
Martins, L.E.G., & Daltrini, B.M., 1999. “An Approach
to Software Requirements Elicitation Using Precepts
from Activity Theory” Proceedings of the 14th IEEE
Conference on Automated Software Engineering
ASE’99, Cocoa Beach, USA
Nielsen, J., 1994. Usability Engineering, Morgan
Kaufmann, San Francisco.
Oxford English Dictionary Online. www.oed.com,
Entry for “Doing, vbl.n.”, 2nd definition
Paterno, F., & Palanque, P., 1996. “Formal Methods in
Computer Human Interaction: Comparisons, benefits,
Open Questions”, workshop session, CHI’96.
Vrazalic, L., 2004. “Towards Holistic Human-Computer
Interaction Evaluation”, PhD Thesis, University of
Wollongong, Australia.
Vygotsky, L.S, 1978. Mind in Society Harvard University
Press, Cambridge, MA.
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
158