Entre os fatores que geram o alto custo da rastreabilidade, está a dificuldade na criação e manutenção de relações precisas entre artefatos. Praticamente todas as metodologias existentes preocupam-se em relacionar artefatos diretamente entre si, o que dificulta o uso de processos automatizados na derivação de novos relacionamentos, bem como na manutenção dos já existentes. Com base nestas observações, o presente trabalho propõe o uso de estruturas intermediárias nos relacionamentos, chamadas de entidades, para representar os interesses tratados pelos artefatos, e derivar, automaticamente, relações complexas entre os mesmos. Este modelo foi avaliado por profissionais da indústria e apresentou-se como solução de rastreamento viável, em comparação com as tradicionais matrizes de rastreabilidade. Espera-se que este sirva como base para soluções inovadoras na área, que ainda é considerada problemática. / The difficulties in creation and maintenance of precise relationships between artifacts are the root cause of traceability high cost. VirtualIy alI existing methodologies propose solutions that relate artifacts directly among themselves, what hinders the use of automated processes to derivate new relationships, as welI as maintaining existing ones automaticalIy. Based on these observations, this work proposes the use of intermediate structures, calIed entities, to represent the interests present on traced artifacts. These entities can be used to derive, automaticalIy, complex relationships between artifacts. The proposed model was evaluated by industry professionals and was considered by them as a viable solution for traceability when compared to the traditional traceability matrices. It is believed that this model will serve as a basis for innovative research solutions in traceability, which is still considered a problematic field.

A specification of a software program, hardware component, or system, is a description of what the system is required to do without describing how it is to be done. Specifications provide the necessary details for system developers, suppliers, users and regulators to understand and agree upon the requirements of a system. It is therefore vital that specifications are clear, concise, complete, and are free of ambiguity and inconsistency. Specifications are usually expressed using a combination of informal natural language descriptions, diagrams, and formal mathematical techniques. The degree to which formal mathematics is used depends on the nature of the application and the criticality of the function being described. In industries where the cost of a system or software failure is high, such as national defence and government, banking, transport, energy, and communication, and some manufacturing industries, formal specification is recommended because it offers greater clarity and consistency, and moreover, formal specification are machine readable, allowing some automated checking to be applied. However, poorly written formal specifications can be less useful than informal specifications if they are unreadable (or not clear), or if they are overly large or complex (or not concise), making it hard to determine whether they are consistent or complete. In particular, if the system itself is large or complex, or it features multiple and diverse aspects of behaviour, it can be difficult to capture all aspects of its behaviour clearly and concisely in a monolithic formal model, or within a single formal notation. In many cases this is because the modeling approach may be particularly suited to some aspects of the system but not to others. The widely accepted solution to this problem is to use diverse modeling techniques to specify the different aspects of the system from different viewpoints. This results in a number of view specifications that taken together make up the complete specification of the system. The thesis introduces structuring mechanisms for the formal specification language Z that allow the view specifications of a system to be described, combined and reused. Specification encapsulation and parameter abstraction and application are explored along with object-oriented concepts such sub-typing and sub-classing. Two case studies, which are based on a language-based editor and a database system, are provided to illustrate how the techniques developed in this thesis may be used.

Video game development is a high-risk effort with low probability of success. The interactive nature of the resulting artifact increases production complexity, often doing so in ways that are unexpected. New methodologies are needed to address issues in this domain.<p> Video game development has two major phases: preproduction and production. During <i>preproduction</i>, the game designer and other members of the creative team create and capture a vision of the intended player experience in the game design document. The game design document tells the story and describes the game - it does not usually explicitly elaborate all of the details of the intended player experience, particularly with respect to how the player is intended to feel as the game progresses. Details of the intended experience tend to be communicated verbally, on an as-needed basis during iterations of the production effort.<p> During <i>production</i>, the software and media development teams attempt to realize the preproduction vision in a game artifact. However, the game design document is not traditionally intended to capture production-ready requirements, particularly for software development. As a result, there is a communications chasm between preproduction and production efforts that can lead to production issues such as excessive reliance on direct communication with the game designer, difficulty scoping project elements, and difficulty in determining reasonably accurate effort estimates.<p> We posit that defining and capturing the intended player experience in a manner that is influenced and informed by established requirements engineering principles and techniques will help cross the communications chasm between preproduction and production. The proposed experience requirements methodology is a novel contribution composed of:<p> <ol> <li>a model for the elements that compose experience requirements,</li> <li>a framework that provides guidance for expressing experience requirements, and</li> <li>an exemplary process for the elicitation, capture, and negotiation of experience requirements.</li> <ol><p> Experience requirements capture the designer' s intent for the user experience; they represent user experience goals for the artifact and constraints upon the implementation and are not expected to be formal in the mathematical sense. Experience requirements are evolutionary in intent - they incrementally enhance and extend existing practices in a relatively lightweight manner using language and representations that are intended to be mutually acceptable to preproduction and to production.

Although online social media have achieved spectacular success in some instances, the design of such systems remains an art. In some specialized areas, such as online deliberation systems for participatory democracy, experiences from many projects have been reported in the research literature. Designers can benefit from knowledge accumulated from these experiences. However, the knowledge is dispersed and not organized for ready access by practicing professionals. This thesis proposes a framework for structuring and codifying design knowledge from published studies to help designers make design choices that will attain design objectives.

Although online social media have achieved spectacular success in some instances, the design of such systems remains an art. In some specialized areas, such as online deliberation systems for participatory democracy, experiences from many projects have been reported in the research literature. Designers can benefit from knowledge accumulated from these experiences. However, the knowledge is dispersed and not organized for ready access by practicing professionals. This thesis proposes a framework for structuring and codifying design knowledge from published studies to help designers make design choices that will attain design objectives.

The complexity of software systems is exploding, along with their use and application in new domains. Managing this complexity has become a focal point for research in Software Engineering. One direction for research in this area is developing techniques for designing adaptive software systems that self-optimize, self-repair, self-configure and self-protect, thereby reducing maintenance costs, while improving quality of service. This thesis presents a requirements-driven approach for developing adaptive and customizable systems. Requirements goal models are used as a basis for capturing problem variability, leading to software designs that support a space of possible behaviours – all delivering the same functionality. This space can be exploited at system deployment time to customize the system on the basis of user preferences. It can also be used at runtime to support system adaptation if the current behaviour of the running system is deemed to be unsatisfactory. The contributions of the thesis include a framework for systematically generating designs from high-variability goal models. Three complementary design views are generated: configurational view (feature model), behavioural view (statecharts) and an architectural view (parameterized architecture). The framework is also applied to the field of business process management for intuitive high-level process customization. In addition, the thesis proposes a modeling framework for capturing domain variability through contexts and applies it to goal models. A single goal model is used to capture requirements variations in different contexts. Models for particular contexts can then be automatically generated from this global requirements model. As well, the thesis proposes a new class of requirements-about-requirements called awareness requirements. Awareness requirements are naturally operationalized through feedback controllers – the core mechanisms of every adaptive system. The thesis presents an approach for systematically designing monitoring, analysis/diagnosis, and compensation components of a feedback controller, given a set of awareness requirements. Situations requiring adaptation are explicitly captured using contexts.

The complexity of software systems is exploding, along with their use and application in new domains. Managing this complexity has become a focal point for research in Software Engineering. One direction for research in this area is developing techniques for designing adaptive software systems that self-optimize, self-repair, self-configure and self-protect, thereby reducing maintenance costs, while improving quality of service. This thesis presents a requirements-driven approach for developing adaptive and customizable systems. Requirements goal models are used as a basis for capturing problem variability, leading to software designs that support a space of possible behaviours – all delivering the same functionality. This space can be exploited at system deployment time to customize the system on the basis of user preferences. It can also be used at runtime to support system adaptation if the current behaviour of the running system is deemed to be unsatisfactory. The contributions of the thesis include a framework for systematically generating designs from high-variability goal models. Three complementary design views are generated: configurational view (feature model), behavioural view (statecharts) and an architectural view (parameterized architecture). The framework is also applied to the field of business process management for intuitive high-level process customization. In addition, the thesis proposes a modeling framework for capturing domain variability through contexts and applies it to goal models. A single goal model is used to capture requirements variations in different contexts. Models for particular contexts can then be automatically generated from this global requirements model. As well, the thesis proposes a new class of requirements-about-requirements called awareness requirements. Awareness requirements are naturally operationalized through feedback controllers – the core mechanisms of every adaptive system. The thesis presents an approach for systematically designing monitoring, analysis/diagnosis, and compensation components of a feedback controller, given a set of awareness requirements. Situations requiring adaptation are explicitly captured using contexts.

The main goal of any object-oriented analysis (OOA) method is to produce a model that aids in understanding and communicating knowledge about a modeled domain. A higher degree of similarity among independently produced domain models provides an indication of how well the domain was understood by the different analysts, i. e. , more similar models indicate a closer and a more common understanding of a domain. A common understanding is of critical importance for effective knowledge communication and sharing. <br /><br /> The core of any OOA method is discovering and understanding concepts and their relationships in a domain. The main artifact produced by an OOA method is a domain model of the domain. A domain model often serves as the main source of design concepts during objectoriented design (OOD). This thesis evaluates two OOA methods by comparing the degree of similarity of the resulting domain models. <br /><br /> In particular, this work compares the semantic similarity of domain models extracted from use cases by <ol> <li>specification of sequence diagrams and then domain models, and </li> <li>specification of unified use case statecharts and then domain models. </li> </ol> The thesis makes case studies out of the application of the first method to 31 instances of large Voice-over-IP (VoIP) system and its information management system (IMS) and to 3 small elevator systems, and out of the application of the second method to 46 instances of the same large VoIP system and its IMS and to 12 instances of a medium-sized elevator system. <br /><br /> From an analysis of data from these case studies, the thesis concludes that there is an increase of 10% in the semantic similarity of domain models produced using the second method, but at the cost of less than or equal to 25% more analysis time.

The main goal of any object-oriented analysis (OOA) method is to produce a model that aids in understanding and communicating knowledge about a modeled domain. A higher degree of similarity among independently produced domain models provides an indication of how well the domain was understood by the different analysts, i. e. , more similar models indicate a closer and a more common understanding of a domain. A common understanding is of critical importance for effective knowledge communication and sharing. <br /><br /> The core of any OOA method is discovering and understanding concepts and their relationships in a domain. The main artifact produced by an OOA method is a domain model of the domain. A domain model often serves as the main source of design concepts during objectoriented design (OOD). This thesis evaluates two OOA methods by comparing the degree of similarity of the resulting domain models. <br /><br /> In particular, this work compares the semantic similarity of domain models extracted from use cases by <ol> <li>specification of sequence diagrams and then domain models, and </li> <li>specification of unified use case statecharts and then domain models. </li> </ol> The thesis makes case studies out of the application of the first method to 31 instances of large Voice-over-IP (VoIP) system and its information management system (IMS) and to 3 small elevator systems, and out of the application of the second method to 46 instances of the same large VoIP system and its IMS and to 12 instances of a medium-sized elevator system. <br /><br /> From an analysis of data from these case studies, the thesis concludes that there is an increase of 10% in the semantic similarity of domain models produced using the second method, but at the cost of less than or equal to 25% more analysis time.

Video game development is a high-risk effort with low probability of success. The interactive nature of the resulting artifact increases production complexity, often doing so in ways that are unexpected. New methodologies are needed to address issues in this domain.<p> Video game development has two major phases: preproduction and production. During <i>preproduction</i>, the game designer and other members of the creative team create and capture a vision of the intended player experience in the game design document. The game design document tells the story and describes the game - it does not usually explicitly elaborate all of the details of the intended player experience, particularly with respect to how the player is intended to feel as the game progresses. Details of the intended experience tend to be communicated verbally, on an as-needed basis during iterations of the production effort.<p> During <i>production</i>, the software and media development teams attempt to realize the preproduction vision in a game artifact. However, the game design document is not traditionally intended to capture production-ready requirements, particularly for software development. As a result, there is a communications chasm between preproduction and production efforts that can lead to production issues such as excessive reliance on direct communication with the game designer, difficulty scoping project elements, and difficulty in determining reasonably accurate effort estimates.<p> We posit that defining and capturing the intended player experience in a manner that is influenced and informed by established requirements engineering principles and techniques will help cross the communications chasm between preproduction and production. The proposed experience requirements methodology is a novel contribution composed of:<p> <ol> <li>a model for the elements that compose experience requirements,</li> <li>a framework that provides guidance for expressing experience requirements, and</li> <li>an exemplary process for the elicitation, capture, and negotiation of experience requirements.</li> <ol><p> Experience requirements capture the designer' s intent for the user experience; they represent user experience goals for the artifact and constraints upon the implementation and are not expected to be formal in the mathematical sense. Experience requirements are evolutionary in intent - they incrementally enhance and extend existing practices in a relatively lightweight manner using language and representations that are intended to be mutually acceptable to preproduction and to production.