Embed Size (px)
Citation preview
Técnicas e Projeto de Sistemas
André Mesquita [email protected]@gmail.com
Engenharia de requisitos
Técnico Subsequente – Módulo III(08/03/2010)
Engenharia de requisitos
o Introduçãoo Uma das principais medidas do sucesso de um
software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído
Engenharia de requisitos
o Introduçãoo A Engenharia de Requisitos é o processo de
identificar todos os envolvidos (stakeholders), descobrir seus objetivos e necessidades, e documentá-los de forma adequada para análise, comunicação e posterior implementação
o Área do conhecimento do SWEBOK responsável pela elicitação, análise, especificação e validação dos requisitos
o O SWEBOK a denomina apenas Requisitos
Engenharia de requisitos
o Definiçãoo Requisitos expressam necessidades e limitações
sobre um produto que soluciona um problema do mundo real
o São uma combinação complexa de necessidades de diferentes pessoas em diferentes níveis de uma organização e do ambiente em que o software irá operar
o São parâmetros do produto que será desenvolvido (i.e.: requisitos sobre o que o software deve fazer)
o Requisitos devem ser definidos com clareza e de forma quantificável
Engenharia de requisitos
o Tipos de requisitoso Requisitos são classificados em:
o Funcionais e não funcionais
o Requisitos FuncionaisoRepresentam as funções que o software deve executar
o Indicam (apontam) as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações
Engenharia de requisitos
o Tipos de requisitoso Requisitos não funcionais
oDescrevem restrições sobre as funções oferecidas, tais como: o Restrições de uso de recursos, requisitos de qualidade, de
desempenho, de segurança, de manutenibilidade, de usabilidade, etc...
Engenharia de requisitos
o Processo de requisitoso Possui atividades como elicitar (levantar), analisar, documentar e
validar requisitos
o Ocorre desde o início do projeto e é refinado até o final dele
o Identifica os requisitos como itens de configuração e os gerencia
o Atores envolvidos no processo de requisitos
Engenharia de requisitos
o Processo de requisitoso Os processos de engenharia de requisitos variam
de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:o Elicitação (levantamento) de requisitos
oAnálise de requisitos
o Especificação de requisitos
oValidação de requisitos
Engenharia de requisitos
o Elicitação (levantamento)o Preocupa-se tanto com onde os requisitos podem
ser encontrados e como obtê-loso Fontes de requisitos
oObjetivos do negócio
oDomínio da aplicação
oPontos de vista de todos os Stakeholders (diferentes níveis da organização)
oAmbiente de operação
oOrganização (estrutura, cultura e política)
Engenharia de requisitos
o Elicitação (levantamento) – técnicaso Entrevistas: meio mais tradicional e seu sucesso depende
muito da forma como ela é conduzida
o Cenários: contexto operacional do usuário (notação: casos de uso)
o Prototipação: permite ao usuário uma visão melhor das informações que ele necessita
o Reunião com mediadores: identificar pontos de conflito e aplicar técnicas como brainstorming com várias pessoas pode ser mais proveitoso
o Observação: imersão no ambiente dos usuários possibilita um entendimento melhor de algumas funções (ou operações)
Engenharia de requisitos
o Elicitação (levantamento) – técnicaso Algumas dificuldades geralmente são encontradas:
o Dificuldades dos usuários em descrever suas funções
o Falta de vontade em cooperar
o O engenheiro deve entender que não é uma atividade passiva e que, nesta fase, os usuários, clientes e especialistas de domínio identificados devem trabalhar junto com os engenheiros de requisitos para levantar, articular e entender a organização como um todo, o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuaiso Sistema atual não referencia apenas softwares atuais
Engenharia de requisitos
o Elicitação (levantamento) – técnicas auxiliareso O&M
o Elaboração de funcionogramas e fluxogramas do ambiente de operação
o Visa “entender” como a organização atua sem a presença de um sistema, pois auxilia no entendimento dos objetivos e funcionalidades do software
o Exemplo 1 – Funcionograma
o Exemplo 2 – Fluxograma sem software
o Exemplo 3 – Fluxograma com software
Micro-atividade
1. Divisão dos grupos em: entrevistadores e 1 cliente (5 minutos)
2. Os entrevistadores deverão elaborar, no mínimo, três perguntas sobre o sistema a ser modelado por vocês (10 minutos)
3. Realizar a entrevista e documentar as respostas (15 minutos)
Engenharia de requisitos
o Processo de requisitoso Os processos de engenharia de requisitos variam
de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:o Elicitação (levantamento) de requisitos
oAnálise de requisitos
o Especificação de requisitos
oValidação de requisitos
Engenharia de requisitos
o Análise de requisitoso Complementa a elicitaçãoo Detectar e resolver conflito entre requisitos
o Stakeholders com interesses diferentes (incompatíveis)
oDeve-se evitar decisão unilateral por parte do engenheiro
oQuestões contratuais podem obrigar a presença do cliente
oCasos maiores podem ser analisados na fase de validação
Engenharia de requisitos
o Análise de requisitoso Estabelecer um conjunto de requisitos consistentes e sem
ambigüidades, que possa ser usado como base para o desenvolvimento do software
o Deve-se classificar os requisitos em: Funcionais e não funcionais
o Para esta atividade, alguns tipos de modelos podem ser construídos
o Um modelo é uma representação de alguma coisa do mundo real, uma abstração da realidade, e, portanto, representa uma seleção de características do mundo real relevantes para o propósito do sistema em questão
Engenharia de requisitos
o Análise de requisitoso São fundamentais no desenvolvimento de
sistemas e são construídos para:oAuxiliar no estudo do comportamento do sistema
o Facilitar a comunicação entre os componentes da equipe e clientes e usuários
o Facilitar a discussão de correções e modificações com o usuário
o Formar a documentação do sistema
Engenharia de requisitos
o Análise de requisitoso Como foi dito, os modelos possuem níveis de
abstraçãoo O nível de abstração de um modelo diz respeito ao
grau de detalhamento com que as características do sistema são representadas
o No caso do desenvolvimento de sistemas, geralmente, são considerados três níveis:oConceitual
o Lógico
o Físico
Engenharia de requisitos
o Análise de requisitos – níveis de abstraçãoo Conceitual
o Considera características do sistema independentes do ambiente computacional no qual o sistema será implementado
o Essas características são dependentes unicamente das necessidades do usuário
o Modelos conceituais são construídos na atividade de análise de requisitos
o Fatores que influenciam na escolha do modelo: natureza do problema, experiência do engenheiro, requisitos do processo e a disponibilidade de ferramentas e métodos
o A utilização de uma notação “aceitável” pela maioria pode trazer benefícios (UML)
Engenharia de requisitos
o Análise de requisitos – níveis de abstraçãoo Lógico
o Características dependentes de um determinado tipo de sistema computacional
o Essas características são, contudo, independentes de produtos específicos: tais modelos são típicos da fase de projeto (ex.: arquitetura do software)
o Físicoo Características dependentes de um sistema computacional
específico, isto é, uma linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um determinado fabricante, entre outras
Engenharia de requisitos
o Análise de requisitoso Nas primeiras etapas do processo de desenvolvimento
(levantamento de requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais
o Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos
o Paradigmaso Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e,
portanto, definem as características básicas dos modelos a serem construídos
o O paradigma orientado a objetos parte do pressuposto que o mundo é povoado por objetos, ou seja, a abstração básica para se representar as coisas do mundo são os objetos
o O paradigma estruturado adota uma visão de desenvolvimento baseada em um modelo entrada-processamento-saída
Engenharia de requisitos
o Processo de requisitoso Os processos de engenharia de requisitos variam
de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:o Elicitação (levantamento) de requisitos
oAnálise de requisitos
o Especificação de requisitos
oValidação de requisitos
Engenharia de requisitos
o Elicitaçãoo Produção de um documento que possa ser revisado,
avaliado e aprovado
o Especificação de Requisitos de softwareo Estabelece as bases para o acordo entre clientes
o Estabelece o que o software deve fazer e o que ele não deve
o Permite avaliação rigorosa dos requisitos e evita retrabalho
o Fornece base para estimar custo, prazo e risco e para elaboração dos planos de verificação e validação
o Normalmente escrito em linguagem natural, mas pode utilizar outras notações que auxiliem na compreensão do software, como: modelos conceituais para ilustrar o contexto do sistema, cenários (ou telas), principais entidades do domínio e fluxogramas
Engenharia de requisitos
o Processo de requisitoso Os processos de engenharia de requisitos variam
de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:o Elicitação (levantamento) de requisitos
oAnálise de requisitos
o Especificação de requisitos
oValidação de requisitos
Engenharia de requisitos
o Validaçãoo O documento de requisitos deve ser validado pelos
diferentes stakeholders (clientes e desenvolvedores)
o Processo de examinar os documentos para ter certeza que eles definem se o software faz o que o usuário espera dele
o Revisões de requisitoso A maneira mais comum é a inspeção ou revisão do documento
o O grupo de revisão (com pelo menos um representante do cliente) busca por erros, contradições, falta de clareza e desvios de padrões
o As revisões podem acontecer após o término de um dos documentos de requisitos ou em qualquer ponto do processo
Engenharia de requisitos
o Validaçãoo Prototipação
o Construção de um protótipo para validação dos requisitos (também utilizado na elicitação)
o Possibilita uma visão mais completa do funcionamento do SW
o Teste de aceitaçãoo Uma propriedade essencial do requisito é que deve ser possível
validar se um produto finalizado é capaz de satisfazê-lo
o Requisitos que não possam ser validados são “desejos”
o É preciso planejar como testar os requisitos (projetando os testes de aceitação)
Engenharia de requisitos
o Considerações sobre engenharia de requisitoso O processo de requisitos está em todo o ciclo de vida do
software
o Gerenciar a mudança e a manutenção dos requisitos são aspectos chave para o sucesso do processo de requisitos
o Natureza iterativa do processo de requisitoso É impraticável implementar requisitos como um processo linear
o O requisito sofre aperfeiçoamento continuado só ficando pronto quando o produto estiver terminado
o Grande parte dos requisitos irá mudar por: erros de análise, mudanças no ambiente ou de negócio, etc.
o Mudanças são inevitáveis e medidas devem ser tomadas para mitigar o seu impacto
Atividade
1. Definição da visão geral do software e o estado atual que motivou o desenvolvimento de um software.
1. Domínio
2. Visão geral e estado atual / Motivações
1. Principais funcionalidades
3. Usuários do sistema
1. Descrição de cenários (ou telas)
4. Requisitos funcionais
5. Requisitos não-funcionais
Técnicas e Projeto de Sistemas
André Mesquita [email protected]@gmail.com
Engenharia de requisitos – Casos de uso
Técnico Subsequente – Módulo III(22/03/2010)
Casos de uso
o Visão geral de UMLo Unified Modeling Language (Linguagem de
Modelagem Unificada)o UML é uma linguagem para visualização,
especificação, construção e documentação de artefatos de um software orientado a objeto
o Visa facilitar a comunicação entre “clientes” e desenvolvedores
Casos de uso
o Visão geral de UMLo Diagrama de classeso Diagrama de objetoso Diagrama de casos de usoo Diagrama de seqüênciao Diagrama de colaboraçõeso Diagrama de gráficos de estadoso Diagrama de atividadeso Diagrama de componenteso Diagrama de implantação
Casos de uso
o Introduçãoo É um documento narrativo que descreve a
seqüência de eventos de um ator (um agente externo) que usa um sistema para completar um processo
o Eles são histórias ou casos de utilização de um sistema
Casos de uso
o Objetivoo Um diagrama de Caso de Uso descreve um cenário
que mostra as funcionalidades do sistema do ponto de vista do usuário
o O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema
Casos de uso
o Notaçãoo O diagrama de Caso de Uso é representado por:
oAtores, casos de uso e relacionamentos entre estes elementos
o Estes relacionamentos podem ser:o associações entre atores e casos de uso
o generalizações entre os atores
o extends e includes entre os casos de uso
o Casos de uso podem opcionalmente estar envolvidos por um retângulo que representa os limites do sistema
Casos de uso
o Atoreso Um ator é representado por um boneco e um
rótulo com o nome do atoro Um ator é um usuário do sistema, que pode ser
um usuário humano ou um outro sistema computacional
Casos de uso
o Casos de usoo Um caso de uso é representado por uma elipse e
um rótulo com o nome do caso de uso e define uma funcionalidade do sistema
Casos de uso
o Relacionamentoo Entre um ator de um caso de uso
oAssociação: define uma funcionalidade do sistema do ponto de vista do usuário
o Entre atoresoGeneralização: os casos de uso de B são também casos
de uso de A, mas A pode ter seus próprios casos de uso
Casos de uso
o Relacionamentoo Entre casos de uso
o Include: um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A
o Extend: um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.
Casos de uso
o Exemplo de diagrama de caso de uso
Atividade
1. Elabore o diagrama de caso de uso do seu sistema
