Aula 3_Levantamento_Requisitos

In this class on requirements gathering, the main topics discussed include the motivation for requirements gathering, the process of rapido (requirements, analysis, design, implementation, testing, and operation), and the importance of establishing common documentation and language for both the client and the software development team. The class also covers the different stages of requirements gathering, techniques such as interviews and workshops, types of requirements (functional and non-functional), and notations such as IDF0, DFD, and UML. The lecturer also discusses the IEEE ANSI 830-1998 standard for software requirements specification and provides examples of checklists for validating requirements. The class ends with a case study on a customer registration system, which follows the rapido process and uses the waterfall model for project execution. Aula 3, levantamento de requisitos. Roteiro desta aula, contextualização do levantamento de requisitos, a motivação, etapas, técnicas, tipos, notações, especificações e referências. Ainda sobre a contextualização desta aula, processo, gerência e o rapito. O rapito é requisito, análise, projeto, implementação, teste e operação. Motivação, como estabelecer documentação e linguagem comuns para o cliente e para a equipe de desenvolvimento de software. Aqui nós temos um diagrama de Venn que explica a motivação. De um lado você tem a elipse de engenharia de sistemas, do outro você tem engenharia de software e no meio a intersecção, um R, que seria a fronteira entre engenharia de sistemas e engenharia de software. Motivação, fronteiras, requisitos, fornecer à equipe uma melhor compreensão do que está, do que será implementado. Nessa fase, esclarecer com os stakeholders o que será desenvolvido e não como será desenvolvido. Um projeto, aliás dois projetos, traduzir os requisitos do sistema funcionais e não funcionais para uma linguagem que descreva como implementar o sistema. 3. Construção, implementar o sistema baseado nas informações fornecidas pelas fases anteriores. Então, só lembrando que requisitos, você fala o que será desenvolvido e não como será desenvolvido. Já o projeto, ele traduz os requisitos do sistema funcionais e não funcionais para uma linguagem que descreva como implementar o sistema. E a construção, implementar o sistema baseado nas informações fornecidas pelas fases anteriores, que é projeto e requisitos. Motivação, o problema, como traduzir as necessidades dos clientes para a equipe de desenvolvimento. Então, a gente tem aqui, de um lado, pessoa, P igual a Nil, pessoa, e do outro lado, numa divisão, preciso guardar as informações das pessoas que mais compram. Então, desse primeiro lado, pessoa, P igual a Nil, pessoa, é a equipe de engenharia de software. E do outro lado, preciso guardar as informações das pessoas que mais compram, é o cliente. Então, existe essa interposição aqui. Ainda, motivação, a solução. Estabelecer a comunicação entre as necessidades dos usuários e a equipe de desenvolvimento. Usar uma linguagem padrão, exemplo, IDF0, DFD, DR, UML, na visão mais abstrata do problema. Não pode colocar informações muito técnicas sobre o projeto e, sim, de maneira abstrata. E aí, você tem, então, esse paradigma da equipe de engenharia de software. E, através das possíveis linguagens do IDF0, DFD e UML, você liga até o cliente, que é a outra ponta, outra externidade, então, dessa seta de duas pontas. Etapas do levantamento de requisitos. A gente tem a primeira, concepção e levantamento, que ela tem as subetapas, que é definição do escopo, estudo de viabilidade e obtenção dos requisitos. A segunda fase é análise, que ela tem como subetapas, modelos técnicos, definições das prioridades. E a terceira etapa, que é os relatórios, que tem como como subetapa a especificação dos requisitos de software, ERS, especificação dos requisitos de software. E a fase 4, que é a validação e gestão, tem duas subfases, vamos dizer assim, que é a revisão técnica formal, prototipação e geração de casos de teste, além do acompanhamento e rastreabilidade. Então, caso seja utilizada uma ferramenta case, essa ferramenta permitirá rastrear todos os artefatos que serão, que serão artefatos afetados, desculpe, em função da alteração do escopo do problema. Técnicas. Entrevistas com stakeholders. 2, workshop. 3, cenários. 4, casos de uso IDF0 ou DFT. 5, diagramas de atividades. 6, protótipos e etc. Não precisa utilizar todas as técnicas, escolha somente uma em que se tem maior afinidade. Lembrando, por exemplo, que o professor disse que ele não tinha a habilidade de fazer entrevistas diretamente com os clientes, mas sim a habilidade de fazer através de diagramas, enfim, uma parte mais abstrata. Tipos de requisitos. Nós temos os requisitos funcionais, que descrevem o que o sistema deve fazer, as funcionalidades, e os não funcionais, que são padrões usados como confiabilidade, capacidade, tecnologia e etc. Notações. Nós temos 4, linguagem natural estruturada, que faz o uso de formulários. 2, linguagem de descrição de projetos. Ela tem, então, o tópico semelhante à linguagem de programação. 3, notações gráficas, que é aquele do IDF0, DFD e assim por diante. 4, especificações matemáticas, que seria a notação Z. Se trata de uma linguagem formal onde é possível se gerar códigos. E essas notações aqui, ela é utilizada para fazer o levantamento dos requisitos. Algumas questões para o levantamento dos requisitos. Primeiro, quem está solicitando esse projeto? Segundo, quais os usuários? Terceiro, quais informações serão utilizadas descrevendo o negócio? Quarto, quais as responsabilidades de cada usuário? Cinco, quais os benefícios? Seis, projetos semelhantes? Sete, quais são as prioridades? Oito, quais são os prazos? Agora, checklist de validação de requisitos. Estamos falando aqui em sete checklists. Primeiro, os requisitos foram claramente definidos? Segundo, a referência do requisito foi identificada? Terceiro, o requisito viola alguma regra de negócio? Quarto, o requisito pode ser testado? Como? Cinco, padrões de requisitos foram usados? Seis, os requisitos foram especificados no nível de abstração adequado? Especificação de requisitos de software, ERS. Exemplo de padrão. O exemplo de padrão é descrito no IEEE ANSI 830 de 1998. Então, neste exemplo padrão, e tem-se introdução. Dentro de introdução, você tem cinco tópicos, 1.1 Objetivos, 1.2 Escopo, 1.3 Definições, Siglas e Abreviaturas, 1.4 Referências e 1.5 Visão Geral. Sobre o IEEE ANSI ou ANS 830 de 1998, temos a parte dois, continuando. Dois, descrição global. Então, na descrição global, você tem seis subdescrições aqui. Então, você tem 2.1 Perspectiva do produto, 2.2 Funções do produto, 2.3 Características do usuário, 2.4 Restrições, 2.5 Hipóteses e Dependências e 2.6 Distribuição de Requisitos. Ainda sobre o IEEE ANSI 830 de 1998, temos a parte três agora, ou seja, terceira etapa aqui, Requisitos Específicos. Os Requisitos Específicos, nós temos Requisitos Funcionais, Não Funcionais, o GUI, que é o Guia do Usuário, Interfaces Externas. 4, ainda sobre o IEEE, Apêndice e 5, Índice. Então, isso daqui é o que trata o IEEE ANSI 830 de 1998. Continuando a aula, o professor abriu aqui uma tabela de conteúdo, é um formulário por ele aberto, não está em JavaScript, apenas para dar uma noção de como se cria um formulário para fazer o levantamento de requisitos. Então, ele tem esse formulário, as etapas Objetivos, Escopo, Definições, Siglas e Abreviaturas, Referências, Visão Geral, a Descrição Global, Perspectiva do Produto, Função do Produto, Características do Usuário, Restrições, Hipóteses e Dependências, Distribuição de Requisitos, tem depois Requisitos Específicos, Requisitos de Interface, isso daqui ele tem muito a ver com o IEEE ANSI 830 de 1998. Então, ele deu algum exemplo aqui, por exemplo, Introdução, declara as metas e os objetivos do software, dando uma visão geral da especificação do requisito de software. Objetivo especifica as interações e o público-alvo da ERS, a especificação de requisitos de software. Escopo, Definições, Siglas e Abreviaturas, todos os termos, siglas, acrônicos, acrônimos, abreviaturas e símbolos devem ser explicados da forma em que os requisitos, o ERS, possa ser interpretado. Essas informações podem ser incluídas em um glossário, uma tabela de símbolos ou em um apêndice, ou podem ser feitas referências a outros documentos. Isso aqui é apenas um exemplo, mas tem todas as etapas de um processo normal. Bom, agora vamos para um Caso de Uso. Caso de Uso, projeto de uma turma apresentada pelo professor. Tantos casos de uso quanto visão geral são artefatos. Tudo que está no texto é refletido no diagrama. Então vamos ver uma visão geral. Um cliente ao entrar em contato com o vendedor é cadastrado no sistema. Caso já não esteja, para realizar o cadastro, o cliente informa o vendedor seu nome ou razão social, CPF ou CNPJ, data de nascimento ou data da abertura da empresa e endereço. Posteriormente o vendedor verifica se os produtos que o cliente deseja estão em estoque. Se sim, a venda é excetuada. Se não, o setor de compras da autopeça é informado que determinado produto está em falta. Quando o setor de compras adquire um produto, se deve registrar o produto no sistema junto com os demais dados do produto e do fornecedor. O sistema não deve registrar uma venda para um produto que não tem a quantidade necessária em estoque. O sistema deve registrar a forma de pagamento, cartão, dinheiro ou cheque, além da data e local de entrada, salvo o último caso, o cliente não for retirar os produtos na própria autopeça. Então isso aqui é um exemplo de uma visão geral. Projeto de uma turma, apresentada pelo professor na continuidade. Então aqui uma descrição do processo. Para execução desse sistema foi escolhido o modelo de cascata, pois apesar de suas limitações, os requisitos dos projetos permanecerão imutáveis e é o modelo que melhor se enquadra ao cronograma da disciplina. Assim, as atividades serão executadas linearmente seguindo a ordem requisitos, análise, projeto, implementação, testes e operação. É o rapido. Eventualmente algumas dessas etapas serão revistas por falta de requisitos passados, despercebidos no início, para corrigir eventuais erros que possam ser propagados ou para melhorar a diagramação e utilização do sistema. Vocês poderiam sugerir uma adaptação do cascata para fazer isso, que eu disse o professor com relação a esse projeto. Aí depois tem o diagrama de grangante, na parte de cronograma, então ele especifica todas as atividades, o tempo que cada atividade leva para terminar, se existem atividades em paralelo, atividades que são posteriores ou anteriores à atividade em andamento. Então esse é o diagrama de grangante. Aqui o professor sugeriu para a turma para poder, de repente, fazer esse diagrama aqui usando as fases do rapido. Também é bem interessante. Aqui ele apresenta um sistema de automação de peças, com todas as entradas e saídas, enfim, como funcionaria o projeto de uma turma do sistema. Esse daqui é o modelo do IADF 0, nível 0, então é um quadrado no meio escrito sistemas de automação de autopeças. À esquerda você tem dados dos clientes, dados dos funcionários, produtos, pedidos, fornecedores e na saída, que é o lado direito, clientes cadastrados, funcionários cadastrados, produtos cadastrados, pedido cadastrado, fornecedores cadastrados e relatórios. Em cima você tem as regras de cadastro e regras de negócio e embaixo cliente, funcionário, fornecedor. Esse é o diagrama do IADF 0. Então assim, o projeto ele novamente explica como que dá o relacionamento desse cadastro com o outro módulo do pedido e o módulo pedido com o módulo da gestão. Aqui depois ele explica o diagrama de fluxo de dados, não mais o IADF 0. O diagrama de fluxo de dados, com várias caixinhas aqui, funcionário que se liga ao cadastro do cliente e o cadastro do cliente que se liga a clientes e clientes a gestão. Então da mesma forma o gerente que se liga a cadastro de funcionário, cadastro de funcionário a funcionários e funcionários a gestão. E tem o gerente que se liga a cadastro de fornecedor, o fornecedor a fornecedor, de fornecedor a gestão e gestão é o, digamos assim, o principal, onde todas as caixinhas se ligam. Então isso aqui é o diagrama de fluxo de dados. O diagrama de entidade relacionamento ele já é bem no estilo mesmo daquela aula que a gente teve do banco de dados. Então ela tem aqui um banco de dados com várias tabelas. Então você tem a tabela telefone fornecedor, telefone de usuário, endereços fornecedor, telefone fornecedor, login, cidade, cada uma dessas é uma tabela que está dentro dos sistemas estão interligadas. Esse é o diagrama de entidade relacionamento que já aprendemos aí no passado. Vamos para o próximo agora, objetivo. Cadastrar um novo cliente no sistema e o fluxo principal também. Ele dá um exemplo aqui do mesmo projeto da turma dele. Esse caso de uso inicia quando um funcionário entra no sistema através do login e assim por diante. Fluxos alternativos, ele explica também caso o login do funcionário seja inválido, o sistema apresenta uma mensagem de erro e pede novamente o login. E depois ele tem por cima o diagrama de atividades do sistema. Aqui você tem então, por exemplo, funcionário que ele se ramifica em dois, que é fazer pedido e cadastrar cliente. E aí depois é um fluxo na verdade, esse diagrama de atividades do sistema. Então, por exemplo, fazer pedido você depois é conectado por uma seta, um losango, caixa de decisão. E depois de sucesso, se for ter sucesso vai realizar o pagamento. Se tiver sucesso também na consulta do pagamento, baixa o produto em estoque e aí os itens são retirados do estoque. Então, da mesma forma que você tem esse fluxo do funcionário, você tem o gerente que ramifica em quatro elipses, cadastrar fornecedor, gerar relatório, cadastrar funcionário e compra de peça. Então, você tem essas bolinhas pretas, que o relatório foi gerado, por exemplo, ligado ao gerar relatório e cadastrar funcionário, funcionário cadastrado. Você tem aquele cadastrar fornecedor, que depois está ligado a elipse cadastrar produto, que por sua vez está ligado a acrescentar no estoque. Então, esse daqui é o diagrama de atividades do sistema. Agora, tem um diagrama de classes, ele é praticamente um diagrama de entidade relacionamento, muito semelhante de tabelas, tabela produto, pessoa, fornecedor, cliente, usuário, pedido, itens do pedido, mas esse diagrama de classes, ele é um pouco mais sucinto do que o diagrama de entidade relacionamento. Então, esse diagrama de classes, ele tem o produto, o tipo de produto, o método. Então, por exemplo, pessoa. Pessoa se ramifica em fornecedor, cliente e usuário. O fornecedor, ele se conecta à base do produto. Lá no cliente, ou seja, depois pessoa, cliente, o cliente se conecta ao pedido. O pedido, ele se conecta aos itens do produto, que também se conecta ao próprio pedido, e o item do produto se conecta a produto. É interessante, então, esse diagrama de classes. Mapa de componentes é muito parecido com o diagrama de classes, muitíssimo parecido. Tem a seta se ligando e tudo. Muito parecido, mas ele tem, digamos assim, uma delimitação em relação ao diagrama de classes, porque ele delimita os módulos. Por exemplo, pessoa, tem lá fornecedor, cliente e usuário. Então, tem uma grande caixa fazendo com que esse módulo seja fechado na pessoa. Pessoa, fornecedor, cliente e usuário. E, por exemplo, produto e item de produto, é outro módulo que é fechado somente nessas duas tabelas. E o pedido, que tem um outro módulo que é sozinho, somente com o próprio pedido. Bom, vamos continuar agora. Requisitos de desenvolvimento. Então, ele dá um exemplo aqui também. Ferramentas utilizadas para desenvolvimento do sistema. Eclipse Clapper, for Java. EE Developers, ferramenta utilizada para desenvolver o código fonte do sistema. Google Drive, ferramenta utilizada para armazenamento e compartilhamento dos artefatos de software, utilizados para compor o projeto. O Kacou, que é a ferramenta utilizada para desenvolvimento dos programas, de casos de uso. E DF0. O Draw.io, ferramenta utilizada em conjunto com o Google Drive para desenvolvimento o DF0, o DFD, e aí o diagrama de sequência. O H2, que é o bloco de dados em memória utilizado no desenvolvimento do projeto. O Vraptor, que é o framework do MVC. O Hibernate, Java, framework de mapeamento, objeto relacional. O JUnit, framework de teste de unidade. O Serenio, ferramenta para teste de validação de tela. E o Bitbucket, que é uma ferramenta para gerenciar o versionamento do código. Então, isso aqui é o projeto ainda, que ele está explicando o exemplo de requisito de desenvolvimento. O teste de caixa branca. Os testes de caixa branca foram implementados utilizando o framework de testes JUnit. Abaixo, é exibido o teste do método, o GetValorTotal da classe pedido. O método calcula o valor total do pedido feito pelo usuário. Bom, agora ele está mostrando também o cálculo de pontos de função. Métricas não é contemplado no nosso curso, mas ele explica que existe. Enfim, com isso nós acabamos, então, a aula 3.