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

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

O processo de Engenharia de Requisitos. 2. Obtenção e Análise dos Requisitos Avaliar os problemas na situação atual Principal foco para o novo sistema:

Apresentações semelhantes


Apresentação em tema: "O processo de Engenharia de Requisitos. 2. Obtenção e Análise dos Requisitos Avaliar os problemas na situação atual Principal foco para o novo sistema:"— Transcrição da apresentação:

1 O processo de Engenharia de Requisitos

2 2. Obtenção e Análise dos Requisitos Avaliar os problemas na situação atual Principal foco para o novo sistema: O QUE e não COMO: – qual o fluxo e o conteúdo de informação – quais as funções do sistema – quais dados o sistema produz e consome – qual o comportamento do sistema – quais as características de interface com outros subsistemas – quais são as restrições do projeto

3 2. Obtenção e Análise dos Requisitos – cont. Sintetizar uma ou mais soluções –conforme delineado em um Plano de Projeto de Software –o processo de avaliação e síntese continua até que o analista e o cliente concordem que o sistema esteja adequadamente especificado –é a maior área de esforço

4 Modelagem Durante a atividade de avaliação e síntese devem ser criados –modelos do sistema para se compreender melhor o fluxo de dados e de controle: padrão de comportamento padrão da informação –esses modelos devem garantir o atendimento aos requisitos O modelo serve como fundamento para o projeto do sistema e como base para a criação de sua especificação

5 3. Especificação dos Requisitos Refinamento detalhado de todos os requisitos Requisitos de Produto –Funções descritas em detalhe –Estabelecimento das características de interface Com outros subsistemas Ambiente de implementação Interface Humano-Computador Segurança, etc –Identificação das restrições de projeto –Especificação dos critérios de validação

6 4. Validação Verifica os requisitos –Critérios: pertinência, consistência, completude –As revisões são conduzidas pelo Cliente e pelo Desenvolvedor –A base para a revisão são os documentos produzidos na Especificação dos Requisitos O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise

7 A Gerência do Processo de Desenvolvimento

8 Ciclo de Vida Qual o propósito de estabelecer um Ciclo de Vida para o Software? –Definir que atividades devem ser executadas em um projeto de desenvolvimento de sistemas –Introduzir consistência entre vários projetos de desenvolvimento de sistemas de uma mesma organização –Prover pontos de controle para prever, gerenciar e controlar o desenvolvimento de sistemas

9 Ciclo de Vida Cascata Evolucionário Formal Orientado a Reuso Espiral Incremental

10 Cascata Ciclo de Vida Clássico Prevê um processo de desenvolvimento com etapas seqüenciais Base: engenharia convencional O resultado de cada fase envolve a elaboração de um ou mais documentos que são aprovados

11 Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção Cascata

12 Problemas: –Para grandes projetos o tempo que decorre desde a especificação até sua implantação é grande –O Ambiente Externo evolui e é diferente daquele que deu origem a sua especificação –Na prática os estágios se sobrepõem –O processo de software envolve interações

13 Evolucionário Base –Desenvolver uma implementação inicial –Expor o resultado ao comentário do usuário –Aprimoramento por meio de muitas versões –Até que o sistema tenha sido totalmente desenvolvido Dois tipos: –Exploratório –Protótipos descartáveis

14 Evolucionário Exploratório –Trabalhar com o cliente –O desenvolvimento inicia com as partes do sistema que são compreendidas –O sistema evolui com as novas características propostas pelo cliente Protótipos descartáveis –O protótipo experimenta os requisitos não compreendidos –Neste caso o objetivo é a Especificação de Requisitos –Falaremos de protótipos mais adiante

15 Evolucionário Descrição do Esboço Versão Inicial Descrição do Esboço Especificação Versões Intermediárias Versão Final Desenvolvimento Validação

16 Evolucionário Produz sistemas que atendem as necessidades imediatas do cliente Problemas –O processo não é visível Não se produzem documentos que reflitam as versões do sistema –Freqüentemente são mal estruturados Software sem estrutura Modificações cada vez mais custosas –Ferramentas e técnicas especiais Possibilitam rápido desenvolvimento Poucas pessoas podem ter a habilitação necessária para usá-las

17 Evolucionário Definição de Requisitos e Refinamento Projeto Rápido Constru- ção do Protótipo Avaliação do Usuário Refinamento do protótipo Produto Final Início Fim

18 Formal Base: a transformação matemática formal de uma especificação de sistema em um programa executável –A especificação de requisitos é redefinida com uma linguagem formal Especificação de Requisitos Especificação Formal Transformação Formal Testes

19 Formal Transformação formal –Várias etapas –Representação mais detalhada, matematicamente correta Adequada a sistemas críticos –Permite verificação automática de consistência –Model checking utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições –Prova de teoremas axiomas do comportamento do sistema são empregados para derivar uma prova de que o sistema vai se comportar de uma determinada forma

20 Orientado a Reuso Ampla base de componentes reusáveis Infra-estrutura de integração Etapas: –De posse da Especificação de Requisitos, buscam-se componentes para implementá-la –Negociação – requisitos são modificados para que se possa usar os componentes Redução do esforço de desenvolvimento

21 Iteração de processo Existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema Partes do processo são repetidas enquanto os requisitos evoluem Modelos Híbridos –Apóiam a iteração do processo –Desenvolvimento Espiral –Desenvolvimento Incremental

22 Modelo Espiral O processo de desenvolvimento se move sobre uma espiral evolucionária –Melhores características do Ciclo de vida clássico Evolucionário – Prototipação Acrescenta Análise de Riscos As fases são executadas de forma iterativa As fases de análise e projeto não são monolíticas e distintas

23 Modelo Espiral

24 Planejamento –objetivos, alternativas e restrições Análise de Riscos –Análise de alternativas e identificação/resolução de riscos –Prototipação pode ser usada –Simulações e outros modelos podem ser usados para definir melhor o problema Desenvolvimento e Validação –Desenvolvimento do produto no nível seguinte Avaliação feita pelo Cliente Volta ao Planejamento

25 Enfoque Incremental Uma variação do modelo cascata onde a partir da fase de especificação de requisitos são feitos incrementos sucessivos. Estratégia para minimizar riscos, obtendo- se resultados de médio e curto prazo sem se descuidar do objetivo final

26 Enfoque Incremental Requisitos Design Codificação Testes Implantação Requisitos Design Codificação Testes Implantação Uma interação tempo

27 Desenvolvimento Incremental O Processo de Desenvolvimento RUP está em conformidade com o Desenvolvimento Incremental.

28 Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em partes, com cada incremento entregando parte da funcionalidade requerida Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados, embora possam continuar a evoluir para incrementos posteriores

29 Desenvolvimento Iterativo e Incremental (RUP)

30 Engenharia de Requisitos

31 Compreender a natureza do software a ser desenvolvido é realmente muito complexo Conseqüentemente é difícil estabelecer o que o sistema deve fazer Estabelecer o que o sistema deve fazer descrevendo suas funções e restrições é conseguir determinar todos os seus requisitos O Processo de: 1.Descobrir2.Analisar 3.Documentar4.Verificar É chamado de Engenharia de Requisitos

32 Engenharia de Requisitos

33 O processo de estabelecer as funções que um cliente requer de um sistema e as restrições sob as quais ele deve funcionar e ser desenvolvido Os requisitos são descrições das funções e restrições que são geradas durante o processo de engenharia de requisitos

34 Atividades de Engenharia de Requisitos – Recursos Humanos

35 Atividades de Engenharia de Requisitos Elicitação dos Requisitos - Especificação e Modelagem dos Requisitos Verificação e Validação dos Requisitos Rastreabilidade e Gestão de Mudanças Analista de Negócio ClienteTestadorInspetorAnalista de Requisitos

36 Organização e Responsabilidade - Papéis Analista de Negócios Negocia junto com os clientes e os demais envolvidos a lista dos requisitos iniciais e suas ampliações, priorizando-os e quando necessário agrupando-os em pacotes a serem desenvolvidos em iterações. É responsável por explicitar as regras de negócio e o glossário associado ao negócio. Analista de Requisitos Elicita os requisitos de produto e registrá-os de forma adequada. Garante a rastreabilidade dos requisitos de negócio e requisitos de produto ao longo do projeto. ClienteAprova a versão final do escopo da aplicação, descrito na Especificação de Requisitos de software InspetorInspeciona a Especificação de Requisitos de Software com relação ao formato. TestadorAplica o Plano de Testes e assegura que os requisitos implementados estão de acordo com o requisitado pelo cliente.

37 Explicitar o domínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão Elicitação dos Requisitos de Negócio

38 Especificação e Modelagem de Requisitos Elicitar Requisitos de Produto Especificar casos de uso e validá-los Especificar requisitos não funcionais Analisar e validar os requisitos Requisitos p/ Inspeção Plano e Casos de Teste Casos de Uso e Esp. Suplementar Regras de Negócio Glossário Documento de Visão Analista de Requisitos

39 Verificação e Validação dos Requisitos Verificar conflitos de requisitos Verificar consistência de requisitos Verificar completude de requisitos Verificar existência de requisitos ambíguos Analista de Requisitos p/ Inspeção Plano e Casos de Teste Casos de Uso e Esp. Suplementar Garantir a rastreabilidade dos requisitos Validar requisitos com o cliente Inspetor Especificação de Requisitos Atualizada Resultado dos Casos de Teste

40 Rastreabilidade e Gestão de Mudanças Avaliar o impacto nos requisitos Validar com o cliente Notificar os envolvidos Atualizar as especificações de requisitos Garantir a rastreabilidade nos requisitos Necessidade Documento de Visão Atualizado Solic. Mudança Analista de Requisitos Analista de Negócios Especificação de Requisitos Atualizada

41 Resumo da nomenclatura e templates RequisitoTiposDocumento Requisitos de Negócio (RQN)F, NF, IDocumento de Visão Requisitos de ProdutoFCasos de Uso (UC) NFEspecificação Suplementar (SUPL) Regras de Negócios (RN)-Regras de Negócios Termos (TERM)Glossário

42 Elicitação de Requisitos

43 Explicitar o domínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão Elicitação dos Requisitos de Negócio

44 Elicitação de Requisitos Atividades que envolvem a descoberta de requisitos de um sistema: –identificação das fontes de informação –técnicas de elicitação (coleta de fatos) –comunicação (estabelecer uma linguagem comum) Envolve pessoal objetivando descobrir: –o domínio de aplicação –serviços que devem ser fornecidos –restrições

45 Elicitação de Requisitos Pode envolver diferentes tipos de pessoas em uma organização (stakeholders): –usuários –gerentes –desenvolvedores –especialistas de domínio –sindicatos,... A equipe de desenvolvimento e clientes trabalham em conjunto visando identificar: –detalhes do domínio da aplicação –serviços que o sistema deve oferecer –desempenho –restrições de hardware,...

46 Elicitação de Requisitos Problemas: –Em geral, stakeholders não sabem o que querem de fato dificuldade de expressão pedidos não realistas –Stakeholders expressam requisitos em sua própria terminologia conhecimento implícito –Stakeholders distintos podem ter requisitos conflitantes –Fatores políticos podem influenciar os requisitos do sistema –Ambientes econômicos e de negócios são dinâmicos requisitos mudam durante o processo de análise novos requisitos podem surgir (novos stakeholders)

47 Elicitação de Requisitos Atividades do Processo: –Compreensão do domínio –Coleta de requisitos –Classificação –Resolução de conflitos –Definição de Prioridades –Verificação de requisitos

48 Compreensão do Domínio Os analistas devem desenvolver sua compreensão do domínio da aplicação –se estiver desenvolvendo um sistema de supermercado deverá descobrir como este funciona –utilizar técnicas para descobrir este funcionamento –aprender a linguagem do usuário elaborar um Glossário

49 Coleta de Requisitos Interagir com stakeholders para descobrir os requisitos A coleta de requisitos é feita através de técnicas Os requisitos são simplesmente documentados à medida que são coletados –resulta em documento preliminar (draft)

50 Classificação dos Requisitos Consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidas Classificação: –Funcional Ex.: Deve ser possível consultar o preço de uma mercadoria –Não Funcional Ex.: A consulta deve retornar uma resposta em no máximo 5s –Inversos Ex.: O sistema não fará controle de estoque.

51 Resolução de Conflitos É normal que ocorram requisitos conflitantes Por exemplo –R-23: O sistema deve... –R-45: O sistema não deve... Cliente é o responsável por resolver conflitos e ambigüidades

52 Atribuição de Prioridade Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar

53 Prioridade Requisitos podem ser agrupados em classes, por exemplo: –Essenciais –Importantes –Desejáveis Em princípio, o sistema deve abranger todos os requisitos de essenciais para desejáveis

54 Exemplo de Prioridade A consulta ao extrato bancário deve retornar dados do movimento até o dia anterior –Prioridade: Essencial A consulta ao extrato bancário deve visualizar dados segundo padrão X –Prioridade: Importante A consulta ao extrato bancário deve usar cores vermelhas para saldos negativos –Prioridade: Desejável

55 Verificação de Requisitos Os requisitos são verificados –Completos? –Consistentes? –Em concordância com o que os stakeholders desejam?

56 Processo de Elicitação de Requisitos Compreensão do Domínio Coleta de Requisitos Verificação dos Requisitos Definição de Prioridades Resolução de Conflitos Classificação Especificação de Requisitos Documento de Requisitos

57 Técnicas de Elicitação

58 Entrevistas Questionários Leitura de Documentos Observação Reuniões –Brainstorming –JAD – Joint Application Design Cenários

59 Entrevistas Técnica direta –Pode ser usada na análise do problema e na elicitação de requisitos Objetivo –Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders Pode ser guiada por um questionário

60 Entrevistas Quatro tipos de questões são importantes em entrevistas: -Sobre o usuário -Sobre o processo -Sobre o produto -Meta-perguntas

61 Entrevistas Usuário: –Quem é o cliente? –Quem é o usuário? –Suas necessidades são diferentes? –Quais são suas formações, habilidades, ambientes?

62 Entrevistas Processo: –Qual é o problema? –Como é resolvido atualmente? –Qual a razão para resolver o problema? –Existe outra solução para este problema? –Qual o valor de uma solução bem-sucedida?

63 Entrevistas Produto: –Que problema esse produto resolve? –Que problemas de negócios esse produto poderá ocasionar? –Que riscos poderão existir para o usuário? –Que ambiente o produto encontrará? –Quais são as suas expectativas em relação à usabilidade (facilidade de uso)? –Quais são as suas expectativas em relação à confiabilidade? –Que desempenho/precisão é exigido?

64 Meta-perguntas: –Estou fazendo muitas perguntas? –Minhas perguntas parecem relevantes? –Você é a pessoa certa para responder a essas perguntas? –As suas respostas são requisitos? –Posso fazer mais perguntas depois? –Você aceitaria participar de uma revisão de requisitos? –Há algo mais que eu poderia perguntar a você? Entrevistas

65 Questionários Acesso a um grande número de pessoas Vantagens: –padronização de perguntas –possibilidade de tratamento estatístico das respostas Desvantagens: –limitação do universo de respostas –pouca interação (impessoalidade técnica)

66 Questionários Aplicabilidade a mercados específicos –com perguntas bem definidas Em questionários: –perguntas relevantes podem ser decididas antecipadamente, por entrevistas –o leitor interpreta a pergunta da maneira que deseja – possibilidade de análise com questões abertas

67 Análise de documentos referentes ao sistema –Documentos técnicos: relatórios, manuais –Documentos legais: normas, leis, atas –Análise de formulários Leitura de Documentos

68 Observação Analista se insere no ambiente de trabalho em que o sistema será utilizado –Observa trabalho diário –Anota as tarefas reais dos participantes Analista é imparcial Deve ser usada com outras técnicas Técnica de observação: etnografia

69 Observação É eficaz na descoberta de dois tipos de requisitos –Os derivados da maneira como as pessoas realmente trabalham e não a forma como deveriam trabalhar Operadores desligam alarme de colisão em um controle aéreo –Os derivados da cooperação e conscientização das atividades de outras pessoas Um controlador de tráfego aéreo pode prever quantas aeronaves entrarão no seu setor de controle, observando trabalho em setores adjacentes Portanto o sistema deve prever alguma visibilidade destes setores adjacentes

70 Reuniões Permite uma interação mais natural entre pessoas Revela múltiplas visões sobre a questão abordada –explicitar cada problema encontrado nos requisitos –todos os interessados devem ter a oportunidade de comentar (criação coletiva) –oportunidade para priorizar requisitos

71 Reuniões Desvantagens: –possibilidade de dispersão –custo Estratégias para Reuniões: –Brainstorming –Joint Application Design (JAD)

72 Reuniões - Brainstorming Fase de exploração de requisitos Regras para Brainstorming –Estabeleça o objetivo da sessão –Gere quantas idéias for possível –Deixe sua imaginação livre –Não admita críticas ou debates –Ajuste e combine as idéias

73 Reuniões - JAD Joint Application Design Surgiu em meados de 1970, na IBM Similar a um Workshop de requisitos Fase de especificação de requisitos Põe todos os stakeholders juntos por um período intensivo (focado) Pode utilizar representações de Engenharia de Software

74 Reuniões - JAD Provê um ambiente para aplicar outras técnicas de elicitação Facilitador conduz a reunião Todos têm sua vez de falar Resultados estão disponíveis imediatamente

75 JAD - Definições Executivo patrocinador: –Gerente de nível mais alto comprometido com JAD –Patrocina o processo do início ao fim –Fornece diretrizes sobre os objetivos e metas de um projeto –Define expectativas claras para saída do processo JAD –Realiza breve palestra; não participa de atividades das sessões detalhadas, pode ser chamado para esclarecer questões administrativas críticas Gerentes funcionais e usuários finais: –Peritos em sessões JAD detalhadas –Tem a capacidade de descrever porque precisam do sistema

76 JAD - Definições Representantes da TI: –Poucas pessoas –Convidadas a participar das sessões –Tem conhecimentos técnicos das aplicações atuais do negócio pelo ponto de vista dos sistemas Líder de sessão JAD –Coração do processo JAD –Seu papel é conduzir as entrevistas preparatórias antes da sessão JAD real com o executivo patrocinador e com gerentes funcionais para a definição do escopo básico do processo

77 JAD - Definições Escribas –Registrar oficialmente todas as informações pertinentes ao sistema estudado –Sessões maiores – 2 escribas Um descreve os comportamentos do sistema Outro (da mesma área dos usuários) controla questões de negócio levantadas pelos usuários durante a sessão de dinâmica de grupo –Uso de ferramentas automatizadas para capturar os requisitos e exibir de volta para os usuários as telas, relatórios, etc.

78 Reuniões - JAD

79 Processo JAD Quatro etapas: –Orientação inicial –Familiarização com a área/aplicação –Preparação do material para o workshop –Workshop

80 Processo JAD – Orientação Inicial Definição global do projeto documentando os seguintes itens –finalidade do projeto –escopo do projeto e áreas funcionais envolvidas –objetivos que devem ser alcançados no final do workshop –suposições técnicas e de negócio que afetam o projeto –fatores críticos de sucesso Informações são obtidas pelo líder –com o executivo patrocinador –com os gerentes funcionais e de sistemas ligados ao projeto antes do workshop

81 Processo JAD - Familiarização com a área/aplicação Análise de procedimentos atuais do negócio e identificação do fluxo geral de trabalho dos documentos no local do trabalho Documentar procedimentos, ressaltando: –finalidade da tarefa –dados de entrada –dados de saída –descrição do processo feito –problemas/oportunidades

82 Processo JAD - Preparação do material para o workshop Analista de Sistema (pode ser o líder JAD) constrói um modelo elementar do sistema –esboço de telas e relatórios –veículos para simular as idéias

83 Processo JAD - Conduzir o workshop Duração: 3 a 5 dias 1º dia: –Explicar a finalidade do projeto –Descrever os compromissos de todos os participantes com apoio da administração –Dar as informações gerais relacionadas ao escopo, objetivo –Revisar o material detalhado e consolidado antes da reunião - abordagem estruturada, passo a passo Conforme o workshop progride, os escribas transcrevem as decisões para telões, permitindo rápidas revisões do trabalho realizado até o momento

84 Cenários Esboço da interação Os métodos baseados em Cenários consistem de uma coleção de narrativas de situações do domínio do problema que permitem a identificação de componentes do projeto Meio de representação de fácil compreensão para os usuários envolvidos que passam a poder avaliar, criticar e fazer sugestões

85 Cenários Esboço da interação Podem incluir: –Uma descrição do estado do sistema no início do cenário –Uma descrição do fluxo normal de eventos no cenário –Uma descrição do que pode sair errado e de como lidar com isso –Informações sobre outras atividades que possam estar em andamento ao mesmo tempo, e –Uma descrição do estado do sistema no final do cenário.

86 Cenários Exemplo de Cenário de uso típico para um sistema da biblioteca: –Um aluno chega na biblioteca para procurar livros-texto dos cursos que está freqüentando. Ele entra no sistema e seleciona os cursos, e obtém uma lista de todos os livros-texto e sua localização na biblioteca. Seleciona a opção de bibliografia complementar e uma nova lista de livros e periódicos lhe é apresentada. Ele então manda imprimir todas as referências encontradas

87 É uma técnica psicolingüística que permite a psicólogos e lingüistas examinarem o conteúdo e a estrutura de informações contidas numa narrativa Objetivo é investigar de que maneira as narrativas são efetivamente compreendidas Pode ser utilizada pelos analistas e projetistas tanto para adquirir mais rapidamente conhecimentos sobre o domínio como para inferir objetos e interações não- descritos na narrativa Cenários – Técnica de Questionamento Sistemático

88 Abrange quatro Etapas: 1.Geração do Cenário 2.Elaboração da Rede de Proposições 3.Análise 4.Questionamento Sistemático Cenários – Técnica de Questionamento Sistemático

89 1.Geração do Cenário As narrativas que compõem o cenário devem ser escritas pelo especialista no domínio. O analista pode motivá-lo fazendo perguntas como num processo convencional de entrevista Um exemplo de cenário seria: Eu quero sacar R$ 100,00. Eu insiro o cartão no caixa eletrônico, pressiono o botão de saque, digito minha senha, retiro o cartão e o dinheiro Cenários – Técnica de Questionamento Sistemático

90 2.Elaboração da Rede de Proposições As narrativas devem ser simplificadas e expressas através de proposições, como por exemplo: cliente insere cartão no caixa eletrônico cliente pressiona botão de saque rápido cliente digita a senha cliente pega cartão cliente pega dinheiro Cenários – Técnica de Questionamento Sistemático

91 3.Análise A partir das proposições, pode-se determinar o perfil das tarefas (ações e objetos) e dos usuários (agentes das ações) Cenários – Técnica de Questionamento Sistemático

92 4.Questionamento Sistemático Novas proposições podem ser elaboradas através de questões que são feitas sobre elementos das proposições anteriores, num processo iterativo. Existem diversos tipos de questões: –Por que...? –visa revelar consequências e causas a respeito de eventos da narrativa Cenários – Técnica de Questionamento Sistemático

93 –Como...? –Oferece maiores detalhes a respeito de determinados eventos, permitindo determinar sub-tarefas e maiores detalhes sobre a interação –O que é...? –Pode ser feita sobre objetos e revelam atributos e hierarquias de objetos –Então isto é/ocorre assim...? –Pode ser feita para saber se as proposições estão sendo entendidas corretamente Cenários – Técnica de Questionamento Sistemático

94 Exercício Quais técnicas poderiam ser usadas em: 1.Sistema da padaria de pequeno porte 2.Sistema inteligente de preenchimento do IRPF 3.Sistema de abertura automática de porta


Carregar ppt "O processo de Engenharia de Requisitos. 2. Obtenção e Análise dos Requisitos Avaliar os problemas na situação atual Principal foco para o novo sistema:"

Apresentações semelhantes


Anúncios Google