Baixe o app para aproveitar ainda mais
Prévia do material em texto
Engenharia de Requisitos. Software Orientado ao negócio Carlos Eduardo Vazquez Guilherme Siqueira Simões Rio de Janairo: Brasport, 2016 ISBN: 978-85-7452-790-1 Direitos autorais e conteúdo • Estudo retirado do livro: ENGENHARIA DE REQUISITOS : Software Orientado ao Negócio Carlos Eduardo Vazquez Guilherme Siqueira Simões Rio de Janeiro: Brasport, 2016 ISBN: 978-85-7452-790-1 Base: . IEEE830 ISO 9000 ISO/IEC 12207 ISO 9126 SOMMERVILLE, Ian . Engenharia de Software, 9ª Edição. Pearson Education, 2011. PRESSMAN, R. S. Engenharia de Software. 7º Edição. Editora McGraw Hill. Rio de Janeiro, 2010. Conteúdo – 1. Engenharia de Requisitos – 2. Requisitos – 3. A Importância da Engenharia de Requisitos – 4. Dificuldades Comuns com Requisitos – 5. Tipos de Requisitos, Restrições e Premissas – 6. Atividades de Engenharia de Requisitos – 7. Elicitação de Requisitos – 8. Análise de Requisitos – 9. Gerência de Requisitos Início da Jornada Necessidade de nossos clientes.. Entenda !! 1. Engenharia de Requisitos • Primeiro passo: • Entender o que significa ! • “- Quando eu uso uma palavra - disse Humpty Dumpty num tom escarninho - ela significa exatamente aquilo que eu quero que signifique ... nem mais nem menos. - A questão - ponderou Alice saber se o senhor pode fazer as palavras dizerem coisas diferentes. - A questão - replicou Humpty Dumpty é saber quem é que manda. É só isso. (Alice no País das Maravilhas)” Lewis Carroll Terça 1.1. Definição de Engenharia de Requisitos • Isto é: • Consiste no uso sistemático e repetitivo de técnicas para cobrir atividades de obtenção, documentação e manutenção de um conjunto de requisitos de software que atendam aos objetivos de negócio e sejam de qualidade Terça 1.2. Por que usar “engenharia” em Engenharia de Requisitos? • Pois está ligada à aquisição e aplicação de conhecimento para criação, aperfeiçoamento e implementação de sistemas de informações. Melhore Pergunte Imagine Planeje Crie Terça Estratégias de desenvolvimento Terça Estratégias de desenvolvimento Terça Estratégias de desenvolvimento Terça Estratégias de desenvolvimento Terça Estratégias de desenvolvimento Terça Ambiente da Engenharia de Requisitos • Facilita a interação com o cliente. – Identificar e entender suas necessidades – Acordo da solução a ser entregue • Inicia com o entendimento da necessidade do cliente e; • Passa pelo acordo sobre a solução que será construída Terça Contexto Terça Requisito Terça Tipos de requisitos • IEEE830/98 • Requisitos Funcionais • Requisitos Não Funcionais • Requisitos de Domínio Terça Requisitos Funcionais • Descrevem explicitamente as funcionalidades e serviços do sistema • Documenta – como o sistema deve reagir a entradas específicas – como deve se comportar em determinadas situações – o que o sistema não deve fazer • Atributos – Completude • Todas os serviços devem estar definidos – Consistência • Os requisitos não devem ter definições contraditórias • Na prática, é quase impossível atingir completude e consistência dos requisitos Terça Requisitos Não Funcionais • Definem propriedades e restrições do sistema – Exemplos: segurança, desempenho, espaço em disco • Podem ser do sistema todo ou de partes do sistema • Requisitos não funcionais podem ser mais críticos que requisitos funcionais – Se não satisfaz, o sistema é inútil Terça Entender seu significado • Não confundir: – Requisitos = documentação – Requisitos = Software (Completo) • Está direcionado á – Necessidade – Propriedade – Especificação Terça Definição de requisito • ISSO/IEC/IEEE • Uma condição ou capacidade do sistema, solicitada por um usuário, para resolver um problema ou atingir um objetivo; • Uma condição ou capacidade que deve ser atendida por uma solução para satisfazer um contrato, especificação, padrão ou quaisquer outros documentos formais; • Documentação de representação das condições ou capacidade nos dois itens anteriores; • Uma condição ou capacidade que deve ser alcançada ou possuída por um sistema, produto, serviço, resultado ou componente para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto. Requisitos incluem as necessidades quantificadas e documentadas, desejos e expectativas do patrocinador, cliente e outras partes interessadas. Terça Especificação de requisitos • É um contrato entre cliente e equipe de desenvolvimento. – Então ambos obrigatoriamente serão seus leitores • Deve estabelecer aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento. • Serve de base para manutenções futuras. Terça Nível de detalhe • A falha em não detalhar de maneira suficiente as informações na especificação de requisitos pode levar a interpretações equivocadas ou à criação de um número elevado de premissas. • Por outro lado, decidir por detalhar demais as especificações pode ser um elemento paralisante do projeto (a especificação nunca é finalizada), além de oneroso. • O desafio é encontrar o equilíbrio do nível de detalhe adequado da especificação de requisitos par ao projeto. • Atenção ::: Deve Delimitar o Escopo.. Terça Nível de detalhe da especificação • Definir com clareza o contexto em que ela será usada; • Decidir dobre quais tipos de informação devem estar presentes; • Avaliar os riscos conforme os fatores que podem implicar em mais ou menos detalhes. • Grau de incerteza: – Toda estimativa envolve incerteza (por definição) • Envolvimento dos clientes – Fator crítico para o sucesso Terça Critérios de qualidade da especificação. • Correta • Completa • Clara • Consistente • Modificável • Priorizada • Verificável (ou testável) • Rasteável Terça Importância da engenharia de requisito • Motivação • Impactos negativos da falha de requisitos – Sonda Mars .. Etc.. Terça Aquecendo os motores “As pessoas não sabem o que querem, até mostrarmos a ela” Steve Jobs Dificuldades comuns com Requisitos • Comunicação Minha esposa disse: - Amor, vá ao mercado e compre uma caixa de leite. Se eles tiverem ovos, traga seis. Eu voltei com seis garrafas de leite. Ela disse: - Porque você comprou seis garrafas de leite ? Respondi: - Porque eles tinham ovos !! Quarta Outa dificuldade • De manter sintonizados todos os envolvidos nos requisitos, sejam membros da equipe ou partes interessadas. • O número de canais de comunicação em potencial entre essas pessoas é 𝑝 = 𝑛 (𝑛−1) 2 Quarta Acesso às partes interessadas • Muitas vezes o trabalho de requisitos acontece sem que seja permitido ao analista interagir diretamente com algumas partes interessadas. – Seja por falta de disponibilidade; – Seja por falta de tempo; – Seja por falta de interesse da parte interessada; – Seja por questões políticas, sociais culturais ou outros. • Princípio 4 dom manifesto Ágil: – “Pessoas de negócio e desenvolvimento devem trabalhar diariamente em conjunto por todo o projeto” Quarta Indecisões / Indefinições do usuário • Dificuldade de o usuário saber o que quer. • Falta de conhecimento da atividade que exerce. • A princípio podemos pensar que a culpa é do usuário, pois ele não sabe pedir e nem sabe no que trabalho. – Se fosse verdade o analista de requisito seria um tomador de notas. • Deve procurar métodos mais adequados para obtenção de informações (Cap. 7 e 8) Quarta Muita Dificuldade • Requisitos Implícitos ou não ditos – Caso comum: Fizemos um bom trabalho, ouvi as partes interessadas,li os documentos e confirmou todas as necessidades. • Pronto: Na validação/Homologação encontra diversas necessidades não atendidas pelo produto..... Pois estas necessidades nunca tinhas faladas ao analista.... • “Claro que não falei sobre isso, pois para mim estava implícito que isso estaria contemplado. É óbvio que o produto deveria ter isso !” – Quem errou neste caso ? Quarta Mais difuculdades • Mudanças. – Alta frequência de mudança em requisitos. • Toda mudança acarreta em algum ônus. – Gestor com outras prioridades. – Quanto maior o projeto, maior tende sua duração e consequentemente, maior a incidência de mudanças. – Gerir mudanças é fundamental – Resistencia a mudança Quarta Parte interessada • Não domina seu negócio – Parece algo comum. • Não lê a especificação de requisitos. – Ela tem que está de acordo com o que foi solicitado, a responsabilidade não é só sua. • Insaciável com requisitos.. – Porque os requisitos se expandem? Porque as partes interessadas sempre têm necessidade a serem satisfeitas. Quarta Um bom trabalho • Consistência. – Um bom trabalho de requisitos tem que resultar em uma especificação de requisitos que seja uma história bem contada, com início, meio e fim tudo se encaixando. • Necessidades vagas. – Encontrar um cenário onde a necessidade apresentada é mais ou menos vaga. • Objetivo é transformar estas necessidades vagas em necessidades claras. • Priorização. Quarta Tipos de requisitos, Restrições e Premissas • Domínio do problema Quarta Domínio • Qual é a sua importância ? – Delimita escopo • Requisitos (ou necessidades) de negócio. – Declarações de mais alto nível de objetivos, metas ou necessidades das organizações. – Necessidades de negócio são problemas a resolver. • Critérios de qualidade – “é tão fácil sugerir uma solução quando você não sabe demais sobre o problema.” Malcolm Forbes Quarta Método SMART • Tem como objetivo avaliar a validade de objetivos que devem ser: • S – eSpecífico : Descreve algo que apresenta um resultado observável. • M – Mensurável : São resultados passíveis de acompanhamento e medição. • A – Alcançável : As necessidades de negócio consideram a viabilidade de investimento. • R – Relevante : Elas estão alinhadas com a visão, a missão e os objetivos-chave da organização. • T – Tempestivo : Os objetivos definidos têm uma janela de tempo definida que é consistente com as oportunidades ou os problemas associados. Quarta Papel do Analista de Requisitos • É refinar os requisitos de negócio, identificando questões que – uma vez respondidas – permitam melhor compreensão das intenções iniciais. • Perguntas podem ser elaboradas para entender o domínio do problema. – Quais são as principais dificuldades na fiscalização e que dificultam a coleta de dados ? – Qual é a sua ideia de agilidade de coleta de dados posposta? – Agilizar em quantos % o processo de coleta de informação? – Como se mede a coleta de informação ? Quarta Onde ficam registrados? • Os registros de negócio costumam estar presentes em documentos que justifiquem o projeto. – Caso de negócio (busines case); – Estudo de viabilidade; – Anteprojetos; – Termos de abertura de projeto. Quarta Restrições e premissas • Restrições – Limitações as possíveis soluções • Premissas – Suposições – Informações que se acreditam como verdadeiras, mas ainda não foram confirmadas Quarta O caminho a partir dos requisitos de negócio Quarta Autoridade e responsabilidade • Usuário que detém o negócio; • Pessoas que usam o processo. • Importante e identificar as partes interessadas. • A responsabilidade do requisito não deve ser imputada somente no analista, e sim compartilhada nas partes interessadas. – Habituar a fazer o acordo de aceito com o cliente. Quarta Requisitos • Requisitos de Software, são compostos pelos requisitos da solução – produto a ser entregue – e pelos requisitos da transição (se houver) = ambos são compostos pelos requisitos funcionais Quarta Nível de granularidade • Mais detalhado o possível ou informações macros ? Quarta Figura 5.9. Diferentes níveis de granularidade em requisitos presentes em uma especificação funcional e sua relação com os objetivos associados Atenção • Diferença entre requisitos não funcionas e restrições técnicas. • RNF = É o resultado de uma elaboração “de escolha” para uma solução em particular dentre muitas possíveis. • RT = São limitações impostas externamente as possíveis soluções. Quarta Quase no fim..... Atividades da Engenharia de Requisitos “A luz precede toda transição, Seja a luz no fim do túnel, Pelas frestas nas portas ou no brilho de uma ideia, ela está Sempre lá, anunciando um novo começo” Teresa Tsalaky (The Transition Witness) Um único tema, diferentes pontos de vista. • A produção de requisitos pode ser descrita em diferentes perspectivas. • Entender que: O desenvolvimento de um software só termina quando o objetivo do processo é alcançado. – Mas como terminar se não sei o objetivo? • Como diminuir estes problemas. – Existe métodos ? • Ágil, Sequencial e RUP Quinta Um método que pode ajudar a acompanhar Figura 6.1. Exemplo de quadro que permite a visualização do progresso do desenvolvimento ao longo de um processo de referência baseado no Kanban Também pode ajudar !! • Para mitigar riscos, podemos usar um processo genérico, que não se propõe a cumprir o papel de uma metodologia de desenvolvimento completa. – Mas...... É melhor servir como referência geral do que o caos! • Podemos usar o mapeamento baseado no COCOMO II (Constructive Cost Model), também não podemos ignorar as repercussões do Manifesto Ágil, como o SCRUM por ser uma das metodologias ágeis mas empregadas (atualmente) Mapeamento entre fases e objetivos gerais Figura 6.2. Compatibilização entre diferentes estratégias com base nos resultados que devem entregar no tempo na forma de um modelo de processo para referência. Podemos destacar 3 MARCOS 1 Marco de Definição da necessidade 2 Marco de Consenso do Escopo 3 Marco de Detalhamento dos Requisitos Importante definir o primeiro marco: necessidade • Geralmente usa uma ferramenta da administração primitiva – Solicitação de proposta (Request for Proposal – RFP) ou conhecido pela admistração pública como “Projeto básico” • O Trabalho também acontece com o estudo de viabilidade – Geralmente obtém no “caso de negócio” ou quando existe um “Plano Diretor de Tecnologia da Informação – PDTI” • Então Temos que: – Definir as necessidades de negócio; – Identificar as partes interessadas; – Definir os casos de negócio; – Definir o escopo da solução. Atividades da engenharia de Requisitos Quinta Figura 6.3. Tarefas da Engenharia de Requisitos As atividades de gerência de requisitos têm como principais objetivos: a) Identificar a melhor forma de comunicar os requisitos e amaneira como será mantido o conhecimento obtido para uso. b) Administrar conflitos, problemas e mudanças a fim de garantir o acordo sobre o escopo da solução c) Priorizar requisitos Segundo: Consenso sobre o escopo • Entender o problema e alinhar um escopo para o desenvolvedor. • Para avaliar de este Segundo Marco foi atingido requer que definam: – Necessidades de negócio, juntamente com as principais restriçõe e premissas do desenvolvimento; – As entidades importantes que integram com o sistema (de maneira ativa ou passiva); – Eventos mais importantes para quais o sistema deve responder – Os termos importantes e um glossário analisado Quinta Terceiro: Detalhamento dos requisitos • Estemarco, é de fundamental importância no sucesso do desenvolvimento. • A partir do marco de consolidação do escopo, o objetivo maior é criar uma arquitetura que sirva como linha de base para todo o desenvolvimento. • Este terceiro Marco é atingido quando: • A visão e os requisitos do produto são estáveis. • Todos os eventos para os quais o produto deve prover resposta e todas as entidades que interagem com ele devem estar identificadas. Técnicas • Como são técnicas, são sugestões e não receita para o sucesso!! – Declaração de problemas. (págs. 127 – 129) – Modelagem de escopo (modelagem ambiental) (pág. 129) – Técnica: Diagrama de contexto (págs. 129 – 133) – Técnica: Diagrama de caso de uso (págs. 133 – 135) – Técnica: Modelo de processo de negócio(págs. 135 – 136) Ótimo, tenho muitos métodos e técnicas. E agora qual usar ? Quinta Como saber com quem conversar !!! • Agora é uma parte que requer uma visão investigativa. – Vestir a capa de “sherlock holmes” – Contratar o CSI. – O que não pode é fazer premonições ....... • “mãe dinah” • “Walter mercado” • Sei, não é fácil – Comunique-se, – Faça perguntas, – Nunca suponha, mesmo que seja óbvio. – Tente obter uma resposta única (problema das duas portas) Quinta Elicitação de Requisitos “O óbvio, Lóri, é a verdade mais difícil de se enxergar.” Clarice Lispector LISPECTOR, C. Uma Aprendizagem ou o Livro dos Prazeres. Rio de Janeiro. 1998. “Só profetas enxergam o óbvio.” Nelson Rodrigues. Definição: Um anglicismo do termo em inglês “elicit requirements” na versão brasileira vira => Elicitação de Requisitos. Nada mais é que: Levantamento de requisitos. Quinta Atividades do levantamento • Preparação (ou planejamento) • Execução • Documentação • Confirmação Quinta Preparação • Tem como objetivo a garantir que todos os recursos necessários estejam organizados e reservados para a sua realização. – Recursos: Agenda disponível das pessoas, disponibilidade de salas para reuniões – Obter o acordo do problema a ser resolvido – Estabelecer consenso com o entendimento Quinta Execução do requisito • Aqui o objetivo é levantar informações, de maneira proativa, juntos as partes interessadas. • Um bom uso de algumas técnicas – Não fugir do escopo do projeto; – Rastreabilidade de requisitos (reuso); – Evitar os requisitos implícitos; – Não omitir requisitos; “Mais como vou identificar este requisito se a parte interessada não fala ?” Não se deve esperar que a parte interessada fale tudo que é necessário, se fosse verdade, não precisaríamos de levantar requisitos, basta um tomador de notas. (já ouvimos isso antes... Lembra ?) O bom analista consegue extrair estas informações da parte interessada. Quinta Documentação dos resultados • É uma boa técnica utilizada no levantamento para que: – A informação não se perca; – O conhecimento adquirido possa ser compartilhado; – Outras pessoas possam dar sequencia na análise; – Seja possível confirmar, por meio desta documentação, seu entendimento com as partes interessadas. • Além da documentação das informações colhidas ao realizar a elicitação, é importante registrar as questões que ficaram em aberto e dúvidas que surgiram durante estes evento que por ventura não puderam ser resolvidas. Quinta Confirmação dos resultados do requisito • Imagine: • “Você e seu cônjuge vão a um restaurante, fica ali alguns minutos com o menu em mãos, logo vem um garçom e pergunta se vocês já fizeram a escola, ele escuta suas escolhas e sai... Algum tempo depois chega apenas um pedido... Tudo bem você imagina que o outro irá chegar em breve..... Mais um tempo e você pergunta ao garçom. – O meu outro pedido ainda não chegou !. E a resposta que você ouve é. – Nossa esqueci de pedir !” • Vários pontos de falha poderemos elencar. Quinta Ajustes • Normalmente, em uma primeira versão da documentação há problemas de entendimento, e o documento retorna sem confirmação. – O importante e ajustar os pontos equivocados ou ausentes • Só depois do ajuste uma nova versão e encaminhada as partes interessadas. Técnica: análise de documentos • Dificuldade em conseguir acesso as partes interessadas. – Pouco interesse em analisar documentos onde estão materializados as necessidades do negócio. • Sempre há algo já documentado (por mais simples e fraco que seja) que deve ser analisado primeiro para depois partir para outras técnicas. • Análise de documento: (Estudo dos documentos existentes) – Como realizar (pág. 150) Quinta O que é análise de documentos • É um meio de elicitar requisitos pelo estudo de documentação disponível sobre uma solução existente. – Para identificar informações relevantes para o desenvolvimento de uma solução • Documentação deve ter um significado mais amplo do que especificação de requisitos. – Identificar as necessidades de negócio – Identificar as partes interessadas • Sommervile cita um instrumento chamado de “interação com partes interessadas por meio de entrevistas e observação” Técnica: glossário • Instrumento originalmente usado na gestão do conhecimento. • Serve para identificar os termos chaves para o domínio do problema. – No final de nosso livro de estudo existe um glossário de termos da engenharia de requisitos. – Um exemplo como aplicar – pág. 157 Quinta Técnica : Observação (etnografia) • Usar a observação das atividades dos interessados, para clarear os requisitos. – Nem todas as partes conseguem se articular ou explicar com clareza sobre sua solicitação. • Compreende em observar e tomar o problema como seu, identificar os processos e dificuldades. • Extrair os detalhes, inclusive o como se faz. – Observação Passiva (ou invisível) – Observação Ativa (ou visível) Quinta Técnica : entrevista • Usar a forma de dialogo para buscar respostas parra um grupo de questões previamente elaboradas. • Quando se tem uma resposta, normalmente e utilizada a mesma resposta para elaborar uma outra pergunta par que possa ser clareada a sua solução. • Cuidado com a primeira impressão. – Seja um bom ouvinte – Vá de coração aberto: livre-se de preconceitos – Busque fatos, mas também opiniões. Lembre “A primeira impressão é a que fica” Quinta Formato da entrevista Figura 7.2. Nas entrevistas não estruturadas, o roteiro é apenas um guia para o entrevistador, mas não o obriga a seguir uma sequência prévia de perguntas Tipos básicos de estrutura da entrevista Como preparar a entrevista • Págs. 169 – 173 • Técnica 5W + 3H – What (o quê), Who (quem), Why (por quê), Where (onde), When (quando) – How (como) e How Much (quanto) • Tipos de questões – Abertas – Fechadas • Formato da entrevista – Formal – Informal Quinta Técnica : pesquisa/questionário • Consiste em aplicação de questionário para ser respondido. • Diferente da entrevista, pois não há interação • Risco – Omissão de informação • Aplicado quando há um conhecimento pleno do negócio de ambas as partes. Quinta Como realizar a pesquisa • Selecionar o publico • Preparação de questionário – Questões com respostas limitadas – Questões com respostas livres • Mesmo com muito cuidado na elaboração do questionário, é muito importante que ele seja testado antes de ser distribuído. • Nada serve um questionário bem elaborado se ele não alcança o publico alvo..... Agora estamos no fim..... ...Falta pouco... Seja forte !!! Análise de requisitos “Noite, a amada. Noite, quando palavras se dissolvem e as coisas tornam-se vivas. Quando a destrutiva análise diária está completa, e tudo que é realmente importante se torna inteiro e razoável novamente.Quando o homem junta outra vez o seu ser fragmentado e cresce com a calma de uma árvore.” Antoine de Saint-Exupéry Descoberta tardia que ainda falta muito • Quando o produto não atende às necessidades e as partes interessadas só descobrem quando executam testes de aceitação ou alguns dias antes de instalar em produção. – Isso é uma das expectativas mais frustrantes para todos. • Um fenômeno comum – O projeto apresenta um caminho de conclusão final do projeto, quando na realidade próximo da metade. • Este problema ocorre quando se esclarece qual o marco inicializado para indicar 50% concluído e outro para avaliar 100%. lustrando o paradoxo Visão geral da análise de requisitos • A análise de requisitos é o olhar mais de perto, especificamente cada pedaço de informação revelado na elicitação e sobre como eles se relacionam entre se em conjunto. Sexta Análise de Requisitos Sexta Figura 8.3. Dinâmica da interação entre elicitação e análise, onde os produtos de uma são insumos para a outra Então • Análise de requisitos transforma a informação presente nos requisitos das pastes interessadas e na necessidade de negócio em diferentes processos. – Exame da informação – Decomposição da informação; – Síntese da informação Sexta A análise • Porque ? – Aumentar o entendimento atual da informação, completa- la e melhora-la. • Como realizar ? – Uso da técnicas Os requisitos das partes interessadas são difusos, fragmentados e escondem muitas questões em aberto. Sexta Organizar a partir do exame, decomposição e síntese • O exame em discussão busca identificar requisitos que agregam vários objetivos do usuário. • Garante elucidar questões encobertas Sexta Tratar decisões que impactam o escopo • Deve ser acordado qual opção melhor adequa-se às necessidades de negócio e restrições do domínio do problema. • São decisões que implicam em: – Identificar tarefas; – Consolidar tarefas; – Transferir parte do processamento de tarefas. Sexta Tarefas (Identificar ou descrever) • Identificar o comportamento das tarefas • Decompor as informações • Síntese da informação Sexta Modelar e usar modelos para refinar a informação • O que é modelar ? • Porque modelagem ? • Como Realizar a modelagem ? – Modelos preexistentes – Modelos a elaborar – Tipos quanto a forma – Tipos quanto a informação Sexta Especificar para documentar os requisitos • A modelagem coloca a ênfase na revelação dos requisitos e a comunicação ente as partes. • A Especificação tem a ênfase na transmissão da informação para a equipe de desenvolvimento, mesmo que exija a produção compreensível para todas as partes Sexta O que é especificação • Especificação de requisitos tem papel de documentar os tipos de requisitos. • Formatar a documentação resultante da especificação. – Agora estamos falando em formatar !!!!! • Por que especificar ? – Veja uma relação bem completa que o PMI – 2015 “Project Management Institute” pág. 201 Sexta Tentando fazer um exercício Bernadinho, (Treinador de vôlei) deseja levar um Notbook para os jogos, a fim de obter: - controle do placar. - controle dos pontos de cada partida, identificando-os como: Ponto de saque; Ponto de ataque (quando a vantagem estiver com o time adversário), ponto de contra-ataque (quando a vantagem estiver com o próprio time); Ponto de bloqueio; Erro do adversário. No caso de bloqueio deve cadastrar se é individual, duplo ou triplo. São expectativas de Bernadinho para a implantação dessa aplicação: - cadastrar o nome de todos os jogadores do time e o número de suas camisas; - Para cada jogador, cadastrar a data e hora do jogo, o local o nome do time adversário, os nomes do juiz e juiz auxiliar. - a aplicação dever exibir para controle em cada set, o placar que pode ser alterado pelo auxiliar técnico, informando quem fez o último ponto e o tipo do ponto. No caso do ponto ser do time adversário, basta identificar o tipo do ponto. - ao final de um jogo, o sistema deve exibir a lista dos maiores pontuadores e o somatório de pontos, por tipo e o jogo Como elaborar • Agora depois do exercício fica tudo mais fácil. • Bem aqui, vamos deixar o nosso livro de lado... • Não existe um formato único definido, vários autores descrevem muitos exemplos de modelo. • Nem as normas formalizam isso, pois não é o formato que diz se o requisito será feito com qualidade ou não. – Porém, precisamos de padrões – organizar os métodos para aplicar as técnicas. • Mesmo assim vamos ver alguns modelos e definir o nosso. Sexta Modelo do livro • Podemos ver que o nosso livro de estudo sugere na página 203 um exemplo simples. • No modelo atual do JIRA, não podemos deixar de apresentar alguns requisitos bem elaborado, que pode nos servir de exemplo positivo, e usar como estudo de caso: – https://uniksa.atlassian.net/browse/PRJBNC0071-11 – https://uniksa.atlassian.net/browse/PRJBNC0071-12 • Agora existem muitos outros exemplos bons, só citei estes mais recentes. • Vamos ver alguns templates . . . . . Sexta Modelo de Caso de Uso - Simples Sexta Modelo de Caso de Uso - Detalhado • Contém: – Identificação do ator que iniciou o caso de uso – Objetivo – Nível – Pré-requisitos (se houver) do caso de uso – Condições de disparo (triggers) – Descrição textual do: • Fluxo normal • Fluxos alternativos (se houver) Sexta O modelo que usamos no JIRA • OBJETIVO • DESCRIÇÃO • PRÉ-CONDIÇÕES • PÓS-CONDIÇÕES • CENÁRIO ATUAL • NOVO CENÁRIO Sexta Podemos montar um que nos atenda • Então, percebemos que o formato não é muito relevante. • E sim o conteúdo e a qualidade do requisito que será descrito. • Lembrando que, quando o analista desenvolvedor pede esclarecimento de duvidas sobre o objetivo do requisito diretamente ao Analista de requisitos e este comportamento for muito frequente. – Significa que existe algo errado em algum processo que não foi devidamente explicitado no requisito. • Hora de rever o entendimento com a parte interessada. Sexta Este assunto exige um estudo constante. Não pare de estudar. Obrigado
Compartilhar