Dissertations / Theses on the topic 'Software requirements specification (SRS)'

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

Frequent automated testing of software services is vital to speed up the development cycle and ensure upgrades do not break existing features. With a centralised testing service, it is also possible to catch errors at customer sites before they become severe enough that the customers (or in the end – regular people) start suffering from them. It also gives the customers an insight into how well their services are working at a predictable cost. When developing a larger software system such as an automated testing service toolkit, a requirements specification can drastically cut development costs at the expense of a larger up-front investment. We discover some of the immediately important requirements for the first version of such an automated testing toolkit.
Upprepade automatiserade tester av mjukvarutjänster är mycket viktiga för att öka utvecklingshastigheten och försäkra att uppgraderingar inte påverkar existerande, äldre delar av systemet. Med en centraliserad testningstjänst är det också möjligt att upptäcka fel i kundens miljö innan de blir allvarliga nog att kunden märker av dem. Det ger även kunden en möjlighet att se hur väl deras tjänster fungerar utan att behöva betala oförutsedda driftrelaterade kostnader. När större mjukvarusystem, som en centraliserad tjänst för automatiserade tester, kan en kravspecifikation drastiskt minska utvecklingskostnaden mot en större initial investering. Vi har undersökt vilka några av de omedelbart viktiga kraven är för en första version av denna typ av tjänst.

Cette thèse porte sur l’utilisation d’une langue contrôlée pour les spécifications des besoins du logiciel en thaï. L’étudedécrit les ambiguïtés syntaxiques et sémantiques ainsi que les problèmes rencontrés dans les spécifications des besoins dulogiciel en thaï. Ce travail explique également la nature de la langue thaïe. Le modèle de la langue contrôlée pour lesspécifications des besoins du logiciel en thaï, proposé dans cette étude, comprend trois composantes: l’analyse lexicale,l’analyse syntaxique et l’analyse sémantique. Pour l’analyse syntaxique, une syntaxe contrôlée est conçue en utilisant laforme du Backus-Naur (BNF). Quant à l’analyse lexicale, nous créons une ressource lexicale sous forme de langage XMLpour stocker tous les mots classés selon leur domaine. Les mots reçus de la ressource XML sont corrects d’un point de vueconceptuel mais ne sont pas pertinents d’un point de vue sémantique. Pour résoudre ce problème, nous faisons alors usage dematrices booléennes pour aligner les phrases sémantiquement. Ainsi les phrases produites par le modèle serontsyntaxiquement et sémantiquement correctes.Après avoir créé le modèle, nous avons construit un logiciel pour tester son efficacité. Il est ainsi évalué par quatreméthodes d’évaluation : 1. le test de fonctionnement syntaxique pour vérifier la syntaxe de la phrase; 2. le test defonctionnement sémantique pour tester la sémantique de la phrase; 3. le test d’acceptation en terme de satisfaction desutilisateurs avec le logiciel; et 4. le test d’acceptation en terme d’acception des données de sortie.Des résultats positifs montrent que : 1. les phrases produites par le modèle proposé sont syntaxiquement correctes; 2. lesphrases produites par le modèle proposé sont sémantiquement correctes; 3. les utilisateurs sont satisfaits et acceptent lelogiciel; et 4. les utilisateurs acceptent et comprennent les phrases produites par ce modèle
This thesis focuses on using controlled language for Thai software requirements specifications. The studydescribes the ambiguities and problems encountered in Thai software requirements specifications; both syntacticambiguity and semantic ambiguity. The study also describes the nature of the Thai language. The model of controlledlanguage for Thai software requirements specifications is composed of three main components: lexical analysis,syntactic analysis, and semantic analysis. For syntactic analysis, a controlled syntax is created using Backus-NaurForm (BNF). In the lexical analysis stage, an XML format lexical resource is built to store words according to theirdomain. The words received from the XML resource are conceptually correct but may be semantically irrelevant. Tosolve this issue, the model applies Boolean Matrices to align sentences semantically. As a result, the sentencesproduced from the model are guaranteed to be syntactically and semantically correct.After having created this model, a program for testing the efficiency of the model is developed. The model isevaluated using four testing methods as follows: 1. functional testing for the correctness of the sentence’s syntax, 2.functional testing for the semantic correctness of the sentences produced by the model, 3. acceptance testing in termsof user satisfaction with the program, and 4. acceptance testing in terms of the validity of the outputs.The positive results signify that: 1. the sentences produced by the proposed model are syntactically correct, 2. thesentences produced by the proposed model are semantically correct, 3. the users are satisfied and accept the softwarecreated, and 4. the users approve and understand the sentences produced from this model

The precision of formal specifications allows us to prove program correctness. Even if formal methods are not used throughout the software project, formalisation improves our understanding of the problem. Formal specifications are amenable to automated analysis and consistency checking. However using them is challenging. Customers do not understand formal notations. Specifiers have difficulty tackling large problems. Once systems are built, formal specifications quickly become outdated during software maintenance. A method of developing formal specifications using concrete scenarios is proposed to tackle the disadvantages just mentioned. A concrete scenario describes system behaviour with successive steps. The pre- and post-states of scenario steps are expressed with actual data rather than variables. Concrete scenarios are expressed in a natural language or formal notation. They increase customer involvement in the creation of formal specifications. Scenarios may be ranked by priorities allowing specifiers to focus on a small part of the system. Formal specifications are constructed incrementally. New requirements are also captured in concrete scenarios which guide the modification of formal specifications. On one hand, concrete scenarios assist the creation and maintenance of formal specifications. On the other hand, they facilitate program correctness proofs without using conventional formal specifications. This is achieved by adding implementation details to customer scenarios. The resulting developer scenarios, encapsulating decisions of data structures and algorithms, are generalised to operation schemas. With the implementation details, the schemas written in formal notations are programs rather than specifications.

Approved for public release; distribution is unlimited.
This thesis concerns the software requirements necessary to automate the present manual effort associated with ammunition inventory management and reporting at the afloat end-user level. Functional characteristics for the application software are developed, program and data structures are proposed and possible sources of data are identified. The end-product of this research is the software requirements specification. This document supports further design development of the application software and is independent of programming language and system hardware configuration. Ammunition management, Ammunition inventory management, Automated ammunition management, automated ammunition inventory management. (eg)

SCHUENEMANN, Carla Taciana Lima Lourenco Silva, também é conhecida em citações bibliográficas por: SILVA, Carla
Submitted by Fernanda Rodrigues de Lima (fernanda.rlima@ufpe.br) on 2018-07-31T22:18:30Z No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Approved for entry into archive by Alice Araujo (alice.caraujo@ufpe.br) on 2018-08-01T22:34:12Z (GMT) No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Made available in DSpace on 2018-08-01T22:34:12Z (GMT). No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5) Previous issue date: 2017-03-13
Although Agile Software Development (ASD) has grown in recent years, research evidence points out several limitations concerning its requirements engineering activities. It was observed that an inadequate specification acts as a catalyst to others problems, such as low productivity of the team and difficulty in maintaining software. Improving the quality of Software Requirements Specifications (SRS) may help gaining a competitive advantage in the software industry. The goal of this study is to investigate the phenomenon of the requirements specification activity in ASD, discuss relevant findings of this phenomenon to industrial practice, and propose practices to write a SRS targeted to development team. First, a Systematic Mapping (SM) study was conducted to characterize the landscape of requirements engineering in ASD. The thematic synthesis method was used to code and synthesize the data collected from the primary studies selected. After that, some of the challenges pointed out in the SM were investigated in more depth in six industrial case studies. Data collected from documents, observations, and interviews with software engineers were triangulated, analyzed, and synthesized using techniques of grounded theory and metaethnography. The analysis and cross-synthesis of the case studies resulted in a model that defines the simplicity and objectivity as essential quality factors of SRS in ASD. The main factors that affect the quality are related to the customer-driven nature that tends to leave the prolix SRS, hindering the understanding of the software engineers, as they are, at the same time, insufficient to support coding, testing and maintenance tasks. One approach was proposed to provide a SRS closer to the development needs, addressing some of the quality factors of the model. Empirical studies that evaluated the approach show that the design practices used in the proposed approach have the potential to reduce the gap between the problem and the solution domains, producing an objective SRS that is team-driven and closer to that will be implemented.
Embora o Desenvolvimento Ágil de Software (DAS) tenha crescido nos últimos anos, estudos empíricos apontam vários problemas relacionados com as atividades de engenharia de requisitos. Observou-se que a especificação inadequada age como um catalizador para outros problemas, como por exemplo, baixa produtividade da equipe e dificuldades na manutenção do software. Melhorar a qualidade da Especificação de Requisitos de Software (ERS) pode ajudar a ganhar uma vantagem competitiva na indústria de software. O objetivo deste estudo é investigar o fenômeno da especificação de requisitos no DAS, discutir relevantes implicações desse fenômeno para a indústria, e propor práticas para escrever ERS voltadas para a equipe de desenvolvimento. Primeiro, um Mapeamento Sistemático (MS) foi realizado para caracterizar o panorama da engenharia de requisitos no DAS. O método de síntese temática foi utilizado para codificar e sintetizar os dados coletados a partir dos estudos primários selecionados. Em seguida, alguns dos desafios apontados no MS foram investigados com mais profundidade em seis estudos de caso industriais. Os dados coletados a partir de documentos, observações e entrevistas com engenheiros de software foram triangulados, analisados e sintetizados usando técnicas de teoria fundamentada e meta-etnografia. A análise e síntese cruzada dos estudos de caso resultaram em um modelo de qualidade que define a simplicidade e objetividade como fatores essenciais na ERS no DAS. Os principais fatores que afetam a qualidade estão relacionados à natureza orientada para o cliente que tende a deixar a ERS prolixa, dificultando a compreensão do engenheiro de software, ao mesmo tempo que é insuficiente para a codificação, testes e manutenção. Uma abordagem foi proposta para fornecer uma especificação de requisitos mais próxima das necessidades de desenvolvimento, atendendo alguns dos fatores de qualidade do modelo. Os estudos empíricos que avaliaram a abordagem demonstram que as práticas de design utilizadas pela abordagem tem o potencial de reduzir a distância entre o domínio do problema e o da solução, produzindo uma ERS objetiva, voltada para o desenvolvedor, e próxima do que vai ser implementado.

Systems development projects and their documents are more or less standardized and can mainly be applied on systems that are supposed to be built from scratch, or updated. In pace with the number of IT-systems are increasing worldwide there is no need for every organization to build their own IT-system. Nowadays it is also possible to purchase licenses which allow the purchaser to modify or add functions to the system. Along with those changes, there have been an increased amount of “rapid development methods” such as Agile and “Quick and Dirty” solutions, but these methods and perspectives are mainly focusing on entire systems development processes, as the old ones, but quicker.

If a company purchases an off-the-shelf system with source code available, there is no real need to go through a proper systems development process. During interviews with a small company that has acquired a system as mentioned above, the researcher realized that only one single document is needed, the requirements specification. Today’s requirements specifications can be either well detailed or less, but a project still needs the details specified. Combining a known agile development process with IEEE’s standardized requirements specification, a new way to proceed with projects based on one single document (the requirements specification) has been made. This document also has a focus on simplicity for the inexperienced readers, but with the depth that every developer has got a use for.

Specifying, verifying, and testing software requirements and design are very important tasks in the software development process and must be taken seriously. By investing more up-front effort in these tasks, software projects will gain the benefits of reduced maintenance costs, higher software reliability, and more user-responsive software. However, many individuals involved in these tasks still find that the techniques available for the tasks are either too difficult and far from practical or if not difficult, inadequate for the tasks. This thesis proposes practical and capable techniques for specifying and verifying software requirements and design and for generating test requirements for acceptance and system testing. The proposed software requirements and design specification techniques emerge from integrating three categories of software specification languages, namely an infonnal specification language (e.g. English), semiformal specification languages (Entity-Relationship Diagrams, Data Flow Diagrams, and Data Structure Diagrams), and a formal specification language (Z with an extended subset). The four specification languages mentioned above are used to specify both software requirements and design. Both software requirements and design of a system are defined graphically in Entity-Relationship Diagrams, Data Flow Diagrams, and Data Structure Diagrams, and defined formally in Z specifications. The proposed software requirements and design verification techniques are a combination of informal and formal proofs. The informal proofs are applied to check the consistency of the semiformal specification and to check the consistency, correctness, and completeness of the formal specification against the semiformal specification. The formal proofs are applied to mathematically prove the consistency of the formal specification. Finally, the proposed technique for generating test requirements for acceptance and system testing from the formal requirements specification is presented. Two sets of test requirements are generated: test requirements for testing the critical requirements, and test requirements for testing the operations of the system.

Abstract There is a broad consensus in the software engineering (SE) research community that understanding system desiderata and design creativity is critical for the success of software projects. This has motivated a plethora of research in SE to improve requirements engineering (RE) processes. However, little research has investigated the relationship between the way desiderata are presented (i.e., framed) and creative design performance. This dissertation, therefore, examines the effects of more formal presentations of desiderata on design creativity. The research was conducted in three phases. The first consisted of summarizing the available literature on cognitive biases in SE to build a comprehensive body of knowledge, understand the current state of research, and identify the relevant literature to position and delineate subsequent investigations involving the framing effect and fixation. This research phase also investigated how creativity is conceptualized (i.e., understood, assessed and improved) in SE by exploring the perceptual differences and similarities between SE researchers and practitioners. In the second phase, two controlled experiments were conducted to investigate the impact of framing desiderata first as requirements (in general) and then as prioritized requirements on design creativity (i.e., the originality and practicality of a design). The third phase involved a protocol study to explore the underlying cognitive mechanisms that may explain why framing desiderata as formal requirements affects creativity. The empirical evidence from the second and third phases was interpreted together to propose a theoretical framework that explains the effect of specification formality on design creativity. While the results of the experiments show that specification formality is negatively related to design creativity (i.e., desiderata framed as requirements or prioritized requirements result in designs that are less creative), the findings from the protocol study indicate that the negative relationship between specification formality and design creativity is mediated by fixation (i.e., more formal presentation of desiderata induces fixation and hinders critical thinking). Overall, the results of this dissertation suggest that more formal and structured presentations of desiderata cause requirements fixation—the tendency to attribute undue confidence and importance to desiderata presented as formal requirements statements—that affects design creativity, and thus undermines software engineering success
Tiivistelmä Ohjelmistotuotannon tutkijoiden keskuudessa on laaja yksimielisyys järjestelmän tarpeiden ja suunnittelun luovuuden ymmärtämisen kriittisyydestä ohjelmistoprojektien menestyksessä. Tämä on motivoinut monia ohjelmistotuotannon vaatimusmäärittelyprosessien parantamiseen liittyviä tutkimuksia. Harvassa on tarkasteltu tarpeiden esitystavan (eli muotoilun) ja luovan suunnittelun lopputuloksen välistä yhteyttä. Tässä väitöskirjassa tarkastellaan tarpeiden muodollisempien esitystapojen vaikutuksia suunnittelun luovuuteen. Tutkimus oli kolmivaiheinen. Ensin referoitiin ohjelmistotuotannossa kognitiivisiin harhoihin liittyvä kirjallisuus kartoittamaan nykytutkimuksen tila ja merkityksellinen kirjallisuus myöhempien, kehysvaikutuksen ja fiksaation sisältävien tutkimusten sijoittamiseen ja rajaamiseen. Lisäksi tarkasteltiin luovuuden käsitteellistämistä (eli ymmärrettävyyttä, arviointia ja parantamista) tutkimalla katsannollisia eroja ja yhtäläisyyksiä tutkijoiden ja ammattilaisten välillä. Toisessa vaiheessa tehtiin kaksi kontrolloitua koetta tarpeiden muotoilun vaikutuksien tutkimiseksi, ensin vaatimuksina (yleisesti) ja sitten tärkeysjärjestykseen laitettuina vaatimuksina suhteessa suunnittelun luovuuteen (eli omaperäisyyteen ja käytännöllisyyteen). Lopuksi, protokollatutkimuksella selvitettiin taustalla olevia kognitiivisia mekanismeja selittämään syitä muodollisina vaatimuksina esitettyjen tarpeiden vaikutuksista luovuuteen. Toisesta ja kolmannesta vaiheesta saatujen empiiristen aineistojen tulkittiin yhdessä muodostavan teoreettisen viitekehyksen, joka selittää määrittelyn muodollisuuden vaikutusta suunnittelun luovuuteen. Vaikka kokeiden tulokset osoittavat määrittelyjen muodollisuuden vaikuttavan negatiivisesti suunnittelun luovuuteen (eli tarpeiden muotoilu vaatimuksina tai priorisoituina vaatimuksina vähentää suunnitelmien luovuutta), protokollatutkimuksen tulokset viittaavat fiksaation vaikuttavan negatiiviseen yhteyteen määrittelyjen muodollisuuden ja suunnittelun luovuuden välillä (eli tarpeiden muodollisempi esitystapa aiheuttaa fiksaatiota ja vaikeuttaa kriittistä ajattelua). Kaiken kaikkiaan, väitöskirjan tulokset esittävät muodollisempien ja strukturoidumpien tarpeiden esitystapojen aiheuttavan vaatimusten fiksaatiota, taipumusta pitää luottamusta ja tärkeyttä tarpeiden muodollisten vaatimusten ilmaisun ansioina, joka vaikuttaa suunnittelun luovuuteen heikentäen ohjelmistotuotannon menestymisen mahdollisuutta

This thesis emphasizes on surveying the state-of-the-art in software requirements specification with a focus on, autonomic, self-adapting software systems. Since various requirements are brought forward accord with environments, modeling requirements for adaptive software systems may be changed at run-time. Nowadays, Keep All Objectives Satisfied (KAOS) is an effective method to build goal model. Various manipulations, such as change, remove, active and de-active goals, appear new goals, could mediate conflicts among goals in adaptive software system. At specification time, specifications of event sequences to be monitored are generated from requirements specification.

Context: Security Requirements engineering is necessary to achieve secure software systems. Many techniques and approaches have been proposed to elicit security requirements in the initial phases of development. With the growing importance of security and immense increase in security breaches over the past few years, researchers and practitioners have been striving to achieve a mature process of coping with security requirements. Much of the activities in this regard are seen in academia but industry still seems to be lacking in giving the required importance to security requirements engineering. That is why, security requirements engineering is still not always considered as a central part of requirements engineering. This study is targeted to bridge this gap between academia and industry in terms of security requirements engineering and to provide a concrete approach to efficiently elicit and specify security requirements. The Misuse case technique is proposed for this purpose. However it lacks in providing guidelines for enabling scalable use. This limitation has been addressed to achieve a mature process of security requirements elicitation. Objectives: In this study, we propose a framework to elicit security requirements early in the software development using misuse case technique. Objective is to make misuse case technique scalable and applicable to the real-world projects. The proposed framework was presented to two representatives from the Swedish Armed Forces (SWAF). The feedback received from the representatives was utilized to refine, update and finalize the framework. Methods: The study involved a systematic review to gain an insight of the academic perspective in the area of study. Document extraction was adopted to observe the industrial trends in the said subject. These were the software requirements specification documents of the real-world systems. Document extraction was supported with informed brainstorming because the study revolved around misuse case technique and informed brainstorming is considered to be the most suitable technique for this purpose. A workshop was conducted with two representatives of Swedish Armed Forces followed by two subsequent asynchronous communication rounds and a facilitated session to get feedback about the proposed solution. This feedback was utilized to refine, update and finalize the proposed solution. Results: The results of the systematic review were organized in tabular forms for a clear understanding and easy analysis. A security requirements categorization was obtained as a result which was finalized after an initial validation with the help of real-world projects. Furthermore, a framework was proposed utilizing this categorization to address the limitations of misuse case technique. The framework was created and refined through workshop and different communication rounds with representatives of SWAF. Their feedback was used as input to further improve the usefulness and usability aspects of the framework. Conclusions: The significance of security requirements engineering is undisputedly accepted both in academia and industry. However, the area is not a subject of practice in industrial projects. The reasons include lack of mature processes as well as expensive and time consuming solutions. Lack of empirical evidences adds to the problems. The conducted study and proposed process of dealing with this issue is considered as a one step forward towards addressing the challenges.
Säkerhet Kravhantering är nödvändigt för att uppnå säkra programvarusystem. Många tekniker och metoder har föreslagits för att framkalla säkerhetskraven i de inledande faserna i utvecklingen. Med den växande betydelsen av säkerhet och enorma ökning av brott mot säkerheten under de senaste åren har forskare och praktiker strävat efter att uppnå en mogen process för att klara säkerhetskraven. Mycket av verksamheten i detta avseende ses i den akademiska världen, men industrin fortfarande tycks saknas i att ge den nödvändiga betydelse för säkerheten kravhantering. Därför är säkerheten kravhantering fortfarande inte alltid som en central del av kravhantering. Denna studie är inriktad att överbrygga denna klyfta mellan akademi och näringsliv när det gäller säkerhet kravhantering och att ge en konkret strategi för att effektivt få fram och specificera säkerhetskrav. Missbruk fallet tekniken föreslås för detta ändamål. Men det saknar i att ge riktlinjer för att möjliggöra skalbar användning. Denna begränsning har åtgärdats för att uppnå en mogen process av säkerhetskrav elicitation.
+46 (0) 735 84 12 97, +46 (0) 760 60 96 55

Context. Public procurement is an important economic factor. To protect against corruption government organizations are required to apply principles of non-discrimination and transparency for the procurement of goods such as software and of services such as software development. As a consequence, communicating requirements in software procurement has become challenging from the perspective of fairness and transparency, and also from the perspectives of system value and acceptance. Objectives. This study investigates requirements communication techniques which are being practiced in WTO-regulated tenders. The study also identifies challenges and determines the efficiency, effectiveness, and legal compliances of these techniques Methods. A systematic literature review is used to determine requirements communication approaches used in public procurement projects and the difficulties identified. This is followed by a case study to research the known requirements communication techniques used in the selected case through conducting interviews and artifact analysis. Results. The contributions are guidelines for stakeholders to select suitable techniques to communicate requirements during the procurement process. Challenges and recommendations are presented to be taken into consideration while planning software procurements. Conclusions. This study concluded that from a total of 17 requirements communication techniques, 14 have been used in the project analyzed in the case study. It is also stated by the interviewees that all of the techniques are legal to use in public procurement with the exception of one, and this is Interview. From both the literature review and the case study conducted in this research, balanced communication techniques are concluded to be most recommended since they will lead to more interaction between customers and suppliers to communicate requirements.

Software projects with a larger code base can be hard to maintain, and testing could therefore be a necessity. But how would one prioritize tests in their existing software project, if their project never had any tests? The purpose of this study is to find concrete steps of how to prioritize tests in a software project, independent of project type and development language. Said steps were found through two iterations of the Action Learning method. The results were found without any requirements specification, which lead to using intuition, together with code complexity, to prioritize test cases, after breaking down the project into its modules. As the study was conducted on only one specific software project, the result is limited to that specific software project until further research is conducted.

This work is dedicated to the requierements specification process automation issues. Main goal of the paper is to specify a conceptual model of the multy-user software requirements specification system and create a working prototype of this model. Analysis part of the work focuses on requirement specification templates and existing requirements specification software investigation. A detailed analysis of most popular templates Volere and IEEE STD 830-1998 is followed by existing software requirements specification software analysis : AnalystPRO and RequisitePRO. Requirements and tasks for the system prototype are raised on the basis of main features and weknesses of analysed requirements specification templates and software. This work presents a complete conceptual model of the software requirements specification automation. System model is based on the Volere template. Main features of the system prototype are as follows: complete independence from operating system and working environment, no any client software installation is needed, server part does not require any special components installation and is based on popular free software: Apache and MySQL Servers. System architecture is based on JAVA Applets technology. Working prototype is an implementation of main system protoype features. This is a multy-user software requirements specification environment with all main collaboration fetures: version control, document locking, presence awareness. Usability of system... [to full text]

Au cours de la phase de l’analyse des besoins pour le développement d’un système, l’accent est souvent porté sur les besoins fonctionnels, tandis que les besoins non fonctionnels (Non Functional Requirements - NFR) sont capturés par les analystes systèmes seulement à un niveau très global : au cours de cette phase, les NFR sont décrits typiquement au niveau du système et non au niveau du logiciel. Le détail de ces besoins non fonctionnels est souvent précisé (c'est à dire défini au niveau de détail nécessaire) par les concepteurs du système à la phase de l’architecture et à la phase de conception du système. Pour le moment, il n’y a pas de consensus sur la manière de décrire et de mesurer les besoins non fonctionnels des systèmes (system-NFR) : c’est donc un défi de les prendre en compte dans l’estimation des efforts pour le développement des logiciels qui feront partie de ces systèmes et dans l’évaluation de la productivité des projets de développement de ces logiciels. Durant la phase de l’analyse des besoins pour les logiciel, les besoins non fonctionnels des systèmes peuvent être décrits et spécifiés comme étant les besoins fonctionnels alloués au logiciel : ceci permet alors aux ingénieurs logiciels de développer, tester et configurer les livrables finaux aux utilisateurs du système. La motivation de cette recherche est de contribuer à l’effort d’amélioration des modèles d’estimation des projets de développement logiciel en introduisant les exigences non fonctionnelles des systèmes au sein du processus d’estimation du projet logiciel et ce au travers d’une vue quantitative. Le but de cette recherche est d’aider les chefs de projets, les organisations ainsi que les chercheurs, à prendre des décisions éclairées sur les plannings des projets et sur le développement des logiciels et ce pendant la phase initiale d’identification des besoins, des spécifications et d’estimation des besoins non fonctionnels d’un système incluant du logiciel embarqué. Plus précisément, cette étude a comme but de contribuer à une meilleure définition, description et estimation de certains entrants, qui sont les besoins non fonctionnels du système, nécessaire pour réaliser une estimation préalable des couts. Dans les standards internationaux, un certain nombre de concepts sont utilisés afin de décrire différents types de besoins non fonctionnels des systèmes, que ces besoins soient au niveau du système, du logiciel ou du matériel. L’objectif de cette recherche est d’effectuer, le plus en amont possible, les spécifications et la quantification des besoins fonctionnel pour le logiciel, dérivés des besoins non fonctionnels au niveau système, en utilisant comme base les standards de l’ingénierie du logiciel. Pour atteindre cet objectif de recherche les deux sous-objectifs de recherche spécifiques suivants doivent être atteints: • Conceptions de modèles standards pour l’identification et la spécification des besoins fonctionnels de l'utilisateur (FUR) alloués au logiciel pour répondre aux besoins non fonctionnels du système (system-NFR). • Mesure de la taille fonctionnelle, en utilisant le standard COSMIC ISO 19761. des besoins fonctionnels alloués au logiciel pour répondre aux besoins non fonctionnels du système les résultats de cette recherche sont à un ensemble de quatorze (14) modèles de spécifications et de mesure, basés sur des standards, pour les besoins non-fonctionnels du système qui peuvent être alloués à du logiciel embarqué temps réel. La contribution principale de cette recherche est cet ensemble de quatorze modèles des besoins fonctionnels des utilisateurs du logiciel basés sur des standards pour l’identification, la spécification et la mesure des besoins non fonctionnels du système.

Main goal of this paper is to define a solution for employee training and development programs. The goal is accomplished through formulating of project management plan and specifications of requirements and software architecture.

This diploma thesis deals with the areas of requirements management in large organizations, especially banks. Bank projects have their own characteristics, as well as the banking environment as such. The paper will analyze the problem of requirements management in general and during description of best practices and methodological procedures attention will be drawn to the peculiar characteristics of the banking environment. This thesis focuses mainly on methodological and personal aspects of requirements management - the role of the analyst and the requirements management methodology. One of the main goals is selection of requiremets management methodology suitable for use in banks. Other important objectives are the description of best practices and mapping of the description of requirements management in the most widely used software development methodologies. The paper can serve as a textbook for junior analysts and other team members, or as a reference guide. Well-educated analyst and knowledgeable project team members enhance probability of a successful completion of the project and objectives achievement within set deadlines, budget and to everyone's satisfaction.

A formal specification language used during the requirements phase can reduce errors and rework, but formal specifications are regarded as expensive to maintain, discouraging their adoption. This work presents a single-subject experiment that explores the costs of modifying specifications written in two different languages: a tabular notation, Software Cost Reduction (SCR), and a state-of-the-practice notation, Real-time Unified Modeling Language (UML). The study records the person-hours required to write each specification, the number of defects made during each specification effort, and the amount of time repairing these defects. Two different problems are specified—a Bidirectional Formatter (BDF), and a Bicycle Computer (BC)—to balance a learning effect from specifying the same problem twice with different specification languages. During the experiment, an updated feature for each problem is sent to the subject and each specification is modified to reflect the changes.

The results show that the cost to modify a specification are highly dependent on both the problem and the language used. There is no evidence that a tabular notation is easier to modify than a state-of-the-practice notation.

A side-effect of the experiment indicates there is a strong learning effect, independent of the language: in the BDF problem, the second time specifying the problem required more time, but resulted in a better-quality specification than the first time; in the BC problem, the second time specifying the problem required less time and resulted in the same quality specification as the first time.

This work demonstrates also that single-subject experiments can add important information to the growing body of empirical data about the use of formal requirements specifications in software development.

A definição de requisitos tem sido reconhecida como uma das mais críticas e difíceis tarefas em engenharia de software. A necessidade de ferramentas de suporte é essencial. Nos dias de hoje, entre os vários métodos existentes para apoiar a fase de requisitos, destaca-se o SADT (Structured Analysis and Design Techniques) devido a sua capacidade de representar modelos. Este trabalho estabelece semântica para o método SADT, baseando-se na inter-relação do método aos sistemas de fluxo de dados (redes, grafos e máquinas de fluxo). Faz-se, inicialmente, uma abordagem operacional para a semântica de seus construtos básicos e, posteriormente discute-se a possibilidade de executar especificações através de simulação. Uma ferramenta para suportar o método SADT foi projetada e construída e é apresentada. Ela foi definida a partir de um modelo, denotado por uma classe, através de uma sintaxe abstrata. Essa ferramenta foi implementada no ambiente PROSOFT, fornecendo para o usuário mais de quarenta operações de apoio a construção/manipulação de diagramas. O trabalho também apresenta a especificação formal em VDM - Vienna Development Method, da semântica dos principais construtos do método SADT, bem como uma proposição de execução de especificações através de simulação são ainda indicadas direções nas quais o trabalho pode ser estendido.
The definition of systems requirements has been known as one of the most critical and dificult tasks as far as the software engineering is concerned. The need support is essential. Nowadays, among the various methods devised to support the phase of requirements, a special emphasis is given to the SADT method (Structured Analysis and Design Techniques), due to its capability of representing models. This work set semantic for the SADT method, based primarily upon the interrelation of the method to the systems of dataflow (nets, graphs and dataflow machines). It deals with an approach of operational semantics to its basic constructs, and it will, afterwards, discuss the possibility of carry out specifications by simulation. A tool was built to support the SADT method, and it was defined by a model denoted by a class, through an abstract syntax. This tool was implemented in the PROSOFT environment, providing for the user, more than forty support operations for the construction /manipulation of diagrams. This work also presents the formal specification of the semantics of the main constructs of the SADT method in VDM - Vienna Development Method; as well as an execution proposal of specifications through simulation. Directions have been indicated concerning the extension of the research.

Les travaux développés dans cette thèse visent à assister le processus d’ingénierie des exigences temporelles pour les systèmes complexes à contraintes de temps. Nos contributions portent sur trois volets : la spécification des exigences, la modélisation du comportement et la vérification. Pour le volet spécification, une nouvelle classification des exigences temporelles les plus communément utilisées a été proposée. Ensuite, afin de cadrer l’utilisateur durant l’expression des exigences, une grammaire de spécification à base de motifs prédéfinis en langage naturel est développée. Les exigences générées sont syntaxiquement précises et correctes quand elles sont prises individuellement, néanmoins cela ne garantie pas la cohérence de l’ensemble des exigences exprimées. Ainsi, nous avons développé des mécanismes capables de détecter certains types d’incohérences entre les exigences temporelles. Pour le volet modélisation du comportement, nous avons proposé un algorithme de transformation des state-machine avec des annotations temporelles en des automates temporisés. L’idée étant de manipuler une notation assez intuitive et de générer automatiquement des modèles formels qui se prêtent à la vérification. Finalement, pour le volet vérification, nous avons adopté une technique de vérification à base d’observateurs et qui repose sur le model-checking. Concrètement, nous avons élaboré une base de patterns d’observation (ou observateurs) ; chacun des patterns développés est relatif à un type d’exigence temporelle dans la nouvelle classification. Ainsi, la vérification est réduite à une analyse d’accessibilité des états correspondants à la violation de l’exigence associée
The work developed in this thesis aims to assist the engineering process of temporal requirements for time-constrained complex systems. Our contributions concern three phases: the specification, the behaviour modelling and the verification. For the specification of temporal requirements, a new temporal properties typology taking into account all the common requirements one may meet when dealing with requirements specification, is introduced. Then, to facilitate the expression, we have proposed a structured English grammar. Nevertheless, even if each requirement taken individually is correct, we have no guarantee that a set of temporal properties one may express is consistent. Here we have proposed an algorithm based on graph theory techniques to check the consistency of temporal requirements sets. For the behaviour modelling, we have proposed an algorithm for transforming UML State Machine with time annotations into Timed Automata (TA). The idea is to allow the user manipulating a quite intuitive notation (UML SM diagramsduring the modelling phase and thereby, automatically generate formal models (TA) that could be used directly by the verification process. Finally, for the verification phase, we have adopted an observer-based technique. Actually, we have developed a repository of observation patterns where each pattern is relative to a particular temporal requirement class in our classification. Thereby, the verification process is reduced to a reachability analysis of the observers’ KO states relatives to the requirements’ violation

Software deployment, eller mjukvarudistribution översatt till svenska kan ses som processen där alla aktiviteter ingår för att göra en mjukvara tillgänglig för användare utan en manuell installation på användarens dator eller annan maskin. Det finns ett flertal software deployment-verktyg, som hanterar automatiska installationer, tillgängliga för företag på marknaden idag.  Avdelningen HVDC på ABB i Ludvika har behov att börja använda ett verktyg för automatiserade installationer av mjukvaror då installationer idag utförs manuellt och är tidsödande. Som Microsoftpartners vill ABB se hur Microsofts verktyg för mjukvarudistribution skulle kunna hjälpa för detta behov.  Vår studie syftade till att undersöka hur arbetet med installationer av mjukvara ser ut idag, samt hitta förbättringsmöjligheter för installationer som inte kan automatiseras i nuläget. I studien ingick även att ta fram ett generellt ramverk för hur verksamheter kan gå tillväga när de vill börja använda sig utav software deployment-verktyg. I ramverket ingår en utformad kravspecifikation som ska utvärderas mot Microsofts verktyg.  För att skapa en uppfattning om hur arbetet i verksamheten ser ut idag har vi utfört enkätundersökning och intervjuer med personal på HVDC. För att utveckla ett ramverk har vi använt oss av insamlade data från de intervjuer, enkätundersökning och gruppintervju som utförts, detta för att identifiera krav och önskemål från personalen hos ett software deployment-verktyg. Litteraturstudier utfördes för att skapa en teoretisk referensram att utgå ifrån vid utvecklande av ramverket och kravspecifikationen.  Studien har resulterat i en beskrivning av software deployment, förbättringsmöjligheter i arbetet med installationer av mjukvara samt ett generellt ramverk som beskriver hur verksamheter kan gå tillväga när de ska börja använda ett software deployment-verktyg. Ramverket innehåller också en kravspecifikation som använts för att utvärdera Microsofts verktyg för mjukvarudistribution. I vår studie har vi inte sett att någon tidigare har tagit fram ett generellt ramverk och kravspecifikation som verksamheter kan använda sig av som underlag när de ska börja använda ett software deployment-verktyg. Vårt resultat av studien kan täcka upp detta kunskapsgap.
Software deployment can be seen as the process where all activities are included to make a software available to users without a manual installation on the user’s computer or other machine. There are several software deployment tools that manage automated installations available to enterprises on the market today. The department HVDC at ABB in Ludvika has needs of starting to use a tool for automated installations of software which currently is installed manually and is time consuming. As Microsoft partners ABB wants to see how Microsoft’s tool for software deployment could help for this need.  Our study aimed to investigate how the department´s work with installations of software looks like today and to find opportunities for improvement for installations that can’t be automated at this time. The study also includes to develop a general framework for how businesses can proceed when they want to start using a software deployment tool. The framework also includes a designed requirement specification that will be evaluated against Microsoft´s tool. To create an idea of how the work in the business looks like today, we have performed surveys and interviews with staff in HVDC. In order to develop a framework, we have used the data collected from the interviews, questionnaires and group interviews conducted to identify requirements and wishes from the staff of a software deployment tool. Literature studies were also conducted to create a theoretical framework to use when developing the framework and the requirement specification.  Our studies have resulted in a description of software deployment, opportunities for improvement in the work of software installations and a general framework that describes how businesses can proceed when they are about to start using a software deployment tool. The framework also provides a set of requirements that have used to evaluate Microsoft's tool for software distribution. In our study we have not seen that anyone before have developed a general framework and requirements specification that businesses can use as a basis when to start using a software deployment tool. Our results of the study can cover up this knowledge gap.

La plupart des projets de développement logiciel actuel dépendent de l'utilisation des solutions existantes pour gagner du temps et réduire les coûts de développement. Pour atteindre cet objectif, les entreprises doivent tirer parti des fonctionnalités offertes par les services techniques ou les interfaces de programmation applicatives exposées par les solutions existantes. La collecte et la qualification de ces composants ou services techniques permet de les réutiliser directement ou par orchestration. L'objectif de ce travail est double. Tout d'abord, nous visons la conception d'un conteneur de capacités logicielles qui offre une vision plus large des solutions applicatives internes ou externes d'une organisation. Le deuxième objectif est de définir un modèle d'exploitation de ces profils de capacités logicielles en adéquation avec l'ingénierie des besoins et l'architecture d'entreprise, afin de combler l'écart entre les objectifs des parties prenantes et ce qui peut être fourni comme solution pratique. Cependant, pour atteindre les objectifs susmentionnés, il y a de nombreux défis à relever pour gérer la complexité de l'exploitation des profils de capacités logicielles internes ou externes, afin de sélectionner les meilleurs composants candidats pour servir d'éléments constitutifs dans un nouveau système. Parmi ces défis, on peut citer l'identification des connaissances architecturales pour l'évaluation et la réutilisation des composants techniques, ou l'alignement des besoins et des artefacts d'architecture dans un cycle d'ingénierie pour la consolidation et le raffinement des exigences, afin de faciliter la découverte et la réutilisation des solutions applicatives existantes. A cet effet, nous définissons un Framework offrant un processus de qualification qui permet de recueillir les exigences initiales utilisées pour guider le développement des applications existantes et des services techniques exposés. Le processus de qualification est4basé sur un profil de capacité d'architecture d'entreprise proposé et de son ontologie associée. Cette dernière est utile pour spécifier formellement le profil de capacité produit qui offre une qualification couvrant les aspects organisationnels, opérationnels et techniques des applications orientées services. De plus, une méthodologie d'exploitation du conteneur conçu pour agréger ces profiles est proposée avec le Framework et basée sur l'alignement du processus d'ingénierie des besoins avec une méthode de développement d'architecture. Ces derniers évoluent ensemble pour étudier la plus grande compatibilité fonctionnelle et technique des fonctionnalités souhaitées et des contraintes associées, pour répondre aux besoins des utilisateurs finaux et réutiliser efficacement les solutions qualifiées.Notre contribution vise à améliorer l'évaluation, la découverte et la réutilisation des applications et des services techniques associés. Par ailleurs, l'originalité de ce travail de recherche consiste à mettre à niveau la recherche sur la consommation et l'orchestration des services au niveau des besoins des utilisateurs finaux, afin d'accélérer et de faciliter le développement d'applications métier futures. Une implémentation du Framework ainsi qu'une étude de cas industriels sont proposés pour valider et démontrer l'efficacité de cette approche
Most of today's software development projects depend on the usage of existing solutions to save time and development cost. To achieve this goal, companies should take advantage of the features provided by services or application programming interfaces exposed by existing solutions. Collecting and qualifying IT components and services helps to reuse them directly or via orchestration. The goal of this work is twofold. First, we target the design of a software capability container that provides a broader view of an organization’s internal and external software. The second objective is to define an exploitation model of the software capability profiles in line with requirements engineering and enterprise architecture, to fill the gap between the goals of the stakeholders and what can be delivered as a practical solution. However, to achieve the above-stated objectives, there are many challenges to manage the complexity of the exploitation of internal or external’s software capability profiles, to select the best candidate components to act as a building blocks in a new system. Among those challenges, one can mention the identification of architectural artifacts for the evaluation and reuse of software components. Adding to this challenge, the alignment of requirements and architectural artifacts in engineering cycle for requirements consolidation and refinement to facilitate the discovery and reuse of existing solutions.For this purpose, we define a Framework offering a qualification process that helps to retrieve and gather initial requirements used to guide the development of existing software and related services. The qualification process is based on a proposed Enterprise Architecture Capability Profile and its associated ontology. This latter is useful to formally specify and encode the produced capability2profile that offers a qualification and covers business, operational and technical aspects for service-oriented software. Furthermore, an exploitation methodology of the designed container is proposed along with the Framework and based on the alignment of requirements engineering process with an architecture development method. These latter evolve together to investigate the highest functional and technical compatibility of the desired functionalities and related constraints, to respond to end-user’s requirements and efficiently reuse the qualified solutions.Our contribution aims to improve the evaluation, discovery, and reuse of existing software and related services. Besides, the originality of this research work consists in upgrading research on services consumption and orchestration to the level of end-users’ requirements, mapped with advanced service assets as an enabler for accelerating business application development. An implementation of the Framework along with an industrial case study are proposed to validate and demonstrate the effectiveness of this approach

A exemplo de qualquer outra atividade que se destine a produzir um produto, a engenharia de software necessariamente passa por um fase inicial, onde necessário definir o que será produzido. A análise de requisitos é esta fase inicial, e o produto dela resultante é a especificação do sistema a ser construído. As duas atividades básicas durante a analise de requisitos são a eliciação (busca ou descoberta das características do sistema) e a modelagem. Uma especificação completa e consistente é condição indispensável para o adequado desenvolvimento de um sistema. Muitos tem sido, entretanto, os problemas enfrentados pelos analistas na execução desta tarefa. A variedade e complexidade dos requisitos, as limitações humanas e a dificuldade de comunicação entre usuários e analistas são as principais causas destas dificuldades. Ao considerarmos o ciclo de vida de um sistema de informação, verificamos que a atividade principal dos profissionais em computação é a transformação de uma determinada porção do ambiente do usuário, em um conjunto de modelos. Inicialmente, através de um modelo descritivo representamos a realidade. A partir dele derivamos um modelo das necessidades (especificação dos requisitos), transformando-o a seguir num modelo conceitual. Finalizando o ciclo de transformações, derivamos o modelo programado (software), que ira se constituir no sistema automatizado requerido. Apesar da reconhecida importância da analise dos requisitos e da conseqüente representação destes requisitos em modelos, muito pouco se havia inovado nesta área ate o final dos anos 80. Com a evolução do conceito de reutilização de software para reutilização de especificações ou reutilização de modelos de requisitos, finalmente surge não apenas um novo método, mas um novo paradigma: a reutilização sistemática (sempre que possível) de modelos integrantes de especificações de sistemas semelhantes ao que se pretende desenvolver. Muito se tem dito sobre esta nova forma de modelagem e um grande número de pesquisadores tem se dedicado a tornar mais simples e eficientes várias etapas do novo processo. Entretanto, para que a reutilização de modelos assuma seu papel como uma metodologia de use geral e de plena aceitação, resta comprovar se, de fato, ele produz software de melhor quantidade e confiabilidade, de forma mais produtiva. A pesquisa descrita neste trabalho tem por objetivo investigar um dos aspectos envolvido nesta comprovação. A experimentação viabilizou a comparação entre modelos de problemas construídos com reutilização, a partir dos modelos de problemas similares previamente construídos e postos a disposição dos analistas, e os modelos dos mesmos problemas elaborados sem nenhuma reutilização. A comparação entre os dois conjuntos de modelos permitiu concluir, nas condições propostas na pesquisa, serem os modelos construídos com reutilização mais completos e corretos do que os que foram construídos sem reutilização. A apropriação dos tempos gastos pelos analistas durante as diversas etapas da modelagem, permitiu considerações sobre o esforço necessário em cada um dos dois tipos de modelagem. 0 protocolo experimental e a estratégia definida para a pesquisa possibilitaram também que medidas pudessem ser realizadas com duas series de modelos, onde a principal diferença era o grau de similaridade entre os modelos do problema reutilizado e os modelos do problema alvo. A variação da qualidade e completude dos dois conjuntos de modelos, bem como do esforço necessário para produzi-los, evidenciou uma questão fundamental do processo: a reutilização só terá efeitos realmente produtivos se realizada apenas com aplicações integrantes de domínios específicos e bem definidos, compartilhando, em alto grau, dados e procedimentos. De acordo com as diretrizes da pesquisa, o processo de reutilização de modelos de requisitos foi investigado em duas metodologias de desenvolvimento: na metodologia estruturada a modelagem foi realizada com Diagramas de Fluxo de Dados (DFD's) e na metodologia orientada a objeto com Diagramas de Objetos. A pesquisa contou com a participação de 114 alunos/analistas, tendo sido construídos 175 conjuntos de modelos com diagramas de fluxo de dados e 23 modelos com diagramas de objeto. Sobre estas amostras foram realizadas as analises estatísticas pertinentes, buscando-se responder a um considerável número de questões existentes sobre o assunto. Os resultados finais mostram a existência de uma série de benefícios na análise de requisitos com modelagem baseada na reutilização de modelos análogos. Mas, a pesquisa em seu todo mostra, também, as restrições e cuidados necessários para que estes benefícios de fato ocorram.
System Engineering, as well as any other product oriented activity, starts by a clear definition of the product to be obtained. This initial activity is called Requirement Analysis and the resulting product consists of a system specification. The Requirement Analysis is divided in two separated phases: elicitation and modeling. An appropriate system development definition relies in a complete, and consistent system specification phase. However, many problems have been faced by system analysts in the performance of such task, as a result of requirements complexity, and diversity, human limitations, and communication gap between users and developers. If we think of a system life cycle, we'll find out that the main activity performed by software engineers consists in the generation of models corresponding to specific parts of the users environment. This modeling activity starts by a descriptive model of the portion of reality from which the requirement model is derived, resulting in the system conceptual model. The last phase of this evolving modeling activity is the software required for the system implementation. In spite of the importance of requirement analysis and modeling, very little research effort was put in these activities and none significant improvement in available methodologies were presented until the late 80s. Nevertheless, when the concepts applied in software reuse were also applied to system specification and requirements modeling, then a new paradigm was introduced, consisting in the specification of new systems based on systematic reuse of similar available system models. Research effort have been put in this new modeling technique in the aim of make it usable and reliable. However, only after this methodology is proved to produce better and reliable software in a more productive way, it would be world wide accepted by the scientific and technical community. The present work provides a critical analysis about the use of such requirement modeling technique. Experimental modeling techniques based on the reuse of similar existing models are analyzed. Systems models were developed by system analyst with similar skills, with and without reusing previously existing models. The resulting models were compared in terms of correction, consumed time in each modeling phase, effort, etc. An experimental protocol and a special strategy were defined in order to compare and to measure results obtained from the use of two different groups of models. The main difference between the two selected groups were the similarity level between the model available for reuse and the model to be developed. The diversity of resulting models in terms of quality and completeness, as well in the modeling effort, was a corroboration to the hypothesis that reuse effectiveness is related to similarity between domains, data and procedures of pre-existing models and applications being developed. In this work, the reuse of requirements models is investigated in two different methodologies: in the first one, the modeling process is based on the use of Data Flow Diagrams, as in the structured methodology; in the second methodology, based on Object Orientation, Object Diagrams are used for modeling purposes. The research was achieved with the cooperation of 114 students/analysts, resulting in 175 series of Data Flow Diagrams and 23 series of Object Diagrams. Proper statistical analysis were conducted with these samples, in order to clarify questions about requirements reuse. According to the final results, modeling techniques based on the reuse of analogous models provide an improvement in requirement analysis, without disregarding restrictions resulting from differences in domain, data and procedures.

A Modelagem Orientada a Objetos (MOO) é o processo de construção de modelos de sistemas através da identificação e definição de um conjunto de objetos relacionados, que comportam-se e colaboram entre si conforme os requisitos estabelecidos para o sistema. Esta definição inclui os três aspectos ortogonais, ou dimensões, deste tipo de modelagem: a dimensão estrutural dos objetos, a dimensão dinâmica do comportamento e a dimensão funcional dos requisitos. Conforme a importância relativa dada a cada uma destas dimensões, podem ser definidas três estratégias possíveis para conduzir a MOO. Estas estratégias são as dirigidas por dados, por comportamento e por processos. A estratégia dirigida por processos já esta superada. Atualmente, a estratégia dirigida por dados domina na maioria das técnicas de MOO. A estratégia dirigida por comportamento propõe que a estrutura dos objetos em um sistema pode ser determinada a partir do comportamento externo e interno que o sistema deve apresentar. Esta idéia é interessante, porque permite introduzir tardiamente o encapsulamento na MOO. Conforme é argumentado neste trabalho, as vantagens atribuídas a orientação a objetos são de implementação, isto é, a decisão de orientar ou não a objetos é, na realidade, uma decisão de design. Ao introduzir o encapsulamento na modelagem inicial do sistema, ganha-se o benefício da continuidade estrutural ao custo de colocar a MOO mais perto do design. Neste contexto, este trabalho apresenta um processo de modelagem conceitual de sistemas do ponto de vista comportamental que introduz tardiamente o encapsulamento da orientação a objetos como primeiro passo de design. Em outras palavras, é proposta uma técnica de modelagem sob uma estratégia dirigida por comportamento (privilegiando, assim, o aspecto dinâmico dos sistemas) com o suficiente poder de expressão para, ao mesmo tempo, permitir a modelagem de sistemas de informação no nível conceitual e derivar dos modelos dinâmicos obtidos uma representação estrutural orientada a objetos. 0 sistema, na concepção desta proposta, é composto por um conjunto de processos concorrentes, cada um dos quais recebe um estimulo do ambiente, realiza um tratamento especifico sobre ele e gera para o ambiente uma resposta. Os estímulos externos são decompostos em conjuntos de eventos concorrentes tratados no interior do processo. As ações realizadas no interior do mesmo são compostas nas respostas geradas para o exterior. Os processos são modelados comportamentalmente, utilizando o formalismo proposto High-Level Statecharts (HLS). HLS é uma extensão dos statecharts de Harel. As principais extensões propostas são a introdução de estados "parametrizados" usando variáveis e a representação genérica de conjuntos de estados concorrentes e exclusivos. 0 modelo de processos e desintegrado em unidades de comportamento que tratam das mesmas variáveis. Estas unidades são integradas em um modelo de ciclos de vida para estas variáveis. Finalmente, apos a aplicação da técnica de modelagem conceitual, e obtido um modelo estrutural orientado a objetos. Este modelo e derivado utilizando unicamente informações contidas nos modelos dinâmicos gerados no processo da técnica proposta. No modelo estrutural são identificadas classes, objetos, atributos, associações estáticas, hierarquias de herança e operações. Todo o processo e exemplificado utilizando o problema padrão de preparação de congressos da IFIP.
Object-Oriented Modeling (OOM) is the process of construction of systems models, through an identification and definition of a set of relating objects. These objects have a collaborative behavior according to the system requirements previously defined. This definition includes three modeling aspects or dimensions: object structural dimension, behavior dynamic dimension and requirements functional dimension. Depending on a relative importance of each dimension, three possible strategies to drive OOM are defined. The strategies are: data-driven, behavior-driven and process-driven. Process-driven strategy is obsolete. Nowadays, data-driven is the dominant strategy in the world of OOM techniques. Behavior-driven strategy suggests both internal and external system behaviors define its object structure. This idea is attractive because it allows a late encapsulation in the OOM. As explained in this work, the main advantage to use object-orientation is for implementation. So, to object-orient or not to object-orient is a design decision. If encapsulation is introduced in the very beginning of systems modeling, the structural continuity is achieved at the cost of pulling OOM closer to design. In this context, the work presents a process of systems conceptual modeling using a behavioral point of view. This process introduces object-oriented encapsulation lately as a first step in the design phase. In other words, this work is a proposal of a modeling technique under a behavior-driven strategy (focusing the dynamic aspect of the systems) with enough expression power to model information systems at conceptual level and, at the same time, to derive of an object-oriented structural representation from the dynamic models. As conceived in the proposal, a system is composed by a set of concurrent processes. Each process receives a stimuli from the environment, makes a specific treatment on it and generates a response to the environment. The external stimuli is decomposed into a set of concurrent events which are internally handled by the process. Actions internally performed by the process are composed into a response which is sent outside the process. Processes are behaviorally modeled using a proposed formalism called High-Level Statecharts (HLS). HLS is a extension of Harel's statecharts. The main extensions proposed are parameterized states using variables and generic representation of concurrent and exclusive sets of states. Process model is disintegrated into behavior units handling the same variables. The units are integrated into a life cycle model for these variables. Finally, after the modeling technique has been applied, an object-oriented structural model is obtained. This model is derived exclusively using information from the dynamic models constructed during the modeling process. Classes, objects, attributes, static associations, inheritance hierarchies and operations in the structural model are identified. Examples used in all the modeling process are taken from the standard problem of IFIP conference.

The derivation of a specification document that is understandable, precise and unambiguous is indispensable to successful software development. This work investigates the advantages and disadvantages of four different specification approaches which vary in their degree of formality. The thesis outlines qualities of a good specification. An example requirements specification of a case study system is produced using each technique. The four specification approaches are ad hoc natural language approach (informal), threadsbased technique (structured informal), Computer-Aided Software Engineering (CASE) methodology Structured Analysis (semi-formal), and the mathematical notation Z (formal). The specification techniques are compared based on their likelihood to produce a specification document which is useful to customers, design engineers, test engineers, and maintenance personnel. The main conclusion is that using techniques that provide both a high degree of guidance and process description for deriving the specification is critical to achieve high quality specifications. Hence, a good specification technique must inherently have guidelines that facilitate the specification of requirements in an understandable, precise and unambiguous manner.

The growing need for computer software in different sectors of activity, (health, agriculture, industries, education, aeronautic, science and telecommunication) together with the increasing reliance of the society as a whole on information technology, is placing a heavy and fast growing demand on complex and high quality software systems. In this regard, the anticipation has been on non-functional requirements (NFRs) engineering and formal methods. Despite their common objective, these techniques have in most cases evolved separately. NFRs engineering proceeds firstly, by deriving measures to evaluate the quality of the constructed software (product-oriented approach), and secondarily by improving the engineering process (process-oriented approach). With the ability to combine the analysis of both functional and non-functional requirements, Goal-Oriented Requirements Engineering (GORE) approaches have become de facto leading requirements engineering methods. They propose through refinement/operationalisation, means to satisfy NFRs encoded in softgoals at an early phase of software development. On the other side, formal methods have kept, so far, their promise to eliminate errors in software artefacts to produce high quality software products and are therefore particularly solicited for safety and mission critical systems for which a single error may cause great loss including human life. This thesis introduces the concept of Complementary Non-functional action (CNF-action) to extend the analysis and development of NFRs beyond the traditional goals/softgoals analysis, based on refinement/operationalisation, and to propagate the influence of NFRs to other software construction phases. Mechanisms are also developed to integrate the formal technique Z/Object-Z into the standardised User Requirements Notation (URN) to formalise GRL models describing functional and non-functional requirements, to propagate CNF-actions of the formalised NFRs to UCMs maps, to facilitate URN construction process and the quality of URN models.
School of Computing
D. Phil (Computer Science)

Automating test processes is becoming more and more up-to-date and one of the reasons is that manual tests are time-consuming and complicated. The aim of the study is to identify the manual test process in integration systems to see if there can be a value in automating them and which requirements can then form the basis of an automation. Pros and cons of both manual and automated tests are highlighted in the study in order to make a fair comparison between them. The advantages of the automation that has been highlighted have since, together with collected empirical data at the company Pulsen Integration, been used to produce a requirement list for automation. The study addresses whether it is worth automating all processes or whether some of the test activities work better as manual. By looking at Pulsen Integration's testing processes, one could see that some flexible processes are better as manual, while more general activities can be more easily automated. The study has had a qualitative approach and the chosen respondents from Pulsen Integration contributed with information to be able to produce a relevant list of requirements. We believe that the result presented can be generalized to companies in similar context.

Este trabajo de tesis presenta lineamientos específicos para la aplicación de Ingeniería de Requerimientos Web al tratamiento de los RNF. Presenta procesos de Elicitación y Especificación de RNF Web y ofrece las plantillas diseñadas particularmente para la captura y especificación de los RNF en los procesos definidos. Si bien actualmente la Ingeniería de Requerimientos proporciona numerosas técnicas y herramientas para identificar, describir, validar y gestionar requerimientos, estos no son aplicados muy a menudo, en el desarrollo de aplicaciones Web. La madurez del proceso de ingeniería de requerimientos parece ser insuficiente, esa insuficiencia demanda nuevos enfoques o evolución de los actuales para el tratamiento adecuado de los RNF. Los RNF de los sistemas software no son un todo homogéneo, hay falta de consenso para responder a los interrogantes: ¿Qué son? ¿Cómo se clasifican dentro del contexto de desarrollo de software? y ¿Cómo se clasifican en el desarrollo de aplicaciones Web? Este trabajo parte de una revisión del estado de arte de los conceptos de RNF en la literatura de la Ingeniería de Requerimientos y establece como bases conceptuales que los RNF son requerimientos de calidad y son restricciones. Luego ofrece un análisis comparativo de seis enfoques existentes de desarrollo de aplicaciones Web para estudiar qué tratamiento aplican a los RNF, en el cual se pudo determinar que las metodologías de aplicaciones Web estudiadas: Contemplan los RNF, aunque se carece de consenso en su significado. No disponen de técnicas específicas para la elicitación de RNF, ni lineamientos uniformes para la especificación y la validación. No brindan técnicas que soporten el tratamiento de los RNF a lo largo del ciclo de vida. Hay carencia de consenso para establecer en qué fase del ciclo de vida de desarrollo se identifican los RNF. Hay RNF que no son identificados durante la fase de relevamiento y análisis. A partir de este análisis y dada la importancia de los RNF, se proponen procesos para la elicitación y especificación de los RNF Web (de calidad y restricciones), se describen las plantillas propuestas que dan soporte a los procesos y finalmente se presenta la validación de los conceptos y técnicas propuestos mediante un caso de estudio en un proyecto real.
This thesis introduces specifics guidelines to apply Web Requirements Engineering to the treatment of Non-Functional Requirements. It introduces the process of Elicitation and Specification for Web Non-Functional Requirements and offers spreadsheets designed to capture and specify Non-Functional Requirements in the defined processes. While at present Requirement Engineering has numerous techniques and tools to identify, describe, validate and manage requirements, these are not frequently applied in the development of Web applications. The maturity of the Requirements Engineering process seems insufficient; this insufficiency demands new approaches or the evolution of current process to the correct treatment of Non-Functional Requirements. Non-Functional Requirements of software systems are not homogenous; there is a lack of consensus to answer the following questions: What are Non-Functional Requirements? How they are classified within the context of software development? and How the Non-Functional Requirements are classified within the development of web software application? This thesis starts with a revision of the state of art of the concept of Non-Functional Requirements in Requirements Engineering literature and establishes as conceptual foundations that Non-Functional Requirements are quality requirements and restrictions. Then, there is a comparative analysis of six different existing approaches in Web application development to study what treatment applies to Non-Functional Requirements, in which methodologies of the Web applications studied: Non-Functional Requirements are considered, but there is no consensus in their meaning. There are neither specifics techniques for elicitation of Non-Functional Requirements nor uniform guidelines for the specification and validation. There are no techniques supporting the treatment of the Non-Functional Requirements along the lifetime cycle. There is a lack of consensus to establish within which phase of development lifetime cycle Non-Functional Requirements are identified. There are Non-Functional Requirements that are not indentified during requirement capture and analysis phases. After this analysis and the give importance of the Non-Functional Requirements, a process for the elicitation and specification of the Web Non-Functional Requirements (quality and restrictions) is proposed, exposed spreadsheets are described to support processes and finally, validations of the concepts and techniques are introduced applied to a real project.

Dissertação de mestrado integrado em Engenharia e Gestão de Sistemas de Informação
O facto de vivermos num mundo cada vez mais informatizado e em que os sistemas informáticos já fazem parte do quotidiano das pessoas e das organizações levou a que os sistemas informáticos se tornassem cada vez maiores e mais complexos. Para se construir um sistema que dê resposta ao pretendido e que tenha qualidade, existe um processo de desenvolvimento que deve ser seguido. Durante o processo de desenvolvimento de software existem várias etapas pelas quais se tem de passar, uma dessas etapas é a de testes. Sendo a etapa de testes uma das mais “caras” em termos de recursos e tempo no processo de desenvolvimento de software, a automatização de processos que compõem esta área tornou-se um dos principais desafios e interesses para as organizações. Assim, nasceu a necessidade de se construir uma ferramenta que a partir dos requisitos especificados para um projeto de software conseguir-se identificar quais os casos de teste de uma forma automática, garantindo, não só, uma maior rapidez mas também uma maior qualidade no processo de identificação de casos de teste. O que consequentemente faz com que seja desenvolvido um produto de melhor qualidade. Deste modo, o tema abordado neste documento baseia-se no desenvolvimento de uma solução para um problema numa organização real. O facto da solução abordada neste documento ser realizada para uma organização real, faz com que existam processos e abordagens utilizadas na organização com as quais se tem de trabalhar. Uma das abordagens utilizadas na organização e consequentemente utilizadas para a criação da solução descrita neste documento é o conceito de DSL (Domain-Specific Languages), que são linguagens criadas para um domínio especifico e as quais são utilizadas nesta solução para a especificação dos casos de teste. Este trabalho apresenta uma contribuição para a área de testes de software, com a aplicação de uma solução que permita a identificação de casos de teste de uma forma automática a partir de requisitos especificados para um determinado projeto.
The fact that we live in a world increasingly computerized and the computer systems that are already part of everyday life of people and organizations that led to the computer systems become increasingly larger and more complex. To build a system that is responsive and has the desired quality, there is a developmental process that must be followed. During the process of software development there are various stages through which it must pass one of these steps is to test. As the stage of testing one of the most "expensive" in terms of resources and time in the software development process, the automation of processes that make up this area has become a major challenge for organizations and interests. So, the need to build a tool that was born from the specified requirements for a software project get to identify which test cases in an automated manner, ensuring not only greater speed but also a higher quality process identification of test cases. What therefore causes a better quality product is developed. This way, the issue addressed in this document is based on developing a solution to a problem in a real organization. The fact that the solution discussed in this document be performed to a real organization, means that there are processes and approaches used in the organization with whom they must work. One of the approaches used in the organization and consequently used to create the solution described in this paper is the concept of DSL (Domain-Specific Languages) are languages created for a specific domain and which are used in this solution for the specification of cases test. This work presents a contribution to the field of software testing, with the application of a solution that enables the identification of cases in an automatic way from test requirements specified for a particular project.