A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Fase de Elaboração: Fluxo de Requisitos Análise de Sistemas de Software Prof. Rodrigo Ribeiro.

Apresentações semelhantes


Apresentação em tema: "Fase de Elaboração: Fluxo de Requisitos Análise de Sistemas de Software Prof. Rodrigo Ribeiro."— Transcrição da apresentação:

1 Fase de Elaboração: Fluxo de Requisitos Análise de Sistemas de Software Prof. Rodrigo Ribeiro

2 Princípios Finalidade do Fluxo de Requisitos Artefatos do PRAXIS Documentos PESw ERSw Modelos CRSw MASw

3 Especificação de Requisitos A ERSw deve incluir características de Funcionalidade Interfaces Externas Desempenho Restrições Linguagens, plataformas, etc... Outros Portabilidade Manutenibilidade Confiabilidade

4 Especificação de Requisitos Quem produz? Membros da equipe de desenvolvimento Usuários chaves indicados pelo cliente Porque um equipe mista? A equipe não conhece os processos de negócio do usuário Usuários não entendem de engenharia de software Usuários chaves conhecem o processo? Não, mas devem ser treinados para isso.

5 Especificação de Requisitos Evolução de requisitos Motivos Descoberta de defeitos nos requisitos originais Falta de detalhes nos requisitos originais Alterações incontornáveis nos requisitos originais Uma organização madura... Requisitos são controlados para estabelecer uma base gerencial e de engenharia de software. Todos os artefatos são consistentes entre si

6 Especificação de Requisitos Limites Não inclui decisões de desenho e implement. Exceção:restrições do cliente para uma linguagem Não inclui decisões gerenciais. Qualidade dos Requisitos Especificação de Requisitos deve ser... Correta Todo requisito presente realmente é um requisito Completa Todos os requisitos necessários estão presentes

7 Especificação de Requisitos Qualidade Especificação de Requisitos deve ser... Precisa Todo requisito deve ter uma única interpretação Consistente Não existe conflitos entre requisitos especificados Priorizada Existe uma ordem de prioridade dos requisitos Verificável Todos os requisitos devem verificável Modificável A mudança da estrutura e estilo dos requisitos é simples. Rastreável Permite a fácil identificação de antecedentes e conseqüências dos requisitos

8 Atividades Determinação de Contexto Levantamento dos processos de negócio Resultado: PESw Definição do escopo Delimita problemas a serem resolvidos Resultado: ERSw-1 (Introdução) Definição dos requisitos Versão inicial dos requisitos funcionais e não funcionais Resultado: ERSw-2 (Descrição geral do produto) Detalhamento de requisitos de interface externa Aspectos de GUI considerados como requisitos Resultado: ERSw-3.1 (Requisitos de interface externa)

9 Atividades Detalhamento de requisitos funcionais Descrição completa dos casos de uso Resultado: ERSw-3.2 (Requisitos funcionais) MASw-VCU(Visão de casos de uso) Detalhamento de requisitos não funcionais Detalhamento de desempenho entre outros Resultado: ERSw-3.3(Requisitos não funcionais) Classificação de requisitos Determinação de prioridades Resultado: CRSw (Casos de uso, requisitos não funcionais) Revisão de requisitos Resultado: RRERSw

10 Detalhes das Atividades Determinação de contexto e escopo Uso de UML, BPMN, etc... Definição de requisitos Uso de diagramas e casos de uso Definição de requisitos de interface ERSw deve conter esboços das interfaces do produto Diagramas de Estado Definição de requisitos funcionais Casos de uso Diagramas de seqüência e de atividades

11 Detalhes das Atividades Detalhamento de requisitos não funcionais O que pode ser considerado? Desempenho, qualidades técnicas do produto Requisitos não funcionais Devem ser enunciados de forma precisa Devem ser quantificáveis. Dados persistentes Levantamento inicial de um diagrama de classes persistentes.

12 Detalhes das Atividades Detalhamento de requisitos não funcionais Atributos de qualidade Norma ISSO 9126 Define Atributos de funcionalidade Acurácia, segurança, interoperabilidade Manutenibilidade Analisabilidade, Modificabilidade, Estabilidade, Testabilidade Portabilidade Confiabilidade Desempenho

13 Detalhes das Atividades Classificação de requisitos (CRSw) Listagem formada por... ID Deve ser único no projeto Caso de uso Tipo Fluxo principal, alternativo, subfluxo ou relatório Prioridade Essencial, desejável ou opcional Estabilidade Baixa, média ou alta Aplicável a requisitos funcionais e não funcionais Última Atividade: Revisão dos requisitos.

14 Técnicas Protótipos Tipos Protótipos descartável Protótipos evolucionários No contexto do PRAXIS... Somente protótipos descartáveis... Protótipos evolucionários: liberações Objetivos Alternativas de interface de usuário Problemas de comunicação com outros produtos Validação de requisitos

15 Técnicas Protótipos descartáveis Riscos Cliente achar que protótipos são produtos finais Desejo de reaproveitamento de desenvolvedores Benefícios Redução de riscos na construção dos produtos Aumento da estabilidade dos requisitos

16 Técnicas Oficinas de requisitos Conceito Reuniões estruturadas para definição de requisitos Quem participa Desenvolvedores e usuários chaves Vantagens Comprometimento sobre requisitos Redução do prazo para levantamento de requisitos Eliminar requisitos de valor questionável Eliminar ambigüidades. Produzir um esboço das interfaces do usuário.

17 Técnicas Oficinas de Requisitos Tarefas Personalização, Sessões, Fechamento Detalhamento Personalização Organização da equipe da oficina Orientação dos participantes quanto à técnica Determinação de particularidades do projeto Preparação de materiais e instalações para as sessões Tempo de duração: 1 a 10 dias.

18 Técnicas Oficinas de requisitos Detalhamento Sessões Definição de alto nível dos requisitos Delimitação do escopo do produto Levantamento de casos de uso do produto Detalhamento inicial dos casos de uso do produto Levantamento de requisitos de GUI e interface com outros softwares. Fechamento Documentação dos resultados das seções Versão inicial da ERSw Versão inicial da MASw

19 Técnicas Oficinas de requisitos Problemas Não participação dos usuários chave Participação de pessoas não comprometidas Número excessivo de pessoas Valores recomendados: 8 – 15 pessoas Relacionamento com Clientes Participação de clientes é fundamental Alguns problemas Falta de entendimento da importância da engenharia de software Existência de múltiplos contatos do cliente

20 Técnicas Relacionamento com clientes Problemas Causados pelo fornecedor Promessas de prazo impossíveis Custos artificialmente baixos Falta de competência Baixa qualidade do produto Causados pelo cliente Exigência de prazos impossíveis Exigência de novos ou alterações de requisitos


Carregar ppt "Fase de Elaboração: Fluxo de Requisitos Análise de Sistemas de Software Prof. Rodrigo Ribeiro."

Apresentações semelhantes


Anúncios Google