Paper Review: From Task-Oriented to Goal-Oriented Web Requirements Analysis.
时间：2010-09-30 来源：yikliu
Homework WK2. Arthur Liu.
I. Key Lessons Learned:
1. “Goals” are higher level abstraction of requirement that need to be emphasized in the early stage of conceptualizing the design.
The “goal-oriented” approach in requirement analysis is more preferable in the sense that it overcomes several inherent flaws in traditional “task-oriented” approach. Due to its coarser granularity and ambiguity, goal-oriented approach should be more suitable in early stages of requirement construction. Designers should combine both approaches to comprehensively grasp all stakeholders’ (including users’) goals.
2. There are some inherent flaws of “Task-oriented” approach.
Insightful and logical revelation of inherent flaws of “task-oriented” approach is one of the major contributions of this paper. In particular, designers and web practitioners have long neglected the importance of “ill-defined” goals and the importance to integrate requirements from stakeholders with traditional user requirements. Also, it is worth noting that the “task-oriented” approach inevitably shuts down alternative paths by which users otherwise may follow to complete tasks in order to satisfy goals. This is important because in a real scenario, users don’t really have the script at hand on how to complete the task step by step. In reality, people cognitively search for options and may take several attempting iterations of “trial-fail” before they successfully complete the task.
3. Basic techniques in performing “Goal-oriented” requirement analysis.
A thorough introduction on how to combine “goal-oriented” approach with validated modeling methods to conduct requirement analysis is presented in section 4 and section 5. In particular, this paper provides basic instructions addressing following key topics in stages of early requirement gathering:
1) Adopting AWARE in early modeling.
2) Using AND-OR decomposition method and scenario envisioning for goal refinement.
3) Labeling requirements with design dimensions to organize requirements.
4) Summarizing requirements in forms of “Requirements Set”.
5) Identify conflicts in the requirements.
In another paper, the authors gave a more detailed description on conducting AWARE strategy on gathering requirement for “hypermedia-type of interaction”(Bolchini, Paolini, & Randazzo, 2003).
II Critique:
1. Positives:
A distinct separation and accurate definition of “Tasks” and “Goals” of this paper uplifts readers’ awareness on the importance of comprehensively envision requirements in forms of “goals” instead of solely “Tasks”, particularly involving goals from stakeholders.
This paper has also shrewdly identified several pressing shortcomings in traditional “task-oriented” approach and proposed a complementary “goal-oriented” method to compensate those limits. A conceptual upgrade from “user-goal” alone to involving “stakeholder-goal” is one major step forward in web requirement engineering philosophy. This change of mind not only enables designers to gather requirements from all related stakeholders thus meeting crucial goals that have been neglected before, but also makes up for traditional “task-oriented” method’s inability to properly address problems such as “ill-defined goals”, “non-functional requirements” and so forth.
Also worth noting is the appropriate integration of one instance of practice to build the museum website together with the introduction of “goal-oriented” approach, which vividly lay out basic ideas and concepts in terms of the method’ implementation and practical use. Following this example through both Task-based only analysis to also involving “Goal-based” analysis highlighted advantages of the latter over the former.
2. Negatives:
Aside from the positive points, it will be exciting to see how “goal-oriented” approach could be further validated either by experimental evaluation or by being tried out in the industry on a daily basis. To see how designers and project managers respond to this novel idea is essential in terms of model refinement, promotion or event application to broader audience.
Another disappointment comes from the fact that the discussion is tightly embedded in the flow of constructing requirements for the example of a museum website, which is an information-intensive introductory website. How well is “goal-oriented” strategy going to suit other types websites remain un-discussed.
On discussing identifying conflicts this paper constructed a method of deriving subtasks from goals and see if there are any contradicting tasks on the map of goals and tasks. This method is not sufficient in solving the potential mismatch between the requirements from the organization and the audience. There are many interesting questions needs to be answered: How to guide audiences’ interests toward the ones that the organizations want to promote? How to compromise or alter organization’s goals to meet goals from majority of the audience?
III Discussion Points
1. Managing Complexity
As you go over any books or articles regarding software development and system modeling, the most frequent phrase you’ll probably going to encounter is “Manage Complexity”. True, as said in the old saying, “the only thing that doesn’t change is change itself”. How well a method or framework accommodates constant changes from stakeholders is the gauge for testing its reliability and usefulness.
In designing structures for a new system with UML in software engineering, a designer usually has to foresee possible changes in requirement and separate those vulnerable parts from entities using abstraction and inheritance. Even so, they still cannot predict all the possible changes and eventually they have to re-organize the structure even in the late stages of implementation and coding, which is called “Refactoring”(Fowler, 1999).
It will be interesting to see how “goal-oriented” approach could better facilitate the adaption to changes compared to “task-oriented” approaches.
2. Ill-defined Goals
I’m fascinated by this notion of “ill-defined goals” as I was reading the paper. Call it bad requirement or intrinsic human flaw, people sometimes seem to have the inability to explicitly elaborate what they want, why they prefer one to another or how they really feel.
The “ASK” paper(Belkin, Oddy, & Brooks, 1997) goes beyond limited domain of traditional requirement analysis to adopting language retrieval using statistical word occurrences analysis whose outcome is network representations of requirements statements from users.
Do we really have to go that far to precisely retrieve people’s demands and requirements? Aren’t there any practical techniques that we can adopt to further generate finer, clearer requirements from users?
A further or maybe even more important question is how do we really extract “goal-like” requirement from users in the first place?
IV. Question:
Although the context of this paper is requirement gathering, I’m wondering how to apply this “goal-oriented” idea in the process of usability evaluation. In the referenced paper:(Bolchini, et al., 2003), the authors gave general instructions on this issue. Section 6 covers the topic on how to “reuse requirements for usability evaluation”, which mainly focuses on inspection by experts. On the other end, when conducting user testing, when constructing scenarios, how to better include stakeholders’ goals with users’ goals to coherently make up scenarios and tasks for users to complete?
References:
Fowler, M. (1999). Refactoring. Improving the Design of Existing Code: Addison-Wesley.
相关阅读 更多 +
