Tese de mestrado. Ciências da Informação. Faculdade de Engenharia. Universidade do Porto. 2012

Aspect Oriented Programming has been proposed in order to handle crosscutting concerns in an ecient manner. Initial proposals in this area have been applied to the source code. Subsequently, aspects were considered to be implemented in other phases of software development such as Requirements Engineering and Software Architecture. There are several advantages in identifying aspects at the requirements level and architecture level such as detecting conicts of interest, improving the requirements modularity, reducing costs of software maintenance and preserving the notion of aspects in software development process ensuring traceability. Therefore, the purpose of this work is to develop a model to represent aspects at the requirements level and the architecture level. The requirements model denes the activities of identication of aspect requirements, both functional and non-functional, separation and composition of aspect requirements and identication of conict between aspect requirements. Since dierent stakeholders need to view the system from dierent perspectives, the architecture model allows to represent dierent views considering the representation with aspects. The proposed views are structural, use case + requirements and development. Compared to other analysed approaches, the proposed models in this work represent important characteristics that others models do not represent, such as maintaining traceability of aspects between requirements and the architecture level. In order to represent the models, extensions to the SysML modeling language were proposed. / A Programação Orientada a Aspectos foi proposta com o objetivo de manipular interesses transversais de uma maneira eciente. Propostas iniciais nesta área foram aplicadas no código fonte. Posteriormente, aspectos foram considerados para serem aplicados em outras fases do desenvolvimento de software tais como Engenharia de Requisitos e Arquitetura de Software. Há várias vantagens em identicar aspectos no nível de requisitos e no nível arquitetural, tais como detectar inicialmente conitos de interesses, melhorar a modularidade dos requisitos, reduzir custos de manutenção de software e preservar a noção de aspectos no processo de desenvolvimento de software garantindo rastreabilidade. Portanto, o propósito desse trabalho é desenvolver um modelo para representar aspectos no nível de requisitos e no nível arquitetural. O modelo de requisitos dene as atividades de identicação de requisitos aspectuais tanto de origem funcional quanto não-funcional, separação e composição de requisitos e requisitos aspectuais e identicação de conitos entre requisitos aspectuais. Uma vez que diferentes stakeholders necessitam visualizar o sistema a partir de diferentes perspectivas, o modelo de arquitetura permite representar diferentes visões considerando a representação com aspectos. As visões propostas são a estrutural, a de casos de uso + requisitos, e a de desenvolvimento. Em comparação com outras abordagens analisadas, os modelos propostos nesse trabalho cobrem importantes características que os outros modelos não cobrem, como por exemplo, manter a rastreabilidade de aspectos entre os níveis de requisitos e de arquitetura. Para representar os modelos, extensões da linguagem de modelagem SysML foram propostas. / Mestre em Ciência da Computação

Orientador: Prof. Dr. Francisco de Assis Zampirolli / Dissertação (mestrado) - Universidade Federal do ABC, Programa de Pós-Graduação em Ciência da Computação, 2014. / Métodos e Processos de Engenharia de Software têm se tornado foco de pesquisas científicas, onde a qualidade, estimativa de custos e prazos são trabalhadas como boas práticas em desenvolvimento. A construção de um produto de software envolve algumas etapas, e a mais complexa saber precisamente o que construir. A precisão nesta etapa do projeto é essencial, pois se houver falha na especificação, haverá maior prejuíz ao final doprojeto do sistema de software. A principal razão para as falhas de projeto de software é o gerenciamento inadequado dos requisitos do sistema, gerando custos elevados para serem corrigidos nas fases seguintes ao levantamento de requisitos e insatisfac~ao para todos os envolvidos. Deste modo, produzir software com qualidade é uma tarefa complexa, que demanda entender, planejar e atender, provendo soluc~oes necessárias. Este trabalho tem como objetivo, apresentar uma metodologia para o desenvolvimento de especifícação de requisitos, com uma abordagem orientada ao alinhamento entre TI e Negócio, por meio de um processo de engenharia de requisitos, [integrando diagramas de Caso de Uso como Business Process Modeling Notation (BPMN). Por meio de estudos de caso aplicados a uma empresa operadora de planos privados de assistência a saúde. A metodologia se mostrou ecaz, com melhoria de 69,68% na redução dos custos no orcamento acordado. Alem disso, este trabalho de pesquisa encontra-se em funcionamento na empresa citada,otimizando recursos e atingindo melhores resultados para a organização. / Requirement Engineering Methods and Processes have become a focus point for scientic research, in which quality, cost estimates and time frames are elaborated as good practices in development. Building a software product includes several phases, and the most complex is to know exactly what to build. Precision is essential during this phase of the project, because if the specication fails, there will be greater loss at the end of the software system project. The main reason for software project failures is inept management of system requirements, generating high costs that have to be corrected in the phases following requirement survey, and creating dissatisfaction for all those involved. Thus, producing quality software is a complex task, which demands understanding, planning, and compliance to provide the necessary solutions. This paper presents a methodology for developing requirement specifications, with an approach directed towards aligning IT and Business through a requirement engineering process integrating Use Case with Business Process Modeling Notation. Through case studies presented and applied at a private health care insurance company, the methodology proved to be eective, by reducing exceeding the agreed-upon budget by 69.68%. Additionally, this study is still on-going at the abovementioned company, optimizing resources and reaching better results for the organization.

Made available in DSpace on 2016-06-02T19:05:25Z (GMT). No. of bitstreams: 1 DissKKK.pdf: 1271632 bytes, checksum: 7825f0fbdf16d2be8d537be29256ecce (MD5) Previous issue date: 2005-09-30 / This work presents Guidelines to elaborate the Requirements Document (RD) based on Functional Requirements made up of three items: i) a Template to specify the Functional Requirements, which determines a set of basic information that should compose the requirement description; ii) Writing Recommendations that offer suggestions to avoid certain defects during requirement writing and iii) a Pre-Inspection Checklist that supports a brief evaluation of the requirements to help in deciding if the RD should be submitted to an inspection. Definition of such Guidelines were based on the analysis of some requirement specification standards, some writing recommendations suggested by some authors and mainly, on the evaluation of applying PBR-User, Checklist and TUCCA (Technique for Use Case Construction and construction-based requirements Analysis) inspection techniques in three different RDs. The main objective to define these Guidelines was to facilitate the application of TUCCA, which supports the elaboration of Use Case Model (UCM) and the inspection of RD, for which a tool that has the RD as input is being developed. The case study to evaluate the proposed Guidelines consisted of the application of PBR-User, Checklist and TUCCA in three RDs and posterior application of the three techniques in these same RDs after they were modified according to the proposed Guidelines. The obtained results showed that TUCCA application was made easier when RD followed the Guidelines and there was a defect reduction in RD thus increasing the quality of this document. / Este trabalho apresenta Diretrizes para a Elaboração de Documento de Requisitos (DR) com ênfase nos Requisitos Funcionais, compostas por três itens: i) Formato para Especificação de Requisitos Funcionais, que determina um conjunto de informações básicas que deve compor a descrição do requisito; ii) Recomendação de Escrita, que oferece sugestões para que determinados defeitos sejam evitados durante a escrita do requisito e iii) Checklist Pré-Inspeção, que apóia uma sucinta avaliação dos requisitos de forma a ajudar na decisão se o DR deve ser submetido a uma inspeção. A definição dessas Diretrizes teve como base a análise de alguns padrões de especificação de requisitos, algumas recomendações de escrita sugeridas por alguns autores e, principalmente, uma avaliação da aplicação das técnicas de inspeção PBR-Usuário, Checklist e TUCCA (Technique for Use Case Construction and construction-based requirements Analysis) em três DRs diferentes. O objetivo principal de se definir essas Diretrizes foi apoiar a aplicação da TUCCA, a qual dá suporte à construção de Modelos de Casos de Uso (MCU) e à inspeção do DR, para a qual está sendo desenvolvida uma ferramenta que possui como entrada um DR. O estudo de caso para a avaliação das Diretrizes propostas consistiu da aplicação da PBR-Usuário, Checklist e TUCCA em três DRs e posterior aplicação dessas três técnicas de inspeção nesses mesmos DRs alterados de acordo com as Diretrizes propostas. O resultado obtido mostrou que a aplicação da TUCCA é bastante facilitada quando o DR segue as Diretrizes e que houve uma redução de defeitos no DR, o que contribui para a qualidade desse documento.

Made available in DSpace on 2016-06-02T19:06:05Z (GMT). No. of bitstreams: 1 5226.pdf: 3993089 bytes, checksum: a0750877fc955b7274271f1326ade7b3 (MD5) Previous issue date: 2011-08-24 / One of the benefits of Service-Oriented Architecture is to make business processes adaptable when this architecture is adopted during software development. For reaching this purpose, it is essential to have a support for services identification in order to meet the business goals. However, many available services found on web environment are too specific and can hardly be reused in different applications. This happens because there is a lack of systematic approaches for supporting generic services identification in a systematic way. Objective: Presenting a strategy for identifying generic services that support business processes. The identification is supported by Goal Diagrams and Business Process Models and is composed by a set of guidelines which assist the domain engineer in extracting the services. The identified services are generic enough to be reused in similar applications of a specific domain. Methodology: To elaborate our strategy, some domain-specific business process were analyzed, aiming at extracting key tasks and turn them into generic web services. This analysis was supported by an extended version of goal diagrams (GTR) and conventional BPM models. Results: As a proof-of-concept we applied our strategy for identifying services in the planning processes domain and we developed a real e-gov web portal based on the identified services. The web portal was used successfully by two different schools for elaborating their planning processes. Conclusion: We claim that our strategy is generic and can be applied to other business processes providing software suitability to the organization dynamics, besides the potential reuse of services in different instances of the same business process. / Um dos benefícios da Arquitetura Orientada a Serviços é tornar os processos de negócios adaptáveis quando esta arquitetura é adotada durante o desenvolvimento de software. Para atingir este propósito, é essencial ter um suporte para a identificação de serviços a fim de atender os objetivos de negócio. No entanto, muitos serviços disponíveis encontrados no ambiente web dificilmente podem ser reutilizados em diferentes aplicações. Isso acontece porque faltam abordagens sistemáticas de apoio à identificação de serviços genéricos de uma forma sistemática. Objetivo: Apresentar uma estratégia para identificar serviços genéricos que dêem suporte aos processos de negócios. A identificação é apoiada por diagramas de objetivos e modelos de processos de negócios, e é composto por um conjunto de diretrizes que auxiliam o engenheiro de domínio na extração dos serviços. Os serviços identificados são genérico o suficiente para serem reutilizados em aplicações semelhantes de um domínio específico. Metodologia: Para elaborar a nossa estratégia, um processo de negócio específico de domínio foi analisado, com o objetivo de extrair tarefas chaves deste processo e transformá-las em serviços web genéricos. Esta análise foi apoiada por uma versão estendida de diagramas de objetivos (GTR) e modelos BPM convencionais. Resultados: Como prova de conceito, aplicamos a nossa estratégia para a identificação de serviços no domínio do processo de planejamento e desenvolvemos um portal web real com base nos serviços identificados. O portal foi utilizado com sucesso por duas escolas diferentes para a elaboração de seus processos de planejamento. Conclusão: Afirmamos que nossa estratégia é genérica e pode ser aplicada a outros processos de negócios provendo a adequação do software à dinâmica organização, além do potencial de reúso de serviços em diferentes instâncias do mesmo processo de negócio.

Submitted by Clebson Anjos (clebson.leandro54@gmail.com) on 2016-02-11T19:32:02Z No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) / Made available in DSpace on 2016-02-11T19:32:02Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) Previous issue date: 2014-07-24 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / In software development process, Requirements Engineering is responsible for identifying what are the objectives of the desired product, its features, activities and constraints, based on the understanding of the scenario where this product is used and/or expected behaviors by users. To interact directly or indirectly with the people, the products and the processes impacted by them, are required to comply with the legal regulations related and found in the legal rules or laws. At the organizational level, these regulations determine how business practices should be, which will be reproduced for their products/processes. The Legal Compliance is a requirement imposed on organizations by government departments and their non-compliance may result in legal and financial problems for these organizations. It is the role of Requirements Engineering dealing with legal compliance in these scenarios. In this context, the Nòmos framework extends the i* framework to achieve legal compliance requirements of information systems and business processes. Nòmos proposes a systematic and cohesive method to achieve this goal, from the execution of activities of elicitation, modeling and negotiation of requirements and laws. However, Nòmos was designed to be used in requirements models represented in i*. Since i* is not widely used in industry, dependence on i* can hurt the adoption of Nòmos as a process to achieve legal compliance in Requirements Engineering. In this sense, this work proposes to adapt the process of Nòmos, making it less dependent on i* and more flexible to be used with other modeling languages requirements. So, was created the GenNormas, in order to guide the acquisition of legal compliance of software requirements or business processes specified in other modeling languages, in addition to i *. Finally, to illustrate the use of our approach, it has been applied in the specification of a hypothetical system, connected to the e-commerce domain, applying GenNormas in requirements specification models, such as the Business Process Modeling Notation (BPMN), in Use Case Diagram and the User Stories. / No processo de desenvolvimento de software, a Engenharia de Requisitos é responsável por identificar quais são os objetivos do produto pretendido, suas funcionalidades, atividades e restrições, a partir do entendimento do cenário onde este produto será utilizado e/ou dos comportamentos esperados por seus usuários. Por interagirem direta ou indiretamente com as pessoas, estes produtos, e os processos impactados por eles, estão obrigados a cumprirem com as regulamentações jurídicas relacionadas e encontradas nas normas jurídicas ou leis. No âmbito organizacional, estas regulamentações determinam como devem ser as práticas de negócio, que serão reproduzidas por seus produtos/processos. A conformidade legal é uma exigência imposta às organizações pelos departamentos governamentais e o seu não-cumprimento pode acarretar transtornos judiciais e financeiros às organizações. É papel da Engenharia de Requisitos lidar com a conformidade legal nestes cenários. Nesse contexto, o Framework Nòmos estende o Framework i* para alcançar a conformidade legal dos requisitos de sistemas de informação e de processos de negócio. Nòmos propõe um método sistemático e coeso para atingir este objetivo, a partir da execução de atividades de elicitação, modelagem e negociação de requisitos e leis. Porém, Nòmos foi concebido para ser usado em modelos de requisitos representados em i*. Visto que o i* não é usada amplamente na indústria, a dependência do i* pode prejudicar a adoção do Nòmos como processo para alcançar a conformidade legal na engenharia de requisitos. Neste sentido, esta dissertação propõe adaptar o processo do Nòmos, tornando-o menos dependente do i* e mais flexível para ser utilizado com outras linguagens de modelagem de requisitos. Assim, foi criado o GenNormas no intuito de guiar a obtenção da conformidade legal de requisitos de software ou de processos de negócio especificados em outras linguagens de modelagem, além do i*. Finalmente, para exemplificar a utilização da nossa abordagem, ela foi aplicada na especificação de um sistema hipotético, ligado ao domínio do comércio eletrônico, aplicando o GenNormas em modelos de especificação de requisitos, como a Notação de Modelagem para Processos de Negócio (BPMN), no Diagrama de Caso de Uso e nas Estórias de Usuário.

Submitted by Viviane Lima da Cunha (viviane@biblioteca.ufpb.br) on 2016-02-17T10:53:15Z No. of bitstreams: 1 arquivototal.pdf: 20428901 bytes, checksum: b66dc5cc2c10c67d4c70f46436440ab4 (MD5) / Made available in DSpace on 2016-02-17T10:53:15Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 20428901 bytes, checksum: b66dc5cc2c10c67d4c70f46436440ab4 (MD5) Previous issue date: 2015-06-23 / Goal Oriented Requirements Engineering approaches capture both the stakeholders’ goals and the requirements of the system-to-be, so that the latter corresponds to the stakeholders desires. Goal models can capture similarities and the variability of a Software Product Line (SPL), but they cannot describe the detailed behavior of its functionality. Due to this limitation, a process called GS2SPL (Goals and Scenarios to Software Product Lines) was defined to systematically obtain, from goal models, feature models and the specification of use case scenarios with variability described in PLUSS (Product Line Use case modeling for Systems and Software engineering). However, the variability of the SPL and the configuration knowledge are tangled an the scenarios described in PLUSS, jeopardizing the maintenance and reuse of artifacts. In order to solve this problem, it was proposed techniques to specific use case scenarios with separation of crosscutting concerns (or just, aspectual scenarios). One of these techniques is called MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms), which specifies the variability and configuration knowledge of a SPL separately, as well as it defines a process to configure the specifications of a product. Thus, this work proposes an extension of the GS2SPL to obtain, systematically, a feature model and a specification of aspectual scenarios in MSVCM, from goal models. This approach is called GAS2SPL (Goals and Aspectual Scenarios to Software Product Lines) and their activities were described using the TaRGeT (Test and Requirements Generation Tool) example. GAS2SPL approach was evaluated through a comparative study between TaRGeT and MyCourses artifacts generated by GS2SPL and GAS2SPL approaches, taking into account modularity (features scattering and tangling scenarios) and expressiveness (how detailed are the configuration knowledge). After evaluating our approach, we realize that GAS2SPL approach reduced in the features scattering and tangling in the scenarios to zero, addition to own a knowledge configuration more specific because uses less symbols for it elaborate. / Abordagens de Engenharia de Requisitos Orientadas a Objetivos capturam tanto os objetivos dos interessados ( stakeholders) como os requisitos do software a ser desenvolvido, de modo que este último corresponda ao que realmente os interessados desejam. Modelos de objetivos são capazes de capturar as similaridades e variabilidades de uma Linha de Produto de Software (LPS), mas não conseguem descrever o comportamento detalhado de suas funcionalidades. Diante dessa limitação, o processo GS2SPL (Goals and Scenarios to Software Product Lines) foi definido para obter sistematicamente, a partir de modelos de objetivos, modelos de features e especificações de cenários de casos de uso com variabilidade, descritos em PLUSS (Product Line Use case modeling for Systems and Software engineering). Entretanto, a variabilidade da LPS e o conhecimento de configuração ficam entrelaçados nos cenários descritos em PLUSS, o que prejudica a manutenção e reuso dos artefatos. A fim de solucionar esse problema, foram propostas técnicas de especificação de cenários de caso de uso com separação de interesses transversais (ou, simplesmente, cenários aspectuais). Uma destas técnicas é o MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms), que especifica a variabilidade da LPS separadamente do conhecimento de configuração e define um processo para configurar as especificações de produto. Assim, este trabalho propõe uma extensão do GS2SPL visando obter, sistematicamente, modelos de features e especificações de cenários aspectuais em MSVCM, a partir de modelos de objetivos. Esta abordagem chama-se GAS2SPL (Goals and Aspectual Scenarios to Software Product Lines) e suas atividades foram descritas utilizando o TaRGeT (Test and Requirements Generation Tool) como exemplo. A abordagem GAS2SPL foi avaliada através de um estudo comparativo entre os artefatos do TaRGeT e do MyCourses- A Course Scheduling System gerados pelas abordagens GS2SPL e GAS2SPL, levando-se em consideração a modularidade (espalhamento de features e entrelaçamento de cenários) e, a expressividade (quão detalhado é o conhecimento de configuração). Depois de realizar a avaliação, percebemos que a abordagem GAS2SPL conseguiu reduzir o espalhamento de features e o entrelaçamento de cenários para zero, além de possuir um conhecimento de configuração mais expressivo, pois utiliza menos símbolos para elaborá-lo.

Made available in DSpace on 2016-12-01T19:11:32Z (GMT). No. of bitstreams: 1 115825.pdf: 377095 bytes, checksum: 3f6965e330641919a238073a8190da6c (MD5) Previous issue date: 2013-12-16 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / More than ever organizations are linking themselves in networks, and governments, aware of what can be gained with those connections, are developing incentives to foster its development. In Florianópolis, the promulgation of the Law of Innovation defined incentives to the formation of organizational networks, called Arranjos Promotores de Inovação (API). With that, the city s first API, the API.nano, started to be developed by CERTI, which invited LabGes/ESAG/UDESC to define the API s management and governance system, containing the system s business process mapping. In this context, this thesis details the development of a stakeholders requirement engineering of ICT systems capable of supporting the collaborative activities of the API.nano s organizations based in the process mapping developed. Supported by the literature about clusters of innovation, computer-supported cooperative work and requirement engineering, the research is divided in two phases. The first one constituted in the coding of the activities of the process mapping, which allowed their classification in 11 collaborative characteristics. Afterwards, a interpretative requirement analysis of the relationships exposed by the coding ensued. As a result, 30 stakeholders requirements were elicited. These requirements can the base for the definition of a ICT systems ecology capable of satisfying the collaborative work support technological needs of the API. / Cada vez mais organizações vem se ligando em redes, e os governantes, cientes dos ganhos obtidos com estas ligações, criam incentivos para fomentar seu desenvolvimento. Em Florianópolis, a promulgação da Lei da Inovação criou incentivos para a formação de redes organizacionais chamadas pela lei de Arranjos Promotores de Inovação (API). Com isso, o primeiro API da cidade, o API.nano, começou a ser desenvolvido pela Fundação CERTI, que convidou o LabGes/ESAG/UDESC a definir o sistema de gestão e governança do API, contendo um mapeamento de processos de negócio do sistema. Neste contexto, esta dissertação detalha o desenvolvimento de uma engenharia de requisitos de stakeholder de sistemas de TIC capazes de auxiliar as atividades colaborativas das organizações do API.nano com base no mapeamento de processos desenvolvido. Fundamentada pela literatura sobre clusters de inovação, sistemas de TIC no trabalho colaborativo e engenharia de requisitos, a pesquisa se dividiu em duas etapas. A primeira consistiu numa codificação das atividades do mapeamento de processos, que permitiu a classificação das atividades em 11 características colaborativas. Em seguida, uma análise de requisitos interpretativa foi realizada nas relações expostas pela codificação. Como resultado, 30 requisitos de stakeholders foram propostos. Estes requisitos podem servir de base para a definição de uma ecologia de sistemas de TIC capaz de satisfazer as necessidades tecnológicas de suporte do trabalho colaborativo do API.

Submitted by Jean Medeiros (jeanletras@uepb.edu.br) on 2017-02-16T18:47:29Z No. of bitstreams: 1 PDF - Eliclenes Porto.pdf: 5725031 bytes, checksum: 8183ce7e099ad97e170841dfd7fd1d5c (MD5) / Approved for entry into archive by Secta BC (secta.csu.bc@uepb.edu.br) on 2017-03-07T16:47:56Z (GMT) No. of bitstreams: 1 PDF - Eliclenes Porto.pdf: 5725031 bytes, checksum: 8183ce7e099ad97e170841dfd7fd1d5c (MD5) / Made available in DSpace on 2017-03-07T16:47:56Z (GMT). No. of bitstreams: 1 PDF - Eliclenes Porto.pdf: 5725031 bytes, checksum: 8183ce7e099ad97e170841dfd7fd1d5c (MD5) Previous issue date: 2016-12-28 / Among the diseases that most concern public health is chronic kidney disease (CKD), considered the great epidemic of this millennium. CKD is neglected at the primary level of attention, since most patients are only aware of their condition in the late stages of the disease. Objective: To describe the functional requirements of a system that will assist the monitoring of chronic kidney disease in primary health care. Methods: It is a research, technological, exploratory, experimental, with a qualitative approach, based on a process of requirements engineering, which aims to specify a future system called Epidemiorim. The methodological path to achieve the objectives was divided into five stages: the first one was the identification of the functional requirements and future users of the system; The second stage corresponded to the documentation of the functional requirements elicited; The third, in the development of a document with the possible screens of the system in paper A4; In the fourth stage, there was negotiation of the requirements and implementation of a prototype; And the fifth and final step consisted in validati ng the main functional requirements of the system. The validation stage occurred after the use of the prototype by professionals of the family health teams of the municipality of Montadas-PB, who enrolled, evaluated and monitored the DRC in 99 patients. The reports generated in the prototype were still analyzed to verify the prevalence of the disease in the studied population, demonstrating that there was a second research coupled in the study being of the observational, transversal and descriptive type with a quantitative approach. Results: The documents developed by the client of the system in the first three stages were enough for the development team to implement a prototype able to both assist the Family health teams to monitor the CKD and generate repo rts with epidemiological data. The finding that the prototype was able to meet these demands occurred after the validation of 16 functional requirements in the fifth and final stage. The analysis of reports generated in the prototype showed that the prevalence of CKD in the sample was of 17.2%, and a second renal evaluation in these patients is still necessary to confirm this index. Conclusion: Based on the Epidemiorim prototype, whose requirements were based on the guidelines of the Ministry of Health regarding the management of CKD in SUS, the research objectives were reached. Thus, the Epidemiorim presented an effective partial system, either for providing the family health teams with the follow-up in their work process of the guidelines that are recommended to them by the Ministry of Health, or as a tool that will contribute to the patient Of risk to have a complete health care, or for the municipal management, that can refer this patient to the nephrologist in a timely manner and will have at his disposal epidemiological reports of the disease for the planning of health actions. / Introdução: Entre as doenças que mais preocupam a saúde pública está a doença renal crônica (DRC), considerada como a grande epidemia deste milênio. A DRC apresenta-se negligenciada no nível primário de atenção, uma vez que a maioria dos pacientes só tem conhecimento de sua condição nos estágios finais da doença. Objetivo: Descrever os requisitos funcionais de um sistema que auxiliará o monitoramento da doença renal crônica na atenção primária à saúde. Métodos: Trata-se de uma pesquisa de natureza tecnológica, exploratória, experimental, com abordagem qualitativa, fundamentada em um processo de engenharia de requisitos, que visa especificar um futuro sistema intitulado de Epidemiorim. O caminho metodológico para atingir os objetivos foi dividido em cinco etapas: a primeira, tratou-se da identificação dos requisitos funcionais e futuros usuários do sistema; a segunda etapa correspondeu a documentação dos requisitos funcionais elicitados; a terceira, no desenvolvimento de um documento com as possíveis telas do sistema em papel A4; na quarta etapa houve a negociação dos requisitos e implementação de um protótipo; e a quinta e última etapa consistiu na validação dos principais requisitos funcionais do sistema. A etapa de validação ocorreu após o uso do protótipo por profissionais das equipes de saúde da família do município de Montadas-PB, que cadastraram, avaliaram e monitoraram a DRC em 99 pacientes adscritos. Os relatórios gerados no protótipo ainda foram analisados para verificar a prevalência da doença na população estudada, demonstrando haver uma segunda pesquisa acoplada nesse trabalho, sendo do tipo observacional, transversal e descritiva com abordagem quantitativa. Resultados: Os documentos desenvolvidos pelo cliente do sistema nas três primeiras etapas foram suficientes para que a equipe de desenvolvimento implementasse um protótipo capaz, tanto de auxiliar as eSF a monitorar a DRC, quanto gerar relatórios com dados epidemiológicos da mesma. A constatação que o protótipo era capaz de atender a essas demandas ocorreu após a validação de 16 requisitos funcionais na quinta e última etapa. A análise de relatórios gerados no protótipo mostrou que a prevalência da DRC na amostra foi de 17,2%, sendo necessária ainda uma segunda avaliação renal nesses pacientes para confirmação desse índice. Conclusão: A partir do protótipo do Epidemiorim, cujos requisitos tiveram por base as diretrizes do Ministério da Saúde quanto ao manejo da DRC no SUS, os objetivos da pesquisa foram alcançados. Sendo assim, o Epidemiorim apresentou-se um sistema parcial eficaz, seja por propiciar às equipes de saúde da família o seguimento no seu processo de trabalho das diretrizes que lhes são preconizadas pelo Ministério da Saúde, seja como uma ferramenta que contribuirá para que o paciente de risco passe a ter um cuidado de saúde integral, seja para a gestão municipal, que poderá referenciar esse paciente ao nefrologista em tempo oportuno e terá a sua disposição relatórios epidemiológicos da doença para o planejamento de ações em saúde.

O avanço tecnológico recente tem atraído tanto a comunidade acadêmica quanto o mercado para a investigação de novos métodos, técnicas e linguagens formais para a área de Projeto de Engenharia. A principal motivação é o atendimento à demanda para desenvolver produtos e sistemas cada vez mais completos e que satisfaçam as necessidades do usuário final. Necessidades estas que podem estar ligadas, por exemplo, à análise e reconhecimento de objetos que compõe uma imagem pela sua textura, um processo essencial na automação de uma enorme gama de aplicações como: visão robótica, monitoração industrial, sensoriamento remoto, segurança e diagnóstico médico assistido. Em vista da relevância das inúmeras aplicações envolvidas e pelo fato do domínio de aplicação ser muito próximo do contexto do desenvolvedor, é apresentada uma proposta de um processo de design baseado no Projeto Axiomático como sendo o mais indicado para esta situação. Especificamente, se espera que no estudo de caso da análise de textura haja uma convergência mais rápida para a solução - se esta existir. No estudo de caso, se desenvolve uma nova concepção de arquitetura de rede neural artificial (RNA), auto-organizável, com a estrutura espacial bidimensional da imagem de entrada preservada, tendo a extração e reconhecimento/classificação de textura em uma única fase de aprendizado. Um novo conceito para o paradigma da competição entre os neurônios também é estabelecida. O processo é original por permitir que o desenvolvedor assuma concomitantemente o papel do cliente no projeto, e especificamente por estabelecer o processo de sistematização e estruturação do raciocínio lógico do projetista para a solução do problema a ser desenvolvido e implementado em RNA. / The recent technological advance has attracted the industry and the academic community to research and propose methods, seek for new techniques, and formal languages for engineering design in order to respond to the growing demand for sophisticated product and systems that fully satisfy customers needs. It can be associated, for instance, with an application of object recognition using texture features, essential to a variety of applications domains, such as robotic vision, industrial inspection, remote sensing, security and medical image diagnosis. Considering the importance of the large number of applications mentioned before, and due to their characteristic where both application and developer domain are very close to each other, this work aims to present a design process based on ideas extracted from axiomatic design to accelerate the development for the classical approach to texture analysis. Thus, a case study is accomplished where a new conception of neural network architecture is specially designed for the following proposal: preserving the two-dimensional spatial structure of the input image, and performing texture feature extraction and classification within the same architecture. As a result, a new mechanism for neuronal competition is also developed as specific knowledge for the domain. In fact, the process proposed has some originality because it does take into account that the developer assumes also the customers role on the project, and establishes the systematization process and structure of logical reasoning of the developer in order to develop and implement the solution in neural network domain.