The following research presents a study of communication in requirement elicitation meetings. Achieving consensus of requirements is difficult in mostsituations, but even more so in requirement elicitation meetings. This report proposes and validates questions regarding requirement elicitation meetings between different stakeholders by modelling their subjective perspectives using the conceptual metaphor theory. Through a case study, qualitative data was collected from project managers and communicators from 5 Swedish companies. The result shows that misunderstanding is not detected until further into the process as a result of carrying different notions behind terms. The importance of shared experiences of words presents itself, and the use of metaphorisation is suggested as a useful approach to reach consensus.

Context: Security considerations are typically incorporated in the later stages of development as an afterthought. Security in software system is put under the category of non-functional requirements by the researchers. Understanding the security needs of a system requires considerable knowledge of assets, data security, integrity, confidentiality and availability of services. Counter measures against software attacks are also a security need of a software system. To incorporate security in the earliest stages, i.e. requirement gathering, helps building secure software systems from the start. For that purpose researchers have proposed different requirements elicitation techniques. These techniques are categorized into formal and informal techniques on the basis of finiteness and clarity in activities of the techniques. Objectives: Limitations of formal methods and lack of systematic approaches in informal elicitation techniques make it difficult to rely on a single technique for security requirements elicitation. Therefore we decided to utilize the strengths of formal and informal technique to mitigate their weaknesses by combining widely used formal and informal security requirements elicitation techniques. The basic idea of our research was to integrate an informal technique with a formal technique and propose a flexible framework with some level of formality in the steps. Methods: We conducted a systematic literature review to see “which are the widely used security requirement elicitation techniques?” as a pre-study for our thesis? We searched online databases i.e. ISI, IEEE Xplore, ACM, Springer, Inspec and compendeX. We also conducted a literature review for different frameworks that are used in industry, for security requirement elicitation. We conducted an experiment after proposing a security requirements elicitation Framework and compared the result from the Framework with that of CLASP and Misuse cases. Results:Two types of analysis were conducted on results from the experiment: Vulnerability analysis and Requirements analysis with respect to a security baseline. Vulnerability analysis shows that the proposed framework mitigates more vulnerabilities than CLASP and Misuse Cases. Requirements analysis with respect to the security baseline shows that the proposed framework, unlike CLASP and Misuse cases, covers all the security baseline features. Conclusions:The framework we have proposed by combining CLASP, Misuse cases and Secure TROPOS contains the strengths of three security requirements elicitation techniques. To make the proposed framework even more effective, we also included the security requirements categorization by Bogale and Ahmed [11]. The framework is flexible and contains fifteen steps to elicit security requirements. In addition it also allows iterations to improve security in a system

The stakeholders for requirements elicitation need to be identified at an early stage and their knowledge is the basis for what is to become a requirements specification. Just because a stakeholder holds a lot of expertise and knowledge it does not mean that the stakeholder can communicate the knowledge in a clear way. Validation of knowledge means that knowledge is valued and recognized in a structured way. People and organizations can evolve by exchanging knowledge, experience and skills.   The purpose of this study is to increase the understanding of knowledge management between requirement elicitation and external stakeholders. The following report is written based on requirements elicitation and stakeholders, knowledge, and validation of knowledge. This study has been carried out at one company as a case study to examine the context of the requirement elicitation, Nonakas knowledge model and validation of knowledge. The theories that support this study are about explicit and implicit knowledge, Nonakas knowledge model and validation of knowledge.   What emerged from this study is that communication and understanding are perceived to be key elements in the case study. The company that participated in this case also has a willingness to develop the internal knowledge and reduce the problems of knowledge. It has also emerged that the respondents perceive that there is a correlation between skills, qualifications and Nonaka's knowledge model. / Vid en kravinsamling ska intressenter identifieras i ett tidigt skede, det är deras kunskap ligger till grund för vad som sedan blir till en kravspecifikation för att utveckla en produkt. Bara för att en intressent innehar mycket kompetens och kunskap behöver det inte innebära att intressenten kan förmedla det på ett tydligt sätt. Validering av kunskap innebär att kunskap blir värderad och erkänd på ett strukturerat sätt. Människor och organisationer kan utvecklas genom att utbyta kunskap, erfarenheter och kompetens.   Syftet med studien är att öka förståelsen för kunskapshantering mellan kravinsamlare och externa intressenter. Följande rapport är skriven med utgångspunkt i kravinsamling, intressenter, kunskap och validering av kunskap. En kvalitativ studie har genomförts på ett fallföretag för att undersöka samband med mellan kravinsamling, Nonakas kunskapsmodell och validering av kunskap. Teorierna som stödjer denna undersökning handlar om explicit och implicit kunskap, Nonakas kunskapsmodell och validering av kunskap.   Vad som framkommit av denna studie är att kommunikation och förståelse upplevs vara centrala delar i fallföretagets arbete. Företaget har även en vilja om att utveckla den interna kunskapen och reducera kunskapsproblem. Det har även framkommit att respondenterna uppfattar att det finns samband mellan kompetens, kvalifikation och Nonaka’s kunskapsmodell.

Kunskap om olika utvecklingsmetoder vid start av ett nytt mjukvaruutvecklingsprojekt äravgörande för utvecklarna, styrorganen och slutprodukten. Därför prioriteras ofta nya ochokända metoder ned för att säkerställa att arbetet blir gjort och att lösningen kommer attlevereras i tid och med hög kvalitet. Detta beteende gör på lång sikt att mjukvaruutvecklingsprojektgår miste om nya och bättre utvecklingsmetoder.För belysa nya utvecklingsmetoder och upplysa de som behöver, valde vi att undersökaskillnaderna i krav framställning inom området Open Source Software(OSS)1-utveckling.I vårt arbete ställer tre forskningsfrågor som ska belysa ämnet dessa bevarar vi genom attutföra en fallstudie. I fallstudien undersöker vi hur och av vilka som krav framställts i ettföretagsstyrt projekt jämfört med ett projekt drivet av en frivilligorganisation.Fallstudien visade att externa användare i frivilligorganisation OSS-projekt har lägredelaktighet, det vill säga bidrag till projektartefakter, jämfört med företagsdrivna projektdär deltagandet av externa användare är högre. Slutligen diskuterar vi implikationerna avresultaten för både OSS-projekt drivna av företag och frivilligorganisationer. Vi kan förbåda styrorganen dra slutsatsen att det är möjligt att öka både utvecklingshastighet ochproduktens värde för kunden. / Knowledge about different development methods when starting up a new software developmentproject is crucial for the developers, the governing bodies and the end product.Therefore new and unfamiliar options are taken out of the equation to make sure that thework gets done and that the solution will be delivered on time and with high quality. Thisbehaviour in the long term does, however, exclude new and better ways of executing thework in the process.To shine light upon new development methods and enlighten those who are in needof insight into a new viable option we chose to investigate the differences in requirementelicitation within the area of Open Source Software development. By examining how andby who requirements are elicited in a firm-driven project compared to a community drivenproject, we framed a total of three research questions to base our case study on.The case study showed that in community driven Open Source Software projects externalusers have low participation, in other words contributions to project artefacts, comparedto firm-driven projects where the participation of external users is high. Finally, wediscuss the potential implications of the findings for both community- and firm-driven OSSprojects. We could conclude for both types that it’s possible to increase both developmentspeed and customer product value.

在傳統資訊系統開發過程中，需求分析通常被視為非常關鍵的步驟。但在Web-based的資訊系統開發中，需求分析卻很少被提及。這篇論文提要主要強調傳統資訊系統與Web資訊系統的差異，並提出一個社群導向系統的需求擷取架構。這個架構將需求擷取分成三個階段：初步分析、關鍵使用者需求分析以及一般使用者的反應。目前Web的開發技術以及社群設計的方法，通常只做初步分析，在系統開發過程中並不直接蒐集使用者的需求。本文提出的三階段架構強調關鍵使用者的重要性，並建議採用社會網路分析作為辦識關鍵使用者的工具。 關鍵使用者區分為資訊、溝通、交易以及娛樂四大類別。初步預試這四種不同類別的關鍵使用者是否會產生較多該類別的資訊需求，以及是否產生較多的需求總數。結果發現只有資訊的關鍵使用者產生較多的資訊需求以及總需求，而其他類別的關鍵使用者與產生需求數量上的關係都不顯著。而另一項有趣的發現是：20％資訊關鍵使用者可以產生大約80％的需求總數，與Pareto規則的預測相似。資訊關鍵使用者的意見是否可以代表全體的意見，預試的結果顯示80％以上的需求重要性評估，關鍵使用者與全體的意見沒有顯著差異。 實地研究採用則探究兩個線上社群，一為關係導向社群，另一則為興趣社群，用以探索使用者角色，涉入程度以及需求知覺間的關係。多變量共變數分析的結果顯示：去除涉入程度的影響後，使用者角色會顯著影響使用者對於需求的知覺，雖然影響的方式以及程度並不相同。高涉入的使用者對於需求的敏銳度，普遍比低涉入者需求要高，並不因為需求種類而有所不同，最後並討論管理的意涵以及日後的研究方向。 / Although the requirement analysis is generally considered a critical stage in traditional information systems development (ISD), but it does not get enough attention in most Web-based information systems development (WISD) or the emerging community-oriented design. The thesis highlighted the difference between ISD and WISD, and proposed a three-stage model of user requirements elicitation for community-oriented design. This model divides the requirements definition in three stages: initial analysis, key user requirements elicitation, and regular user responses. Most current WIS and community design methodologies consider only initial analysis or attempt to build common system architecture, and neglect actual users’ requirements. Key user input is emphasized in this model, and social network analysis (SNA) is proposed as a tool for identifying key users. The pilot study empirically tested the relationship between the number of key users and that of elicited requirements. The study applied SNA to identify key users (defined as their influence) in “information”, “purchase”, “communication” or “entertainment” networks, and then elicited their requirements of two WIS. The preliminary results demonstrated that the number of key users in “information” dimension was significantly correlated with the numbers of elicited “information” requirements and overall requirements. However, the number of key users in “purchase”, “communication” and “entertainment” dimension had no significant relationships with the number of the elicited requirements. The requirements collected from 20 percent of “key users” accounted for approximate 80 percent of total requirements, similar to the results predicted by Pareto’s rule. In addition, the representativeness of requirements from key users opinions was also tested. Two online communities were designed to explore the relationship between user roles, user involvement and users’ perception towards requirements. And the MANCOVA results showed that user role (with user involvement as a blocking variable) has a major impact on an individual’s perception towards requirements, though the difference varies in a certain way. User involvement has also a determining effect on a user’s perception toward each type of requirements. Managerial implications were also discussed.

Este trabalho apresenta os métodos consensuais como uma proposta para reduzir as insatisfações das pessoas envolvidas no processo de levantamento de requisitos e respeitar as dimensões humanas e sociais já no inicio do ciclo de vida de um sistema sociotécnico, considerando a aderência desses métodos às demais fases do ciclo de vida. / This text proposes the use of consensual methods to reduce people dissatisfaction in take part of requirement elicitation process and indentify, and respect, the human and social dimensions since the beginning of a sociotechnical system life cycle, evaluating the adhesion of these methods to the other phases of the lifecycle.

Este trabalho apresenta os métodos consensuais como uma proposta para reduzir as insatisfações das pessoas envolvidas no processo de levantamento de requisitos e respeitar as dimensões humanas e sociais já no inicio do ciclo de vida de um sistema sociotécnico, considerando a aderência desses métodos às demais fases do ciclo de vida. / This text proposes the use of consensual methods to reduce people dissatisfaction in take part of requirement elicitation process and indentify, and respect, the human and social dimensions since the beginning of a sociotechnical system life cycle, evaluating the adhesion of these methods to the other phases of the lifecycle.

Requirement elicitation is a critical activity in the requirement development process and it explores the requirements of stakeholders. The success or failure of this process is based on identifying the relevant stakeholders and discovering their needs as well as the quality of requirements. The quality of the requirements is greatly influenced by methods applied during requirements elicitation process. Only complete and structured requirements make these projects more reliable. The common challenges that analysts face during elicitation process are to ensure effective communication between stakeholders as well as the acquisition of tacit knowledge. Mostly errors in the systems are due to poor communication between user and analyst, and these errors require more resources (time and money) to correct them. The understandability problems during elicitation process of large web projects can lead to requirements ambiguous, inconsistent, incorrect and unusable. Different methods (Conversational, Observational, Analytical and Synthetic) are available to deal with the problems during requirement elicitation process. The challenge for analysts is to select an appropriate method or set of methods and apply them for the clear, consistent and correct requirement gathering. This study based on the results of interviews conducted to the professionals, who have industrial experience in development of web systems. The elicitation problems that are identified in literature and interview along with applicability of elicitation methods for requirement gathering in large web projects development are documented in this report. / Umar Sajjad Charhoi, Kotli, Azad Kashmir, Pakistan Muhammad Qaisar Hanif Bhimber, Azad Kashmir, Pakistan

[pt] Durante as etapas iniciais de design, o designer forma um entendimento inicial sobre o problema que ele deve resolver e desenvolve suas primeiras ideias, geralmente influenciadas por conhecimentos de design passados. Com o objetivo de auxiliar o design de IHC (interação humano-computador) neste contexto, nós investigamos como podemos usar o raciocínio baseado em casos (CBR) para ajudar designers a acessar e reutilizar conhecimentos de design para resolver novos problemas de IHC. Nós conduzimos entrevistas com designers de IHC profissionais para coletar dados sobre como eles lidam com problemas de design e suas motivações e expectativas sobre o uso de conhecimentos de design auxiliado por uma ferramenta de CBR. Usando estes dados, construímos uma ferramenta, chamada CHIDeK, que contém uma biblioteca contendo casos de design de IHC e fornece acesso aos casos através de navegação facetada, links diretos entre casos e busca. Para investigar como o CHIDeK influencia a atividade de design, conduzimos um estudo que simulava a etapa inicial de design de IHC de um sistema online de reserva de bicicletas. Alguns participantes podiam resolver o problema enquanto tinham acesso ao CHIDeK e outros deviam resolver sem o CHIDeK. Descobrimos que os casos no CHIDeK ajudaram o design motivando o processo de reflexão dos designers, ativando memórias de experiências com sistemas similares aos descritos nos casos e ajudando a gerar novas ideias. Também identificamos algumas limitações na representação dos casos, o que oferece oportunidade para novas pesquisas. Comparando ambos os tipos de atividade de design, percebemos que os designers sem a biblioteca de casos usaram a mesma solução para um dos itens descrito no cenário do estudo, enquanto os designers com os casos variaram entre duas soluções. Concluímos dizendo que uma ferramenta de CBR tem muito potencial para ajudar na atividade de design, porém existem problemas que devem ser endereçados por pesquisas futuras. / [en] During the early stages of design, the designer forms an initial understanding about the problem and some ideas on how to solve it, often influenced by previous design knowledge. In order to support HCI design in this context, we investigated ways to use case-based reasoning (CBR) to help designers access and reuse design knowledge to solve new HCI design problems. We conducted interviews with professional HCI designers to collect data about how they deal with design problems, and their motivations and expectations regarding the use of design knowledge aided by a CBR tool. Using this data, we designed and developed a tool called CHIDeK, which has a library containing HCI design cases and provides access to them through faceted navigation, direct links between cases, and search. To investigate the way CHIDeK influences the design activity, we conducted a study that simulated the early stage of HCI design of an online bike reservation system. Some participants could solve the problem while having access to CHIDeK and others had to solve it without CHIDeK. We discovered that the cases from CHIDeK supported the design by motivating the designers reflective process, triggering their memories of experiences with systems similar to the ones in cases, and helping generate new ideas. We also identified some limitations in the case representation, which offers an opportunity for further research. When comparing both kinds of design activities, we noticed that designers without the case library used the same solution for one of the issues described in the study scenario, while the designers with the cases varied between two solutions. We concluded that a CBR tool has much potential to aid the design activity, but there are still issues that need to be addressed by further research.

Requirements are features or attributes which we discover at the initial stage of building a product. Requirements describe the system functionality that satisfies customer needs. An incomplete and inconsistent requirement of the project leads to exceeding cost or devastating the project. So there should be a process for obtaining sufficient, accurate and refining requirements such a process is known as requirement elicitation. Software requirement elicitation process is regarded as one of the most important parts of software development. During this stage it is decided precisely what should be built. There are many requirements elicitation techniques however selecting the appropriate technique according to the nature of the project is important for the successful development of the project. Traditional software development and agile approaches to requirements elicitation are suitable in their own context. With agile approaches a high-level, low formal form of requirement specification is produced and the team is fully prepared to respond unavoidable changes in these requirements. On the other hand in traditional approach project could be done more satisfactory with a plan driven well documented specification. Agile processes introduced their most broadly applicable technique with user stories to express the requirements of the project. A user story is a simple and short written description of desired functionality from the perspective of user or owner. User stories play an effective role on all time constrained projects and a good way to introducing a bit of agility to the projects. Personas can be used to fill the gap of user stories.