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.

mailto:[email protected]

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE8/Presentations/index.html



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


Processos da Engenharia de Requisitos

2009/2010


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


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


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


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


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


Eliciação e análise

Pode envolverUtilizadores finaisGestoresEngenheiros responsáveis

pela manutençãoPeritos no domínioSindicatosEtc.

Partes interessadasou Stakeholders

2009/2010


Parte interessada ou stakeholder Termo muito importante!

Qualquer pessoa ou entidade afectada pelo sistema ou interessada nele, quer directa, quer indirectamente

2009/2010


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


Espiral da análise de requisitos

Documentação

Prioritização e

negociação

Descoberta

Classificação e

organização

2009/2010


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Etnografia focalizada

Combina etnografia e prototipagem

Desenvolvimento de protótipos resulta em novas questões focalizando análise etnográfica

2009/2010


Â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


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


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


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


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


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


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


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


Evolução dos requisitos

2009/2010

Compreensão inicial do problema

Requisitos iniciais

Compreensão do problema

modificada

Requisitos modificados

tempo


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


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


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


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


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


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


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


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


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


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

eng.ª do software - 3. processos da engenharia de requisitos

Education

utilizador e

negcio e

sistema proposto e

software i14

software i19

software i18

e que competncias

sistema que usam e