Search

Requirements specifcation is a core activity in the requirements engineering phase of a software development project. Researchers have contributed extensively to the feld of requirements specifcation, but the extent to which their proposals have been adopted in practice remains unclear. We gathered evidence about the state of practice in requirements specifcation by focussing on the artefacts used in this activity, the application of templates or guidelines, how requirements are structured in the specifcation document, what tools practitioners use to specify requirements, and what challenges they face. We conducted an interview-based survey study involving 24 practitioners from 12 diferent Swedish IT companies. We recorded the interviews and analysed these recordings, primarily by using qualitative methods. Natural language constitutes the main specifcation artefact but is usually accompanied by some other type of instrument. Most requirements specifcations use templates or guidelines, although they seldom follow any fxed standard. Requirements are always structured in the document according to the main functionalities of the system or to project areas or system parts. Diferent types of tools, including MS Ofce tools, are used, either individually or combined, in the compilation of requirements specifcations. We also note that challenges related to the use of natural language (dealing with ambiguity, inconsistency, and incompleteness) are the most frequent challenges that practitioners face in the compilation of requirements specifcations. These fndings are contextualized in terms of demographic factors related to the individual interviewees, the organization they are afliated with, and the project they selected to discuss during our interviews. A number of our fndings have been previously reported in related studies. These fndings show that, in spite of the large number of notations, models and tools proposed from academia for improving requirements specifcation, practitioners still mainly rely on plain natural language and general-purpose tool support. We expect more empirical studies in this area in order to better understand the reason of this low adoption of research results. This paper has been funded by the Spanish Ministerio de Ciencia e Innovación under project/funding scheme PID2020-117191RB-I00/AEI/.

The slides are licensed under CC BY 4.0, with the following exceptions: images and slides explicitly listed under a different license, memes and Canva graphics., This course introduces the fundamental concepts and activities in requirements engineering and the skills and knowledge of a requirements engineer. It covers various methods and strategies for eliciting, documenting, validating and managing requirements. By the end of the course, attendees will have the ability to: * Describe the fundamental phases of the requirements engineering process * Understand select strategies and methods that can be applied in each phase * Effectively identify relevant standards and modeling languages to formulate requirements * Develop a basic requirements engineering plan and select appropriate beginner-level methods for a given project

Зростаюча популярність гнучких методологій розробки програмного забезпечення та розвиток інструментів керування вимогами вплинули на роботу бізнес-аналітиків та інженерів з вимог в частині підготовки бізнес-аналітичних артефактів. Якщо при використанні таких методології як RUP перелік та структура документів були стандартизовані, методології Agile не містять таких рекомендацій. Для вивчення поточної практики щодо використання шаблонів бізнес-аналітичних документів, а також їх змісту було проведено опитування фахівців українських ІТ компаній, що задіяні в процеси роботи з вимогами. Результати дослідження можуть бути використані як безпосередньо бізнес-аналітиками при плануванні підходу до керування вимогами, так і для формування навчальних програм, пов’язаних з інженерією вимог та бізнес-аналізом. The growing popularity of agile software development methodologies and the development of requirements management tools have influenced the business analysts’ and requirements engineers’ activities in part of business analysis artefacts’ preparation. If, when using methodologies such as RUP, the list and structure of documents were standardized, Agile methodologies do not contain such recommendations. In order to study the current practice regarding the use of templates of business analysis documents, as well as their content, a survey of specialists of Ukrainian IT companies involved in the processes of working with requirements was conducted. Business analysts can use the research results directly when planning a requirement management approach, and results can be considered for forming study programs related to requirements engineering and business analysis

[Context and motivation] Requirements reuse has been proposed asa key asset for requirements engineers to efficiently elicit, validate and document softwarer equirements and, as a consequence, obtain requirements specifications of better quality through more effective engineering processes.[Question/problem] Regardless the impact requirements reuse could have in software projects’ suc-cess and efficiency, the requirements engineering community has published veryfew studies reporting the way in which this activity is conducted in industry. [Principal ideas/results] In this paper, we present the results of an interview-based study involving 24 IT professionals on whether they reuse requirementsor not and how. Some kind of requirements reuse is carried out by the majorityof respondents, being organizational and project-related factors the main drivers.Quality requirements are the type most reused. The most common strategy isfind-copy-paste-adapt. Respondents agreed that requirements reuse is beneficial,especially for project-related reasons. The most stated challenge to overcome inrequirements reuse is related to the domain of the project and the development of acompletely new system. [Contribution] With this study, we contribute to the stateof the practice in the reuse of requirements by showing how real organizationscarry out this process and the factors that influence it. This work has been partially funded by the Horizon 2020 project OpenReq, which is supported by the European Union under the Grant Nr. 732463.

As globalisation is now a reality for most large organizations, and the competition for most businesses moving faster and becoming tougher, there is a need for engineering projects to deliver results faster in a more complex environment than ever, but also for companies to collaborate to utilize a wider array of competencies and to reach new markets with their products. This case study analyses which difficulties arise in interorganizational requirements engineering, and what organizations can do to alleviate the effects of those difficulties, as well as suggest which actions are most effective to focus on. The conclusion of this study is that the difficulties can be divided into three categories, namely interpersonal, structural and processual. Each category concerns a different set of people and require different actions for increased effectiveness. For the interpersonal category, prioritized efforts should be to establish a shared vocabulary and use techniques to build shared contextual understanding. For structural difficulties, evaluating management and control structures and the implementation of the project’s strategy should be prioritized. In the processual category, codifying existing processes to enable improvements, defining information artefacts and aligning information flows should be of high priority. Globaliseringens effekter är idag en verklighet för de flesta stora organisationer, och konkurrensen för företag blir hårdare och förändrar sig allt snabbare. Därför blir det allt viktigare för utvecklingsprojekt att anpassa sig till en allt mer komplex miljö och leverera resultat snabbare än tidigare, men också att samarbeta mer med andra företag för att såväl utnyttja bredare kompetens som att nå nya marknader. Den här studien undersöker utmaningarna i interorganisatoriskt kravställningsarbete, vad företag kan göra för att möta de utmaningarna, såväl som att föreslå vilka handlingar som ger mest effekt för ett bättre kravställningsarbete. Slutsatsen av studien är att utmaningarna kan delas in i tre kategorier, nämligen personorienterade, strukturella och processorienterade. Varje kategori rör en viss mängd deltagare i projektet och kräver olika handlingar för ökad effektivitet. För att minska utmaningar i den personorienterade kategorin bör ett projekt prioritera att använda tekniker för att skapa ett gemensamt språkbruk och att använda tekniker för att bygga upp gemensam kontextuell förståelse. För strukturella utmaningar bör det prioriteras att utvärdera styrnings- och kontrollstrukturer, samt hur projektets strategi har implementerats och förankrats bland deltagarna. I den processorienterade kategorin bör det prioriteras att kodifiera existerande processer för att möjliggöra förbättringsarbete, definiera informationsartefakter och att försäkra sig om att informationsflöden är i linje med varandra mellan företagen, så att rätt information möts vid rätt tillfällen.

Requirements Engineering stands out as a key phase within Software Engineering, for establishing a strict and common vision between the client and the project team on software requirements. It is possible to find software coding specialists in a variety of programming languages currently used, but for software requirements few professionals are available. The definition of software requirements determines the scope and system boundary that must be provided. When System Analysts make mistakes during elicitation activities and requirements documentation, problems are likely to arise for next activities on the software development cycle. Costs incurred for problem-solving in the requirements documentation can rise significantly as new phases are initiated on the development cycle. It is common to find private companies or public institutions with di culties to elicit and document software requirements, either by the lack of a specific process, or because qualified professionals are not available to carry out these activities. The main motivation of this study was the necessity of resolution of problems related to user requirements documentation faced by a Public Institution during development of software projects. To solve this problem, a study was carried out using the action research methodology in this institution, with a goal of proposing and applying a user requirements elicitation and documentation process. In the process, a template was used for documenting requirements using SysML. During the execution of the research, a qualitative evaluation was carried out to verify the e ectiveness of the process. In this research, twelve System Analysts represented the public institution, distributed in five projects. The methodology used proved to be e ective and provided a participatory construction of problem-solving, involving researchers and participants. Results suggest that the intervention achieved positive results, including evidence of improvements in user requirements elicitation and documentation, in respect to activities previously performed at the institution. A Engenharia de Requisitos se destaca como uma fase fundamental na Engenharia de Software, por instituir uma visão estrita e comum entre o cliente e a equipe do projeto sobre os requisitos do software a ser desenvolvido. É possível encontrar especialistas em codificação de software nas várias linguagens de programação utilizadas atualmente, porém especialistas em requisitos de software são profissionais escassos no mercado. A definição dos requisitos de um software determina o escopo e os limites do sistema que deve ser fornecido. Quando Analistas de Sistemas cometem erros durante as atividades de elicitação e documentação dos requisitos é provável que surjam problemas nas próximas atividades do ciclo de desenvolvimento do software. Os custos despendidos para resolução de problemas inseridos na documentação de requisitos podem elevar-se significativamente à medida que novas fases são iniciadas no ciclo de desenvolvimento. É comum encontrar empresas privadas ou instituições públicas com dificuldades para elicitar e documentar requisitos, seja pela falta de um processo específico ou pelo fato de não possuírem profissionais capacitados para realizarem essas atividades. A realização deste estudo teve como principal motivação a resolução dos problemas relacionados à documentação de requisitos em nível de usuário enfrentados por uma Instituição Pública na condução de seus projetos de software. Para resolver este problema foi realizado um estudo utilizando a metodologia da pesquisa-ação nesta instituição, com objetivo de propor e aplicar um processo para elicitação e documentação de requisitos em nível de usuário. No processo foi utilizado um template para documentação de requisitos utilizando a SysML. Durante a execução do estudo foi realizada uma avaliação qualitativa para avaliar a eficácia do processo. Participaram do estudo de pesquisaação doze Analistas de Sistemas representantes da instituição, distribuídos em cinco projetos. A metodologia utilizada mostrou-se eficaz e proporcionou a construção da resolução do problema de forma participativa, envolvendo os pesquisadores e participantes do estudo. Os resultados obtidos sugerem que a intervenção realizada alcançou resultados positivos, inclusive com evidências de melhorias na elicitação e documentação dos requisitos em nível de usuário, em relação às atividades realizadas anteriormente na instituição. São Cristóvão, SE

Diferentes investigadores han propuesto técnicas y modelos para elicitar requisitos y la mayoría describe procesos y recomendaciones para capturarlos, pero muy pocos detallan cómo documentarlos en esta etapa. Aunque en la comunidad se reconoce ampliamente la importancia de la ingeniería de requisitos y de la elicitación como una etapa importante de esta fase de la ingeniería del software, se han presentado pocos trabajos que orienten a los ingenieros a documentar esa elicitación. La importancia de una adecuada documentación de esta etapa radica en que permite una mayor comprensión de las necesidades del cliente y el usuario, y les ayuda a los ingenieros a percibir de mejor forma el problema y a modelar una solución que se refleje adecuadamente en la especificación. En este trabajo se presentan los resultados de una revisión sistemática de la literatura, orientada a conocer, analizar y comparar las propuestas para documentar la elicitación de requisitos. Se consultaron 73 trabajos en las bases de datos, de los cuales 18 conforman la muestra final. La conclusión es que falta más trabajo en lo que tiene que ver con esta documentación, porque ninguno de los trabajos analizados describe una propuesta directa y completa para hacerlo. Different researchers have proposed techniques and models for eliciting requirements, and most described process and recommendations to capture them, but there are few details on how to document with this step. Although the community has widely recognized the importance of engineering requirements, and elicitation of an important stage of this phase of software engineering, there have been few studies to guide engineers to document this elicitation. The importance of proper documentation of this step is that it allows a better understanding of customer and the user needs, and helps engineers to best perceive the problem, and model a solution that adequately reflected in the Specification. In this work are presented the results of a literature review, aimed at discovering, analyzing and comparing the proposals to document the elicitation of requirements. 73 works were consulted in the databases, of which 18 formed the final sample. The conclusion is that more work is missing on what to do with this documentation, because none of the studies analyzed directly and completely describes a proposal to do so.