Method Engineering 2012 | Assignment 2
Sutcliffe, A., Fickas, S., & Sohlberg M. M. (2006).
PC-RE: a method for personal and contextual requirements engineering.
Requirements Engineering, 11(3), 157-173.
Arno Gregorian, 3375935, Group 1
PC-RE: a method for personal and contextual requirements engineering
Introduction
Requirement analysis should deliver “a condition or capability needed by a user to solve a problem or
achieve an objective” as defined by IEEE 610.12-1990 (1990). These conditions or capabilities apply
to a system or a system component and can be represented in various ways. Classifications for
requirements and users already exist. The authors (of PC-RE) however want to introduce a method
that includes the goals of users, their characteristics and how computer systems should support users to
achieve their goals. This results in a method that takes into account the personal and contextual
requirements of users.
A three layer framework is introduced to analyze changes in time and location that influence
requirements. The layers describe requirements for the following user groups: general stakeholders,
user characteristics and personal goals. Three implementations paths of requirements are suggested for
the layers of user characteristics and personal goals. The first path develops the requirement as a
conventional system function, the second as a user-customizable feature and the third as an automatic
system adaption.
The framework is developed into a scenario based road map with five different pathways. Every path
starts with an assessment of the application type and ends with a negotiation and validation of
requirements. The time and location dimensions of the framework are used to differentiate the
pathways. Every pathway has unique and overlapping activities that help in finding the right
requirements. The first two paths focus on the location dimension and describe requirements analysis
for international applications and mobile applications. The third and fourth path focus on the time
dimension and have predictable or unpredictable change as a starting point. The fifth path has an
individual user focus and is used to determine personal goals. The paths are iterative, one application
can by analyzed by one or more paths. Different pathways can result in different cost-benefit
distribution. A technique to analyze these distributions is also discussed by the authors.
The method extends requirements engineering by taking into account individuals and changes in time
and location for requirements analysis. The method delivers a set of personal and contextual
requirements but does not give any directions on how to validate and negotiate the requirements.
The authors (of PC-RE) have an extensive research background, Sutcliffe and Fickas provide a solid
requirements engineering background and Sohlberg the psychology expertise. Alistair Sutcliffe is a
professor of systems engineering at Manchester University and the director at the centre for HCI
design. He has authored 6 books and 200+ publications on human computer interaction and
requirements engineering. Stephen Fickas is a professor at the department of computer and
information science at the University of Oregon and a researcher of requirements engineering. McKay
Moore Sohlberg is a communication disorders and sciences professor at the University of Oregon and
is known for her work in cognitive rehabilitation.
Example
In this example we describe all the steps of the method in order to determine the requirements for a
desktop email application like MS Outlook or Mozilla Thunderbird for a student. The example is in
part based on the case study presented in the paper.
The final deliverable of the three layer framework should be a requirements document for the
application, the authors present this document in a simple table which can be found in Table 1. The
table takes into account the three layer framework by using the layers ‘Group’, ‘User characteristics’
and ‘Personal goals’ as rows and using the two dimensions of time (temporal) and space (spatial) as
columns.
Requirements layer and
goals
Group: students
Functional requirements
Temporal change
Spatial context
Basic email functions such
as reading, sending, replying
and deleting.
Overtime a backup option or
search options can be useful
to all users.
User characteristics: Young,
frequent use of the
application, probably large
amount of email traffic,
email checking at home and
at school.
Personal goals: More
efficient use of the
application and reduce
spam.
Additional functions such as
hints and reminders for
sending and reading emails.
Adding categories to email
for more structure in the
email inbox.
Spam detection based on
personal preferences and
choices.
Shortcuts and commands for
speeding up the use of the
applications for advanced
users.
Making sure that all emails
can be managed at different
locations and desktop
systems.
Making sure that in some
geographical locations the
emails are stored locally and
some other locations the
emails are left at the email
server.
None.
Table 1, a sample requirements table for one personal profile
Table 1 begins with some example requirements for the student, then takes into account his or her
special user characteristics and in the final row focuses on the wishes of the student to be more
efficient while using the application and reduce spam. It is important to notice that not all cells need a
value, for example if the personal goals do not specify any spatial conditions no spatial requirements
will be needed.
The method to gather the requirements is described in the scenario road map. The scenario starts with
an assessment of the application which will help determining which paths to take. In this case we can
leave out the mobile application path and focus on the international application, predictable time
change, unpredictable change and individual user focus paths. These paths all include three activities
that help analyzing, specifying and generalizing requirements. For example the culture of students can
be analyzed, requirements such as saving emails locally can be specified and smart shortcuts may be
generalized for all users. The paths all end in a negotiation and validation of the requirements. The
final path of ‘individual user focus’ is quite unique, it is the only path that sets achievement goals for
the student and has the unique step of trading off solutions where goals set by expert stakeholders are
compared to personal goals of specific users.
The scenario road map itself also can have a deliverable that presents the findings of all the activities
of the paths taken. The authors do not specify how this deliverable should look, but in this case it also
could be a table. The first path of ‘international applications’ could for example result in the following
deliverable Table 2.
International application pathway
Activity
Analyze cultural context
Refine requirements for localization
Specify local configurations
Requirements
For example, students are individualistic, avoid
uncertainty and ‘prefer precise instructions’.
…
…
Table 2, the requirements determined by the activities of the international application pathway
In the first column each activity in the pathway is given and the requirements found during this
activity are given in the second column.
Related literature
Classifying functional and non-functional requirements using taxonomies is not a new concept. The
taxonomies however usually focused on the subject or a part of the system and not on the users or
other agents involved with the system (Sutcliffe, Fickas, & Sohlberg, 2006). Adapting requirements to
the changes in time was first introduced by Fickas & Featjer (1995). The changes in time might
become more important with the ageing population in the US, Europe and Japan as suggested by
Newell & Gregor (2000).
Location, another important property of the PC-RE method was partly discussed in the Inquiry Cycle
by Potts, Takahashi & Anton (1994). The importance and possibilities of using spatial requirements
has been discussed by Cheverst, Davies, Michell, Firday & Efstratiou (2000). They showed to
advantages of using a context-aware tourist guide that used its location as an important requirement
for its features.
Defining requirements based on stakeholder groups has been included in other methods such as
ScenIC (Potts, 1999) and Volere (Robertson & Robertson, 1999). The research on cultural influences
on requirements is still in its infancy, however ethnographic studies suggest very different
requirements are needed in different cultures. The example mentioned by the authors is the privacy
requirement differences for ATM machines in the west and in India as researched by De Angeli,
Athavankar, Joshi, Coventry & Johnson (2004). The big power-distance in India created for example a
situation in which people, who considered themselves to be of a lower status, did not use the ATM
machines.
The PC-RE method also includes a layer that focuses on individual users. Two known approaches for
handling personal requirements are creating adaptable and adaptive systems. An adaptable system uses
explicit input provided by the users to change its behavior while an adaptive systems tailors its output
by implicit actions of the user (Van Velsen, Van der Geest, Klaassen, & Steehouder, 2008). Personal
approaches are also discussed in human computer interaction research. Two topics in this field are the
requirements for generic tasks and their support and how to select system features that can be
customized for individual users (Sutcliffe A. G., 2002). Norman (2004) makes the case for adaptability
from a human computer interaction standpoint in order to make a system ‘your own’ and to be
satisfied in using it.
Al these different dimension, stakeholders and architectural approaches give a different way of
analyzing requirements. The authors bring all these topics together in their PC-RE method for the first
time. Currently this method only has been evaluated by the authors themselves.
Product-Deliverable Diagram
The scenario-based requirements analysis is the most important new method introduced by the authors
of the PC-RE method. This method is modeled in Figure 1 as a Product-Deliverable Diagram (PDD)
(Weerd & Brinkkemper, 2008). In this diagram the important activities and deliverables are modeled
side by side. On the left side of the diagram we find the activities in rounded rectangles and on the
right side we find the so called ‘concepts’ in rectangles modeled as meta-data models. Each activity
that results in a concept is connected with a dotted arrow to the concept in belongs to. Each activity
and concept are explained in more detail in Table 3 and Table 4. The activities are almost all defined
by the activities in the road map of the article. The authors rarely assign any roles to the activities, two
roles are therefore modeled in the activities. These are the roles of the expert stakeholder and
application owner, all the other activities are performed by the consultant or researcher.
PDD
Figure 1, a PDD based on the PC-RE method
Activity table
Activity
Assess application type
Sub-activity
Analyze international
application
Analyze cultural context
Refine requirements for localization
Specify local configurations
Description
An assessment is done to identify which of
the five pathways will be taken for the
specific application and user. This results
in an APPLICATION ASSESSMENT.
This analysis provides a part of the spatial
dimension in the framework and results in
the CULTURAL CONTEXT.
The CULTURAL CONTEXT is refined for
requirements.
The analysis and refinement result in this
activity in the LOCAL
REQUIREMENT
CONFIGURATIONS.
Analyze mobile
application
Analyze spatial context
Specify requirements for
monitoring
Specify requirements for adaptation
Analyze predictable time
change application
Analyze temporal applications
Specify temporal monitoring
requirements
This analysis provides a part of the spatial
dimension in the framework and results in
the SPACIAL CONTEXT ANALYSIS.
The SPACIAL CONTEXT
ANALYSIS is used to specify the
MONITORING REQUIREMENTS.
The SPACIAL CONTEXT
ANALYSIS is used to specify the
MOBILE ADAPTATION
REQUIREMENTS.
This analysis provides a part of the
temporal dimension in the framework and
results in the TEMPORAL
IMPLICATIONS ANALYSIS.
Temporally significant events result in
requirements for monitoring, which are
determined and result in TEMPORAL
MONITORING REQUIREMENTS.
Specify requirements for adaptation
Temporally significant events result in
requirements for adaptation, which are
determined and result in PREDICTABLE
TIME CHANGE ADAPTATION
REQUIREMENTS.
Analyze unpredictable
change application
Analyze evolving requirements
Specify variation points
This analysis provides a part of the
temporal dimension in the framework and
results in the EVOLVING
REQUIREMENTS ANALYSIS. The
analysis is exhaustive and includes the
complete domain.
The points determine when requirements
change can be expected and results in
VARIATION POINTS.
Generalize evolving requirements
For future implementations the
requirements are made more adaptable
resulting in the GENERALISED
EVOLVING REQUIREMENTS that
use the VARIATION POINTS.
Analyze individual user
focus application
Define user profile
Set achievement levels
An expert stakeholder determines the
personal profile by using stereotypes
resulting in USER PROFILE.
The application owner sets his or her
personal achievement levels in
ACHIEVEMENT LEVELS.
Specify monitoring and adaptations
Important temporal events result in
monitoring and adaption requirements set
in the MONITORING AND
ADAPTION REQUIREMENTS.
Trade off solutions
The consultant compares the
ACHIEVEMENT LEVELS and the
USER PROFILE and creates a
combined list of TRADE OFF
SOLUTIONS.
Negotiate and validate
requirements
This is a closed activity and results in
VALIDATED REQUIREMENTS.
Table 3, a table of all the activities used in the PDD in Figure 1
Concept table
Concept
APPLICATION ASSESSMENT
INTERNATIONAL REQUIREMENT
CULTURAL CONTEXT
LOCAL REQUIREMENT CONFIGURATIONS
MOBILE REQUIREMENT
SPATIAL CONTEXT ANALYSIS
MONITORING REQUIREMENT
MOBILE ADAPTATION REQUIREMENT
PREDICTABLE TIME CHANGE
REQUIREMENT
TEMPORAL IMPLICATIONS ANALYSIS
TEMPORAL MONITORING REQUIREMENT
PREDICTABLE TIME CHANGE
Description
A consideration of the type of application to
determine requirements related to individuals and
changing requirement of a temporal and spatial
nature.
International requirements including
CULTURAL CONTEXT and LOCAL
REQUIREMENT CONFIGURATIONS.
A cultural context including and / or cultural
impact, authority relationships, work patterns,
literacy and local languages as defined by
Hofstede (1980) and Hall (1976).
A requirement created by refinement of the
CULTURAL CONTEXT.
A requirement of mobile requirements containing
SPACIAL CONTEXT ANALYSIS,
MONITORING REQUIREMENT and MOBILE
ADAPTATION REQUIREMENT.
Spatial context described in ‘locales’ models
(Fitzpatrick, 2003).
Monitoring includes the sensors, functions and
processes, interpreters and domain models of an
application (Dix, Rhodden, Davies, Trevor, &
Friday, 2000).
Requirements based on mobile adaptation using
SPATIAL CONTEXT ANALYSIS.
A requirement of predictable time change
requirements containing TEMPORAL
IMPLICATIONS ANALYSIS, TEMPORAL
MONITORING REQUIREMENT and
PREDICTABLE TIME CHANGE
ADAPTATION REQUIREMENT.
An analysis using as sensor the system clock and
the implications of time. Temporal dependencies
might be defined in a language such as KAOS
(Lamsweerde & Letier, 2000).
Requirements that are the result of events
specified in the predictable time change pathway
or others.
Requirement that is the result of events specified
ADAPTATION REQUIREMENT
UNPREDICTABLE CHANGE
REQUIREMENT
EVOLVING REQUIREMENTS ANALYSIS
VARIATION POINTS
GENERALISED EVOLVING REQUIREMENT
INDIVIDUAL USER FOCUS REQUIREMENT
USER PROFILE
ACHIEVEMENT LEVELS
MONITORING AND ADAPTION
REQUIREMENT
TRADE OFF SOLUTIONS
REQUIREMENT
REQUIREMENTS FRAMEWORK
in the predictable time change pathway or others.
A requirement of unpredictable change
requirement containing EVOLVING
REQUIREMENTS ANALYSIS, VARIATION
POINTS and GENERALISED EVOLVING
REQUIREMENTS.
A documentation of the anticipated changes in
the requirements.
A documentation of when the changes will occur,
the moments will be called variation points.
A generalization of processes and procedures,
parameters, run-time binding of procedures and
data structures, adding functionalities at variation
points and making the architecture loosely
coupled.
A requirement of an individual user focus
requirement consisting of a USER PROFILE,
ACHIEVEMENT LEVELS, MONITORING
AND ADAPTION REQUIREMENTS and
TRADE OFF SOLUTIONS.
A user stereotype description defined by an
expert stakeholder.
Achievement levels and personal goals set by the
application owner.
Contains a requirement (benchmarks) for
monitoring and adapting for the USER PROFILE
and ACHIEVEMENT LEVELS.
The list of solutions that remains after the
comparison of the USER PROFILE and
ACHIEVEMENT LEVELS.
“A statement on an action that the product is
requested to do, or a quality that the product is
requested to have.” (Robertson & Robertson,
1999)
A table consisting of requirements and an
application assessment to create a framework of
requirements for the development of applications.
Table 4, a table of all the concepts used in the PDD in Figure 1
References
Cheverst, K., Davies, N., Mitchell, K., Friday, A., & Efstratiou, C. (2000). Developing a contextaware electronic tourist guide: some issues and experiences. Proceedings of the Conference on human
factors in computing systems, New York, USA, 17–24.
De Angeli, A., Athavankar, U., Joshi, A., Coventry, L., & Johnson, G. I. (2004). Introducing ATMs in
India: a contextual enquiry. Interact Comput 16, 29–44.
Dix, A., Rhodden, T., Davies, N., Trevor, J., & Friday, A. (2000). Exploiting space and time as a
design framework for interactive mobile systems. ACM Trans Comput Hum Interact, 7, 285–321.
Fickas, S. (2005). Clinical requirements engineering. Proceedings of the ICSE 2005: 27th
International conference of software engineering. Los Alamitos, USA, 45-59.
Fickas, S., & Featjer, M. S. (1995). Requirements monitoring in dynamic environments. Proceedings
of the IEEE international symposium on requirements engineering, Los Alamitos, USA, 140–147.
Fitzpatrick, G. (2003). The locales framework: understandingand designing for wicked problems.
Dordrecht: Kluwer Academic.
Hall, E. T. (1976). Beyond culture. New York: Anchor Doubleday.
Hofstede, G. (1980). Cultures consequences: international differences in work related values.
Thousand Oaks: Sage.
IEEE Standards Coordinating Committee of Computer Society. (1990) IEEE Standard Glossary of
Software Engineering Terminology. New York: IEEE Publishing
Newell, A. F., & Gregor, P. (2000). User sensitive inclusive design: in search of a new paradigm.
Proceedings of the Conference on Universal Usability, New York , USA, 39–44.
Norman, D. A. (2004). Emotional design: why we love (or hate) everyday things. New York: Basic
Books.
Potts, C. (1999). ScenIC: a strategy for inquiry-driven requirements determination. Proceedings of the
4th IEEE international symposium on requirements engineering, Los Alamitos, USA, 58–65.
Potts, C., Takahashi, K., & Anton, A. I. (1994). Inquiry-based requirements analysis. IEEE Software
11 , 21–32.
Robertson, J., & Robertson, S. (1999). Mastering the requirements process. Harlow: Addison Wesley.
Sutcliffe, A. (2002). User-centred requirements engineering. London: Springer.
Sutcliffe, A., Fickas, S., & Sohlberg, M. M. (2006). PC-RE: a method for personal and contextual
requirements engineering. Requirements Engineering 11(3) , 157-173.
Van Lamsweerde, A., & Letier, E. (2000). Handling obstacles in goal-oriented requirements
engineering. IEEE Trans Softw En, 26, 978–100.
Van Velsen, L., Van der Geest, T., Klaassen, R., & Steehouder, M. (2008). User-centered evaluation
of adaptive and adaptable systems: a literature review. The Knowledge Engineering Review , Volume
23:3, 261–281.
Weerd, I., & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In
M. Syed, S. Syed, J. Neidig, & J. Snavely (Eds.), Handbook of research on modern systems analysis
and design technologies and applications (pp. 133-162). Hershey, New York : Information Science
Reference.