Esta apresentação discute e fornece informação sobre o Ciclo de Requisitos de Software, indo da elicitação até a especif...
Rild Ri ldo o F Sant Santos os
[email protected] [email protected] e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/
Análise de Requisitos de Software
Conteúdo:
Sobre o Autor e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Sobre a Apresentação Introdução 1 – Requisitos de Software 2 - Identi Identific ficaçã ação o e Elicit Elicitaçã ação o de Requis Requisito itoss 3 - Análise Análise de de Requisito Requisitoss 4 - Especificaç Especificação ão de Requisito Requisitoss com Caso de de Uso 5 - Validação alidação de de Requisitos Requisitos 6 - Gerenciamen Gerenciamento to de Mudança Mudança de Requisit Requisitos os Anexo
Sobre o autor: Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
e r a w t f o S Rildo Santos e d s o t i s i u q e R e d e s i l a n A
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, T ecnologia da Informação (Métodos Ágeis), Inovação e Liderança.
Minha Experiência: Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie. Fui instrutor de Tecnologia de de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems Microsystems e na IBM. Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA ( Arquitetura Orientado a Serviço), RUP/UP - Processo Unificado, Business Intelligence, Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos Projetos e GRC GRC - Governanc Governance, e, Risk and Compliance Compliance), ), SOX, SOX, Basel II e PCI; PCI; E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo Possuo as certificaç certificações: ões: CSM - Certified Certified SCRUM Master, Master, CSPO CSPO - Certified Certified SCRUM Product Product Owner Owner , SUN Java Certified Certified Instrutor, Instrutor, ITIL ITIL Foundation Foundation e sou Instrutor Instrutor Oficial de Cobit Cobit Foundation Foundation e Cobit Games; Games; Sou membro membro do IIBA-Int IIBA-Internatio ernational nal Institute Institute of Business Business Analysis Analysis (Canada) (Canada)
Onde estou: Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/ http://rildosan.blogspot.com/
Sobre o Apresentação Apresentação
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A Esta apresentação discute e fornece informação sobre o Ciclo de Requisitos de Software, indo da
elicitação elicitação até a especificação especificação de requisitos requisitos de software. software. É abordado as principais técnicas, ferramentas e melhores práticas para desenvolvimento da especificação de requisitos
Introdução
Análise de Requisitos: Introdução Um entendimento completo dos requisitos de software é essencial para um o sucesso do desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado e r seja, um programa mal analisado e especificado frustrará o usuário. a w Análise de requisitos é um processo de descoberta, refinamento, modelagem e t f especificação.
o S i nicialmente estabelecido pelo Analista de Sistemas e refinado e O escopo do software, inicialmente d durante o planejamento do projeto de software, é aperfeiçoado em detalhes. s o Modelos, diagramas, fluxos são criados para melhor compreensão do problema. t i O analista e o usuário desempenham um papel ativo na análise e especificação de s i u requisitos. q e R O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às e vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e d solucionador de problemas. e Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente s i l simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as a n oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável. A
O dilema com o qual se depara um analista pode ser mais m ais bem entendido, repetindo-se a declaração de um cliente anônimo: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”
Introdução
Ciclo de Desenvolvimento de Software: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Melhores Práticas: A Metodologia de Teste Teste deve ser aplicada durante todo o ciclo de desenvolvimento do software
Fases
Fluxos de Trabalho Concepção Elaboração
Construção
Transição
Modelagem de Negócios Nosso Requisitos escopo Análise e Projeto Implementação Teste Implantação
Opcional Gerência de Configuração Gerência de Projeto Ambiente Iterações Preelim.
Iter. #1
Iter. #2
Iter. #n
Iter. Iter. #n+1 #n+2
Iterações
Iter. #m
Iter. #m+1
Introdução
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Da perspectiva da engenharia de software, a “ elicitação” de requisitos é talvez a mais parte mais critica do processo de desenvolvimento de software. Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Requisitos de Software
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos de Software Objetivo desta parte: É apresentar e discutir o Ciclo de Requisitos de Software: – Identificação, Elicitação, Análise, Especificação e Validação
Introdução Um cenário comum:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos de Software
Requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Definições de requisito (segundo IEEE) 1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um objetivo. 2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente. 3) Uma representação documentada de uma condição ou capacidade, conforme os itens (1) e (2).
Requisitos de Software
Contexto de Definição de Requisito: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Stakeholder = Todos os clientes interessados no contexto de requisitos
Requisitos de Software
Elicitação de Requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A elicitação de requisitos corresponde corresponde a identificar junto aos aos clientes/usuários quais são os objetivos do sistema, o que deve ser acompanhado, como o sistema se „encaixa‟ no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema no dia-a-dia. “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores. " — F. Brook
Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade: Problemas de escopo: Os limites do sistema são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários; Problemas de compreensão: Os clientes/usuários geralmente não estão completamente certos das necessidades, têm uma pouca compreensão ou do domínio do seu negócio, omitem informações que julgam óbvias e etc. etc . Problemas de volatilidade: Os requisitos mudam o tempo todo.
Requisitos de Software
Elicitação de Requisitos Para ajudar a superar estes problemas, os desenvolvedores devem abordar os requisitos de forma simples, simpl es, prática e organizada. Alguns passos são recomendados para atividade e r Elicitação de Requisitos Requisitos de Software: Software: a de Elicitação
w t f o S e d s o t i s i u q e R e d e s i l a n A
- Avaliar a viabilidade técnica e de negócio para o sistema sistema proposto; - Identificar as pessoas que vão auxiliar a especificar os requisitos requisitos e compreender compreender seus preconceitos organizacionais; - Definir o ambiente ambiente técnico no qual qual o sistema será instalado; - Identificar regras de domínio domínio que limitam a funcionalidade ou desempenho do software software que será construído; - Definir Definir um ou ou mais métodos métodos de elicitaçã elicitação o de requisito requisitos; s; - Solicitar participação de várias várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista; - Identificar claramente a justificativa de existência para cada requisito requisito registrado; - Identificar requisitos ambíguos que serão candidatos a prototipação.
Os documentos criados como conseqüência da atividade atividade de elicitação de requisitos irão depender do tamanho do software/sistema que será construído.
Stakeholder = Todos os clientes interessados no contexto de requisitos
Elicitação de Requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Para a maioria dos sistemas, estes documentos de trabalho incluem: - As necessidades e viabilidade estruturadas; - O limite de escopo escopo do software software/siste /sistema; ma; - Lista de clientes, usuários e outros stakeholders* que participaram da atividade de de elicitação elicitação de requisitos; requisitos; - Descrição Descrição do ambiente ambiente técnico do sistema; sistema; - Lista de requisitos e as regras de domínio aplicáveis aplicáveis a cada um. - Conjunto de cenários de uso capazes de de prover uma idéia do uso do sistema ou produto sob diferentes condições de operação; - Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado participado da elicitação elicitação de requisitos. requisitos.
Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade
Requisitos de Software
Elicitação de Requisitos Objetivos Objetivos da Elicitação Elicitação de Requisitos: Requisitos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Obter conhecimento relevante para o problema e prover o mais correto entendimento de o que é esperado do software/sistema; s oftware/sistema; Técnicas Técnicas para Elicitaçã Elicitação o de Requisitos: Requisitos: - Cenários: representar tarefas tarefas que executam executam e as que que desejam executar executar - Técnicas tradicionais: questionários, entrevistas, análise de documentação existente existente - Técnicas Técnicas de elicitaçã elicitaçãoo de grupo: grupo: Dinâmica Dinâmica de grupo - Prototipação: quando existe alto grau de incerteza e necessita de um rápido feedback feedback
Stakeholder = Todos os clientes interessados no contexto de requisitos
Requisitos de Software
Requisitos. Road Map e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Regras de negócio
Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos Usuários e Clientes
Fazer Especificação de Requisitos
Documentos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Identi Identific ficaçã ação o e Elicita Elicitaçã ção o de Requisitos Objetivo desta parte: É apresentar e discutir as atividades de Identificação I dentificação e elicitação de requisitos
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos
Requisitos. Road Map e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Regras de negócio
Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos Usuários e Clientes
Fazer Especificação de Requisitos
Documentos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Identificação e elicitação de requisitos é uma tarefa tarefa que parece simples, mas, não devemos nos enganar, enganar, às vezes, para obtermos algumas informações é exigido muita dedicação, persistência e técnica. e apresenta e discute as as principais técnicas para identificação e elicitação de r Esta parte apresenta a requisitos de software.
w t f o S e d s o t i s i u q e R e d e s i l a n A
Por que o “ elicitação” é importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitação de requisitos, pois, é a base que permitirá permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema. Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é elaborada de forma metodológica, geralmente tem uma abordagem intuitiva. elicitação de requisitos”: • Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros; • Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e Qualidade; • Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usuários e o Patrocinador. • Identificar os documentos e procedimentos que definem as políticas de negócios da empresa. Principais características de uma “boa
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Uma Simples Comparação: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Elicitação Boa
Elicitação Ruim
Bom Diagnóstico
Diagnóstico ineficiente
Soluções eficientes
Soluções medíocres
Satisfação dos usuários
Insatisfação dos usuários
Melhoria dos processos e redução de custo Problemas operacionais e financeiros
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Documento (Artefato) desta etapa: “ Documento de Visão” e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Participantes: Analistas e Especialista em Negócios Participantes: Usuário, Clientes, Fornecedores e Patrocinadores
Reuniões e Workshops
Documentos e sistemas
identificação/ elicitação de Requisitos Entrevistas
Observação de campo
Objetivo: Descrever a visão inicial do software Documento de visão
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos As fases da Identificação/Elicitação de Requisitos: Um projeto de elicitação de requisitos têm as seguintes fases: e r a w t Como deve ser feito ? f o S e d s o O que devo coletar ? t i s i u q e R Como devo documentar ? e d e s i l a n A
Planejamento
Identificar Fontes Técnicas
Elicitação de Requisitos
Identificar Funcionalidades Identificar Restrições e Riscos
Documentação
Documento de Visão
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos As informações podem ser identificadas ou encontradas em diversas fontes: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
- Usuár Usuário ios; s; - Docume Documento ntos; s; - Especificaçõe Especificaçõess técnicas; técnicas; - Clien Cliente tes; s; - Sistema Sistemass legado legadoss - Patroci Patrocinad nadore ores; s; - Analista Analista de Negócio Negócio - “Domain Domain Expert Expertss” - Especia Especialist listaa em uma uma ou mais mais área de de negócio negócio
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Quais são as técnicas ? e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Existem várias técnicas, todas elas possuem seus próprios conceitos, vantagens e desvantagens, desvantagens, que podem ser usada nesta atividade entre elas estão: - Reuniõ Reuniões es formai formais; s; - Reuniõ Reuniões es informais informais;; - Entrevi Entrevista stas; s; - Questio Questionár nários; ios; - Work Worksh shop op;; - Brains Brainstor tormin ming; g; - JAD (Join (Join Applica Applicatio tionn Develop Developmen ment) t) - F a st ; - Análise Análise de Documentos; Documentos; - Manual Manual de Sistemas Sistemas Legad Legados. os.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Quais as informações que devo identificar, identificar, levantar e coletar ? e atividade de Identificação/Elicitação de Requisitos, Requisitos, r Após a atividade a através de alguma técnica formal ou informal, as seguintes w t f informações que devemos obter são: o problema, identificação da S Entendimento do problema, e lista dos principais usuários, lista dos principais Requisitos, d identificação dos Riscos e as Restrições do software. s o t i s Daí podemos organizar as informações da seguinte maneira: i u - Contexto (Declaração do do problema e Diagrama de q e Contexto); R usuários e entidades externas; e - Identificação dos usuários d Identificação ão dos Requisitos; Requisitos; e - Identificaç s Identificação i ão dos dos Riscos Riscos e l - Identificaç a Identificação ão das Restri Restrições. ções. n - Identificaç A
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Co Cont ntex exto to:: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Após o entendimento do problema podemos escrever a Declaração do Problema e também desenhar um diagrama de contexto.
- Declaraçã Declaração o do problema: problema: É uma “descrição narrativa”, que apresenta de forma concisa e clara às necessidades dos usuários. Esta narrativa também deve descrever o cenário atual e as necessidades futuras. A linguagem linguagem usada neste documento pode ser técnica ou de negócios, entretanto, evite o usar jargões que não se enquadram no escopo do problema.
- Diagrama Diagrama de Contex Contexto: to: Estabelece quais são as fronteiras do software e principais funcionalidades, ou seja, onde as responsabilidades do software começam e quando acabam.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificação dos “Stakeholders” e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Que é “stakeholders” ?
Stakeholders podem ser pessoas ou entidades que que influenciam a construção do software. Exemplo: - Usuários, Usuários, porque porque definem definem os requisitos requisitos - Gerentes, Diretores, Patrocinadores porque influenciam através de tomada de decisão.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão dos Requisitos: Requisitos: Identificar as funcionalidades do software que deve ter para atender as necessidades do usuário. e r Para identificar você pode fazer as seguintes perguntas:
a - O que o softwar software e deve fazer fazer ? w t funcionalidade lidades s ele deve deve ter ? f - Quais funciona o S Devemos identificar também as principais características do software e d como: s - Perfor Performan mance: ce: o t Qual é tempo de resposta r esposta adequado ? i s - Segu Segura ranç nça: a: i u Quais são os requisitos de segurança que o software precisa? q e - Usabili Usabilidad dade: e: R O software deve seguir a identidade visual da empresa,as interfaces e devem ser intuitivas e amigáveis d e s i l Os requisitos encontrados não devem ser descritos neste momento, a precisamos apenas identificá-los, ou seja, é uma informação de alto n A nível.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificação dos dos Requisitos: Requisitos: Tipos Tipos de Requisitos Os requisitos podem ser divididos em duas categorias: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos
Requisitos Funcionais
Requisitos Não-Funcionais
Definem as funcionalidades do sistema. O que sistema deve fazer.
Declaram as características que o sistema deve possuir e que estão relacionadas às suas funcionalidades.
Requisitos de Software
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão dos Requisitos: Requisitos: Tipos de Requisitos Requisitos Requisitos Funcionais: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções necessárias para atender os objetivos do sistema. Exemplo: - Cadast Cadastrar rar Clientes Clientes;; - Fazer Análise de Crédito; Crédito; - Fazer uma Transaç Transação ão com Banco de Dados; Dados; - Cadastrar Cadastrar um Registro de Atendi Atendimento mento;; - Imprimi Imprimirr Relatóri Relatórioo - etc.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão dos Requisitos: Requisitos: Tipos de Requisitos Requisitos Requisitos Não Funcionais: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Os requisitos não funcionais dizem respeito as características do software, exemplos: performance, portabilidade, segurança, usabilidade e etc. Estas características descrevem também a qualidade do serviço (QoS ( QoS). ). A não consideração ou esquecimento desses fatores na “Workflow de Requisitos” constitui uma das principais razões razões de uma eventual insatisfação dos usuários com relação a um software. Os requisitos não funcionais também são chamamos de “RNF” ou “Requisito Suplementares.”
Exemplos de RNF:
- Confidenc Confidencialid ialidade; ade; - Confia Confiabil bilida idade; de; - Perfor Performan mance; ce; - Qual Qualid idad ade; e; - Usabi Usabilid lidade ade;;
- Portab Portabili ilidad dade; e; - Pr Prec ecis isão ão;; - Integri Integridad dade; e; - Segu Segura ranç nçaa - etc.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão dos Requis Requisitos: itos: Os requisitos de software podem ser identificados no texto da “ declaração declaração do problema ” (geralmente são verbos que identificam algumas ações).
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Este documento possibilita a identificação, extração e classificação dos requisitos - Requisitos Requisitos funcionais funcionais e - Requisitos Requisitos não não funcionais funcionais..
Texto da Declaração do Problema
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Exemplo: Declaração do Problema e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Exemplo: Acompanhamento das estatísticas de aprendizado do aluno e da turma (professor) Inf Infor orma maçã ção: o: Rela Relató tóri rio o de apr aprovei oveita tame ment nto o do alun aluno o e da turm turma a (s) (s)
Requisitos Requisitos Funcionais: Funcionais: O sist sistem ema a deve deve regis egistr trar ar as prin princi cipa pais is açõe açõess de cada cada usuá usuári rio. o. O sist sistem ema a deve deve forn fornec ecer er um relat elatór ório io do apr aprovei oveita tame ment nto o do alun aluno. o. O relatório de apr aproveitamento do alu aluno deve conter o tempo de uso uso do sof software, o número de exercícios feitos, o número de acertos e o de erros. O sist sistem ema a deve deve forn fornec ecer er um relat elatór ório io do apr aprovei oveita tame ment nto o da turm turma. a. O relató atório de aprove oveitamento da turm urma dev deve conter a média e o desvio-p o-padrão dos seguintes dados: tempo de uso do software, número de exercícios feitos, núme númerro de acer acerto toss e err erros de cada cada exer exercí cíci cio. o. Requisitos Requisitos Não-Funciona Não-Funcionais: is:
O sistema dev deve usar gráficos compar parati ativos do apr aproveitam itameento do alun aluno o com a média da turm turma a O sist sistem ema a deve deve usar usar cor cores na cons constr truç ução ão dos dos gráf gráfic icos os O tempo empo de respos sposta ta na elabo labora raçã ção o do relató latóri rio o não não pode pode ser ser super uperiior a 15 segu segund ndos os..
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão de de Riscos: Riscos: Os riscos são a principal razão de falha em um projeto de software. Para um projeto ter sucesso é importante a identificação dos riscos o e r mais cedo o possível. Assim poderemos criar um plano para reduzi-los.
a w t f o S e d s o t i s i u q e R e d e s i l a n A
No Documento de Visão precisamos apenas identificar e criar uma Lista de Riscos encontrados. Os eventos de riscos podem ter várias vári as origens como: - Polí Políti tica ca: :
O software pode sofre a influência de Política de Negócios da Empresa ou Leis, Decretos, Normas e Regulamentos que regulam a sociedade. Problemas financeiros Exemplos de Sistemas que tem restrições legais: - SPB (Sistema Brasileiro Brasileiro de Pagamentos) - Banco Central Central - Sistema de Faturamento Faturamento e Contábil Contábil (Secretária da Fazenda Fazenda Municipal, Estaduais e Federais) - Sistema de Folha de Pagamento Pagamento (Ministério do Trabalho Trabalho e Previdência Social) - Sistema Sistema de de Cont Conta a Corre Corrente nte (Banco (Banco Centr Central al - CPMF) CPMF)
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão de de Riscos: Riscos: - Tecnolo ecnologia gia: :
e Uso de tecnologias emergentes; Integração com legado r a - Recu Recurs rsos os: : w t Orçamento estreito; Contratação de Terceiros Terceiros f o - Habilidade: S Falta de domínio da tecnologia (conhecimento e experiência) e d - Requisitos: s Requisitos não são plenamente conhecidos o t i s i u q e R e d e s i l a n A
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos - Identificaç Identificação ão das Restriçõe Restrições: s: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Definem o conjunto de restrições impostas sobre o desenvolvimento do software. Restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com usuário, componentes de hardware e software a serem adquiridos etc. Nesta momento apenas identificamos as restrições e criamos uma Lista das Restrições, Restrições, esta lista podem ser divida em partes como: Restrições de Hardware, Restrições de Software e Restrições de Ambiente e Tecnologia. Exemplo de Restrição: Quando o projeto requer uma determinada tecnologia, tecnologia, tal como WebServices. Ou quando o software necessita de algum hardware ou software em especifico. Tal Tal como um servidor exclusivo para banco de dados.
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Documento de Visão: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Objetivo: Fazer uma descrição da visão do software Este documen documento to tem as as seguinte seguintess seções: seções: - Declaração Declaração do do Problema; Problema; - Lista dos Stakeholde Stakeholders rs - Lista Lista dos Requisi Requisitos tos - Lista Lista de Riscos Riscos - Lista Lista das Restriçõ Restrições es
Identificaç Identificação ão e Elicitação Elicitação de Requisitos Requisitos Exemplo de Simples Documento de Visão: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Documento de Visão: Data: ________ | Autor: ________ | Revisão: Revisão: ____ Índice: 1.0 - Introd Introduçã ução o 1.1 Objetivo do documento 1.2 Escopo 1.3 Abreviaturas, Abreviaturas, Siglas e etc. 2.0 Contexto 2.1 Declaração do Problema
3.0 Lista de Stakeholders 3.1 Stakeholders Stakeholders primários primários 3.2 Stakeholders Stakeholders segundários segundários 4.0 Lista dos Requisitos 4.1 Requisitos funcionais 4.2 Requisitos não funcionais 5.0 Lista dos Riscos 6.0 Lista das Restrições 6.1 Software 6.2 Hardware 6.3 Ambiente e Tecnologia
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Análise de Requisitos Objetivo desta parte: É apresentar e discutir as atividades da análise de requisitos de software
Análise de Requisitos
Requisitos. Road Map e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Regras de negócio
Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise de Requisitos Usuários e Clientes
Fazer Especificação de Requisitos
Documentos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Análise de Requisitos
Análise de Requisitos: Introdução e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A análise de requisitos procura sistematizar o processo de definição de requisitos. Essa sistematização é necessária porque a complexidade dos sistemas exige que se preste mais atenção ao correto entendimento do problema antes do comprometimento comprometimento de uma solução. Uma definição para requisitos é apresentada a seguir. “Requisitos: Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo objetivo .“ .“
O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos algumas razões: - Da perspectiva perspectiva da engenha engenharia ria de software, software, a elicitação de requisitos requisitos é talvez a mais parte parte mais critica do processo de desenvolvimento de software. Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Análise de Requisitos
Análise de Requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A Análise de Requisitos deve ser: Correta: Correta: Quando cada requisito expresso nela for encontrado no software; Não Ambígua: Ambígua: Cada requisito deve ter somente uma interpretação; Completa: Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades funcionalidades e requisitos relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais) Consistente: Consistente: Quando não existir conflito entre os requisitos; Verificável: Verificável: Quando for possível verificar/validar verificar/validar cada requisito; Modificável: Modificável: Quando os requisitos podem ser facilmente alterados.
Análise de Requisitos
Análise de Requisitos Atividades da Análise de Requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados. Detalhar os Requisitos Funcionais Classificar os Requisitos não Funcionais Descrever os Usuários e Entidades Externas Fazer Plano de Redução de Risco
Documento de Requisitos
Análise de Requisitos
Análise de Requisitos. Detalhar Requisitos Funcionais: e Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para r a esta atividade. Veja o exemplo: w t
f o S e d s o t i s i u q e R e d e s i l a n A
Lista de Requisitos funcionais Autor:
Nome
Revisão:
Código
Data Atualização:
Descrição
Fazer Reserva RF01E Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, remover, alterar e consultar reservas. Cada reserva deverá ter um cliente e um apartamento e respectiva período)
Análise de Requisitos
Análise de Requisitos. Detalhar e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Descrição de Regras de Negócio Nome do Projeto Objetivo
id RN01
Serviço de Atendimento e Reserva de Apartamento Descrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.
Nome da Regra Registrar Reserva de Apartamento
Descrição da Regra de Negócio A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de 25% do valor da estadia. Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem preferência de data e tipo de apartamento. No período de baixa a estação (de mar a jun e ago a nov) o valor da diária tem um desconto de 40%. Para que agilizar o atendimento manter a satisfação do cliente as consultas de reserva devem ser feitas em no máximo 30 segundos. Data
Os códigos permitem a rastreabilidade
01/01/08
Nome / Equipe RFS
Versão
Status
2.1
Vigente
Requisitos Funcional RN: RN01 Nome: Reserva
Descrição: Serviço de Atendimento e Reserva de Apartamento
ID
Nome
Descrição
RFC01
Registrar Reserva de Apartamento
Esta funcionalidade funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.
Análise de Requisitos
Análise de Requisitos. Classificar Requisitos Não Funcionais: e Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos r a categorizar estes requisitos, as mais frequente são: w t
f o S e d s o t i s i u q e R e d e s i l a n A
- Performance:
Tempo de resposta
- Segurança: Uso de senhas, certificados digitais e etc..
- Usabilidade: Identidade Visual e Interfaces amigáveis
- Disponibilidade: O software deve estar disponível para usuário 24x7. Exemplo: Tolerância Tolerância a falha - Flexibi Flexibilida lidade: de: Capacidade de adaptação quando um requisito muda
- Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais)
- Escalabilidade: Capacidade de responder aumento de carga (novos usuários) Outras categorias como Integração, Processamento, Manutenível e etc.
Análise de Requisitos
Análise de Requisitos. Classificar e Detalhar e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos Não Funcionais: Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos Requisi tos funcionais, precisamos ter um padrão Lista de Requisitos Não funcionais Categoria: Performance Autor: Req. Funcional
Fazer Consulta
Revisão:
Data Atualização:
Código
Descrição
RNFP1
As consultas que serão realizadas pelo cliente não poderão exceder ao tempo de resposta de 15 segundos Por que preciso de um código ? Este código tem como objetivo facilitar a “rastreabilidade”.
Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual é o caso de uso que realiza este RNF, RNF, no caso de mudanças.
Análise de Requisitos
Análise de Requisitos. Classificar e Detalhar e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos Não Funcionais: Continuação: Lista de Requisitos Não funcionais Categoria: Usabilidade Autor:
Revisão:
Data Atualização:
RF / Aplicação
Código
Descrição
Aplicação
RNFU1
As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa.
Aplicação
RNFU2
As interfaces com usuário devem seguir padrão de interfaces estabelecido pelo Manual de Sistema
Análise de Requisitos
Análise de Requisitos. Detalhar e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Lista de Stakeholders: Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de decisão decisão ou participam participam direta direta ou indiretamen indiretamente te do processo processo de de construção construção do do software. software. Mais uma vez criaremos um formato padrão. Veja o exemplo: Lista de Stakeholders Autor:
Revisão:
Data Atualização:
Nome
Descrição
Cliente
São todas as pessoas físicas ou jurídicas que fazem reservas
Colaborador
É qualquer pessoa que presta presta algum tipo tipo serviço para empresa
Análise de Requisitos
Análise de Requisitos. Detalhar e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Lista de Stakeholders: Continuação: Lista dos Stakeholders Autor:
Revisão:
Data Atualização:
Nome
Descrição
Administradora de Cartão de Crédito
Entidade que faz validação de um cartão de crédito presente em transação de pagamento.
Análise de Requisitos
Análise de Requisitos. Elaborar: Plano de Mitigação de Riscos: e r r isco que já foram a Precisamos elaborar um Plano de Mitigação de Risco, para os risco w identificados. Este plano deve detalhar como mitigar os riscos identificados. t
f o S e d s o t i s i u q e R e d e s i l a n A
Exemplo: Foi identificado o Risco de Habilidade, Habilidade, pois, somente uma pessoa da equipe conhece a Web 2.0, as outras pessoas nunca trabalharam com esta técnologia. Para mitigar este risco toda equipe deverá receber treinamento de Web 2.0, antes do começo do projeto.
Análise de Requisitos
Análise de Requisitos. Artefato e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Documento de Requisitos: Objetivo: Classificar, descrever os requisitos de software, usuários e entidade externas e elaboração do plano de redução de risco Este documento tem as seguintes seções: - Requisitos Requisitos Funcionais Funcionais - Requisitos Requisitos Não Funcion Funcionais ais - Descrição Descrição do Usuários Usuários e Entidades Entidades Externas Externas - Plano de Redução Redução de Risco Risco
Análise de Requisitos
Análise de Requisitos. Artefato.Template e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Documento de Requisitos: Data: ________ | Autor: ________ | Revisão: ____ Índice: 1.0 - Introd Introduçã ução o 1.1 Objetivo do documento 1.2 Escopo 2.0 Descrição dos Requisitos Funcionais 3.0 Descrição dos Requisitos Não Funcionais 4.0 Lista Lista dos dos Stakehold Stakeholders ers (clientes (clientes e usuário usuários) s) 4.1 Stakeholders Stakeholders primários 4.2 Stakeholders Stakeholders segundárioss 5.0 Plano de Mitigação de Riscos
Análise de Requisitos
Mitos e Lendas: e r O que é dito: a - Usuários não entendem entendem do negócio... negócio... w t f - Requisit Requisitos os são estático estáticos... s... o solução, mesmo antes antes de conhecer todo o problema... problema... S - Achar que tem a solução, e d s o t i Entretanto, a realidade é outra... s i u Requisitos não são estáticos, estáticos, eles mudam constantement constantemente... e... q - Requisitos e R amplas discussões discussões que envolvam envolvam o maior e - Fazer amplas d número de pessoas que conheçam o negócio, antes de e s apresentar uma a solução i l a n A
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Especificação Especificação de Requisitos com Caso de Uso Objetivo desta parte: É apresentar as principais técnicas t écnicas para especificação de requisitos de software.
Especificação de Requisitos com Caso de Uso
Requisitos. Road Map e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Regras de negócio
Fazer identificação e elicitação de requisitos Documento de Visão
Fazer Análise Análise de Requisitos Usuários e Clientes
Fazer Especificação de Requisitos
Documentos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Documento de Visão
Requisitos Funcionais
Requisitos Não Funcionais
Restrições de Projeto
Documento de Requisitos
Especificação de Requisitos
Comportamento externo Casos de Uso Comportamento interno Estrutura
Seqüência Classes
Implementação Distribuição
Colaboração
Arquitetura do Software
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
O produto que devemos ter após Análise de Requisitos é a “ A especificação de Uso, conforme definido pela UML. Um Requisitos” é feita através de Casos de Uso, conjunto de casos de uso é importante para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”) a ser oferecida pelo sistema, ou seja, um serviço.
Análise de Casos de Uso: •Casos de uso expressam o diálogo entre os usuários e o sistema •Casos de uso expressam “o quê” o sistema deverá fazer. E não “ como” fazer. •Casos de uso formam a base para testes e documentação do sistema •O modelo de casos de uso expressam todos os casos de uso do sistema e os seus relacionamentos. •As técnicas para criar e expressar casos de uso em uma aplicação Web são as mesmas para construir outros sistemas de software.
Objetivos: • • • •
Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso e Escrever cenários.
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Transformar os Requisitos Funcionais em Casos de Uso:
Calcular Total
Cliente
Fazer Cadastro Funcionário Fazer Pedido Emitir NF 59
Especificação de Requisitos com Caso de Uso Atividades e Passos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Fazer Diagrama de Casos de Uso Identificar Atores / Casos de Uso Escrever cenários Escrever Formulário Fazer Diagrama de Caso de Uso Refinar Diagrama de Casos de Uso
Ferramenta de Modelagem UML
Especificação de Requisitos com Caso de Uso Introdução: Caso de Uso é uma representação gráfica e semântica da e r a interação do usuário e o sistema. w t f Os diagramas de caso de uso são usados para capturar os o requisitos funcionais do sistema. Ajuda o entendimento do S e contexto dos requerimentos do sistema. d s Os casos de uso podem ser agrupados em pacotes, desta o forma temos uma organização funcional. t i s i u q e R e d e s i l a n A
Especificação de Requisitos com Caso de Uso O que são Caso de Uso? São diagramas de que permitem visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes e r fiquem acessíveis e compreensíveis, por apresentarem a interagem w uma visão externa sobre como esses elementos interagem t f com sistema.
o S e d s o t i s i u q e R e d e s i l a n A
Definição: Caso de Uso é uma descrição de um conjunto de seqüências de de ações, inclusive variantes, que um sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma elipse.
Caso de Uso
Gerenciar Reserva
Ator
Usuário
Nome
Os nomes de casos de uso são breves expressões verbais ativas.
Especificação de Requisitos com Caso de Uso Casos de Uso e Cenários: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários caminhos para completar esta função. Um cenários é como uma “ instance instance ” do Caso de uso, isto é, um caminho lógico com início e fim. Principais características: - Cenários não contém declarações condicionais; - Pode ter mesmo começo, mas, com final final diferente; - Um cenário cenário é narrativ narrativa a de uma situação situação e - Os cenários devem descrever descrever os os bons caminhos e maus maus também. também.
Especificação de Requisitos com Caso de Uso Casos de Uso e Cenários: Exemplos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Em dada Loja virtual, podemos o seguinte cenário de Compra de um produto: “O cliente navega no catálogo de itens e adiciona os itens desejado à sua cesta de
compra. Quando o cliente deseja pagar, fornece os dados do cartão de crédito e confirma a compra. O sistema solicita o endereço de entrega para o pedido. O sistema verifica a autorização do cartão de crédito e confirma a transação imediatamente enviando um e- mail mail para o usuário.”
Este é um dos cenário que pode acontecer. Se houver algum problema, com a autorização da transação do cartão cartão de crédito teremos um novo cenário.
Especificação de Requisitos com Caso de Uso Casos de Uso e Cenários: Exemplos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Autorização de acesso. O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a identificação do usuário, ou seja, seu nome e sua senha, O usuário informa seu nome e sua senha, o sistema valida as informações e dá a autorização de acesso ao sistema. Se senha for invalida ou nome neste caso teremos um novo cenário.
Especificação de Requisitos com Caso de Uso Casos de Uso e Fluxo de Eventos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Uso caso de uso descreve “ o quê” um sistema (ou subsistema, classe, ou interface) faz, ele não especifica “ como” como” isso é feito . Ao fazer uma modelagem, importante manter
clara a separação de questões entre a visão interna e externa. Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e quando o caso de uso interage i nterage com os atores e o fluxo básico e fluxo alternativo do comportamento. Tipos de fluxos: • Fluxo de eventos principal e • Fluxo alternativo de eventos.
Especificação de Requisitos com Caso de Uso Casos de Uso e Fluxo de Eventos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Tipicamente descrevemos descrevemos um fluxo de eventos para um caso de uso. Os fluxos de eventos ajudam a compreensão dos requisitos do sistema, entretanto, você desejará utilizar utili zar os diagramas de interação para especificar esses fluxos graficamente. Além disso, você também utilizará um diagrama de seqüência para especificar o fluxo principal de um caso de uso e variação deste diagrama para especificar os fluxos excepcionais.
Fluxo Normal Fluxo alternativo 2 Fluxo alternativo 1 Fluxo alternativo 3 Cenário 1
Especificação de Requisitos com Caso de Uso Casos de Uso e Formulário: Os formulários devem ter as seguinte informações: - Ponto de ativação (momento (momento que caso de uso começa) começa) - Nom Nome e do caso de uso uso - Obje Objeti tivo vo - Atores Atores que participam participam do caso de uso - Pré-co Pré-condi ndição ção - Fluxo Fluxo Norm Normal al - Fluxo Fluxo Alternat Alternativo ivo - Pós-co Pós-condi ndição ção..
e r a w t f o S e d s o t i s i u q e Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso . R Exemplos: e d - Nom RN e RNF Nome e ou código dos dos Requisitos Requisitos ( RN ) que estão associados a este caso de uso e s i l a n A
Especificação de Requisitos com Caso de Uso Exemplo Formulário de Descrição de Caso Uso: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Nome: Fazer Busca Produto Ponto de ativação: Este caso de uso começa quando entra na página de Busca e seleciona um item da caixa de seleção Ator: Visitante e Cliente Objetivo: Fazer busca de produto por categoria Pré-condição: Aplicação Disponível Fluxo Normal: 1 - O visitante visitante seleciona seleciona a página de busca busca 2 - O visitante visitante seleciona seleciona a categoria para busca busca 3 - O visitante visitante informar informar o produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa a busca 6 - Retorna as as informações informações sobre o produto produto Fluxo Alternativo: 1 - O Visitante Visitante seleciona a página de busca 2 - O visitante visitante seleciona seleciona a categoria para para busca 3 - O visitante visitante informar informar o produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa a busca 6 - Retorna as uma mensagem “produto não encontrado” Pós-condição: Busca realizada Requisito Funcional: RF002 -Fazer Busca do Produto Requisito Não Funcional: --69
Especificação de Requisitos com Caso de Uso Organização dos Casos de Uso: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Os casos de uso também podem ser organizados pela especificação de relacionamento de generalização, generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade de fatorar fatorar o comportamento comportamento comum (obtendo esse comportamento comportamento a partir de outros casos de uso que ele inclui) e fatorar variantes (obtendo (obtendo esse comportamento comportamento em outros casos de uso que o estendem)
Especificação de Requisitos com Caso de Uso Exemplos de Casos de Uso: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Manter informações dos cursos
Manter informação de aluno
Manter informação de professor
Gerente de Educção
Gerar catalogo
Pedir lista dos matriculados Sistema de cobrança
Matrícula nos Cursos Professor
Aluno Selecionar curso para ensinar
Especificação de Requisitos com Caso de Uso Elementos dos Caso de Uso: Ator: Um ator representa um conjunto coerente de papéis que os usuários de casos de e desempenham quanto interagem interagem com esses casos de uso. Geralmente um r uso desempenham a ator representa um papel, que pode ser de pessoa, de um sistema ou de um w dispositivo e etc... t
f o S e d s o t i s i u q e R e d e s i l a n A
Cenários: É narrativa de determinado determinado fato ou de uma situação. “O caso de uso deve ser descrito através de cenários. c enários. Devem ser construídos tantos cenários quantos quantos forem necessários para para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação vali dação dos requisitos do sistema.”
Formulário: É a representação estruturada de um ou mais cenários
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Generalização: Entre os casos de uso é parecida à generalização existente entre as classes. No caso de uso a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça. Include: Quando você estiver se repetindo em dois ou mais caso de uso separados devemos evitar a repetição Extends: Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição descrição mais controlada, explicando os pontos de extensão no caso de uso. Realizes: Especifica a colaboração entre os casos de uso * Use (obsoleto): Especifica que a semântica do elemento de origem depende da semântica da parte pública do destino. Substituído pelo include.
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Generalização: Podemos usar a generalização entre casos de uso, pelo mesmo motivo que utilizamos nas classes, para compartilhar comportamento: c omportamento:
Receber Pagamento
generalização
Pagto Cartão de Crédito
Pagto Cartão de Débito
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Generalização: A generalização também pode ser aplicado aplic ado aos atores e seus respectivos r espectivos papéis. Veja o exemplo:
Funcionário
Recepcionista
Gerente de Reservas
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Extends: Podemos usa- lo para “Demonstrar Variação de Comportamento”: Cada uma das extensões descreve as diferentes maneiras com que um passo do caso de uso pode ser executado. Variação Variação de Comportamento. Comportamento. Exemplo: Locadora de Automóveis Devolver Veículo
Alte lterar rar stat statuus do carr carroo
Consul nsulta ta Clie liente nte
Calcular Multa
Especificação de Requisitos com Caso de Uso Explicando o estereotipo “include”
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base. O caso de uso incluído nunca permanece per manece isolado, mas é apenas uma “ instance instance ” como parte de alguma base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o obtém o comportamento comportamento a partir do fornecedor do caso de uso. Você utiliza utiliza um relacionamento de inclusão para evitar descrever o mesmo mesmo fluxo de eventos várias vezes, vezes, incluindo o comportamento comum em um caso de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que precisamos utilizar essa funcionalidade.
Fazer Pedido Validar Usuário
Acompanhar Pedido
Especificação de Requisitos com Caso de Uso Include. (Mais) exemplos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Fazer Check IN
Fazer Check OUT Gerenciar Reserva
Receber Pagamento
Especificação de Requisitos com Caso de Uso Casos de Uso - Identificação de Atores
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Os atores não fazem fazem parte do sistema - eles representam qualquer qualquer um e qualquer coisa que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode: - Apenas fornecer fornecer informações informações ao sistema - Apenas receber receber informações do sistema - Fornecer e receber informações ao sistema Tipicamente os atores são identificados nas Declarações de Problemas (Documento de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo, como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio, por exemplo. As seguintes questões podem ser usadas para identificar o atores: - Onde o sistema sistema será usado ? - Quais áreas áreas serão usuárias usuárias do sistema sistema ? - O sistema usará usará recurso recurso externo externo ? - Quem será será o responsável responsável pelo pelo sistema sistema ? - Quem serão serão os usuários usuários do sistema sistema ?
Especificação de Requisitos com Caso de Uso Um engano comum na identificação de casos de uso é representar como Caso de uso passos individuais, operações ou transações. e r Exemplo: a No domínio de ponto ponto de venda, alguém alguém pode definir um caso de uso chamado w t f “Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo o no processo muito mais abrangente do caso de uso Comprar Itens S e d Lembre-se: s o t i Um caso de uso é uma descrição completa de processo, que inclui outros passos s i ou transações. u q e R e d e s i l a n A
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as seguintes propriedades: - Número, preços preços base, capacidade capacidade de pessoas - Tipo (Single, (Single, double, triplo ou suite) O preço de cada apartamento está relacionado com seu tipo e sazonalidade s azonalidadess (períodos especiais, tais como: férias, natal, carnaval...) Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de reserva do Hotel .
1
2 Refinado pelo
Requisitos Funcionais • Gerenciar Reserva •...
Documento de Visão „
Documento de Requisitos
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Especificação de Requisitos: 3 Formulário
Cenários
Gerenciar Reserva
Usuário Ator
Caso de Uso Associação
Caso de Uso: Gerenciar Reserva
Especificação de Requisitos com Caso de Uso Estudo de Caso:
Escrevendo os Cenários: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Gerenciamento de Reserva:
Cenários
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita s olicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data d ata de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva.
Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita s olicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem disponibilidade de apartamento para o período perío do informado pelo cliente e oferece um outro tipo de apartamento. O cliente aceita o apartamento e então o funcionário confirma a reserva.
Especificação de Requisitos com Caso de Uso Estudo de Caso:
Escrevendo os Cenários: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Gerenciamento de Reserva:
Cenários
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita s olicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data d ata de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem disponibilidade de apartamento para o período períod o informado pelo cliente e oferece um outro tipo de apartamento. O cliente não aceita a proposta do funcionário e a reserva não é confirmada.
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Escrevendo o Formulário: Compilar os Cenários em Formulário:
Cenários
Formulário
Identificando a pré-condição e pós-condição: Cenário Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema t elefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data de chegado e partida, pa rtida, e qual tipo de apartamento Pré Pré- condiç condição ão ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva. Pós Pós- condiçã condição o
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Escrevendo o Formulário: Compilar os Cenários em Formulário:
Primeiras linhas do cenário
“caminho feliz”
Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal:
Gerenciar Reserva
Fluxo Alternativo:
Gerenciar Reserva
“caminho alternativo”
Pós-condição: Reserva confirmada
Última linha do cenário 86
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Escrevendo o Formulário: Formulário: Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o período (data de chegada e partida) O funcionário do Hotel verifica a disponibilidade disponibilidade do apartamento O funcionário confirma a reserva
Fluxo Alternativo: ... O funcionário do Hotel verifica a disponibilidade disponibilidade do apartamento O funcionário faz proposta de outro apartamento para cliente O cliente aceita e então o funcionário confirma a reserva
Pós-condição: Reserva confirmada
Especificação de Requisitos com Caso de Uso Estudo de Caso:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Especificação de Requisitos: 3 Formulário
Cenários
Funcionário Ator
Gerenciar Reserva
Associação
Caso de Uso: Gerenciar Reserva
Caso de Uso
Especificação de Requisitos com Caso de Uso
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Ferrament Ferramenta: a: Enterprise Enterprise Archite Architect ct (EA (EA))
Especificação de Requisitos com Caso de Uso
Mitos e Lendas • Requisitos não são Casos de Uso; e r • Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo: a w Caso de Uso Fazer Busca, está associado a dois requisitos: t f • (RF) Fazer Buscar o • (RNF) O tempo de resposta para transação deve ser 10 segundos S e (Desempenho) d s o t i s i u q e R e d e s i l a n A
Especificação de Requisitos com Caso de Uso Atividades e Passos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Fazer Diagrama de Casos de Uso Identificar Atores Atores / Casos de Uso Escrever cenários
Rational Rose
Escrever Formulário Fazer Diagrama de Caso de Uso Refinar Diagrama de Casos de Uso 91
Especificação de Requisitos com Caso de Uso Vamos Vamos fazer os Caso C aso de Uso (iniciais) Especificação de Requisitos, como fazer: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique também os ATORES ATORES e seus respectivos PAPÉIS; PAPÉIS; 3 - Dê um nome para o CASO CASO DE USO, lembre-se que este nome deve deve ser único no modelo; 4 - Escreva Escreva os CENÁRIOS CENÁRIOS para o CASO CASO DE USO; 5 - Compile Compile os CENÁRIOS CENÁRIOS em único único FORMULÁRIO FORMULÁRIO e 6 - Faça o Diagrama Diagrama de Caso de de Uso (Use “Rational Rose” Rose” para fazer isto).
Especificação de Requisitos com Caso de Uso Modelo do “Formulário de Descrição de Requisitos”: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Data: ______ | Autor: ________ | Revisão: ____ Nome: Ponto de ativação: Ator: Objetivo: Pré-condição: Fluxo Normal:
Fluxo Alternativo:
Pós-condição: RF: RNF:
Especificação de Requisitos com Caso de Uso Refinar: Atividades e Passos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Fazer Diagrama de Casos de Uso Identificar Atores / Casos de Uso Escrever cenários Escrever Formulário Fazer Diagrama de Caso de Uso Refinar Diagrama de Casos de Uso Neste momento vamos “refinar” o Diagrama de Caso de Uso:
1 - Identificar Identificar os os pontos pontos de extensão extensão 2 - Identificar Identificar as as generalizaçõ generalizações es 3 - Identificar os pontos de “inclusão”
Rational Rose
Especificação de Requisitos com Caso de Uso Exemplo 2 – Adicionando o e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Sem include:
Com include:
Buscar Apartamento
Funcionário
Gerenciar Reserva
Funcionário
Gerenciar Reserva
Cadastrar Cliente
Especificação de Requisitos com Caso de Uso Exemplo 1 – Adicionando o e e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Cancelar Check Check IN
Recepcionista Fazer Check IN
Recepcionista
Consultar Reserva
Fazer Check IN
Consultar Cliente
Especificação de Requisitos com Caso de Uso Exemplo 3 – Adicionando o e r a Sem include: w t f o S e d Recepcionista Fazer Check OUT s o t i s i u q e R e d e s i l a n A
Com include:
Consultar Cliente
Consultar Reserva
Recepcionista
Fazer Check OUT
Receber Pagamento
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Validação de Requisitos Objetivo desta parte: É apresentar as principais técnicas para validação de requisitos de software.
Validação Validação de Requisitos
Requisitos. Road Map e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Regras de negócio
Fazer identificação e elicitação de requisitos requisitos Documento de Visão
Fazer Análise Análise de Requisitos Usuários e Clientes
Fazer Especificação de Requisitos
Documentos
Documento de Requisitos
Fazer Validação de Requisitos Documento de Especificação de Requisitos
Validação Validação de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Deve preocupa-se em mostrar que os requisitos definem o sistema s istema que o cliente/usuário deseja. Validação é importante uma vez que o custo para remover um erro de requisitos é grande. Pequen Pequeno o Check Check List List de Requi Requisit sitos: os: Validade. Validade. O sistema fornece as funções que melhor atende as necessidades do usuário? Consistência. Consistência. Existem conflitos de requisitos? Todas as funções necessárias para o cliente estão incluídas? Completeza. Completeza. Todas Realismo. Realismo. Os requisitos podem ser implementados i mplementados com a tecnologia e orçamento disponíveis? Facilidade de verificação. verificação . Os requisitos podem ser checados?
Validação Validação de Requisitos Técnicas de validação de requisitos Revisão de requisitos: - Análise Análise manual sistemática sistemática dos requisitos requisitos e r a Prototipação: w - Uso de um modelo executável do sistema para para checar os requisitos. t f o Geração de casos de teste: S - Desenvolver testes para validar a implementação dos requisitos. e d Análise automatizada da consistência: consistência do modelo. s - Uso de ferramenta para verificar a consistência o t i s i u q e R e d e s i l a n A
Revisão de requisitos: - Revisões regulares devem ocorrer durante a formulação da definição dos dos requisitos - Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões - As revisões podem podem ser formais (com documentos completos) ou informais. Uma boa comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em estágios iniciais Verificação de revisões: - “Verificabilidade”. O requisito é realisticamente testável? - Compreensibilidade. O requisito é propriamente propriamente entendido? - Rastreabilidade. A origem do requisito é claramente estabelecida? - Adaptabilid Adaptabilidade. ade. O requisito requisito pode pode ser modificado modificado sem grande grande impacto sobre sobre outros requisitos?
Validação de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Caso de Teste Teste Definição: Caso de Teste Teste - Casos de de Testes: Testes: Especifica uma forma de fazer testes, incluindo o que testar (as entradas e/ou as saídas) , como testar e as condições de testes. Em engenharia de software, Caso de Teste é um conjunto de condições usadas para teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna do software, através de situações que exercitem adequadamente todas as estruturas utilizadas na codificação; ou ainda, garantir que os requisitos do software que foi construído sejam plenamente atendidos. Podemos utilizar os Casos de Uso para criar e rastrear os Caso de Teste.
O Caso de Teste Teste deve especificar a saída esperada e os resultados esperados do processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros.
Os Casos de Uso são a base para os Casos C asos de Teste Teste
Validação de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Caso de d e Teste Teste Definição: Modelo de Teste Teste - Caso de Teste. Teste. Exemplo: Caso de Teste ID Caso Teste
ID Caso de Uso
Nome
Descrição
Fazer Login
Validar o Caso de Uso: Fazer Login de Acesso
Cenário
Resultado Esperado
Resultado Observado
Fluxo Normal Entrada: nome e senha
Usuário autorizado (Sucesso)
Usuário autorizado (Sucesso)
OK
Fluxo Alternativo 1 Entrada: nome e senha
Mensagem usuário inválido (Insucesso)
Usuário autorizado (Sucesso)
NOK
25
24
Nome do Testador:
Caso de Uso Fluxo Normal Fluxo alternativo 2
Cenário 1
Data: ____/____/_____
Fazer Login
Fluxo alternativo 1 Fluxo alternativo 3
OK ?
Descrição do Caso de Uso
Cliente
Validação Validação de Requisitos Técnicas de validação de requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Verificação Verificação de Consistência Automatizada:
Requisitos em linguagem formal
Relatório
Processador de Requisitos
Análise de Requisitos
Base de Dados de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Gerenciamento Gerenciamento de Mudança de Requisitos Objetivo desta parte: É apresentar as principais técnicas para processo de gerenciamento de mudança de requisitos de software.
Gerenciamento de Mudança de Requisitos Gerenciamento de Mudança de Requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento. Requisitos são inevitavelmente incompletos e inconsistentes: e r a • Novos requisitos surgem durante o processo de desenvolvimento. w • Diferentes pontos de vista vis ta possuem diferentes requisitos e esses são freqüentemente t f contraditórios. o S e d Mudanças nos requisitos: s o - A prioridade prioridade dos requisitos podem mudar para atender novas demandas demandas de negócio t i s i u - Requisitos podem sofrer sofrer alteração quando quando muda a regra de negócio; negócio; q e R - As pessoas que pagam pelo software/sistema podem podem especificar os requisitos de de maneira e conflitantes com os requisitos das pessoas que irão utilizar o software/sistema. d e s - A empresa empresa e o ambiente ambiente técnico do software software/siste /sistema ma se modificam durante durante o processo processo i l a de desenvolvimento n A
Gerenciamento de Mudança de Requisitos Evolução dos requisitos e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Entendimento do problema (alterado)
Entendimento inicial do problema
Requisitos modificados
Requisitos iniciais
tempo
Gerenciamento de Mudança de Requisitos
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Requisitos permanentes e voláteis: - Requisitos permanentes. permanentes. Requisitos estáveis, derivados da atividade principal da organização. Exemplo: Em um hospital sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras e aos tratamentos. - Requisitos voláteis. Requisitos que se modificam durante o desenvolvimento ou quando o software/sistema está em uso. Requisitos resultantes de políticas governamentais ou resultantes de regra de negócio da empresa. Exemplo: Plano de saúde; Mudança na política de venda Classificação dos requisitos: Requisitos Mutáveis: - Requisitos Requisitos que se modificam modificam por causa do ambiente ambiente do sistema. Requisitos Emergentes: - Requisitos Requisitos que surgem à medida que a compreensão do cliente do sistema sistema se desenvolve desenvolve Requisitos Conseqüentes: - Requisitos Requisitos que resultam da introdução introdução do sistema de computador. computador. Requisitos de compatibilidade: - Requisitos Requisitos que dependem de outros sistemas ou processos de negócio específicos específicos dentro da organização
Gerenciamento de Mudança de Requisitos Planejamento do gerenciamento de requisitos: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Durante o processo de engenharia de requisitos, será necessário planejar: A identificação dos requisitos: Como os requisitos são individualmente identificados Um processo de mudança de gerenciamento: O processo seguinte à análise de uma mudança de requisito Políticas de rastreabilidade: A quantidade quantidade de informações (histórico) sobre o relacionamento entre requisitos que é mantida. Como rastrear as mudanças de requisitos e seus s eus possíveis impactos. Suporte à ferramenta: O suporte à ferramenta necessário para auxiliar no Gerenciamento de Mudanças de Requisitos
Gerenciamento de Mudança de Requisitos Rastreabilidade: - Rastreabilid Rastreabilidade ade preocupa-se preocupa-se com as relações relações entre entre requisitos, requisitos, suas fontes fontes e o projeto do software/sistema e r
a w Rastreabilid Rastreabilidade ade de fonte: fonte: t f • Links de requisitos para stakeholders que propuseram os requisitos o S e Rastreabilid Rastreabilidade ade de requisitos: requisitos: d s • Links entre requisitos dependentes o t i Rastreabilidade ade do projeto: projeto: s Rastreabilid i u • Links dos requisitos para o projeto q e R e d e s i l a n A
Gerenciamento de Mudança de Requisitos Suporte à ferramenta: Armazenamento dos requisitos: e gerenciados em uma memória de dados dados segura e gerenciada r - Os requisitos devem ser gerenciados
a w t f o S e d s o t i s i u q e R e d e s i l a n A
Mudança de gerenciamento: - O processo processo de mudança mudança de gerenciamen gerenciamento to é um processo processo de fluxo de de trabalho trabalho cujos estágios podem ser definidos e o fluxo de informação entre esses estágios parcialmente automatizado Gerenciamento de rastreabilidade - Recuperaçã Recuperaçãoo automática automática dos links entre requisitos
Gerenciamento de Mudança de Requisitos Gerenciamento de Mudanças de Requisitos: Deve ser feita em qualquer proposta de mudança de requisito. e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Principais estágios: - Análise do problema problema e especificação da mudança. Discute-se os problemas com os requisitos e propõe-se mudanças. - Análise e custo da mudança. Avalia-se os efeitos da mudança mudança em outros requisitos do sistema. - Implementação das mudanças. O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças.
Solicitação de Mudança de Requisito
Análise do Problema e especificação da mudança
Análise e custo mudança
implementação da mudança
Requisito Alterado
Gerenciamento de Mudança de Requisitos Exemplo: Matriz de Rastreabilidade (na ferramenta ferramenta ReqPro): e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Gerenciamento de Mudança de Requisitos Exemplo: Exemplo: Matriz de Rastreabilida Rastreabilidade de (na ferramenta ferramenta EA): e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Conteúdo: Técnicas para identificação/elicitação de requisitos: - JAD - FAST Documento de Requisitos - Padrão Padrão IEEE/ANSI IEEE/ANSI 830-199 830-1993: 3:
Anexo JAD (Join Application Development) e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A ttécnica écnica JAD desenvolvida na IBM no fim dos anos 70 visa vis a criar sessões de trabalho estruturadas, através de uma dinâmica de grupo e recursos visuais, vis uais, em que analistas e usuários trabalham juntos para projetar um sistema, desde os requisitos básicos até o layout de telas e relatórios, prevalecendo a cooperação e o entendimento [PORTELLA1994]. Os desenvolvedores ajudam ajudam os usuários a formular os problemas e explorar possíveis soluções, envolvendo-os e fazendo com que eles se sintam participantes do desenvolvimento JAD se baseia em quatro princípios básicos: 1. Dinâmica de grupo, com a utilização de de sessões de grupo facilitadas para aumentar a capacidade dos indivíduos; 2. Uso de técnicas audiovisuais audiovisuais para aumentar a comunicação e o entendimento; entendimento; 3. Manutenção do processo organizado e racional; e 4. Utilização de documentação-padrão, documentação-padrão, que é preenchida e assinada por todos todos os participantes de uma sessão. A técnica JAD tem duas grandes etapas: planejamento, cujo objetivo é elicitar e especificar requisitos; e projeto, em que se lida com o projeto do software. Nesta monografia somente será tratada a primeira etapa. Os participantes de uma sessão de JAD desempenham seis diferentes papéis: líder da sessão, representantes do usuário, especialista, analista, representantes dos sistemas de informação i nformação e patrocinador executivo.
Anexo JAD (Join Application Development) continuação
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
A técnica pode ser usada tanto para elicitar como nas fases iniciais da especificação de requisitos. Ela ajuda a identificar os assuntos que podem necessitar de rastreamento rastreamento e fornece uma perspectiva multifacetada dos requisitos. Sessões de JAD permitem aos analistas coletar simultânea e eficientemente uma grande quantidade de requisitos do sistema junto a uma gama de usuários-chave. São úteis por considerar necessidades específicas dos usuários. JAD também pode ser usada em conjunto com outra técnica de elicitação como, por exemplo, a prototipação. À medida que os requisitos são obtidos nas sessões, pode-se construir um protótipo que demonstre alguma funcionalidade destes requisitos.
Anexo FAST (facilited application specification technique): e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Combina: identificação do problema, negociação e especificação de um conjunto preliminar de requisitos. Diretrizes básicas: - Encontro de clientes e desenvolvedores em local neutro - Estabelecer regras regras para preparação e participação; - É sugerida uma agenda agenda cobrindo todos todos os pontos importantes importantes e que encoraja o livre fluxo de idéias; - “Facilitador”(cliente,desenvolvedor “Facilitador”(cliente,desenvolvedor,, ou elemento externo) para controlar c ontrolar o encontro.
Anexo Documento de Requisitos: Formato do documento de de especificação de requisitos sugerido pela IEEE/ANSI 830 e r 1993:
a w t f o S e d s o t i s i u q e R e d e s i l a n A
Estrutura do Documento: 1.0 Introdução 1.1 propósito do documento de requisitos 1.2 escopo do produto 1.3 definições, acrônimos e abreviações 1.4 referências
1.5 visão geral do restante do documento 2.0 Descrição geral 2.1 perspectiva do produto 2.2 funções do produto 2.3 características do usuário 2.4 restrições gerais 2.5 suposições e dependências
3. Requisitos (Específicos) os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, características de qualidade. 4. Apêndices 5. índice
Notas: Marcas Registradas: e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Todos os termos mencionados e reconhecidos reco nhecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você vo cê encontrou algum problema ou erro envie um e-mail.
Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail.
Rildo F dos Santos (
[email protected] (
[email protected]))
[email protected]
Licença:
e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Rild Ri ldo o F Sant Santos os
[email protected] [email protected] e r a w t f o S e d s o t i s i u q e R e d e s i l a n A
Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/
Análise de Requisitos de Software
