From Task-Oriented to Goal-Oriented Web Requirements Analysis
D. Bolchini, и J. Mylopoulos. 4th International Conference on Web Information Systems Engineering (WISE), Roma, Italy, (2003)
Аннотация
Task analysis has been used traditionally in HCI and CSCW to define requirements for user interfaces, webbased or otherwise. This paper argues that a shift of paradigm is needed in web engineering from taskoriented to goal-oriented approaches for designing applications delivering a quality user experience and achieving the objectives of the stakeholders. Task models focus on fine-grained and precisely defined user needs, thereby risking a commitment to premature design decisions. Moreover, since task analysis focuses on users doing things with the system, tasks do not capture the goals of other stakeholders who are not users. Goaloriented methods, on the other hand, provide specific support for coping with high-level users and stakeholders goals, facilitates the exploration of design alternatives and the definition of requirements at a suitable level of abstraction. As such, goal-based techniques are more suitable for early stages of requirements analysis; task models can be used for later stages, such as detailed interaction design and usability evaluation. The paper conducts a detailed comparison of task- and goal-analysis design techniques, using an ongoing project for a museum website to illustrate the two techniques and their relative strengths.
4th International Conference on Web Information Systems Engineering (WISE)
год
2003
comment
says task modeling is fine but assumes a) focus on user and b) some design decisions already made. Suggests using goal analysis and decomposition to achieve tasks. "NFR are not captured in task analysis.. but thery are crucial for the overall quality of the user experience" central contribution of the work is that goal-based analysis broadens the spectrum of requirements to consider the design process using goals refines and analyzes the 'why' question - for the org. However, my view is that one is still not guaranteed to model all possible goals/tasks with either paradigm - the result wil still be unsatisfactory for some subset of the model - and you won't know until the user tries something unanticipated and dislikes it. Although, with goals, *if* you can identify all the top level goals, (which might be difficult in large systems) then you can be certain that the ones not in the model at lower levels (decomposed goals) aren't as important. On the fly customization suggests that we already have all the potential actions are user might take, and then adjust accordingly. Not sure if this is possible. Somewhat presumptuous to say that we can anticipate all uses. The beauty of web services is that users can do crazy shit with them, unanticipated by the company. And if it makes business sense, the company will add functionality - like Amazon. Basically I feel the problem is that both approaches demand a lot of effort and promise little added benefit over straightforward web design companies. I mean, a competent designer can anticipate 80% of this museum's issues and design accordingly. So what's the win for using i*? This is a research issue because although the goal model sounds nice, its utility seems under evaluated in real cases - which is why KHP is interesting.
%0 Conference Paper
%1 bolchini2003
%A Bolchini, D.
%A Mylopoulos, J.
%B 4th International Conference on Web Information Systems Engineering (WISE)
%C Roma, Italy
%D 2003
%K goals erc requirements-engineering
%T From Task-Oriented to Goal-Oriented Web Requirements Analysis
%U http://www.cs.toronto.edu/~nernst/papers/bolchini-wise03.pdf
%X Task analysis has been used traditionally in HCI and CSCW to define requirements for user interfaces, webbased or otherwise. This paper argues that a shift of paradigm is needed in web engineering from taskoriented to goal-oriented approaches for designing applications delivering a quality user experience and achieving the objectives of the stakeholders. Task models focus on fine-grained and precisely defined user needs, thereby risking a commitment to premature design decisions. Moreover, since task analysis focuses on users doing things with the system, tasks do not capture the goals of other stakeholders who are not users. Goaloriented methods, on the other hand, provide specific support for coping with high-level users and stakeholders goals, facilitates the exploration of design alternatives and the definition of requirements at a suitable level of abstraction. As such, goal-based techniques are more suitable for early stages of requirements analysis; task models can be used for later stages, such as detailed interaction design and usability evaluation. The paper conducts a detailed comparison of task- and goal-analysis design techniques, using an ongoing project for a museum website to illustrate the two techniques and their relative strengths.
@inproceedings{bolchini2003,
abstract = {Task analysis has been used traditionally in HCI and CSCW to define requirements for user interfaces, webbased or otherwise. This paper argues that a shift of paradigm is needed in web engineering from taskoriented to goal-oriented approaches for designing applications delivering a quality user experience and achieving the objectives of the stakeholders. Task models focus on fine-grained and precisely defined user needs, thereby risking a commitment to premature design decisions. Moreover, since task analysis focuses on users doing things with the system, tasks do not capture the goals of other stakeholders who are not users. Goaloriented methods, on the other hand, provide specific support for coping with high-level users and stakeholders goals, facilitates the exploration of design alternatives and the definition of requirements at a suitable level of abstraction. As such, goal-based techniques are more suitable for early stages of requirements analysis; task models can be used for later stages, such as detailed interaction design and usability evaluation. The paper conducts a detailed comparison of task- and goal-analysis design techniques, using an ongoing project for a museum website to illustrate the two techniques and their relative strengths.},
added-at = {2007-02-23T21:46:08.000+0100},
address = {Roma, Italy},
author = {Bolchini, D. and Mylopoulos, J.},
biburl = {https://www.bibsonomy.org/bibtex/2f9f17fd42621c48928db250110fdd0dd/mstrohm},
booktitle = {4th International Conference on Web Information Systems Engineering (WISE)},
citeulike-article-id = {111760},
comment = {says task modeling is fine but assumes a) focus on user and b) some design decisions already made. Suggests using goal analysis and decomposition to achieve tasks. "NFR are not captured in task analysis.. but thery are crucial for the overall quality of the user experience" central contribution of the work is that goal-based analysis broadens the spectrum of requirements to consider the design process using goals refines and analyzes the 'why' question - for the org. However, my view is that one is still not guaranteed to model all possible goals/tasks with either paradigm - the result wil still be unsatisfactory for some subset of the model - and you won't know until the user tries something unanticipated and dislikes it. Although, with goals, *if* you can identify all the top level goals, (which might be difficult in large systems) then you can be certain that the ones not in the model at lower levels (decomposed goals) aren't as important. On the fly customization suggests that we already have all the potential actions are user might take, and then adjust accordingly. Not sure if this is possible. Somewhat presumptuous to say that we can anticipate all uses. The beauty of web services is that users can do crazy shit with them, unanticipated by the company. And if it makes business sense, the company will add functionality - like Amazon. Basically I feel the problem is that both approaches demand a lot of effort and promise little added benefit over straightforward web design companies. I mean, a competent designer can anticipate 80% of this museum's issues and design accordingly. So what's the win for using i*? This is a research issue because although the goal model sounds nice, its utility seems under evaluated in real cases - which is why KHP is interesting.},
interhash = {aff06841f887e4a6ff446900bdd30034},
intrahash = {f9f17fd42621c48928db250110fdd0dd},
keywords = {goals erc requirements-engineering},
pdf = {bolchini-wise03.pdf},
priority = {0},
timestamp = {2007-02-23T21:46:08.000+0100},
title = {From Task-Oriented to Goal-Oriented Web Requirements Analysis},
url = {http://www.cs.toronto.edu/~nernst/papers/bolchini-wise03.pdf},
year = 2003
}