Apresentação sobre Requisitos em Engenharia de Software

Engenharia de Software APRESENTAÇÃO DE APOIO Video 1 5 Prof Alessandra Introdução a Requisitos Conceitos Iniciais Tipos de Requisitos Stakeholders O que são Requisitos Requisitos A real arte de descobrir requisitos é descobrir o problema real O foco deve estar na compreensão dos problemas do negócio e prover soluções para tais problemas Negócio referese a pessoas que interagem para executar um conjunto de atividades de entrega de valor para os clientes e gerar retorno as partes interessadas Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais SOMMERVILLE 2007 Um requisito de um sistema e uma característica do sistema ou a descrição de algo que o sistema e capaz de realizar para atingir seus objetivos PFLEEGER 2004 Requisitos Um requisito e alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar ROBERTSON 2006 Requisitos são especificações que estabelecem o que deve ser implementado São descrições de como o sistema deve se comportar de uma propriedade ou atributo do sistema Requisitos EU PRECISO SABER DOS SEUS REQUISITOS ANTES QUE EU COMECE A PROJETAR O SOFTWARE PRIMEIRAMENTE O QUE VOCÊ ESTÁ QUERENDO FAZER EU ESTOU TENTANDO FAZER VOCÊ PROJETAR MEU SOFTWARE EU QUERO DIZER O QUE VOCÊ ESTÁ QUERENDO FAZER COM O SOFTWARE EU NÃO VOU SABER O QUE ESTOU QUERENDO FAZER ATÉ QUE VOCÊ ME DIGA O QUE O SOFTWARE PODE FAZER TENTE COLOCAR ISSO NA SUA CABEÇA DURA O SOFTWARE PODE FAZER QUALQUER COISA QUE EU PROJETE QUE ELE FAÇA VOCÊ PODE PROJETÁLO PARA QUE ELE LHE DIGA OS MEUS REQUISITOS Requisitos Requisitos servem como especificação do que deve ser implementado Requisitos são descrições do que o sistema deve fazer os serviços que oferece e as restrições de seu funcionamento Um requisito pode descrever uma facilidade encontrada no nível do usuário uma propriedade geral do sistema uma restrição do sistema uma restrição ao desenvolvimento do sistema Requisitos Ha varias classificações possíveis de requisitos Uma classificação e Requisitos de usuário Requisitos de sistema Outra classificação e Requisitos funcionais Requisitos nãofuncionais Requisitos de Domínio Regras de Negócio Requisitos de Usuário x Requisitos de Sistemas Requisito de usuario Declaração abstrata em alto nivel de um serviço que o sistema deve oferecer ou uma restrição a um sistema Nivel de definição abrangente Requisito de sistema Definição detalhada e formal de uma função de um sistema Nivel de definição detalhado Requisitos Classificação Quanto ao tipo de informação os requisitos podem ser classificados em Requisitos funcionais Requisitos nãofuncionais Requisitos de Dominio Regras de Negócio Requisitos Requisitos funcionais requisitos nãofuncionais e regras de negócio podem ser confundidos como sinônimos mas possuem caracteristicas diferentes Uma primeira diferença Requisitos Funcionais e Requisitos Não Funcionais referemse ao sistema Ex o sistema deve permitir que um cliente realize a compra de produtos do catálogo Regras de Negócio são independentes do sistema Ex aqui na empresa só vendemos para clientes adimplentes O que são Requisitos Funcionais Requisitos Funcionais São declarações de serviços que o sistema deve fornecer Podese definir tambem o que o sistema não deve fazer 2 RF Requisitos Funcionais Descreve uma ação que o produto deve realizar para ser útil para seu funcionamento Praticamente qualquer ação pode representar um requisito funcional calcular inspecionar publicar Requisitos Funcionais são coisas que o produto deve fazer Exemplos O produto deve gerar a programação da produção mensal da fábrica com base nas quantidades a serem produzidas de cada produto a partir da previsão de vendas O produto deve gerar as faturas de cobrança mensal para os assinantes de acordo com o seu plano contratado O sistema deve emitir relatórios de vendas de cada mês 2 RF Requisitos Funcionais Um Requisito Funcional define uma funcionalidade ou serviço do sistema Descreve como o sistema transforma entradas em saídas Descreve como o sistema se comporta em situações especiais Descreve como o sistema NÃO deve se comportar 2 RF Requisitos Funcionais Características esperadas Completeza todos os serviços requeridos pelo usuário devem ser definidos Consistência as definições não devem ser contraditórias ou ambíguas Obs o Para sistemas grandes ou complexos garantir a completeza pode ser mais difícil pela amplitude do sistema ou dos stakeholders envolvidos e tambem pode gerar inconsistências entre os requisitos 2 RF Requisitos Funcionais Exemplos Emprestimo de Livro O sistema deve permitir a inclusão alteração e exclusão dos livros da Biblioteca Cada livro deverá ter um identificador único O usuário ao pegar um livro emprestado o sistema deverá verificar se o livro está Cadastrado Ativo Disponível ou seja não reservado Que o usuário não esteja com cinco livros emprestados considerando que esse seja o número máximo de emprestimos simultâneos permitido O sistema deverá gerar um recibo de emprestimo 2 O QUE SÃO REQUISITOS NÃO FUNCIONAIS Requisitos Não Funcionais São restrições aos serviços e funções oferecidos pelo sistema Muitas vezes se aplicam por todo o sistema 2 RNF Requisitos Não Funcionais Um Requisito NãoFuncional define restrições ou qualidades do sistema Podem afetar vários requisitos funcionais Existem várias classificações possíveis Uma classificação possível Usabilidade Confiabilidade Desempenho Portabilidade Obs Um requisito não funcional pode gerar novos requisitos funcionais Pode haver relacionamento entre os requisitos 2 RNF Requisitos Não Funcionais Descrevem uma propriedade ou qualidade que o produto deve exibir para ser aceito pelo seus stakeholders Em alguns casos requisitos nãofuncionais são críticos para o sucesso do produto Especificam propriedades tais como performance usabilidade aparência atributos legais Requisitos nãofuncionais são qualidades que o produto deve ter Exemplos O sistema deve suportar 2000 usuários concorrentemente O sistema deve impedir que qualquer dado pessoal ou confidencial seja imprimível O produto deve utilizar a ortografia do inglês britânico RNF Requisitos Não Funcionais Exemplos A resposta do sistema deve ser em até 3 segundos após uma solicitação Os relatórios são gerados em formato PDF não editável Caracteristica esperada Verificáveltestável declarar o requisito nãofuncional de forma que seja possivel identificar uma métrica associada Exemplos Velocidade transaçõessegundo Facilidade de uso número de erros na utilização Portabilidade percentual de declaraçõesbibliotecas dependentes da plataformaalvo RNF Tipo de Requisitos Não Funcionais 1 Organizacionais referese a políticas e procedimentos nas organizações do cliente e do desenvolvedor Políticas de entrega de implementação padrões de processo 2 Externos referese a fatores externos ao sistema e ao seu processo de desenvolvimento Fatores de interoperabilidade interação do sistema com outros éticos legais privacidade e de segurança 3 De produto especificam o comportamento do produto Comportamentos em relação a eficiência desempenho espaço rapidez memória confiabilidade portabilidade RNF Requisitos Não Funcionais Exemplos O que são Regras de Negócio Regras de Negócio Regras de Negócio definem ou restringem aspectos da organização empresa 2 RN Requisito ou Regra de Negócio Caracteristicas É independente do sistema Define as características próprias de como a organização funciona Podem gerar requisitos nãofuncionais e funcionais Exemplos Na nossa empresa só vendemos produtos para clientes adimplentes Na nossa empresa não aceitamos pagamento por cartão de crédito O que são Stakeholders Stakeholders Conceito Os requisitos devem ser redigidos de modo a serem passiveis de entendimento pelos diversos interessados stakeholders São pessoas ou organizações envolvidas no projeto que podem influenciar positivamente ou negativamente o projeto 31 Stakeholders Conceito Stakeholders Exemplos Supondo um Projeto de Desenvolvimento de Software são exemplos de Stakeholders Cliente que esta contratando Gerente do Projeto Arquitetos Fornecedores Desenvolvedores Stakeholders podem ser áreas ou nome das pessoas envolvidas são TODOS que estão envolvidos seja para apoiar ou para influenciar negativamente o projeto Porque investir em Requisitos Os indicadores do mercado mostram que o ROI em solução para gerência de requisitos é muito vantajoso Referências Biliográficas SOMMERVILLE Ian Engenharia de Software 10 ed New York AddisonWesley 2019 ISBN 8543024978 768p PFLEEGER Shari L Engenharia de Software teoria e prática 4 ed São Paulo Prentice Hall 2004 ISBN 8587918311 OBRIGADA PELA ATENÇÃO E ATÉ A PRÓXIMA AULA PUCRS online UOL edtech Engenharia de Software APRESENTAÇÃO DE APOIO Video 2 5 Prof Alessandra Engenharia de Requisitos Conceitos Iniciais Elicitação e Análise de Requisitos de Sistema Processos da Engenharia de Requisitos Técnicas de Elicitação de Requisitos ENGENHARIA DE REQUISITOS Engenharia de Requisitos Engenharia de requisitos é a área da engenharia de software que se ocupa dos objetivos do mundo real para a especificação das funcionalidades e restrições de um sistema de software Engenharia de requisitos envolve a descoberta elicitação desenvolvimento análise determinação de métodos de verificação validação comunicação documentação e gerenciamento de requisitos Atividades de um Engenheiro de Requisitos Comunicar os requisitos Planejar as atividades de requisitos Definir os requisitos de negócio Realizar a elicitação de requisitos Realizar a análise de requisitos Documentar os requisitos Conduzir a validação dos requisitos Facilitar a priorização dos requisitos Identificar os stakeholders do projeto e as classes de usuários Gerenciar os requisitos ELICITAÇÃO E ANÁLISE DE REQUISITOS DE SISTEMAS Engenharia de Requisitos Elicitação Especificação Validação Processos da Engenharia de Requisitos Elicitação Especificação Validação Os processos da Engenharia de Requisitos são Eliticação Especificação e Validação Processos da Engenharia de Requisitos Elicitação Especificação Validação 1 Elicitação levantamento de requisitos a Descoberta identificação derequisitos b Classificação e organização organização derequisitos c Priorização e negociação resolução deconflitos 1 Elicitação levantamento de requisitos a Descoberta identificação de requisitos Os analistas trabalham com o cliente e usuários para descobrir mais informações sobre o domínio da aplicação serviços do novo sistemae restrições operacionais Stakeholders usuários finais gerentes engenheiros envolvidos em manutenção especialistas no domínio etc Processos da Engenharia de Requisitos 1 Elicitação levantamento de requisitos Desafios As pessoas podem não saber o que realmentequerem Stakeholders expressam requisitos em seus própriostermos Stakeholders diferentes podem ter requisitosconflitantes Fatores organizacionais e políticos podem influenciar os requisitos do sistema Os requisitos mudam durante o processo de análise Novos stakeholders podem surgir e o ambiente de negóciomudar Processos da Engenharia de Requisitos 1 Elicitação levantamento de requisitos b Classificação e organização organização de requisitos Classificar requisitos identificados por similaridade Organizar requisitos em grupos exmódulos Vários requisitos identificados podem se tornar apenas um requisito com mais de um cenário conjunto de passos ou atividades para atingir um resultado Processos da Engenharia de Requisitos 1 Elicitação levantamento de requisitos c Priorização e negociação resolução de conflitos Em caso de requisitos conflitantes é necessário negociar com os stakeholders envolvidos a resolução ou ajuste dos requisitos Priorizar requisitos mais importantes Processos da Engenharia de Requisitos Processos da Engenharia de Requisitos Elicitação Especificação Validação 2 Especificação descrição de requisitos Usualmente gera um Documento de Requisitos às vezeschamado de Especificação de Requisitos de Software ou SRS Software Requirements Specification A especificação de requisitos pode ser realizadade diversas formas Sentenças em linguagem natural Linguagem natural estruturada Diagramas Tabelas Especificações matemáticas Processos da Engenharia de Requisitos Sentenças em linguagem natural Interessante para a especificação de requisitos dousuário Diretrizes Busque utilizar uma sintaxe padrão Ex Sujeitoação consequência O sistema deve emitir relatório de gastos mensais no início do mês O usuário deve ser capaz de cadastrar um novo produto no sistema Use um subconjunto de verbos para definir requisitosobrigatórios ex deve e opcionais expode Evite jargão de informática Sempre que possível associar o racional de cada requisito Ex O sistema deve emitir relatório de gastos mensais no início do mês O setor contábil precisa dos dados até o final da primeira semana e os gastos podem variar muito de uma semana paraoutra Processos da Engenharia de Requisitos Linguagem natural estruturada Interessante para permitir que o usuário consiga ler a especificação e a equipe técnica ter uma base mais detalhada para o desenvolvimento do software Ex Detalhamento textual de caso de uso Diagramas e outras técnicas Podem facilitar o entendimento da equipe técnica mas dificultar parao usuário Ex User Stories para Requisitos Funcionais Processos da Engenharia de Requisitos Processos da Engenharia de Requisitos Elicitação Especificação Validação 3 Validação garantia da validade dos requisitos Prototipação geração de casos de teste revisõeschecklists Atividades comuns Identificação e entendimento de requisitos Avaliação e comprometimento com os requisitos Rastreabilidade bidirecional de requisitos Revisão do planejamento em relação aos requisitos Gerenciamento de mudanças de requisitos Processos da Engenharia de Requisitos Atividades para uma Sessão de Elicitação Definição do escopo e agenda da elicitação Preparação dos recursos necessários Preparação das questões e de drafts de modelos de apoio Realização da sessão de elicitação Organização e compartilhamento de anotações Registro dos aspectos em aberto Preparação para elicitação Realização das atividades da elicitação Followup após elicitação 1 Entrevistas 2 Workshops 3 Observação 4 Questionário 5 Análise da interface entre sistemas 6 Análise de interfaces de usuários 7 Análise de documentos Técnicas de Elicitação 1 Entrevistas Perguntas Fechadas Você estava sozinho no carro Perguntas Abertas Porque você estava sozinho no carro Queremos saber O que Quem Quando Onde Como Porque 1 Entrevistas A qualidade das entrevistas depende muito do planejamento feito pelo entrevistador A arte do entrevistador consiste em criar uma situação onde as respostas do informante sejam fidedignas e válidas SELLTIZ Claire et allii Métodos de pesquisa nas relações sociais Tradução de Maria Martha Hubner de Oliveira 2a edição São Paulo EPU 1987 A situação em que é realizada a entrevista contribui muito para o seu sucesso o entrevistador deve transmitir acima de tudo confiança ao informante 1 Entrevistas No Planejamento definir Contexto da entrevista Script dedique tempo para a preparação da entrevista Não ficar preso ao script mas garantir que o script seja cumprido Aproveitar as oportunidades que eles derem quando falam sobre algo perguntas adicionais O perfil dos stakeholdersclientes a serem entrevistados 2 Workshops Wokrkshop no português significa oficina que também pode ser interpretado como um grupo de discussão mais participativo O workshop é um evento onde acontece uma reunião de pessoas interessadas em determinado assunto para aperfeiçoar técnicas por meio da explicação de palestrantesconvidados e de atividades práticas Para organizar um workshop Prepare a agenda defina os entregáveis selecione os participantes encoraja a participação ativa dos participantes ter pelo menos um facilitador 3 Observação A observação pode ser usada para entender requisitos sociais organizacionais O Observador emerge no ambiente de trabalho onde a solução será usada observando o trabalho cotidiano e tomando notas das tarefas em execução nas quais as partes interessadas estão envolvidas Ela então é um meio de elicitar requisitos pela condição de uma avaliação do ambiente de trabalho das partes interessadas quando documentando detalhes sobre um processo existente ou quando se propõe melhorar ou modificar um processo atual 4 Questionário Utilizado para elicitação em grandes grupos de usuários Questionários ganham uma dimensão extra como ferramentas de avaliação principalmente quando se trata de estudos que envolvam diretamente a satisfação do usuário eou que visem respostas sobre como os usuários interagem com os sistemas e quais as características que particularmente os satisfazem ou desagradam 5 Análise da Interface entre os sistemas Interface é o nome dado a toda a porção de um sistema com a qual um usuário mantém contato ao utilizálo tanto ativa quanto passivamente Permite a identificação de interfaces de dados e serviços entre sistemas levando ao conhecimento das funcionalidades dos sistemas com quem o sistema a ser desenvolvido deve se relacionar 6 Análise de interfaces de usuários Estudo da interfaces de usuário dos sistemas existentes similares ao sistema a ser desenvolvido 7 Análise de documentos A análise de documentos é um meio de elicitar requisitos pelo estudo de documentação disponível sobre uma solução existente para identificação de informação relevante para o desenvolvimento de uma nova solução A vantagem é que não se trata de um trabalho iniciado do zero já que aproveita um material existente para descobrir ou validar requisitos Entrevista Workshop Observação Questionário Análise da interface entre sistemas Análise de interfaces de usuários Análise de documentos Mercado massivo X X Uso interno corporativo X X X X X Substituição de software existente X X X X X X Melhoria de software existente X X X X X Aplicação nova X X X Implementação de pacote X X X X X Sistema embarcados X X X X Stakeholders geograficamente distribuídos X X X Boas Práticas para a Análise de Requisitos Modele o ambiente da aplicação Crie a interface do usuário e protótipos técnicos Analise a exequibilidade dos requisitos Priorize os requisitos Crie um dicionários de dados Modele os requisitos Analise as interfaces entre o sistema e o ambiente externo Aloque requisitos aos subsistemas Referências Biliográficas SOMMERVILLE Ian Engenharia de Software 10 ed New York AddisonWesley 2019 ISBN 8543024978 768p PFLEEGER Shari L Engenharia de Software teoria e prática 4 ed São Paulo Prentice Hall 2004 ISBN 8587918311 VAZQUEZ C E SIMÕES GS Engenharia de Requisitos software orientado ao negócio Brasport 328p 2016 OBRIGADA PELA ATENÇÃO E ATÉ A PRÓXIMA AULA PUCRS online UOL edtech Engenharia de Software APRESENTAÇÃO DE APOIO Video 3 3 Prof Alessandra Exercícios sobre Requisitos Funcionais Não Funcionais e Regras de Negócios ENGENHARIA DE REQUISITOS Exercícios httpsmirocom Engenharia de Requisitos Pensando em um sistema bancário vamos identificar 10 Requisitos Funcionais deste sistema e colocar no Miro wwwmirocom Exercício Ao lado vêse uma cena típica envolvendo o pagamento de uma compra por meio de cartão de crédito em um estabelecimento comercial Pense sobre esta situação e identifique possíveis exemplos de Requisitos Funcionais Requisitos NãoFuncionais Aula 2 Engenharia de Requisitos Pensando em um sistema de Vendas pela Internet vamos identificar 10 Requisitos Funcionais desse sistema e colocar no Miro wwwmirocom Engenharia de Requisitos Vamos agora fazer a identificação de 5 Requisitos Não Funcionais do Sistema de Vendas do exercício anterior e colocar no Miro wwwmirocom Engenharia de Requisitos Vamos agora fazer a identificação de algumas regras de negócio Referências Biliográficas SOMMERVILLE Ian Engenharia de Software 10 ed New York AddisonWesley 2019 ISBN 8543024978 768p PFLEEGER Shari L Engenharia de Software teoria e prática 4 ed São Paulo Prentice Hall 2004 ISBN 8587918311 OBRIGADA PELA ATENÇÃO E ATÉ A PRÓXIMA AULA PUCRS online UOL edtech Engenharia de Software APRESENTAÇÃO DE APOIO Video 4 5 Prof Alessandra Engenharia de Requisitos User Stories De onde vieram as User Stories O que são User Stories Estrutura Cuidados Priorização USER STORIES De onde vieram as User Stories Elas surgiram no XP extreme programming no final da década de 80 E seu principal objetivo era representar o desejo do usuário por algum funcionalidade Além de representar um desejo as estórias de usuário também deveriam ser de fácil priorização 4 São descrições simples e curtas de uma determinada funcionalidade requerida pelo cliente de acordo com o ponto de vista dele Utilizadas no processo de desenvolvimento de software seguindo os conceitos de metodologias ágeis O Termo em inglês é story estória conto e não history história relato de fatos O que são User Stories O que são User Stories User Story Descrição de uma necessidade para um público específico com um valor de negócio Temas Um grupo de stories Épicos Grande feature sem especificação ou definição clara é uma story grande bruta Eu como tipo do usuário gostariaquerodevo objetivo com opara que propósito EXEMPLOS Como usuário quero fazer backup do meu drive para que eu possa salvar minhas informações de forma segura Como caixa quero acessar sistema de vendas para que eu possa concluir a compra do cliente Como comprador de livros quero utilizar meu cartão de crédito no pagamento dos livros escolhidos para que eu possa ter praticidade e segurança no pagamento Estrutura As a user role I want goal so that benefit CARTÃO ambiente em que a User Story será escrita cartão ou ficha QUEM define quem utilizará Pode ser tipo de usuário do produto uma persona ou um usuário mais específico O QUE define a necessidade do usuário Os requisitos do produto são normalmente representados apenas por essa parte Componentes de uma User Story POR QUÊ define o benefício que o usuário terá depois que a funcionalidade for desenvolvida ou seja o valor direto obtido por ele CRITÉRIOS DE ACEITAÇÃO como a funcionalidade deve se comportar o que deve ser implementado NOTAS informações adicionais relevantes para o desenvolvimento Componentes de uma User Story Exemplos Pagamento via Cartão de Crédito Como um cliente Eu gostaria de pagar usando meu cartão de crédito para poder parcelar minhas compras Critérios de Aceitação Teste com MC Visa e Amex válidos deve passar Compra com outros cartões válidos não pode passar Compra com cartões expirados não deve passar Teste com CEP inválido deve bloquear pgto Critérios para aceitação O vendedor não pode solicitar a busca se não informar o nome do livro O sistema encontrando o livro deve apresentar todos os dados do livro nome completo autores editora ano de edição e a quantidade em estoque O sistema não encontrando o livro deve informar que o livro não foi encontrado Qualidade 3Cs CARDS devem ser escritas em cartões para que sejam curtas CONVERSATION lembrar funcionalidades conversadas e discutidas com o cliente CONFIRMATION cliente define uma maneira de como validar O que fazer Conversar com o cliente para que fique claro os detalhes do problema e para definir suas possíveis soluções Definir funcionalidades que gerem valor Estabelecer critérios de aceitação Definir prioridades Reuniões com o cliente e integrantes do time de desenvolvimento participando juntos READY Definition of Ready DoR É um acordo entre o time de Desenvolvimento e o Product Owner aplicado a todas as User Stories com a intenção de que os itens do Backlog não cheguem para a reunião de planejamento com granularidade ruim pouco ou nenhum detalhamento Antes que um item do Backlog entre para a Sprint o time deve garantir que ele esteja atendendo aos critérios de Ready em termos de estarem suficientemente bem descritos e compreendidos por todo time de desenvolvimento para que eles tenham condições suficiente para planejálo em uma Sprint e estabelecer um compromisso em relação à sua implementação 16 Definition of Done DoD É um acordo definido pelos Desenvolvedores e Product Owner aplicável a todas as User Stories com o intuito de que todos os membros do time tenham um entendimento compartilhado do que significa Done para garantir a transparência É uma lista de verificação de atividades necessárias para que um incremento de software seja considerado como completo 17 O Que Cuidar Quando for Escrever as User Stories 5 Dicas 1 Estória Pequena demais Quanto se tem a necessidade frequente de revisar as estimativas Este problema ocorre quando uma estória influencia nas estimativas caso a ordem de implementação seja alterada 19 2 Estória Interdependente Quando se tem dificuldade de planejar iterações devido às dependências entre as estórias Este problema ocorre quando uma estória que deve entrar na próxima Sprint precisa uma outra estória que por sua vez precisa de uma terceira e Estórias pequenas demais ou mal quebradas fazem com que esse tipo de problema venha a ocorrer 20 3 Estória Goldplating Quando os desenvolvedores adicionam funcionalidades que não foram planejadas e acabam implementando mais que o necessário Goldplating referese a funcionalidades adicionais desnecessárias geralmente porque o desenvolver que agradar o clientes querem fugir da pressão da Sprint e fazer outras atividades eou gostam de colocar a sua marca no projeto 21 4 Estória muito detalhada Quando gastase muito mais tempo escrevendo os detalhes da estória que falando sobre ela Uma das vantagens de utilizar os cartões para escrever é que eles são limitados Colocar muitos detalhes em um estória indica que a documentação esta sobrepondo a comunicação 22 5 Estória difícil de ser priorizada Quando o cliente sente muita dificuldade de priorizar diversas estórias A primeira coisa a considerar é o tamanho das estórias Estórias muito grandes geralmente são mais difíceis de priorizar O seu valor de negócio deve não estar claro 23 INVEST INDEPENDENT stories devem ser independentes umas das outras NEGOTIABLE não são contratos mas lembretes para discussões VALUABLE devem agregar valor para o cliente ESTIMABLE o tamanho da user story deve ser estimável SMALL devem ser curtas TESTABLE devem possíveis de serem testadas Segundo Mike Cohn uma user story só é considerada válida se seguir todas as características do modelo INVEST Product Backlog Priorização Priorização Técnica descrita no DSDM Dynamic Systems Development Method que pode ajudar na priorização Esta técnica pode ser encontrada no livo Business Focused Development Este técnica recebe o nome de MoSCow 26 Priorização MoSCoW Dicas para fazer uma boa User Story Menos é mais As user stories devem ser curtas e simples sem explicações e detalhes Toda estória deve entregar valor para o cliente Toda estória deve ter critérios de aceitação Fazer levantamento de esforço X valor Focar nas necessidades reais e práticas do usuário As estórias não devem conter termos técnicos Se o desenvolvimento da user story ficar extenso demais quebrea em outras estórias menores Pensar também no caminho triste fluxo alternativo Diversão Referências Biliográficas SOMMERVILLE Ian Engenharia de Software 10 ed New York AddisonWesley 2019 ISBN 8543024978 768p LAPLANTE PA Requirements Engineering for Software and Systems 3a edição CRC Press 2017 378p ISBN 9781138196117 COHN M User Stories Applied For Agile Software Development Boston AddisonWesley Professional 2014 304p OBRIGADA PELA ATENÇÃO E ATÉ A PRÓXIMA AULA PUCRS online uol edtech Engenharia de Software APRESENTAÇÃO DE APOIO Video 5 5 Prof Alessandra Engenharia de Requisitos User Story Mapping Conceito inicial Objetivo Estrutura Exemplos Exercício ESPECIFICAÇÃO DE REQUISITOS EM MÉTODOS ÁGEIS Engenharia de Requisitos Prof Ricardo M Bastos O que é User Story Mapping Jeff Patton descreveu pela primeira vez o Mapeamento de Estórias em seu artigo Its All in How You Slice it em 2005 Ele não chamou de Mapeamento de Estórias na época Ele cunhou esse termo em seu artigo The New User Story Backlog Is a Map em 2008 Ele também escreveu um livro sobre o assunto User Story Mapping Discover the Whole Story Build the Right Product Engenharia de Requisitos Prof Ricardo M Bastos O que é User Story Mapping O User Story Mapping foi criada para ajudar os Gerentes de Produtos Product Owners e seus times a organizarem o backlog do Produto de uma forma que auxilie na comunicação visual de forma eficiente e com um contexto Ela se baseia na organização dos principais requisitos do produto sob a ótica da jornada do usuário Para Jeff Patton o time reclama da perda de visão de todo o backlog pois geralmente trabalhamos apenas com User Stories tendo muita dificuldade de explicar o funcionamento do software por meio de um backlog da forma habitual Engenharia de Requisitos Prof Ricardo M Bastos Objetivo do User Story Mapping O User Story Mapping tem como objetivo Contextualizar todo o desenvolvimento do projeto por meio de uma jornada do usuário que são um conjunto de atividades dispostas em uma linha do tempo nas quais são cortadas em estórias menores e dessas são geradas as tarefas para as entregas dessas estórias Engenharia de Requisitos Prof Ricardo M Bastos User Story Mapping The real goal of using stories is shared understanding Jeff Patton Peter Economy O Princípio Converse com os stakeholders sobre o negócio e seus objetivos Porque você precisa da aplicação Quais são os benefícios esperados para você e para as pessoas que usarão a aplicação Quais problemas serão resolvidos para estas pessoas e para você Procure entender quais são os resultados outcomes que os stakeholders estão procurando obter não as saídas outputs que eles querem produzir Engenharia de Requisitos Prof Ricardo M Bastos User Story Mapping Engenharia de Requisitos Prof Ricardo M Bastos Visão Breve descrição do propósito e objetivo do produto bem como dos benefícios esperados para a organização e seus usuários Identifique os diferentes tipos de usuários e relacione os benefícios esperados Qual seria o propósito de utilizar o produto O que deveria ser possível realizar com o produto Engenharia de Requisitos Prof Ricardo M Bastos Visão Exemplo O sistema AudioLivros deve permitir a pessoas voluntárias selecionarem trechos de livros previamente disponíveis gravar a leitura do trecho selecionado e submeter sua gravação Quando todos os trechos de um livro estiverem gravados pelos voluntários a Editora poderá editar o livro no formato de um áudiolivro em especial em benefício da comunidade com dificuldades visuais Neste sentido a Editora estará viabilizando que os livros por ela editados sejam acessíveis de forma gratuita para pessoas com dificuldades visuais ampliando sua atuação junto a sociedade Engenharia de Requisitos Prof Ricardo M Bastos Story Mapping Estrutura 1 Identificar os Usuários 2 Identificar as Atividades 3 Criar os Passos do usuário Onde se encontra o Backbone que é a estrutura que será a base de seu mapeamento Ele é concebido de forma horizontal e segue uma sequência de atividades na jornada do usuário durante a utilização do seu produto que será feito por meio de temas e épicos 4 Escrever os Detalhes Engenharia de Requisitos Prof Ricardo M Bastos Usuários Editora Deseja editar livros de seu acervo no formato de áudio livro de forma gratuita Pretende Disponibilizar os livros na forma de trechos para gravação por doadores de voz Receber as gravações para posterior edição e publicação do áudiolivro Doador de voz Pessoa que voluntariamente se dispõe a gravar trechos de um livro para doação a editora para composição do áudiolivro Necessita Ter acesso aos trechos do livro para gravação e posterior submissão da gravação Acompanhar a edição do livro Autor do livro Gostaria de ter seu livro Disponibilizado para a sociedade de forma gratuita na forma de áudiolivro Contribuir com gravações de partes do livro que entender relevante Acompanhar o processo de geração do áudio livro Engenharia de Requisitos Prof Ricardo M Bastos Mapeando a Big Picture Atividades Passos Detalhes Backbone Engenharia de Requisitos Prof Ricardo M Bastos Backbone Disponibilizar livros para doação de voz Editora Doador de voz Atividades Usuários Revisar áudiolivro Disponibilizar áudiolivro Realizar a doação do livro Realizar a doação da voz Realizar gravação de áudio para o livro Autor Engenharia de Requisitos Prof Ricardo M Bastos Backbone Fluxo da Narrativa Disponibilizar livros para doação de voz Editora Doador de voz Atividades Usuários Editar o áudiolivro Disponibilizar o áudiolivro Realizar a doação do livro Realizar a doação da voz Realizar gravação de áudio para o livro Autor Autor Editora Engenharia de Requisitos Prof Ricardo M Bastos Backbone Passos Disponibilizar livros para doação de voz Editora Revisar áudiolivro Disponibilizar áudiolivro Atividades Usuários Registrar livro e seus capítulos Passos Registrar blocos de leitura dos capítulos de um livro Revisar áudio dos blocos de leitura Publicar áudio livro Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Registrar livro e seus capítulos Passos Registrar blocos de leitura dos capítulos de um livro Revisar áudio dos blocos de leitura Publicar áudiolivro Cadastrar bloco de livrocapítulo Excluir bloco de livrocapítulo Alocar bloco para um doador de voz Aprovar áudio de um bloco Rejeitar áudio de um bloco Incluir livro no site da Editora Detalhes Disponibilizar livros para doação de voz Editora Revisar áudiolivro Disponibilizar áudio livro Atividades Usuários Cadastrar capítulo de um livro Cadastrar livro Extrair livro Editar livro Excluir livro Editar capítulo de um livro Excluir capítulo de um livro Consultar status blocos de um livro Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doador de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doador de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Autor do Livro Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Como papelfunção eu querogostariadevo objetivometa para que resultadobenefíciovalor Transformar em User Stories Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doados de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Eu Como Doador de voz gostaria de Consultar os status blocos de um livro para que eu possa saber como esta o status da gravação Transformar em User Stories Engenharia de Requisitos Prof Ricardo M Bastos User Story Perspectiva Benefício Objetivo Como papelfunção eu querogostariadevo objetivometa para que resultadobenefíciovalor Exemplo Como cliente eu gostaria de pesquisar produtos de meu interesse para que eu possa adicionar ao meu pedido de compra Engenharia de Requisitos Prof Ricardo M Bastos Escrevendo User Stories Efetivas User stories bem estruturadas expressam uma única ação para atingir um objetivo específico Exemplo Como Editora eu gostaria de registrar um livro seus capítulos e seus blocos de leitura para que que seja possível a reserva de um bloco por um doador de voz Esta user story tem 3 pensamentos distintos Ficaria mais claro expressarmos cada pensamento em uma user story Como Editora eu gostaria de cadastrar um livro para que eu possa registrar os seus capítulos Como Editora eu gostaria de cadastrar um capítulo em um livro para que eu possa adicionar seus blocos de leitura Como Editora eu gostaria de registrar blocos de leitura associados a um capítulo de livro para que seja possível sua reserva por um doador de voz Thomas e Angela Hathaway Writing Effective User Stories Engenharia de Requisitos Prof Ricardo M Bastos Escrevendo User Stories Efetivas Uma user story efetiva enfatiza o que deve ser feito não como deve ser feito Exemplos Errado Como um cliente eu posso selecionar o Estado em que moro utilizando uma caixa dropdown de abreviações para evitar o registro de um Estado não válido para o cálculo do preço do serviço Certo Como um cliente eu gostaria de informar uma abreviação válida do Estado em que moro para evitar o registro de um Estado não válido para o cálculo do preço do serviço Engenharia de Requisitos Prof Ricardo M Bastos EXEMPLO DE COMO ESCREVER AS USER STORY DO STORY MAPPING APRESENTADO Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doador de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Eu Como Doador de Voz gostaria de Consultar os livroscapítulos blocos para que eu possa saber como esta o status da gravação Transformar em User Stories Eu Como Doador de Voz gostaria de Consultar os livroscapítulos blocos para que eu possa saber como esta o status da gravação Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doador de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Eu Como Doador de Voz gostaria de Reservar o bloco para que eu possa doar minha voz Transformar em User Stories Eu Como Doador de Voz gostaria de Cancelar a reserva do bloco para que eu possa escolher outro bloco Engenharia de Requisitos Prof Ricardo M Bastos Detalhes Selecionar livrocapítulobloco Passos Detalhes Realizar a doação da voz Doador de Voz Atividades Usuários Consultar livroscapítulosblocos Reservar bloco Cancelar reserva de bloco Fazer upload de áudio de um bloco Consultar blocos reservados Fazer upload áudio bloco reservado Cancelar upload áudio bloco Consultar andamento geração áudiolivro Realizar a doação da voz Consultar status blocos de um livro Eu Como Doador de Voz gostaria de Cancelar um upload de áudio bloco para que eu fazer um novo upload Transformar em User Stories Eu Como Doador de Voz gostaria de Fazer upload de áudio de um bloco reservado para que possa ser montado um livro Referências Biliográficas PATTON J User Story Mapping Discover the Whole Story Build the Right Product Edi OReilly Media 2005 OBRIGADA PELA ATENÇÃO E ATÉ A PRÓXIMA AULA PUCRS online uol edtech Engenharia de Software Checkpoints Aula 5 Requisitos Questão 1 ENADE 2017 A engenharia de requisitos do ponto de vista do processo de software é uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e contínua na de modelagem Ela deve ser adaptada às necessidades do processo do projeto do produto e das pessoas que estão realizando o trabalho Considere os requisitos a seguir de um sistema de uma universidade na qual se pretenda gerenciar o setor acadêmico R1 o sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou R2 o sistema deverá ser desenvolvido de formar a possibilitar seu transporte para outro sistema operacional em no máximo sessenta dias R3 o sistema deve permitir que um estudante realize a sua matrícula nas disciplinas oferecidas em um semestre letivo R4 o sistema atualiza a nota do estudante permitindo sua visualização em até dois segundos depois do momento que o professor a registra R5 o sistema deve permitir que o auxiliar de serviços acadêmicos realize o cadastro de um estudante em não mais do que dez minutos de orientação Nessa situação representam descrições de requisitos não funcionais apenas os requisitos A R1 R2 e R3 B R1 R2 e R5 C R1 R3 e R4 D R2 R4 e R5 E R3 R4 e R5 Questão 1 ENADE 2017 A engenharia de requisites do ponto de vista do processo de software é uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e contínua na de modelagem Ela deve ser adaptada às necessidades do processo do projeto do produto e das pessoas que estão realizando o trabalho Considere os requisitos a seguir de um sistema de uma universidade na qual se pretenda gerenciar o setor acadêmico R1 o sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou R2 o sistema deverá ser desenvolvido de formar a possibilitar seu transporte para outro sistema operacional em no máximo sessenta dias R3 o sistema deve permitir que um estudante realize a sua matrícula nas disciplinas oferecidas em um semestre letivo R4 o sistema atualiza a nota do estudante permitindo sua visualização em até dois segundos depois do momento que o professor a registra R5 o sistema deve permitir que o auxiliar de serviços acadêmicos realize o cadastro de um estudante em não mais do que dez minutos de orientação Nessa situação representam descrições de requisitos não funcionais apenas os requisitos A R1 R2 e R3 B R1 R2 e R5 C R1 R3 e R4 D R2 R4 e R5 E R3 R4 e R5 Questão 2 ENADE 2021 A etapa de definição de requisitos é voltada para estabelecer quais as funções são requeridas pelo sistema e as restrições sobre a operação e o desenvolvimento do software Os requisitos de software podem ser classificados como requisitos funcionais e não funcionais Considerando as informações do texto assinale a alternativa em que o item é um requisito funcional A O Software dever ser operacionalizado no sistema Linux B tempo de desenvolvimento não deve ultrapassar seis meses C O Software deve emitir relatórios de compras a cada quinze dias D O tempo de resposta do sistema não deve ultrapassar 30 segundos E A base de dados deve ser protegida para acesso apenas de usuários autorizados Questão 2 ENADE 2021 A etapa de definição de requisitos é voltada para estabelecer quais as funções são requeridas pelo sistema e as restrições sobre a operação e o desenvolvimento do software Os requisitos de software podem ser classificados como requisitos funcionais e não funcionais Considerando as informações do texto assinale a alternativa em que o item é um requisito funcional A O Software dever ser operacionalizado no sistema Linux B tempo de desenvolvimento não deve ultrapassar seis meses C O Software deve emitir relatórios de compras a cada quinze dias D O tempo de resposta do sistema não deve ultrapassar 30 segundos E A base de dados deve ser protegida para acesso apenas de usuários autorizados