ME_Assignment_01b

advertisement
1 Introduction
The method itself aims to discover requirements of a software product from the many stakeholders’
perspectives. It comprises of two approaches, scenario based techniques, which in particular attempts
to discover a requirement of a stakeholder in a real situation. The second approach which is contextual
inquiry aims to collect the data and to nurture the requirements out of the collected data.
The contextual requirements discovery method is based on ART-SCENE (Analyzing Requirements
Trade-offs: Scenario Evaluation). The method has several important phases; however the most
important stages are scenario generation and walkthrough preparation, on-site scenario validation, onsite scenario walkthrough, analysis and results. Although some methods are designed to elicit
requirements during the workshops, this method attempts to discover the requirement in a real-life
setting. The method is supported by an application developed by the authors. The MSP, how the
application is named, is intended to be used during the on-site walkthrough scenarios and provides
normal and alternative courses of the events.
The first step in the entire process is to prepare for the on-site validation and walkthrough. To achieve
this, it is necessary to generate the scenarios similarly to the steps used in ART-SCENE projects. The
scenarios should be predicted or based on the domain of research. Then, the walkthrough preparation
should be performed to identify possible walkthrough scenarios. After these steps, the analysts who
will perform the walkthrough should be trained on the tools and the MSP itself. The second step is
performed in practice. Firstly, the validation is done to identify any misleading or missing scenarios
prior to the real walkthrough. This step is intended to hone the application and to remove the errors,
mistakes or misleading situations. When the flaws are identified it is strongly recommended to
incorporate them in the MSP and update the MSP by removing the particular deficiencies.
The third step is performed on-site similarly as the second step. The analyst is interviewing the
stakeholders while performing the desired task or activity. The analyst is trying to gather information
from the stakeholders during the activities. Literally, the requirements are elicited by interviewing the
stakeholders by an analyst on-site. The last step is described as analyzing the data and summarizing
the results. In the last stage the deliverable is prepared. The deliverable is a list of requirements
collected and observed during the walkthroughs. The list of requirements might either consist of costs
or the value of the requirements. However, ART-SCENE CoRE (Contextual Requirements Elicitation)
aims to discover any possible course of the actions and to contribute to the completeness of a software
product by formulating the vast majority of the requirements. The analysts play the main role in the
process since they formulate and cluster the requirements according to the functional area and
according to the different stakeholders involved. Moreover, the method is a significant contributor to
the overall list of the requirements. As a matter of fact, the whole process is executed on-site; this
encompasses encountering unforeseeable and unsearchable shortcomings which are hidden to the
ART-SCENE method.
The method is intended to be used in a field of ethnography where a human factor is notably being
involved and the actions are hardly to be predicted. Therefore, the ART-SCENE method is not
sufficient as it tends to omit lots of the steps in the possible scenarios. The CoRE method is purely
practical and its sense lies in performing it in real-life conditions to get as much requirements as
possible. The method is mostly applied on many different software products which are in the
development or has been already released.
2 Example
A good example of CoRE could be any highly interactive system with a human behavior. It is worthy
to note that I perceive this method mostly used in the system-human interactions. Google Glass might
be a very good example of a usage of CoRE in order to elicit the requirements. Since the glasses
represent a strong interaction of a system and a human. However, Google Glass might have many
functions but not all of them might be as useful as the analysts assumed.
The first step would as described in Section 1, scenario generation and walkthrough preparation. First
of all, it is necessary to determine the scenarios in which Google Glass could be used and how the
walkthrough should look like, what alternatives might occur and so on. For instance, what can occur if
a person wearing the glasses is in the toilet? How can this kind of situations be avoided? What are the
actual requirements and what are the predicted requirements by analysts. The analysts should choose
interviewees, preferably from the focus group of the product. The on-site scenario validation will
recognize errors and misleading scenario events such as recognizing an oral command of a user in a
wrong context. For instance, pouring a cup with a hot water while showing an image and covering the
activity done in a real life could lead to burning your hand. All this kind of situation should be
predicted in a first stage and if not then should be caught in the validation stage. In the third stage
analysts should accompany a few users and interview them what is wrong what should be done
differently, what is annoying what bothers them to identify any new requirements from the
stakeholders. For example, a user of Google Glass may require showing the clock constantly or keep a
small map in the corner during the navigation and so on.
The analysts then should be able to provide a list of what kind of requirements were observed, how
many of the requirements have been observed in different functional areas. For instance, let’s say that
CoRE was applied on a scenario of wearing the glasses in the kitchen while cooking and the users
have identified 10 threats to their health. Hence, the stakeholder will generate new requirements on
Google Glass not to show the information or to show other information. The result list could comprise
of the requirements regarding the security, misunderstanding of a command, new functions or
unnecessary functions etc.
In the example of Google Glass it is very difficult to predict every single situation which might occur
therefore the method of requirement discovery could soundly explain the requirements of the
stakeholders.
3 Related Literature
The origin of ART-SCENE CoRE might be found in ethnography. For the very first time the nurturing
of requirements by using ethnographical approach was identified by Schuman (1987). Ethnography in
terms of a requirements capture is focused more on users and their interactions with a computer
system rather than pure data collection (Sommerville, Rodden, Sawyer, Bentley & Twidale, 1993).
There are many examples when ethnographical approach was chosen to derive computer system
requirements. A study by Heath and Luff (1991) concerned underground railway control and
confirmed that ethnography plays a role in the requirements discovery. Likewise, a study by Ackroyd,
Harper, Hughes, Shapiro and Soothil (1992) examined the police department database systems and
implied the similar findings. The method itself has its roots in discovering stakeholder’s requirements
by generating a structured walking through scenarios used on the examples of naval and air traffic
management systems. These scenarios are elaborated on workshops with the stakeholders. (Mavin &
Maiden, 2003).
Ever since it has been always an issue to determine what a customer require from a new software
product (Maiden, 2004). Gougen and Linde (1993) describe simple methods as questionnaire
interviews, open interviews, conversation or zooming to elicit the requirements; however all of these
methods have certain constraints and limitations. Today’s software products require deeper insight
into users’ requirements. The ART-SCENE is a scenario-based method which intends to discover what
people truly desire from the new software product by performing an on-site validation and
walkthrough (Maiden, 2004). Scenarios are used mostly due to their human-oriented representation
which is emerged by involving the users and stakeholders into the design process (Rosson & Carroll,
2001). Maiden and Robertson (2005) described a different approach of a requirements discovery in an
air traffic management system. The method is called RESCUE and consists of series of creative
workshops in order to discover the requirements from the stakeholders.
Coble, Maffitt, Orland and Kahn (1995) opted contextual inquiry approach in suggesting requirements
for clinical information system for physicians. The study showed that contextual inquiry not only can
identify the stakeholders’ requirements precisely but also fosters stakeholders’ involvement and
devotion to the project as it reflects their true needs. The study follows contextual inquiry process
described by Holtzblatt and Jones (1993). The ART-SCENE CoRE is further used in an iRequire
mobile application, which is intended for requirement elicitation from the end-users. The application is
intended to be used on smartphones and attempts to elicit the requirements from the stakeholders
(Seyff, Graff & Maiden, 2010)
References
Ackroyd, S., Harper, R., Hughes, J.A., Shapiro, D. & Soothil, K. (1992). Information Technology and
Practical Police Work. Milton Keynes: Open University Press.
Coble, J.M., J.S. Maffitt, M.J. Orland & M.G. Kahn (1995). Contextual Inquiry: Discovering
Physicians’ True Needs. In R. M. Gardner (eds.): Proceedings of AMIA Annual Fall
Symposium. Philadelphia: Hanley & Belfus, Inc., pp. 469–473.
Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. Requirements
Engineering, 93, 152-164.
Heath, C., & Luff, P. (1991, September). Collaborative activity and technological design: Task
coordination in London Underground control rooms. In Proceedings of the second conference
on European Conference on Computer-Supported Cooperative Work (pp. 65-80). Kluwer
Academic Publishers.
Holtzblatt, K., & Jones, S. (1993). Contextual inquiry: A participatory technique for system
design. Participatory design: Principles and practices, 177-210.
Maiden, N. (2004). Systematic Scenario Walkthroughs with ART-SCENE. In Alexander, I., Maiden,
N. (Eds.), Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle (pp.
161–178). Hoboken: John Wiley & Sons.
Maiden, N., & Robertson, S. (2005). Integrating creativity into requirements processes: Experiences
with an air traffic management system. In Requirements Engineering, 2005. Proceedings. 13th
IEEE International Conference on (pp. 105-114). IEEE.
Mavin, A., & Maiden, N. (2003). Determining socio-technical systems requirements: experiences with
generating and walking through scenarios. In Requirements Engineering Conference, 2003.
Proceedings. 11th IEEE International (pp. 213-222). IEEE.
Rosson, M.B. & Carroll, J.M. (2001). Usability Engineering: Scenario-Based Development of
HumanComputer Interaction. San Francisco: Morgan Kaufmann.
Seyff, N., Graf, F., & Maiden, N. (2010, September). Using mobile re tools to give end-users their
own voice. In Requirements Engineering Conference (RE), 2010 18th IEEE International (pp.
37-46). IEEE.
Sommerville, I., Rodden, T., Sawyer, P., Bentley, R., & Twidale, M. (1993). Integrating ethnography
into the requirements engineering process. In Requirements Engineering, 1993., Proceedings of
IEEE International Symposium on (pp. 165-173). IEEE.
Suchman, L. (1987). Plans and Situated Action. Cambridge: Cambridge University Press.
Download