My interest is in applying a domain model to help elicit personal requirements for the problem of community travel for people with cognitive impairments. The domain model I took advantage of is the ACT model, which is embedded in the tool I designed for defining required prompts for travel. I set up a study to look at the use of the domain model to help travel-planners generate personalized prompts for a traveler. My goal is to better understand the mechanisms of running a human-performance study and to get a first look at how the domain model can be understood by travel-planners. The study shows that most participants prefer the ACT-based tool to free-thinking and writing down prompts. I found out that the tool helps participants define more organized and concise prompts, but not necessarily a higher number of prompts, compared to the free-think approach. The tool captures prompts for some steps that are neglected while free-thinking. However, some steps of the ACT model need to be disambiguated or presented more effectively in the tool.

The purpose of this thesis is to provide the Maftaki team at Tieto a proposal of a tool or improve one of the current tools that will support their processes. In order to find a suitable tool a problem analysis model, as described by Goldkuhl and Rostlinger (1988), was used. To find out what kind of problem existed, members from the Maftaki team were interviewed. Out of the problems that were brought up during the interviews, difficulties with finding telephone numbers that can be used in the testing environment at testing was chosen. In order to solve the problem, a tool that handles test data was to be developed. Firstly, a requirement elicitation was performed by interviewing potential users of the system. In this way, use cases and functional requirements were elicited. A framework called Struts2, an Object-relational Mapping framework, Hibernate and an Inversion of Control container, Spring was used during the development. Maven was used for building the application. During the development demos were performed in order to elicit more requirements from the users and to clarify some requirements. Also refactoring was done continuously during the development. When the development of the application was done a couple of test cases were written and some basic testing of the application were performed . / Syftet med examensarbetet är att ge Maftaki teamet vid Tieto ett förslag på ett verktyg eller förbättra ett av de nuvarande verktygen för att ge support till deras processer. För att hitta ett lämpligt verktyg gjordes först en problemanalys, den problemanalysmodell som beskrivs i Goldkuhl och Röstlinger, (1988), bok användes. För att ta reda på vilka problem som kunde finnas genomförde ett antal intervjuer med medlemmar i Maftaki. Ur de problem som hade kommit fram under intervjuerna valdes svårigheten att hitta telefonnummer som kan användas i testmiljön vid testning ut. För att lösa problemet beslutades att ett verktyg som hanterar testdata skulle utvecklas. Först genomfördes en kravfångst genom att intervjua potentiella användare och på så sätt togs användningsfall och funktionella krav fram. För att bygga applikationen användes ett ramverk som heter Struts2, ett Object/Relational Mapping ramverk, Hibernate, och en Inversion of Control container, Spring. För att bygga applikationen användes Maven. Under utvecklingens gång genomfördes demos för att få fler krav ifrån användare och för att få en klarare bild av betydelsen av vissa krav. Också omstrukturering av kod genomfördes kontinuerligt under utvecklingens gång. Sist av allt genomfördes ett antal test på applikationen.

Aspect-Oriented Requirement Engineering (AORE) is an emerging software engineering paradigm with increasing attention from academic as well as industrial communities. AORE aims at the systematic identification, modularization, composition and analysis of crosscutting concerns that manifest in requirements. It is believed that systematically managing crosscutting concerns early on at the requirement engineering stage can provide valuable insight at the architecture design and implementation stages and can help identify and thus manage crosscutting concerns at these stages. Moreover, identifying crosscutting concerns in requirements can help to reveal the scope of each concern in a software system, to detect potential conflicts between concerns and to facilitate trade-off negotiation early on. Hundreds of papers regarding AORE have been published in AORE communities. However, few of them address crosscutting concerns in real world requirements. Whether the proposed AORE approaches are productive when applied to real world requirements is unknown. In this thesis, we conduct an AORE case study consisting of an experiment using a real world software requirement specification in order to examine how crosscutting concerns present in real world requirement documents, explore the difference between crosscutting concerns in requirements and crosscutting concerns in code, and reason whether identifying and thus managing crosscutting concerns from real world requirements is a productive practice. / Thesis (Master, Computing) -- Queen's University, 2009-09-21 15:09:27.262

In the automotive industry, the complexity of electronic components is increasing rapidly. Modern functional safety standards rely on strict requirements engineering techniques in order to ensure the safety of a given system. Current requirements management tools on the market either suffer in their ability to handle such constraints or are not susceptible to industrial applicability. To solve this problem, two main questions have been focused in this master thesis. How to visualise the requirements and their relationship to architecture and how to provide a solution that reflects on how work is conducted today at Scania. A prototype with focus on visualisation of requirements and their relationship to architectures has been developed. To provide an intuitive solution that reflects on how work is conducted, an evaluation of the prototype has been conducted. The prototype was evaluated by engineers at Scania that works with requirements in their daily work. The conclusion of the evaluation suggests that visualisation of requirements and their relation to architecture could be beneficial for requirement engineering. To keep the solution intuitive it is important to focus on filtering methods for the visualisation in future development.

Context: Requirement Engineering (RE) is one of the important phases inthe development of any software. Hence, there is a need to take much careon the elicitation and management of these requirements. Attributes playan important role in order to store and manage the important informationabout the requirements. There has been a lot of research performed inthe literature regarding the attributes of requirements engineering, but stillthere is a gap in the research that is concerned to requirement attributesin particular. Hence we focused more on identification and management ofthese requirement attributes. Objectives: In the current thesis, we focused mainly on the requirementattributes used in the companies and how they are managed. The majorobjectives we have framed in order to achieve our aim are: 1. To identify the publication trends in the literature of requirementsengineering that mainly focus on requirement attributes. 2. To identify the requirement attributes that are used by the softwarecompanies which includes both global attributes and project specificattributes. 3. To investigate how the requirement engineering models impact theselection of requirement attributes in companies. 4. To identify the phase and sequence of the requirement attributesbased on the four phases (elicitation, analysis, documentation and validation)of requirements engineering. 5. To investigate how the requirement attributes help in documentingand managing the continuous changes to requirements. Methods: In this thesis, we have performed Systematic Mapping Study(SMS),Systematic Literature Review (SLR) and Survey methods in order to achieveour aim and objectives. SLR is performed through the snowballing procedurebased on the guidelines of Wohlin[1].SMS is performed based on theguidelines of petersen et al.[2]. The main aim of the SMS is to identifythe publication trends in the literature on requirements engineering. Themain aim of SLR is to extract important information about the RE modelsand changes in requirements engineering. The main aim of the Survey is tovalidate the information retrieved from the SLR. Results: 83 requirement attributes were identified through the SLR outof which 15 attributes are in common. These 15 attributes are includedin the survey questionnaire. From these attributes, ID and description areidentified as most commonly used attributes from the survey. Publication trends related to requirement attributes are observed from the past 25 yearsrequirement attributes. From the survey, it is observed that there is a highimpact of RE models on requirement attributes. It is also observed thatmaximum number of attributes is stored in the form of documents and indatabases by the companies and the attributes are generally documented inanalysis phase and in specification phase. Results from the survey indicatedthat there is no particular sequence to document the attributes and theyare identified and documented based on the needs. Conclusions: This thesis lists different attributes that are used by thecompanies and also gives important information about the requirement attributesin detail that is close to the practical scenarios. It also gives scopefor further researches related to requirement attributes. This thesis helpthe practitioners to know the importance of consideration of requirementattributes in developing a project and its advantages. This work can beextended further by considering large number of attributes and retrievingresponses and opinions by large population.

Background: Technical debt(TD) is incurred when developers accept compromises in a system in one dimension to meet urgent demand in some other dimensions (e.g., a deadline). If technical debt is not managed correctly, it will cause hidden danger to software’s long term success. It does not get enough attention when TD applies to the requirements engineering. Objectives: In this study, we investigate the current state of requirements debt(ReD). We aim to give a precise definition of ReD. We also focus on the factors that can induce ReD in the requirement engineering and requirement management process. Moreover, we want to summarize the measurement tools to detect and locate the ReD. Finally, we try to find approaches and ideas to manage ReD. Methods: We conducted a systematic mapping study (SMS) and a survey for all of the objectives. When performing the systematic mapping study, we applied snow- balling method to ensure we find related and enough papers. Results: According to the analysis and results of SMS and the survey, we concluded the definition of requirements debt. We also presented and classified 54 ReD induced factors into 8 categories. 10 ReD measurement techniques searched from literatures were listed with a brief description for each one, suggestions from software practi- tioners on ReD detection also gathered and displayed. The management techniques and theoretical suggestions were presented based on related factors. Conclusions: From research result, we find academia and industry lay different emphasises on how to manage ReD. To stimulate Industry pay more attention on control and manage ReD effectively, this paper calls for the two sides to work on the same point.

Requirements engineering in a system-engineering project is a key factor in the success of a project. In the current state, stand-alone research has been conducted tackling this area, however, few studies addressed the requirements based on a probabilistic approach. In this thesis, a multi-scale probabilistic approach has been developed, named Bayesian Network, to evaluate the requirements engineering of a complex systems In order to pursue the aim of this paper, the FFG(X) navy ship is chosen to serve as a case study and to validate the proposed model. Results indicate the sub-requirements that highly affect the FFG capability/performance. These sub-requirements are: 1) guns, 2) ballistic missiles, 3) antisubmarine, and 4) radar.

Today, globally distributed software development is an unstoppable trend in Information Technology (IT) all over the world due to the benefits it provides such as cost benefits, time saving, accessing the large labor pool and available resources. However, globally distributed software companies face some issues in this regard. Cultural differences are introduced and discussed as one of the fundamental issues in globally distributed IT companies. Further, it is evident from the literature that business analysis process is the fundamental phase of software development process that affects the entire process of software development, and requires effective communication and collaboration among teams and between team members. Globally distributed software development makes the business analysis process and its related sub-phases even much more complicated than it is. Therefore, in this study, the influence of cultural differences on globally distributed business analysis process is analyzed. In order to do that, I conduct a qualitative study in which employees of the Turkey and Poland branches of the GTECH IT Company are interviewed. Hence, in this study remote project team member are asked about varying cultural differences that I extract from several existing cultural models and unify them into an integrated model. There are many studies exist about cultural differences in literature and these studies has similarity and differences which are creating complexity for readers and researchers. Hence, in this research Hofstede’s, Hall’s and Trompenaars’ cultural frameworks are unified and then I develop a new cultural model. By applying this new framework or model I investigated the influence of varying cultural differences on business analysis process that is conducted in a globally distributed IT company.

Recentemente, por conta do dinamismo existente no ambiente de negócio no qual as organizações devem adequar-se mais rapidamente às mudanças, os Sistemas de Informação (SIs) precisam também adequar-se para continuar agregando valor. Diante desse cenário e do uso de serviços eletrônicos distribuídos na rede para o desenvolvimento de sistemas, faz-se necessário o surgimento de novas abordagens em engenharia de sistemas. Sendo assim, surge a disciplina de Engenharia de Requisitos Orientada a Serviços (EROS) que trata da definição de processos e metodologias para captar os requisitos de serviços tanto do ponto de vista de consumidores de serviço quanto de fornecedores de serviço. No contexto de EROS, este trabalho explora alternativas às descrições sugeridas para os metamodelos RGPS (do inglês: Role, Goal, Process and Service) uma abordagem em EROS propondo uma nova definição que visa, principalmente, incorporar à RGPS as vantagens de outros modelos já estabelecidos na literatura. Sendo assim, a nova abordagem aqui proposta, chamada de WS&i*-RGPS, para a descrição das camadas Papel e Meta, propõe o uso do framework i*. E, para a descrição das camadas Processo e Serviço, a nova abordagem propõe o uso de WS-BPEL/WSDL. Esse trabalho apresenta também uma comparação sistemática entre a abordagem WS&i*-RGPS e outras abordagens semelhantes identificadas na literatura EROS. A comparação sistemática entre as abordagens em EROS, incluindo a nova abordagem aqui proposta, considera três parâmetros comparativos e identifica que a abordagem WS&i*-RGPS cobre mais parâmetros que as abordagens em EROS que se baseiam nos metamodelos RGPS, indicando que WS&i*-RGPS é uma alternativa melhor às soluções inicialmente propostas pelos autores dos metamodelos RGPS. / Due to the recent business environment dynamism in which organizations must quickly adapt to the changes, Information Systems also need to adapt to these changes in order to keep adding value. Taking into account this scenario and the use of electronic services distributed on the network to develop systems, the advent of new approaches in Systems Engineering is necessary. Therefore, a new discipline, Service-Oriented Requirements Engineering (SORE), was proposed, which deals with the definition of processes and methodologies in order to capture services requirements beneath two different perspectives: service consumers and service providers. In SORE context, this work aims at exploring some alternatives for those descriptions proposed by the Role, Goal, Process and Service (RGPS) meta-models, proposing a new approach called WS&i*-RGPS in order to incorporate to RGPS the advantages of other models well established in the literature. Accordingly, in order to describe the Role and Goal layers, this new approach proposes the use of the i* framework. Additionally, in order to describe the Process and Service layers, this new approach proposes the use of WS-BPEL/WSDL languages. This work also presents a systematic comparison among SORE approaches, including WS&i*-RGPS. This comparison considers three comparative parameters and identifies that WS&i*-RGPS covers more parameters than other approaches in SORE that uses RGPS metamodels. These results indicates WS&i*-RGPS as a better alternative comparing it to other RGPS approaches.

Recentemente, por conta do dinamismo existente no ambiente de negócio no qual as organizações devem adequar-se mais rapidamente às mudanças, os Sistemas de Informação (SIs) precisam também adequar-se para continuar agregando valor. Diante desse cenário e do uso de serviços eletrônicos distribuídos na rede para o desenvolvimento de sistemas, faz-se necessário o surgimento de novas abordagens em engenharia de sistemas. Sendo assim, surge a disciplina de Engenharia de Requisitos Orientada a Serviços (EROS) que trata da definição de processos e metodologias para captar os requisitos de serviços tanto do ponto de vista de consumidores de serviço quanto de fornecedores de serviço. No contexto de EROS, este trabalho explora alternativas às descrições sugeridas para os metamodelos RGPS (do inglês: Role, Goal, Process and Service) uma abordagem em EROS propondo uma nova definição que visa, principalmente, incorporar à RGPS as vantagens de outros modelos já estabelecidos na literatura. Sendo assim, a nova abordagem aqui proposta, chamada de WS&i*-RGPS, para a descrição das camadas Papel e Meta, propõe o uso do framework i*. E, para a descrição das camadas Processo e Serviço, a nova abordagem propõe o uso de WS-BPEL/WSDL. Esse trabalho apresenta também uma comparação sistemática entre a abordagem WS&i*-RGPS e outras abordagens semelhantes identificadas na literatura EROS. A comparação sistemática entre as abordagens em EROS, incluindo a nova abordagem aqui proposta, considera três parâmetros comparativos e identifica que a abordagem WS&i*-RGPS cobre mais parâmetros que as abordagens em EROS que se baseiam nos metamodelos RGPS, indicando que WS&i*-RGPS é uma alternativa melhor às soluções inicialmente propostas pelos autores dos metamodelos RGPS. / Due to the recent business environment dynamism in which organizations must quickly adapt to the changes, Information Systems also need to adapt to these changes in order to keep adding value. Taking into account this scenario and the use of electronic services distributed on the network to develop systems, the advent of new approaches in Systems Engineering is necessary. Therefore, a new discipline, Service-Oriented Requirements Engineering (SORE), was proposed, which deals with the definition of processes and methodologies in order to capture services requirements beneath two different perspectives: service consumers and service providers. In SORE context, this work aims at exploring some alternatives for those descriptions proposed by the Role, Goal, Process and Service (RGPS) meta-models, proposing a new approach called WS&i*-RGPS in order to incorporate to RGPS the advantages of other models well established in the literature. Accordingly, in order to describe the Role and Goal layers, this new approach proposes the use of the i* framework. Additionally, in order to describe the Process and Service layers, this new approach proposes the use of WS-BPEL/WSDL languages. This work also presents a systematic comparison among SORE approaches, including WS&i*-RGPS. This comparison considers three comparative parameters and identifies that WS&i*-RGPS covers more parameters than other approaches in SORE that uses RGPS metamodels. These results indicates WS&i*-RGPS as a better alternative comparing it to other RGPS approaches.