Understanding and communicating user requirements in a software requirement analysis effort is very important. Misunderstandings of user requirements between stakeholders will cause problems in terms of satisfying their needs, reduction of defects, cost and schedule during the software development process. This dissertation presents a new technique that has the ability to represent the mental models of the user, developers, project managers and sponsors (collectively referred to as ?stakeholders?) as network representations. The requirements are modeled as nodes and the perception of stakeholders is modeled as the interrelationships (links) among the requirements. The requirements are first extracted from a requirements document. The requirements are then categorized into related groups as perceived by each stakeholder. The relatedness (proximity) data collected from the categories is then fed into the Pathfinder generation program that results in the generation of pathfinder network(PFNETs). The PFNETs of stakeholders are then compared for similarities/dissimilarities using a graph similarity metric referred to as a correlation coefficient. During preliminary research work, this technique was applied to multiple student projects with real customers at Mississippi State University (MSU), and to a project at NORTEL, Dallas, Texas with encouraging results. This research was successful in identifying duplicate, ambiguous and misunderstood requirements. The next step was to validate this technique on small-scale and medium-scale projects in an industrial setting. During the summer of 2003, the National Science Foundation (NSF) and AmerInd Inc. jointly sponsored a collaborative industry-university research effort to validate the proposed technique. It was found that this technique is easy to apply and useful to gauge an overall understanding of requirements and identify potentially misunderstood requirements for small and medium scale projects. This technique scaled well from a small-scale project with two stakeholders to a medium-scale project with a little over one hundred requirements and six stakeholders. The correlations helped focus discussions on the requirements that were potentially misunderstood among stakeholders. Duplicate, misunderstood and ambiguous requirements were identified during the facilitation sessions. We also present a new technique that applies information theory-based software metrics to measure consensus about requirements among stakeholders.

Assurance Cases have been effectively used for improving the safety of real-time safety systems. However, until now, Assurance Case techniques have not been applied to building confidence in the correctness of Scientific Computing (SC) software. Our approach is to employ Assurance Case techniques to the case of a specific medical image analysis software, 3dfim+, and then generalize the results/template for other medical and SC software. Using the Goal Structuring Notation (GSN), we develop an Assurance Case to support the top goal that "Program 3dfim+ delivers correct outputs when used for its intended use/purpose in its intended environment." This claim is supported by several sub-claims, including the claims that high-quality requirements exist and that the implementation complies with the requirements. The full argument decomposes each sub-claim further until at the bottom level evidence is provided. The evidence provided includes the requirements documentation, test cases and expert review. To simplify the Assurance Case diagram, a new generic module, parameterized over quality, was developed to argue that each quality has been achieved. Evaluation of the full Assurance Case shows that this approach is feasible for building confidence in SC software, even in the practical situation where confidence is sought, but redesign and reimplementation are not possible. The exercise uncovered issues with the original documentation for 3dfim+, including missing assumptions, and ambiguity with the chosen sign convention. Furthermore, although no errors in output were found, the Assurance Case highlights that confidence in the original 3dfim+ software could be improved through additional checks for input validity. / Thesis / Master of Science (MSc)

Software systems today face many challenges that were not even imagined decades prior. Challenges including the need to evolve at a very high rate, lifecycle phase drift or erosion, inability to prevent the butterfly effect where the slightest change causes unimaginable side effects throughout the system, lack of discipline to define metrics and use measurement to drive operations, and no "silver bullet" or single solution to solve all the problems of every domain, just to name a few. This is not to say that the issues stated above are the only problems. In fact, it would be impossible to list all possible problems--software itself is infinitely flexible bounded only by the human imagination. These are just a portion of the primary challenges today's software engineer faces. There have been attempts throughout the history of software to resolve each one of these challenges. There have been those who tried to tackle them individually, simultaneously, as well as various combinations of them at one time. One such method was to define and encapsulate the various phases within software, which has come to be called a software lifecycle or lifecycle model. Another area of recent research has lead to the hypothesis that many of these challenges can be resolved or at least facilitated through proper traceability methods. Virtually none of today's software components are completely derived from scratch. Rather, code reuse and software evolution become a large portion of the software engineer's duties. As Vance Hilderman at HighRely puts it, "Research has shown that proper traceability is vital. For high quality and safety-critical engineering development efforts however, traceability is a cornerstone not just for achieving success, but to proving it as well." So if software is not derived from scratch, having the traceability to know about its origination is invaluable. Given today's struggles, what is in store for the future software engineer? This paper is an attempt to quantify and answer (or at least project a possibility) that involves a new mindset and a new lifecycle model or structure change that may assist in tackling some of the above referenced issues. / text

Orientadora: Prof.ª Dr.ª Fabiana Soares Santana / Dissertação (mestrado) - Universidade Federal do ABC, Programa de Pós-Graduação em Ciência da Computação, 2014. / As empresas produtoras de software precisam de métodos eficientes para obter resultados competitivos. Uma das principais causas dos resultados negativos em projetos de software se deve às deficiências na engenharia de requisitos de software. A especificação de requisitos inadequada ou incompleta pode levar à construção de sistemas que não estão em conformidade com as necessidades dos clientes, resultando no aumento de custos, atrasos nos cronogramas e realização de atividades desnecessárias. A fim de minimizar os problemas na especificação de requisitos, as boas práticas de engenharia de software recomendam o entendimento adequado do ambiente de tecnologia da informação (TI) e das regras de negócio. O uso de processos de negócio tem sido adotado pela maioria das organizações para mapear as suas necessidades e alinhar o conhecimento entre as equipes de negócio e de TI. BPMN (Business Process Modeling Notation, no original em inglês, ou Notação para Modelagem de Processos de Negócios) é a notação mais comumente adotada pelo mercado para a modelagem de processos de negócio, com diversas ferramentas disponíveis para o mapeamento e simulação de processos. Além da preocupação com os processos de negócio, as organizações têm adotado arquiteturas orientadas a serviços (SOA, Service Oriented Architectures, no original em inglês) com o intuito de facilitar a integração entre processos e tecnologia, resultando em soluções mais flexíveis para atender às constantes necessidades de mudanças e oportunidades de negócio. A união de BPMN e SOA permite o melhor entendimento dos sistemas através do mapeamento e modelagem dos processos de negócio, a partir dos quais é possível identificar os serviços que devem ser encapsulados dentro de um determinado ambiente tecnológico. O resultado é o aumento na produtividade, a melhoria na qualidade dos sistemas (QoS, Quality of Software, no original em inglês) e a redução de custos. Este trabalho propõe um método para modelagem de processos na engenharia de requisitos, incorporando formalmente o uso de processos de negócios na especificação dos requisitos de software. Um estudo de caso foi desenvolvido para experimentar o método proposto e mostrar a sua aplicação. Embora experimentos adicionais sejam recomendados, os resultados do estudo de caso foram promissores e mostram que a análise minuciosa dos processos de negócios na etapa de especificação de requisitos auxilia no entendimento e na identificação mais precisa dos requisitos do sistema, melhorando o potencial de sucesso na produção de software. / Producing software companies need effective methods to achieve competitive results. A major cause of adverse outcomes in software projects is due to deficiencies in the software requirements engineering. The specification of inadequate or incomplete requirements can lead to the construction of systems that are not in accordance with customer needs, resulting in increased costs, schedule delays, and development of unnecessary activities. In order to minimize the problems in the requirements specification, best practices in software engineering recommend a proper understanding of the information technology (IT) environment and of the business rules. The use of business processes has been adopted by many organizations to map their needs and to align the knowledge among business teams and IT. BPMN (Business Process Modeling Notation) is the notation most commonly adopted by the software companies for business processes modeling. Various software tools are available for processes mapping and simulation. In addition to the concern with business processes, many organizations are adopting service-oriented architectures (SOA) in order to facilitate the integration between processes and technology, resulting in more flexible solutions to meet the ever changing IT needs and the new business opportunities. The union of BPMN and SOA allows a better understanding of the systems to be developed by mapping and modeling business processes, from which it is possible to identify the services that should be encapsulated within a particular technological environment. Results include increased productivity, improved quality of software (QoS) and cost reduction. This work proposes a method for including the processes modeling as part of the requirements engineering, formally incorporating the use of business processes in the software requirements specification. A case study was developed to experiment the proposed method and to illustrate its application. Although further experiments are recommended, the results of the case study are promising and show that a thorough analysis of the business processes as part of the requirements specification phase helps in understanding and obtaining a more accurate identification of the system requirements, improving the potential for successful software production.

In software engineering the requirements validation has very core importance. The requirements validation very helpful to judge that software requirements specification (SRS) is complete and free of bugs. The requirements validation is a assurance that the software requirements document is free of unwanted requirements and completely consistent. In order to remove inconsistency, detect defects and make the software requirements document fully functional the requirements validation is key factor. All possible requirements validation techniques available in academia such requirements reviews , requirements prototyping, requirements testing and viewpoint-oriented requirements validation are explained properly in this thesis report. In a very readable and understandable way the thesis presents all pros and cons of these requirements validation techniques practiced in different software companies in Sweden and available in academia. This report explains all possible advantages and issues related with these RVTs. In order to judge the best performance of these RVTs and to make their comparison I used a proper channel. I have designed a very effective survey questionnaire with the help of my colleges and literature review. To make creative comparison I conduct interviews and send survey questionnaire to different people working in requirements engineering departments in different software industries in Sweden. Finally the satisfaction levels of different software industries with these requirements validation techniques presents in this thesis report. These variables such as defect detection, time and cost are used to measure the satisfaction levels. / I Software Engineering kraven validering har en mycket central betydelse. Den kravvalidering very helpful att bedöma att Kravspecifikation (SRS) är klar och felfria. Kraven validering är en garanti för att programvaran kravdokument är fri från oönskade krav och helt konsekvent. För att undanröja inkonsekvens, upptäcka brister och göra programvaran kravdokument fullt funktionella kraven validering är viktig faktor. Alla möjliga kravvalidering tekniker inom den akademiska sådana krav recensioner, krav prototyper, provning och synpunkt-orienterade kravvalidering förklaras ordentligt i denna avhandling rapport. I ett mycket lättläst och begripligt sätt avhandling presenterar alla fördelar och nackdelar med dessa krav validera metoder praktiseras i olika mjukvaruföretag i Sverige och finns i den akademiska världen. Denna rapport förklarar alla möjliga fördelar och frågor kring dessa RVTs. För att bedöma de bästa resultaten i dessa RVTs och göra en jämförelse av dem använde jag en riktig kanal. Jag har skapat en mycket effektiv frågeformulär med hjälp av min högskolor och litteraturgenomgång. Skapa kreativa jämförelse jag intervjua och skicka frågeformuläret till olika personer som arbetar inom tekniska kraven för dessa avdelningar i olika programvaruföretag i Sverige. Slutligen tillfredsställande nivåer av olika programvaruföretag med dessa krav validering teknik presenteras i denna avhandling rapport. Dessa variabler såsom Upptäcka, tid och kostnader används för att mäta tillfredsställande nivåer. / Author: Latif Hussain Sulehri E-mail: latifsulehry@hotmail.com Phone: +46 704 917 140

This diploma thesis deals with the requirements engineering as one of the key areas of development of software applications. By requirements prospective users express their needs and goals which shall be achieved using the developed application. The correctness and completeness of the requirements is thus critical for the success of any software project. The main objective of this dissertation is determination of steps which must be made to improve quality of requirements on real software project in Czech financial institution. This is achieved by analysis of current requirements development process as well as by analysis of the sample of specific requirements. One part of the carried out analysis focuses also on the revision of actual settings of Atlassian JIRA application which is used for requirements management. Based on the analysis some crucial shortcomings are identified and steps for their elimination are introduced. This includes, inter alia, manual of how to specify correct requirements and checklists for different actors who work with requirements. The theoretical part gives a comprehensive overview of selected techniques and practices which are applicable for requirements gathering and analysis. Every mentioned technique is then evaluated from the perspective of its usability in the environment of large Czech bank. This overview can be useful both for junior analytics as a collection of best practices and for senior analytics as an overview of possible areas for their professional development.

A key factor in creating software of good quality is that the requirements for the project being developed are as unambiguous and clear as possible, so the developers will be able to develop the product quickly and effectively. So, there is a need for tools that help requirements engineers create quality requirements. The attributes that define a poorly written requirement are called bad smells. In this thesis we investigate the NALABS tools bad smell detecting capabilities when analyzing industrial requirements. First, we performed a literature study to investigate what types of bad smells exist for requirements and how they were specified. After that we used a case study to examine how many smells and of what categories the NALABS tool detects, when it analyzes industrial requirements. Lastly, we used a small experiment to examine how accurately NALABS detects smells, by designing a simple console application that counted instances of bad smell words in a set of keywords that were from the NALABS tool. The results we gathered gave us an indication that NALABS detects bad smells in all the categories of bad smells that are implemented in it, to a varying degree. Through this thesis we hope to extend the knowledge about bad requirements smells, clarify what attributes of a requirement might be a bad smell, and investigate to what degree the NALABS tool can detect bad smells in industrial requirements.

Since their creation, CubeSats have become a valuable educational tool for university science and engineering programs. Unfortunately, while aerospace companies invest resources to develop verification and validation methodologies based on larger-scale aerospace projects, university programs tend to focus resources on spacecraft development. This paper looks at two different types of methodologies in an attempt to improve CubeSat reliability: generating software requirements and utilizing system and software architecture modeling. Both the Consortium Requirements Engineering (CoRE) method for software requirements and the Monterey Phoenix modeling language for architecture modeling were tested for usability in the context of PolySat, Cal Poly's CubeSat research program. In the end, neither CoRE nor Monterey Phoenix provided the desired results for improving PolySat's current development procedures. While a modified version of CoRE discussed in this paper does allow for basic software requirements to be generated, the resulting specification does not provide any more granularity than PolySat's current institutional knowledge. Furthermore, while Monterey Phoenix is a good tool to introduce students to model-based systems engineering (MBSE) concepts, the resulting graphs generated for a PolySat specific project were high-level and did not find any issues previously discovered through trial and error methodologies. While neither method works for PolySat, the aforementioned results do provide benefits for university programs looking to begin developing CubeSats.

Several studies have applied recommender technologies to support requirements engineering activities. As in other application areas of recommender systems (RS), many studies have focused on the algorithms’ prediction accuracy, while there have been limited discussions around users’ interactions with the systems. Since recommender systems are designed to aid users in information retrieval, they should be assessed not just as recommendation algorithms but also from the users’ perspective. In contrast to accuracy measures, user-related issues can only be effectively investigated via empirical studies involving real users. Furthermore, researchers are becoming increasingly aware that the effectiveness of the systems goes beyond recommendation accuracy, as many factors can be relevant to their adoption besides accuracy. To better understand recommender systems in RE, it has become necessary to explore them from users’ perspectives. Consequently, this research evaluates a feature recommender system from users’ perspectives adopting the “Recommender systems’ Quality of user experience” (ResQue) model - a user-centered evaluation model from the RS field. This was done by designing a content-based feature recommender system and then assessing it from the users’ view point. A between-subjects user study was conducted involving two groups of participants, an experimental and a control group. The experimental group interacted with the feature recommender system while developing a list of software requirements for a software product (an antivirus software). In contrast, the control group performed the same task without receiving support from the recommender. After completing the task, both groups completed a post-task evaluation questionnaire, including questions about their experiences and opinions about the task they completed. In addition, participants in the experimental group rated their perceptions of various aspects of the recommender; question items were adapted from the ResQue questionnaire. Users’ subjective evaluation of the recommender was investigated using the ResQue constructs - perceived system qualities, user beliefs, user attitudes, and behavioral intentions. Additionally, the impact of recommendations on the requirements elicitation process was assessed in terms of the process and outcome level measures. Possible qualitative differences were also examined. Users' preferences were identified, and possible HCI issues requiring attention in recommender systems used in RE are discussed.

O trabalho dos usuários em sistemas de informação é uma atividade social que envolve grupos de pessoas que cooperam entre si para desempenhar as mais variadas funções. A natureza da cooperação, por si só é complexa e depende dos indivíduos envolvidos, do ambiente físico e da organização onde o trabalho se desenvolve. Os aspectos ligados ao trabalho cooperativo dos usuários não são considerados no enfoque tradicional da engenharia de software, uma vez que o usuário é visto de modo independente do meio ou grupo em que está inserido, com o modelo individual generalizado para o estudo do comportamento coletivo envolvendo todos os usuários. O objetivo deste trabalho é propor um processo de requisitos de software para tratar as questões envolvendo o trabalho cooperativo em sistemas de informação que apresentem coordenação distribuída nas ações dos usuários e a comunicação entre eles ocorre, preponderantemente, de modo indireto por meio dos dados inseridos no uso do software. Para tanto, a pesquisa faz uso de conceitos da ergonomia, da cognição e da engenharia de software. Utiliza-se a pesquisa-ação como metodologia de pesquisa em três ciclos, aplicada durante o desenvolvimento de um sistema de workflow corporativo em uma empresa de pesquisa tecnológica. No primeiro ciclo, o processo trata da definição dos requisitos do domínio do problema e das contribuições individuais dos usuários. No segundo ciclo, as contribuições do grupo (suas ações e inter-relações) são consideradas com as contribuições individuais pela simulação da solução proposta. No terceiro ciclo, o processo trata do refinamento dos requisitos do trabalho cooperativo, com o software em uso real no ambiente de trabalho. Os resultados obtidos no final do ciclo 2 e início do ciclo 3 durante a aplicação do processo em campo, mostraram a necessidade de melhoria do processo. Esta evolução é necessária, visto que a inclusão do sistema informatizado altera o ambiente de trabalho dos usuários, passando da interação face a face para a interação mediada pelo software. Os resultados obtidos evidenciaram que o maior grau de consciência dos usuários sobre como os inter-relacionamentos de suas atividades são realizados contribuem para um decréscimo em seus erros individuais, diminuindo o retrabalho de recodificação do software e acima de tudo o uso inadequado do sistema, evitando a propagação das consequências desses erros nos resultados finais do trabalho em grupo. / Users\' work in information systems is a social activity that involves people groups cooperating to perform many different functions. The nature of cooperation itself is complex and depends on the people involved, on the workplace environment and on the organization in which the work develops. Aspects related to the users\' cooperative work are not considered in the traditional approach of software engineering, since the user is viewed independently of his/her workplace environment or group, with the individual model generalized to the study of collective behavior of all users. This work proposes a process for software requirements to address issues involving cooperative work in information systems that provide distributed coordination in the users\' actions and the communication among them occurs indirectly through the data entered while using the software. To achieve this goal, this research uses ergonomics, cognition and software engineering concepts. Research-action is used as a research methodology applied in three cycles during the development of a corporate workflow system in a technological research company. In the first cycle, the proposed process exposes the definition of the problem domain requirements and the users\' individual contributions. In the second cycle, the contributions of the group (their actions and inter-relationships) are considered together with the individual contributions through the simulation of the proposed solution. In the third cycle, the process deals with the refinement of the cooperative work requirements with the software in actual use in the workplace. The results at the end of cycle 2 and the beginning of cycle 3 during the process application in the field show the need for process improvement. This is necessary because the inclusion of a computer system changes the users workplace, from the face to face interaction to the interaction mediated by the software. The results show that the highest degree of users\' awareness as the interrelationship of their activities are carried out contributes to a decrease in their individual errors, reducing software recoding rework and above all the inappropriate use of the system, avoiding the spread of the consequences of these errors in the final results of the group work.