Engenharia de Software

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
Processos de Engenharia de Requisitos Abr/2010

2 Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema. Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (Aula anterior) Validação de Requisitos

3 Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema. Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos

4 Estudo de Viabilidade Entrada: Saída Estudo breve que responde:
Conjunto preliminar de requisitos de negócio Esboço da descrição do sistema Como o Sistema apoiará o negócio Saída Relatório que recomenda ou não prosseguir com os processos de Engenharia de Requisitos e de Desenvolvimento de Sistemas Estudo breve que responde: Sistema contribui para os objetivos gerais da organização Sistema pode ser implementado com Tecnologia atual Restrição de custo Restrição de prazo Sistema pode ser integrado aos outros Sistemas

5 Estudo de Viabilidade Possíveis questões a serem levantadas:
Como seria se esse sistema não fosse implantado? Problemas com os processos atuais e como o novo sistema ajudaria? Contribuição direta do novo Sistema para os objetivos da empresa? As informações podem ser transferidas e recebidas de outros sistemas da organização? O Sistema requer Tecnologia ainda não usada na organização? O que deve ser apoiado pelo Sistema e o que não deve ser apoiado?

6 Estudo de Viabilidade Consulta: Relatório de Viabilidade
Gerência de Departamentos onde o Sistema será usado Outros desenvolvedores familiarizados com o Sistema proposto Especialistas em TI Usuários Finais Relatório de Viabilidade Pode Propor: Mudanças de escopo Mudanças de orçamento Mudanças de prazo Sugestões de requisitos de alto nível adicionais

7 Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema. Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos

8 Levantamento e Análise de Requisitos
Trabalham com clientes e usuários finais do Sistema: Para aprender sobre o domínio da aplicação Quais serviços o Sistema deve fornecer Desempenho esperado Restrições de Hardware Envolve qualquer pessoa ou grupo afetado pelo Sistema, direta ou indiretamente (stakeholder)

9 Levantamento e Análise de Requisitos
Detalhamento e Compreensão dos requisitos dos stakeholders é difícil por várias razões: Não sabem o que querem do Sistema a não ser em termos gerais Não tem conhecimento dos custos envolvidos Expressam as necessidades em seus próprios termos e com o conhecimento implícito de seu trabalho Diferentes stakeholders tem diferentes requisitos, expressos de diferentes formas (pontos de convergência e conflitos) Fatores políticos Ambiente econômico e de negócios é dinâmico.

10 Levantamento e Análise de Requisitos
As atividades envolvidas em espiral Atividades: Obtenção dos requisitos Classificação e Organização dos requisitos Priorização e negociação de requisitos Documentação de Requisitos

11 Levantamento e Análise de Requisitos
As atividades envolvidas em espiral Atividades: Obtenção dos requisitos Classificação e Organização dos requisitos Priorização e negociação de requisitos Documentação de Requisitos

12 Levantamento e Análise de Requisitos
As atividades envolvidas em espiral Atividades: Obtenção dos requisitos Classificação e Organização dos requisitos Priorização e negociação de requisitos Documentação de Requisitos

13 Obtenção dos Requisitos
Processo que reúne informações sobre o sistema proposto e os existentes. Fontes: Documentação Stakeholders (entrevistas e observações) – Uso de cenários e protótipos para auxiliar na obtenção dos requisitos. Especificações de Sistemas Similares Dominío da aplicação Outros sistemas que interagem com o Sistema

14 Obtenção dos Requisitos
Fontes de requisitos podem ser representadas como Pontos de Vista do Sistema, em que cada ponto de vista apresenta um subconjunto de requisitos do Sistema. 3 tipos genéricos de Pontos de Vista: Ponto de Vista de interação – utilizam diretante. Ponto de Vista Indiretos – não usam, mas são afetados Ponto de Vista de Domínio (ex. padrões de comunicação de daods)

15 Obtenção dos Requisitos
Identificar os Pontos de Vista relevantes pode ser difícil. Para ajudar, tentar identificar tipos mais específicos de pontos de vista: Fornecedores e receptores de serviços do Sistema. Sistemas que tem interface. Regulamentos e padrões aplicáveis. Fontes de requisitos de negócio e não funcionais do sistema. Desenvolvedores do Sistema Marketing Depois de identificados e estruturados, identificar os PV mais importantes e começar com eles a obtenção dos requisitos do Sistema.

16 Obtenção dos Requisitos
Entrevistas Formal/Informal Questões sobre o sistema que eles usam e o Sistema a ser desenvolvido. Fechadas / Abertas. Pré-roteiro. Úteis para: Entendimento geral sobre o que os stakeholders fazem Como eles podem interagir com o sistema Dificuldades com os sistemas atuais

17 Obtenção dos Requisitos
Entrevistas Difícil levantar o conhecimento de domínio durante as entrevistas devido a: Terminologia e jargões específicos Alguns conhecimentos de domínio são tão familiares aos stakeholders que são considerados difíceis de explicar ou não vale a pena mencionar. Problemas também para levantar requisitos e restrições organizacionais.

18 Obtenção dos Requisitos
Cenários Pessoas consideram mais fácil relatar exemplos do que abstrair descrições. Começa com um esboço da interação que será detalhada durante o levantamento. Inclui: Descrição do que os usuários esperam do sistema no início do cenário Descrição do fluxo normal de eventos no cenário Descrição do que pode dar errado e como é tratado Informações sobre outras atividades que podem ocorrer simultaneamente Descrição do estado do sistema ao final do cenário. Podem ser escritos ou completados com diagramas, imagens de computador ou ainda uma abordagem mais estruturada como cenários de eventos ou casos de uso.

19 Obtenção dos Requisitos
Casos de Uso Técnica baseada em cenários para elicitação de requisitos. Identifica o tipo de interação e os agentes envolvidos. Como enfocam as interações são eficazes para os requisitos de pontos de vista de interação, em que cada tipo de interação pode ser representado como um caso de uso. Não são eficazes para restrições de requisitos de negócio e requisitos não funcionais de alto nível.

20 Obtenção dos Requisitos
Casos de Uso Busca Artigos Impressão Artigos Usuário de Biblioteca Adm Usuários Funcionários Biblioteca Serv. Catálogo Fornecedor

21 Obtenção dos Requisitos
Etnografia Técnica de observação para compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de trabalho aonde o sistema será usado e observa o dia a dia. Eficaz para: Requisitos implícitos do sistema que refletem os processos reais Requisitos derivados de como as pessoas realmente trabalham Requisitos derivados da cooperação e do conhecimento das atividades das outras pessoas.

22 Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema. Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (aula anterior) Validação de Requisitos

23 Validação de Requisitos
Mostrar que os requisitos realmente definem o Sistema que o Usuário deseja. Verificações de Validade – Necessidade do Sistema ou de mais funções ou características Verificações de Consistência – Requisitos não conflitantes. Verificações de Completeza – O documento de requisitos deve incluir todas as funções e restrições necessárias. Verificação de Realismo – Se podem ser implementados. Facilidade de Verificação – Os requisitos de sistema devem ser escritos de modo que sejam verificáveis. Isto é, pode-se definir um conjunto de testes que possa demonstrar que o sistema entregue atende cada requisito especificado.

24 Validação de Requisitos
Revisões de Requisitos É um processo manual que envolve pessoas de ambas as organizações. Eles verificam o documento de requisitos em busca de anomalias e omissões. Podem ser formais ou informais e com o maior número de stakeholders a confirmação dos requisitos. Os requisitos devem atender: Consistência Completeza. Facilidade de Verificação. Facilidade de Compreensão. Rastreabilidade. Adaptabilidade.

25 Gerenciamento de Requisitos
Processo para compreender e controlar as mudanças dos requisitos do sistema. Manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes de modo que seja possível avaliar o impacto das mudanças de requisitos. Requisitos de Sistema de Software sempre mudam. Normalmente Requisitos de Sistema são incompletos Durante o processo o entendimento dos Stakeholders muda. Depois de instalado surgem novos requisitos Prioridades são mudadas Quem paga o Sistema é diferente de quem usa Ambiente de negócios e técnico do sistema muda.

26 Gerenciamento de Requisitos
Requisitos Permanentes e Voláteis A evolução de requisitos durante o processo engenharia de requisitos e após a entrada em operação é inevitável. Requisitos Permanentes – Relativamente estáveis derivados da atividade central da organização e que se relacionam diretamente ao domínio do Sistema. Requisitos Voláteis. Ex: políticas do governo.

27 Gerenciamento de Requisitos
Planejamento de Gerenciamento de Requisitos No gerenciamento de requisitos devemos: Identificação de requisitos – identificação única para referencia cruzada e avaliações de rastreabilidade. Processo de Gerenciamento de Mudanças – Avaliação do impacto e custo das mudanças. Política de rastreabilidade Apoio informatizado Informações de rastreabilidade: Origem – stakeholders que propuseram e os motivos Requisitos – requisitos dependentes. Projeto – requisitos aos módulos de projeto, nos quais esses requisitos são implementados.

28 Gerenciamento de Requisitos
Gerenciamento de mudanças de requisitos O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas aos requisitos. Existem três estágios no processo: Análise do problema e especificação da mudança – Se existe o problema e se a mudança é válida ou é realizado um maior detalhamento. Análise da mudança e estimativa de custo – Efeito avaliado usando as informações de rastreabilidade e o conhecimento geral dos requisitos do Sistema. Implementação da mudança – O documento de requisitos, o projeto e a implementação do Sistema são modificados.