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

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.

Patients treated at intensive care units (ICUs) are failing in one or several organs and requireappropriate monitoring and treatment in order to maintain a meaningful life. Today clinicians inintensive care units (ICUs) manage a large amount of data generated from monitoring devices.The monitoring parameters can either be noted down manually on a monitoring sheet or, for some parameters, transferred automatically to storage. In both cases the information is stored withthe aim to support clinicians throughout the intensive care and be easily accessible. Patient datamanagement systems (PDMSs) facilitate ICUs to retrieve and integrate data. Before managinga new configuration of patient data system, it is required that the ICU makes careful analysis ofwhat data desired to be registered. This pilot study provides knowledge of how the monitoringis performed in an Intensive Care Unit in an emergency hospital in Stockholm.The aim of this thesis project was to collect data about what the clinicians require and whatequipment they use today for monitoring. Requirement elicitation is a technique to collectrequirements. Methods used to collect data were active observations and qualitative interviews.Patterns have been found about what the assistant nurses, nurses and physicians’ require of systems supporting the clinician’s with monitoring parameters. Assistant nurses would like tobe released from tasks of taking notes manually. They also question the need for atomized datacollection since they are present observing the patient bed-side. Nurses describe a demanding burden of care and no more activities increasing that burden of care is required. Physicians require support in order to see how an intervention leads to a certain result for individual patients.The results also show that there is information about decision support but no easy way to applythem, better than the ones used today. Clinicians state that there is a need to be able to evaluatethe clinical work with the help of monitoring parameters. The results provide knowledge about which areas the clinicians needs are not supported enough by the exciting tools.To conclude results show that depending on what profession and experience the clinicians have the demands on monitoring support di↵ers. Monitoring at the ICU is performed while observing individual patients, parameters from medical devices, results from medical tests and physical examinations. Information from all these sources is considered by the clinicians and is desired to be supported accordingly before clinicians commit to action resulting in certain treatment,diagnosis and/or care. / Patienter som vårdas på intensivvårdsavdelningar har svikt i ett eller flera organ. Övervakning sker av patienterna för att kunna bidra till den vård som behövs för att upprätthålla ett meningsfullt liv. Idag hanterar sjukvårdpersonal en stor mängd data som genereras från övervakningsutrustning och system förknippade med övervakningsutrustning. Övervakningsparameterar kan antecknas förhand på ett övervakningspapper eller direkt sparas i digitalt format. Parameterarna sparas med syfte att vara ett lättillgängligt underlag under hela intensivvårdsprocessen. Patient data management systems (PDMSs) förenklar hämtning och integrering av data på exempelvis intensivvårdsavdelningar. Innan en ny konfiguration av ett patientdatasystem erhålls, är det eftersträvnadsvärt att intensivvårdsavdelningen analyserar vilken datasom skall hanteras. Detta examensarbete bidrog till kunskap om hur övervakning utförs på en intensivvårdsavdelning, på ett akutsjukhus i Stockholm. Målet med detta examensarbete var att insamla data om vad klinikerna behöver och vilken utrustning och system som de använder idag för att utföra övervakning. Behovsframkallning är en teknik som kan användas för att insamla krav. I detta projekt insamlades data genom aktivaobservationer och kvalitativa intervjuer. Mönster har hittats bland undersköterskornas, sjuksköterskornas och läkarnas behov av teknisksupport från system och utrustning som stödjer sjukvårdspersonalen under övervakningen av en patient. Undersköterskor uttrycker ett behov av att bli avlastade från uppgifter så som att manuellt skrivaner vitala parametervärden. De ifrågasätter behovet av automatiserad datahämtning eftersom de ständigt är närvarande bredvid patienten. Sjuksköterskor beskriver en hög vårdtyngd och önskaratt inte bli tillägnade fler aktiviteter som ökar den vårdtyngden. Läkare beskriver ett behov av ökat stöd för hur en interversion leder till resultat för individuella patienter. Resultaten visar attdet finns information om möjliga kliniska beslutsstöd utan givet sätt att applicera dessa, bättre än de sätt som används idag. Sjukvårdspersonalen hävdar att det det finns ett behov av att utvärdera det kliniska arbetet med hjälp av övervakningsparametrar. Resultaten utgör kunskap om vilka områden som sjukvårdpersonalens behov inte har stöd av nuvarnade verktyg. Resultaten visar att beroende på vilken profession och erfarenhet som sjukvårdspersonalen har, är behoven olika. På intensivvårdsavdelningen sker övervakning då enskilda patienter visuellt observeras såväl som övervakningsparametrar från medicintekniska produkter, resultat från medicinska tester och fysiska examinationer. Det finns behov att integrera och presenterainformation från dessa källor givet kunskap om att sjukvårdpersonalen fattar beslut på dessa som resulterar i behandling, diagnostik och/eller vård.