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.