APS UNIP - Aplicação de Engenharia de Requisitos em um Projeto de Software

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP
Instituto de Ciência e Tecnologia - ICET 
Curso de Sistemas de Informação 
Campus Tatuapé 
Aplicação de Engenharia de Requisitos em um projeto de Software
	
SÃO PAULO
2020
Sumário
Objetivo	3
Introdução	4
Conceitos Gerais	5
Requisitos de Software	5
Elicitação de requisitos	6
Análise e Negociação de requisitos	7
Especificação	8
Especificações de Requisitos	8
Modelagem de Sistema	10
Validação	10
Gestão	12
Descrição das Atividades	14
Elicitação	14
Análise e Negociação	15
Especificação	16
Modelagem	17
Diagrama de Caso de Uso	17
Produto	17
Financeiro	17
Serviço	18
Gestão Geral	18
Diagrama de Classe	19
Diagrama de Sequência	20
Validação	23
Gestão	24
Conclusão	25
Bibliografia	26
Anexos	27
Objetivo
Utilizar os conceitos e técnicas da Engenharia de Requisitos para concepção de um documento de requisitos e serviços do sistema, ajudando a entender as necessidades do negócio. 
Introdução
Este documento está dividido em conceitos de requisitos de software e engenharia de requisitos, aprofundando-se nos processos internos da engenharia de requisitos, utilizando seus conceitos é feito um estudo que visa os aplicar em um projeto de planejamento do desenvolvimento de um sistema para melhoria dos processos de uma ONG. Dando uma visão de como foram feitos os processos para chegar ao resultado.
Conceitos Gerais
Requisitos de Software
Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços oferecem e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar ou encontrar informações. (SOMMERVILLE, 2011)
Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir seus objetivos. (PFLEEGER, 2004)
Requisitos de software são sentenças que expressam as necessidades dos clientes e que condicionam a qualidade do software, ou especificações de serviços que o sistema deve prover, restrições no sistema e conhecimentos necessários para desenvolvê-lo. (NARDI e FALBO, 2006)
Portanto, requisito de software pode ser definido como as características, funções, e restrições necessárias para o desenvolvimento e/ou funcionamento de um software.
Engenharia de Requisitos
O processo de descobrir, analisar, documentar esses serviços e restrições é chamado de engenharia de requisitos. (SOMMERVILLE, 2011)
A engenharia de requisitos pode ser definida como uma disciplina da Engenharia de Software que consiste no uso sistemático e repetitivo de técnicas para descobrir atividades de obtenção e manutenção de um conjunto de requisitos de software que atendam aos objetivos do negócio e sejam de qualidade. (VASQUEZ e SIMÕES, 2016)
A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja analisar as necessidades, avaliar a exequibilidade, negociar uma solução razoável, especificar a solução de maneira não-ambígua, validar a especificação e administrar os requisitos à medida que eles são transformados num sistema em operação. O processo de engenharia de requisitos pode ser descrito em seis passos distintos (NOGUEIRA, 2010): 
· Elicitação de requisitos;
· Análise e negociação de requisitos;
· Especificação de requisitos;
· Modelagem de sistema;
· Validação de requisitos;
· Gestão de requisitos.
Portanto, pode-se concluir que a engenharia de requisitos como um processo dentro da engenharia de software que engloba todas as atividades que auxiliam na concepção e manutenção de um documento de requisitos do sistema.
Elicitação de requisitos
É o processo de derivação dos requisitos do sistema por meio da observação dos sistemas existente, além de discussões com os potenciais usuários e compradores, análise de tarefas entre outras etapas. Essa parte do processo pode envolver o desenvolvimento de um ou mais modelos de sistemas e protótipos, os quais nos ajudam a entender o sistema a ser especificado (SOMMERVILLE, 2011).
Pressman (2003), define alguns problemas que ajudam a entender as dificuldades da Elicitação de requisitos: 
· Problemas de Escopo: O limite do sistema é mal definido, com detalhes técnicos desnecessários que podem confundir os objetivos globais do sistema.
· Problemas de Entendimento: Os clientes não têm completa certeza do que é necessário, tem pouca compreensão das capacidades e limitações de seu ambiente computacional e tem dificuldade de se comunicar com os engenheiros, omitindo informações que consideram obvias, especificando requisitos que são ambíguos ou impossíveis de testar. 
· Problemas de volatilidade, em que os requisitos mudam ao longo do tempo.
É a primeira etapa a ser contemplada pela engenharia de requisitos, muito embora pareça simples, não o é, uma vez que engloba variáveis importantes, como o que precisa ser conseguido, como o sistema ou o produto se encaixa nas necessidades do negócio e como o produto vai ser usado no dia-a-dia. (NOGUEIRA, 2003)
É um processo de observar e discutir com o interessado serviço em relevância sobre as funções, etapas ou tarefas a serem desenvolvidas, pode-se usar projetos ou serviços anteriores como base para ajudar no entendimento e busca pelo que foi solicitado. É a primeira etapa a ser realizada, ainda que pareça simples, engana-se, pois exige atenção a variações importante para atendimento dos requisitos em busca da qualidade.
Análise e Negociação de requisitos
Uma vez reunidos os requisitos, os produtos de trabalho formam a base para a análise de requisitos. A análise categoriza os requisitos e os organiza em subconjuntos relacionados; explora cada um em relação aos demais; examina-os quanto à consistência, omissões e ambiguidade; e ordena-os com base nas necessidades dos clientes / usuário (PRESSMAN, 2003).
À medida que à medida que a análise de requisitos começa, as seguintes perguntas são formuladas e respondidas:  Cada requisito está consistente com o objetivo global do sistema/produto?  Todos os requisitos foram especificados no nível de abstração adequado?  O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema?  Cada requisito é limitado e não-ambíguo?  Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito?  Algum requisito conflita com outros requisitos?  Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou o produto?  Cada requisito pode ser testado, quando estiver implementado? Cada requisito está consistente com o objetivo global do sistema/produto? 
Todos os requisitos foram especificados no nível de abstração adequado? 
O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema? 
Cada requisito é limitado e não-ambíguo? 
Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito? 
Algum requisito conflita com outros requisitos? 
Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou o produto? 
Cada requisito pode ser testado, quando estiver implementado? 
Cada requisito está consistente com o objetivo global do sistema/produto? 
Todos os requisitos foram especificados no nível de abstração adequado? 
O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema? 
Cada requisito é limitado e não-ambíguo? 
Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito? 
Algum requisito conflita com outros requisitos? 
Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou o produto? 
Cada requisito pode ser testado, quando estiver implementado? 
Cada requisito está consistente com o objetivo global do sistema/produto? 
Todos os requisitos foram especificados no nível de abstração adequado? 
O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema? 
Cada requisito é limitado e não-ambíguo? 
Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito? 
Algum requisito conflita com outros requisitos? 
Cada requisitoé realizável no ambiente técnico que vai alojar o sistema ou o produto? 
Cada requisito pode ser testado, quando estiver implementado? 
Segundo Nogueira (NOGUEIRA, 2003), à medida que a análise de requisitos começa, as seguintes perguntas são formuladas e respondidas:
· Cada requisito está consistente com o objetivo global do sistema/produto?
· Todos os requisitos foram especificados no nível de abstração adequado?
· O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema?
· Cada requisito é limitado e não-ambíguo?
· Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito?
· Algum requisito conflita com outros requisitos?
· Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou o produto?
· Cada requisito pode ser testado, quando estiver implementado?
O engenheiro de sistemas precisa reconciliar esses conflitos por intermédio de um processo de negociação. Os riscos associados a cada requisito são identificados e analisados. Estimativas grosseiras do esforço de desenvolvimento são feitas e usadas para avaliar o impacto de cada requisito no custo do projeto e no prazo de entrega. Usando uma abordagem iterativa, requisitos são eliminados, combinados ou modificados de modo que cada parte alcance algum grau de satisfação (NOGUEIRA, 2003).
Essa é uma fase em que os requisitos que foram definidos serão categorizados e organizados, explorados e examinados a fim de testar suas consistências e verificar se há ambiguidade. Esses passos são um auxílio para o engenheiro de software que realiza eliminação de requisitos modificados de maneira que as partes possam alcançar a satisfação esperada.
Especificação
A especificação é a descrição sistemática e abstrata do que o software deve fazer a partir daquilo que foi analisado anteriormente. Ela apresenta a solução de como os problemas levantados na análise devem ser resolvidos pelo software em desenvolvimento. A especificação é a forma de comunicação direta entre o analista e a equipe de desenvolvimento do software (TONSIG, 2008).
Especificações de Requisitos
	
A especificação de requisitos deve esclarecer aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento. Esses clientes devem ser capazes de compreender a mensagem e fornecer feedback sobre eventuais falhas na especificação, para que estas sejam corrigidas de imediato, antes que trabalho errado seja produzido mais tarde no projeto. O objetivo é que os clientes aprovem de forma consciente a especificação para que o projeto possa seguir com menos riscos de entregar um produto que não os satisfaça. Logo, o objetivo principal da especificação é documentar de forma fiel e completa todas as necessidades dos clientes e obter um aceite (aprovação) sobre o que se está propondo entregar em termos de produto. Além disso, a especificação tem por objetivo permitir que a equipe de desenvolvimento consiga compreender exatamente o que os clientes desejam. Ela é, portanto, um importante instrumento de comunicação entre clientes e equipe de desenvolvimento. Frequentemente, a especificação de requisitos não é um único documento, mas uma composição de vários tipos de documentos. Sejam apresentados como partes da especificação ou como documentos em separado, é comum que uma especificação de requisitos abranja: 
· Visão geral: cita os objetivos do projeto, principais partes interessadas, um escopo preliminar com uma breve descrição das funções que o sistema deverá desempenhar (exemplo: documento de visão). 
· Glossário: definição dos termos técnicos (do negócio), sinônimos e acrônimos (siglas) usados ao longo do documento.
· Modelos do sistema: mostram o relacionamento entre os componentes do sistema e entre o sistema e seu ambiente (exemplos: diagrama de contexto, diagrama de caso de uso, modelo de processo etc.). 
· Lista de requisitos funcionais: descreve tarefas e serviços que serão fornecidos pelo sistema aos seus usuários (exemplo: lista de casos de uso, histórias do usuário). Inclui também as interfaces externas do software. 
· Lista de requisitos não funcionais: descreve as restrições impostas sobre o software e as relaciona aos requisitos funcionais.
· Especificação detalhada de requisitos: detalha os requisitos funcionais (por exemplo, especificações de caso de uso, regras de negócio). 
Quando se trabalha com metodologias ágeis, uma construção que agrega especificações de requisitos na forma de histórias do usuário é o Product Backlog. Ele representa um estoque de requisitos especificados como histórias do usuário e que estão pendentes de incorporação ao produto de software. Cabe destacar que o Product Backlog não se limita a conter requisitos e inclui também elementos de design entre seus itens (VASQUEZ e SIMÕES, 2016).
Portanto, a especificação de requisitos é a forma de comunicação direta entre o cliente e a equipe de desenvolvimento, que deverá esclarecer o que será entregue como produto, tendo como objetivo documentar de forma fiel e completa todas as necessidades do cliente, para entregar um produto que o satisfaça.
Modelagem de Sistema
Para Booch, Rumbaugh e Jacobson (2005), diagramas definidos em UML (Unified Modeling Language) se tornou uma linguagem de modelagem padrão para modelagem orientada a objetos. A UML apoia a criação de muitos e diferentes modelos de sistema.
 Ao desenvolver modelos de sistema, muitas vezes você pode ser flexível no uso da notação gráfica. O detalhe e o rigor de um modelo dependem de como você pretende usá-lo. Os modelos gráficos são comumente usados de três formas:
· Como forma de facilitar a discussão sobre um sistema existente ou proposto;
· Como forma de documentar um sistema existente;
· Como uma descrição detalhada de um sistema, que pode ser usada para gerar uma implementação do sistema.
A linguagem Unifica de Modelagem é uma linguagem de modelagem gráfica para descrever um software. Ela simplifica o complexo processo de analisem projeto e construção de software criando visões do sistema que está sendo construído. (KRUCHTEN, 2003).
Modelagem é uma parte central de todas as atividades que levam à implantação de um bom software. Construir o modelo de um sistema não é uma atividade simples ou fácil, são várias abordagens a serem consideradas: a organização da empresa, os processos existentes ou requeridos, as informações existentes (ou requeridas) e os recursos envolvidos. (NOGUEIRA, 2005).
Além de flexível, a UML é extensível e independente de processos ou linguagens de programação, o que garante a liberdade para o desenvolvedor adotar qualquer processo, metodologia ou linguagem de programação sem deixar de expressar-se claramente para os seus usuários e outros desenvolvedores, pois utiliza uma notação padrão, comum a todos os ambientes e empresas.
Validação
Os artefatos produzidos pela engenharia de requisitos têm sua qualidade avaliada durante a etapa de validação. A validação de requisitos examina a especificação para garantir que todos os requisitos de software tenham sido declarados de forma não ambígua; que as inconsistências, omissões e erros tenham sido detectados e corrigidos; e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto (PRESSMAN e MAXIM, 2016).
Pressman e Maxim (2016), dão uma ilustração de alguns problemas que ocorrem durante a validação de requisitos, vamos considerar duas necessidades aparentemente inofensivas:
· O software deve ser amigável.
· A probabilidade de invasão não autorizada e bem-sucedida ao banco de dados deve ser menor do que 0.0001.
O primeiro requisito é vago demais para os desenvolvedores testarem ou avaliarem, O que exatamente significa "amigável”? Para sua validação isso precisa ser quantificado ou qualificado de algum modo.
O segundo requisito tem um elemento quantitativo ("menor do que 0.0001"), mas o teste de invasões será difícil e demorado. Esse nível de segurança é realmente garantido pelo aplicativo? Outros requisitos complementares associados à segurança (por exemplo, proteçãocom senha, protocolo de interação especializado) podem substituir o requisito quantitativo mencionado?
Segundo GLINZ (2009), escreve que requisitos qualitativos precisam ser representados de uma maneira que comuniquem o melhor valor. Isso significa avaliar o risco de distribuir um sistema que não cumpra os requisitos qualitativos dos envolvidos e tente mitigar esse risco com um custo mínimo. Quanto mais crítico é o requisito qualitativo, maior é a necessidade de expressá-lo em termos quantificáveis. Os requisitos qualitativos menos críticos podem ser expressos em termos gerais. Em alguns casos, um requisito qualitativo geral pode ser verificado com uma técnica qualitativa. Em outras situações, os requisitos qualitativos podem ser verificados usando-se uma combinação de avaliações qualitativas e quantitativas.
A Validação tem por objetivo assegurar que um software seja adequado e que atenda a todas as necessidades e expectativas do cliente.
Figura 1Fonte: Roger S. Pressman Bruce R. e Maxim. Engenharia de Software Uma abordagem profissional
Gestão
Uma abordagem adotada por Young (2003), que inclui a ER e a gestão de requisitos em um único processo. Baseada na gestão de projetos, o autor acrescenta atividades ao processo de requisitos, como uma etapa de planejamento destes, o desenho do processo de requisitos para o projeto e o investimento em atividades relacionadas a eles, considerando o ciclo de vida do sistema. De acordo com o autor, muitos gestores resumem o processo de requisitos à obtenção dos requisitos do sistema e à gestão de mudanças durante o ciclo de vida do projeto. Por esse motivo, o autor apresenta um desdobramento das etapas básicas da ER em diversas atividades, entre as quais estão o entendimento das necessidades de clientes e usuários; a análise, especificação e priorização dos requisitos; a derivação dos requisitos; a alocação destes em subsistemas; o monitoramento e gerenciamento dos requisitos e a validação deles (YOUNG, 2003).
Segundo Vasquez e Simões (2016) o responsável pela gerência de requisitos é a elaboração do plano de requisitos é responsabilidade ou do gerente de projetos ou do responsável pela metodologia de desenvolvimento de software usada pela empresa. Já a execução deste plano não há uma regra, mas, falando de forma geral, boa parte fica a cargo da equipe de gerenciamento de projetos - sendo que o analista de requisitos exerce um papel de apoio em muitas atividades.
Para Filho (2000) um problema comum no desenvolvimento de software é a instabilidade dos requisitos, que acontece quando clientes e usuários trazem novos requisitos, ou alterações de requisitos, quando o desenvolvimento já está em fase adiantada. A instabilidade dos requisitos costuma ter custo muito alto; geralmente significa perder trabalho já feito, desfazer algumas coisas e remendar outras. Na engenharia de software, a instabilidade dos requisitos é tão danosa quanto nas outras engenharias. Quando se muda a planta de um edifício durante a construção, geralmente é preciso desfazer parte do que já foi construído, e o remendo raramente é satisfatório.
O objetivo da Gestão dos requisitos é controlar os requisitos onde é composta por um conjunto de atividades que possibilita a equipe a identificar, controlar e acompanhar todas as necessidades e as mudanças a qualquer momento no projeto, que acaba estabelecendo um entendimento comum entre cliente e o fornecedor.
Descrição das Atividades
Elicitação
Iniciando nossa jornada nesse projeto, realizamos uma reunião com o cliente para identificação do problema, e com o auxílio do documento do RUP de Visão conseguimos entender qual o impacto o cliente estava sofrendo, procuramos com as informações adquiridas solucionar o problema.
Nosso próximo passo foi realizar uma reunião para Brainstorm afim de chegar em uma boa solução para o problema, definimos dentre todas a ideias implantar um sistema computacional para melhorar o controle das informações de nosso cliente.
Marcamos uma reunião para a equipe afim de melhorar nossa visão diante do problema, realizamos uma sentença para definir a posição do produto a ser construído e definimos qual seria o nosso grupo em foco, o nome do produto e o que o mesmo beneficiaria nos processos da ONG Jovens Ambientalistas, no final da reunião definimos os valores que nosso produto deveria alcançar.
Em nossa reunião inicial com o cliente adquirimos as informações dos envolvidos com o sistema, aqueles que seriam requisitados a manusear o sistema diariamente, nosso próximo passo foi realizar uma lista com as descrições e responsabilidades. Também definimos a plataforma para o ambiente do usuário e as diretrizes de permissões para o acesso ao sistema.
Por fim analisamos o ambiente do usuário e definimos inicialmente construir o produto sob medida, porém pensando em futuros upgrades foi realizada uma análise de requisitos do ambiente para verificar a necessidade de recursos para que o sistema funcionar.
Análise e Negociação
Para a Análise e Negociação o nosso primeiro objetivo foi pegar o problema ja identificado e então realizar a identificação dos requisitos, com isso fizemos uma reunião com o cliente para fazer a priorização dos requisitos, e com a ajuda do manual do documento RUP de Regras de Negócios entendemos quais são os requisitos e suas priorizações.
Começamos com a definição das funcionalidades do sistema onde foi apresentado ao cliente toda a funcionalidade do sistema, em seguida veio o Armazenamento de Dados 
onde foi definido como será o realizado o armazenamento de dados e sua integridade e, por fim, foi realizado um CRUD dos Usuários onde cada usuário tem o seus próprios acessos separado por área de atuação.
Especificação
Especificação dos Requisitos
Este projeto teve como objetivo ser implementado em qualquer organização que necessite ter um melhor gerenciamento de suas áreas, coletando e organizando todos os requisitos do sistema envolvido no projeto, bem como suas restrições e limitações. O desenvolvimento da especificação nesse projeto foi coletar todos os requisitos específicos para obter o máximo de detalhes possíveis, utilizando como base o documento do RUP de Especificação de Requisitos de Software. Abaixo mostra os seguintes passos que utilizamos no desenvolvimento de especificação.
Funcionalidades
Coletamos todas as funcionalidades que existem em todos os módulos, como o Inserir, Alterar, Buscar, Excluir e o Gerar Relatório, que tem como requisitos funcionais no projeto.
Usabilidade
	No desenvolvimento da usabilidade, utilizamos características do que é simples e fácil de usar, tendo a capacidade de satisfazer as necessidades do usuário de forma produtiva, flexível e eficiente.
Confiabilidade
	No desenvolver do projeto, detectamos que obrigatoriamente devemos ter o máximo de confiabilidade possível, tendo em vista os requisitos necessários como a Disponibilidade, monitoramento, falhas e privacidade, inserindo permissões para garantir que somente os usuários autorizados tenham acesso as informações da organização.
Desempenho
Tendo em vista a característica de atender as necessidades do cliente, é fundamental ter o máximo de desempenho possível garantindo o tempo de resposta rápida, e também a performance para trazer estabilidade e armazenamento de dados disponíveis para que o sistema possa desempenhar de forma eficiente.
Suportabilidade
	Claro, teremos que dar suporte aos usuários que usa o sistema, e desenvolvemos os processos e métodos que atenda o cliente, dando manutenções mensalmente conforme o agendamento do usuário, e apoiando a implementação do sistema nas máquinas dos usuários e disponibilizando todo o manual do sistema para o usuário.
Modelagem
No prosseguimento da especificação, foi elaborado a modelagem do sistema com seus requisitos funcionais utilizando a ferramenta Astah, foram modelados os diagramas de caso de uso, classe e sequência.
Para uma melhor compreensão também foram elaborados documentos de Especificação de Caso Uso utilizando templates RUP.
Diagrama de Caso de Uso
ProdutoFinanceiro
Serviço
Gestão Geral
Diagrama de Classe
Diagrama de Sequência
Validação
Para validar a conclusão do projeto foi realizada uma reunião de entrega de projeto com os stackeholders, a fim de apresentar o sistema construído, mostrando as implementações realizadas e sua conformidade com as especificações e informações levantadas durante o projeto. Foi evidenciado a funcionalidade de cada requisito funcional elencado bem como demonstrado sua função e modo de utilização.
Ao final da reunião, com todas fases do projeto entregues, foi elaborado um Termo de Aceite de Entregue, onde os stackeholders e equipe de projeto deram como finalizado o projeto.
Gestão
Para gestão das funcionalidade procuramos elaborar uma matriz de rastreabilidade com o objetivo de identificar com mais agilidade possíveis interferências se houver alterações em tais funcionalidades.
Conclusão
Bibliografia
BOOCH, G.; RUMBAUGH, J. E.; JACOBSON, I. The Unified Modeling Language User Guide. 2ª. ed. [S.l.]: Addison-Wesley Professional, 2005.
FILHO, W. D. P. P. Engenharia de Software: fundamentos métodos e padrões. 3. ed. São Paulo: Grupo Gen - LTC, 2000.
GLINZ, M. A Risk-Base Value-Orient Approach to Quality Requeriments. [S.l.]: IEEE Software, v. 26, 2009.
KRUCHTEN, P. The Rational Unified Process. Edição: 3. ed. [S.l.]: [s.n.], 2003.
MAXIM, R. S. P. B. R. Engenharia de Software Uma abordagem profissional. 8ª. ed. [S.l.]: AMGH Edutira Ltda., 2016.
NARDI, J. C.; FALBO, R. A. Uma Ontologia de Requisitos de Software. Universiade Federal do Espírito Santo. Vitória. 2006.
NOGUEIRA, M. ENGENHARIA DE REQUISITOS E A ERGONOMIA COGNITIVA COMO FATORES CRÍTICOS DE SUCESSO NA PRODUÇÃO DE SOFTWARE. [S.l.]: [s.n.], 2003.
NOGUEIRA, M. Modelagem de Sistemas. São Paulo: UNIP - Notas de Aula, 2005.
NOGUEIRA, M. Processo para gestão de riscos em projetos de software: Apoiado em lógica paraconsistente anotada evidendial EꞆ. Universidade Paulista. São Paulo, p. 205. 2010.
NOGUEIRA, M. [S.l.]. 2016.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2ª. ed. São Paulo: Pearson Education, 2004.
PRESSMAN, R. S. Software Engineering: A Practitioner's Approach with Bonus Chapter on Agile Development. [S.l.]: McGraw-Hill Science/Engineering/Math, 2003.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software uma abordagem profissional. 8ª. ed. [S.l.]: AMGH Edutira Ltda., 2016.
SOMMERVILLE, I. Engenharia de Software. 9ª. ed. São Paulo: Pearson Education, 2011.
SOMMERVILLE, I. Engenharia de Software 9º Edição. [S.l.]: [s.n.], 2011.
VASQUEZ, C. E.; SIMÕES, G. S. Engenharia de Requisitos: software orientado ao negócio. 1ª. ed. Rio de Janeiro: Brasport Livros e Multimídia Ltda., 2016.
YOUNG, R. The Requirements Engineering. Norwood: Artech House, 2003.
Anexos
ALTERAR
BUSCAR
EXCLUIR
GERAR_RELATORIO
INSERIR
SCE
INFORMAR_DADOS
RETORNAR_RELATORIO
Financeiro
ALTERAR
BUSCAR
EXCLUIR
GERAR_RELATORIO
INSERIR
SCE
INFORMAR_DADOS
RETORNAR_RELATORIO
Serviço
GERAR_RELATORIO
SCE
RETORNAR_RELATORIO
SOLICITAR_RELATORIO
Gestão_Geral
+ INFORMAR_DADOS() : void
- Data_Vencimento : String
- Valor : double
- Data_Pagamento : String
- Nome_Cliente : String
- Forma_Pagamento : String
- Desc_Conta : String
- Codigo_Conta : int
Financeiro
+ SOLICITAR_RELATORIO() : void
Gestão_Geral
+ INFORMAR_DADOS() : void
- Valor : double
- Quantidade : int
- Descricao : String
- Nome : String
- Codigo : int
Produto
+ INFORMAR_DADOS() : void
- Status : String
- Data_Conclusao : String
- Data_Inicio : String
- Tipo : String
- Descricao : String
- Codigo : int
Serviço
+ RETORNAR_RELATORIO() : void
+ GERAR_RELATORIO() : void
+ BUSCAR() : void
+ EXCLUIR() : void
+ ATUALIZAR() : void
+ INSERIR() : void
SCE
 : Financeiro
 : SCE
1: INFORMAR_DADOS()
2: INSERIR() : void
3: ATUALIZAR() : void
4: BUSCAR() : void
5: EXCLUIR() : void
6: GERAR_RELATORIO() : void
 : Produto
 : SCE
1: INFORMAR_DADOS()
2: INSERIR() : void
3: ATUALIZAR() : void
4: BUSCAR() : void
5: EXCLUIR() : void
6: GERAR_RELATORIO() : void
 : Serviço
 : SCE
1: INFORMAR_DADOS()
2: INSERIR() : void
3: ATUALIZAR() : void
4: BUSCAR() : void
5: EXCLUIR() : void
6: GERAR_RELATORIO() : void
 : Gestão_Geral
 : SCE
1: SOLICITAR_RELATORIO()
2: GERAR_RELATORIO() : void
X
[ 01] - Inserir[ 02] - Buscar[ 03] - Excluir[ 04] - Alterar[ 05] - Gerar_Relatorio
[ 01] - Inserir
xx
[ 02] - Buscar
[ 03] - Excluir
x
[ 04] - Alterar
x
[ 05] - Gerar_Relatorio
xxx
Matriz de Ratreabilidade - SCE
ALTERAR
BUSCAR
EXCLUIR
GERAR_RELATORIO
INSERIR
SCE
Produto
INFORMAR_DADOS
RETORNAR_RELATORIO