Eng.ª do Software - 3. Processos da engenharia de requisitos
-
Upload
manuel-menezes-de-sequeira -
Category
Education
-
view
7.198 -
download
2
description
Transcript of Eng.ª do Software - 3. Processos da engenharia de requisitos
ENGENHARIA DO SOFTWARE I
Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
[email protected], D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de
Sequeira.
Engenharia do Software I 2
Sumário
Processo da engenharia de requisitosEstudos de viabilidadeEliciação e análise de requisitosValidação de requisitosGestão de requisitos
2009/2010
Engenharia do Software I 3
Processos da Engenharia de Requisitos
2009/2010
Engenharia do Software I 4
Na aula anterior
RequisitosFuncionais e não funcionaisDo utilizadorDo sistemaEspecificação da interfaceDocumento de requisitos de software
2009/2010
5Engenharia do Software I
O processo da engenharia de requisitos
Relatório de viabilidade
Modelos do sistema
Requisitos do utilizador e do
sistema
Documento de requisitos
Estudo de viabilidade
Eliciação e análise de requisitos
Especificação de requisitos
Validação de requisitos
2009/2010
6Engenharia do Software I
Engenharia de requisitos
Especificação dos requisitos do
negócio
Especificação dos requisitos do
utilizador
Especificação dos requisitos do sistema
e modelação
Estudo de viabilidade
Prototipagem
Revisões
Eliciação dos
requisitos do utilizador
Eliciação dos
requisitos do sistema
Documento de requisitos do
sistema
Validação de
requisitos
Especificação de
requisitos
Eliciação de
requisitos
2009/2010
Engenharia do Software I 7
Estudos de viabilidade
Decide se o sistema proposto vale a pena
Estudo bem focado que verifica se sistemaContribui para objectivos da organização?Pode ser realizado usando a tecnologia
existente e com o orçamento disponível?Pode ser integrado com outros sistemas em
uso?
2009/2010
Engenharia do Software I 8
Implementação do estudo de viabilidade Baseada em
Avaliação de informação (o que é necessário)Recolha de informaçãoRedacção de relatórios
Questões para membros da organizaçãoE se o sistema não fosse implementado?Quais são os problemas de processo correntes?De que forma o sistema proposto ajudará?Quais serão os problemas de integração?É necessária nova tecnologia? E que competências?O que terá o sistema de suportar?
2009/2010
Engenharia do Software I 9
Eliciação e análise
Por vezes conhecida por eliciação de requisitos ou descoberta de requisitos
Equipa técnica colabora com cliente para obter informação acerca deDomínio de aplicaçãoServiços a prestar pelo sistemaRestrições operacionais do sistema
2009/2010
Engenharia do Software I 10
Eliciação e análise
Pode envolverUtilizadores finaisGestoresEngenheiros responsáveis
pela manutençãoPeritos no domínioSindicatosEtc.
Partes interessadasou Stakeholders
2009/2010
Engenharia do Software I 11
Parte interessada ou stakeholder Termo muito importante!
Qualquer pessoa ou entidade afectada pelo sistema ou interessada nele, quer directa, quer indirectamente
2009/2010
Engenharia do Software I 12
Problemas da análise de requisitos Partes não sabem o que de facto querem
Partes expressam requisitos usando termos próprios
Partes podem ter requisitos contraditórios
Factores organizacionais e políticos influenciam requisitos do sistema
Requisitos mudam durante a análise Surgem novas partes Contexto do negócio muda
2009/2010
13Engenharia do Software I
Espiral da análise de requisitos
Documentação
Prioritização e
negociação
Descoberta
Classificação e
organização
2009/2010
Engenharia do Software I 14
Actividades do processo de eliciação e análise de requisitosDescoberta Interagindo, descobrir requisitos
das partes (requisitos do domínio também nesta fase)
Classificação e organização
Agrupar e organizar requisitos relacionados
Prioritização e negociação
Prioritizar e resolver conflitos entre requisitos
Documentação Documentar requisitos usando-os como entrada da próxima espira
2009/2010
Engenharia do Software I 15
Descoberta de requisitos
Processo deRecolha de informação acerca do sistema
proposto e de sistemas existentes Destilação dos requisitos do utilizador e do
sistema a partir dessa informação
Fontes de informaçãoDocumentaçãoPartes interessadas no sistemaEspecificações de sistemas semelhantes
2009/2010
Engenharia do Software I 16
Partes interessadas num ATM Clientes dos bancos Representantes dos bancos Gestores dos bancos Pessoal de balcão Administradores de bases de dados Gestores de segurança Departamentos de marketing Engenheiros de manutenção de hardware e
software Reguladores da banca
2009/2010
Engenharia do Software I 17
Pontos de vista
Estruturação de requisitos representando diferentes perspectivas das partes (partes podem ser classificadas sob diferentes pontos de vista)
Análise multi-perspectiva importante: Não há forma correcta única de analisar requisitos do sistema
2009/2010
Engenharia do Software I 18
Tipos de pontos de vistaInteracção Pessoas ou outros sistemas que
interagem directamente com o sistema
Indirectos Partes que não usam sistema mas influenciam requisitos
Domínio Características e restrições do domínio que influenciam requisitos
2009/2010
Engenharia do Software I 19
Tipos de pontos de vista: ATMInteracção Clientes e base de dados das contas
Indirectos Gestores e equipas de segurança
Domínio Normas e protocolos de comunicação interbancária
2009/2010
Engenharia do Software I 20
Identificação de pontos de vista
Fornecedores e consumidores de serviços do sistema
Sistemas que interagem directamente com sistema
Regulamentos e normas
Fontes de requisitos do negócio e não funcionais
Engenheiros de desenvolvimento e manutenção
Marketing e outras facetas do negócio
2009/2010
21Engenharia do Software I
Hierarquia de pontos de vista do LIBSYS
Todos
Indirectos DomínioInteracção
Director da biblioteca
Finanças Fornecedores
Utilizadores Pessoal da biblioteca
Normas da interface com
utilizador
Sistema de classificação
Estudantes Funcionários Externos Gestores de sistemas
Catalogadores
2009/2010
Engenharia do Software I 22
Entrevistas Formais ou informais
Equipa de eliciação coloca questões às partes acerca do sistema que usam e do sistema a desenvolver
Dois tiposFechadas – Conjunto pré-definido de questõesAbertas – Sem ordem de trabalhos pré-definida;
explora-se uma variedade de assuntos
2009/2010
Engenharia do Software I 23
Entrevistas na prática Normalmente misto entre abertas e fechadas
Boas para compreender o que as partes fazem e como podem interagir com o sistema
Más para compreender requisitos do domínioEngenheiros de requisitos não entendem
terminologia específica do domínioAlgum conhecimento do domínio é tão familiar que
entrevistados têm dificuldade em articulá-lo ou julgam não valer a pena fazê-lo
2009/2010
Engenharia do Software I 24
Entrevistadores eficazes Características
Espírito abertoBons ouvintes das partesSem preconceitos acerca dos requisitos
Incentivam entrevistado com perguntas ou propostas
Não esperam que entrevistado responda a perguntas vagas (“O que precisa?”)
2009/2010
Engenharia do Software I 25
Cenários
Exemplos reais de possíveis utilizações do sistema
Devem incluirDescrição da situação inicialDescrição do fluxo normal de eventosDescrição do que pode correr malInformação acerca de actividades paralelasDescrição do estado final
2009/2010
Engenharia do Software I 26
Cenário LIBSYSSuposição inicial
Utilizador autenticou-se no sistema LIBSYS e localizou publicação contendo artigo desejado.
Fluxo normal
Utilizador selecciona artigo a copiar. Sistema solicita informação de subscrição ou método de pagamento. Métodos são cartão de crédito ou factura a centro de custos. Utilizador responde.
Sistema solicita preenchimento de formulário de direitos de autor incluindo pormenores da transacção. Utilizador preenche e submete informação.
Formulário verificado. Se correcto, versão PDF do artigo colocada na área de trabalho LIBSYS do computador do utilizador, que é avisado. Sistema solicita escolha de impressora. Utilizador escolhe. Artigo impresso. Se marcado só para impressão, artigo removido do sistema do utilizador logo que confirme que impressão terminou.
2009/2010
Engenharia do Software I 27
Cenário LIBSYSO que pode correr mal
Utilizador preenche erradamente formulário de direitos de autor. Formulário apresentado de novo para correcção. Se submetido de novo com erros, pedido do artigo rejeitado.
O pagamento rejeitado pelo sistema. Pedido do artigo rejeitado.
Descarregamento do artigo falha. Tenta de novo até sucesso ou até utilizador terminar sessão.
Não é possível imprimir. Se não marcado só para impressão, mantém-se no espaço de trabalho. Se sim, artigo removido e conta do utilizador creditada do seu preço.
Outras actividades
Descarregamentos simultâneos de outros artigos.
Estado final
Utilizador com sessão aberta. Artigo descarregado removido do espaço de trabalho LIBSYS se marcado só para impressão.
2009/2010
Engenharia do Software I 28
Casos de uso Técnica UML baseada em cenários
identificando actores e descrevendo a interacção
Conjunto dos casos de uso deve cobrir todas possíveis interacções com sistema
Diagramas de sequência podem pormenorizar casos de uso mostrando sequência de processamento de eventos
2009/2010
Engenharia do Software I 29
Etnografia Sociólogo/antropólogo dedica tempo a observar
e analisar como pessoas trabalham
Pessoas não explicam seu trabalho
Revela factores sociais e organizacionais importantes
Mostram que trabalho é mais rico e complexo que aparente e que sugerido por modelos simples do sistema
2009/2010
Engenharia do Software I 30
Etnografia focalizada
Combina etnografia e prototipagem
Desenvolvimento de protótipos resulta em novas questões focalizando análise etnográfica
2009/2010
Engenharia do Software I 31
Âmbito da etnografia
Requisitos derivam da forma efectiva de trabalho das pessoas e não das especificações em definições de processos
Problema com a etnografia é que estuda práticas com explicação histórica que já não é relevante
2009/2010
Engenharia do Software I 32
Validação de requisitos
Pretende demonstrar que requisitos definem sistema pretendido pelo cliente
Altos custos associados a erros nos requisitos! Validação importantíssima
Corrigir erro nos requisitos depois da entrega pode custar 100 vezes mais que corrigir erro de implementação
2009/2010
Engenharia do Software I 332009/2010
custo
tempo
Engenharia do Software I 34
Verificação de requisitosValidade Sistema disponibiliza funções que
melhor suportam necessidades do cliente?
Consistência Há conflitos entre requisitos?
Completude Incluídas todas funções requeridas pelo cliente?
Realismo Requisitos implementáveis dados orçamento e tecnologia?
Verificabilidade Requisitos verificáveis?
2009/2010
Engenharia do Software I 35
Técnicas de validação de requisitosRevisão de requisitos
Análise manual sistemática dos requisitos
Prototipagem Verificação de requisitos usando modelo executável do sistema
Geração de casos de teste
Desenvolvimento de testes para requisitos para verificar testabilidade
2009/2010
Engenharia do Software I 36
Revisões de requisitos Devem realizar-se regularmente durante
formulação da definição dos requisitos
Devem envolver cliente e adjudicatário
Formais (documentos) ou informais
Boa comunicação entre desenvolvedores, clientes e utilizadores permite resolver problemas mais cedo
2009/2010
Engenharia do Software I 37
Verificações das revisõesVerificabilidade Requisito realisticamente
testável?
Compreensibilidade Requisito compreensível?
Rastreabilidade Origem do requisito claramente indicada?
Adaptabilidade Requisito pode ser modificado sem grande impacte em outros requisitos?
2009/2010
Engenharia do Software I 38
Gestão de requisitos Processo de gerir requisitos em mudança
durante processo da engenharia de requisitos e desenvolvimento do sistema
Requisitos inevitavelmente incompletos e inconsistentesNovos requisitos surgem durante processo devido
a mudanças nas necessidades do negócio e à melhor compreensão do sistema
Pontos de vista diferentes têm diferentes requisitos muitas vezes contraditórios
2009/2010
Engenharia do Software I 39
Os requisitos mudam Prioridades de diferentes pontos de vista
mudam durante processo de desenvolvimento
Clientes podem especificar requisitos sob perspectiva do negócio que colidem com requisitos de utilizadores finais
Contextos do negócio e técnico mudam durante desenvolvimento do sistema
2009/2010
40Engenharia do Software I
Evolução dos requisitos
2009/2010
Compreensão inicial do problema
Requisitos iniciais
Compreensão do problema
modificada
Requisitos modificados
tempo
Engenharia do Software I 41
Requisitos duradouros e voláteisRequisitos duradouros
Estáveis, derivados da actividade central do cliente (um hospital terá sempre médicos, enfermeiros, etc.). Podem resultar de modelos do domínio.
Requisitos voláteis
Mudam durante o desenvolvimento ou em produção (num hospital, requisitos resultando de políticas de saúde)
2009/2010
Engenharia do Software I 42
Classificação de requisitos
Mutáveis Mudam com o contexto de operação da organização (e.g., financiamento de cuidados de saúde pode variar e requerer informação diferente)
Emergentes Emergem durante desenvolvimento à medida que o cliente percebe melhor o sistema (processo de desenho pode revelar requisitos emergentes)
2009/2010
Engenharia do Software I 43
Classificação de requisitos
Consequentes Sistema pode levar a alterações nos processos da organização e criar nova formas de trabalho resultando em novos requisitos
De compatibilidade Dependem de sistemas ou processos do negócio na organização, tendo de evoluir com eles
2009/2010
Engenharia do Software I 44
Planeamento da gestão de requisitosIdentificação de requisitos
Como identificar os requisitos individualmente
Processo de gestão de mudanças
Processo seguido quando se analisa uma mudança de requisitos
Políticas de rastreabilidade
Quantidade de informação acerca das relações entre requisitos
Suporte em ferramentas CASE
Suporte por ferramentas necessário para ajudar a gerir mudanças de requisitos
2009/2010
Engenharia do Software I 45
Suporte em ferramentas CASE
Armazenamento de requisitos
Requisitos devem ser mantidos num armazém de dados gerido e seguro
Gestão de mudanças
Processo de fluxo de trabalho com etapas definidas e entre as quais o fluxo de informação pode ser parcialmente automatizado
Gestão da rastreabilidade
Extracção automática de ligações entre requisitos
2009/2010
Engenharia do Software I 46
Gestão de mudanças em requisitos Deve aplicar-se a todas as modificações
de requisitos propostas
Principais etapas
2009/2010
Análise do problema
Discutir problema de requisitos e propor mudança
Análise e custeio da mudança
Aferir efeitos da mudança em outros requisitos
Implementação da mudança
Modificar documento de requisitos e outros documentos para reflectirem a mudança
47Engenharia do Software I
Gestão de mudanças em requisitos
2009/2010
Análise do problema e especificação da mudança
Análise e custeio da mudança
Implementação da mudança
Problema identificad
o
Documentos revistos
Engenharia do Software I 48
A reter Processo de engenharia de requisitos inclui
Estudo de viabilidade Eliciação e análise de requisitos Especificação de requisitos Gestão de requisitos
Eliciação e análise de requisitos são iterativas e incluem Compreensão do domínio Recolha de requisitos Classificação de requisitos Estruturação de requisitos Prioritização de requisitos Validação de requisitos
2009/2010
Engenharia do Software I 49
A reter Sistemas têm múltiplas partes interessadas com
diferentes requisitos
Factores sociais e organizacionais influenciam requisitos do sistema
Validação dos requisitos verificaValidadeConsistênciaCompletudeRealismoVerificabilidade
2009/2010
Engenharia do Software I 50
A reter
Modificações no negócio conduzem inevitavelmente a mudanças nos requisitos
Gestão de requisitos inclui planeamento e gestão de mudanças
2009/2010
A ler
Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006
Capítulo 6
Capítulo 7
2009/2010 51Engenharia do Software I