1 adaptado a partir de gerald kotonya and ian sommerville engenharia de requisitos análise e...

1

Adaptado a partir de Gerald Kotonya and Ian Sommerville

Engenharia de RequisitosEngenharia de Requisitos

Análise e Concepção de Análise e Concepção de Sistemas de InformaçãoSistemas de Informação

Carla FerreiraCarla [email protected]

mailto:[email protected]

2ACSI/Adaptado por Carla Ferreira

Engenharia de RequisitosEngenharia de Requisitos Introdução

– Requisitos– Requisitos Funcionais– Requisitos Não-Funcionais– Problemas– Métricas– Documento de Requisitos– Exemplo

Processo de Engª de Requisitos– Actividades Gerais– Modelo Espiral– Maturidade do Processo– Melhoria do Processo de Eng.ª de Requisitos

Levantamento e Análise de Requisitos– Questionários, Análise de Documentos, ...– Selecção de Técnicas de Levantamento– Exemplo

Análise de Requisitos– Lista de Verificações– Matrizes de Interacção

Negociação de Requisitos


FAQS FAQS sobre Requisitos (1/2)sobre Requisitos (1/2)

O que é um requisito?– Uma condição sobre um serviço ou restrição de um sistema

O que é engª de requisitos?– O processo que envolve o desenvolvimento de requisitos de

sistema

Quanto custa a engª de requisitos– Cerca de 15% do custo de desenvolvimento do sistema

O que é um processo de engª de requisitos?– Um conjunto estruturado de actividades que envolve o

desenvolvimento de requisitos de sistema


FAQS FAQS sobre Requisitos (2/2)sobre Requisitos (2/2)

O que acontece qdo os requisitos estão errados? – Os sistemas são entregues atrasados, sem qualidade e sem

responder às necessidades dos clientes.

Existe algum processo de engª de requisitos ideal?– Não! O processo tem de ser configurada às necessidades de

cada organização.

O que é um documento de requisitos?– É a definição formal dos requisitos de um sistema

Quem são os stakeholders de um sistema?– Qualquer pessoa afectada de alguma forma pelo sistema.


Req. Funcionais vs. Req. Não-FuncionaisReq. Funcionais vs. Req. Não-Funcionais

Um requisito funcional está relacionado com um processo/funcionalidade que o sistema deve executar ou com informação que o sistema deve manter.

Um requisito não-funcional está relacionado com as propriedades comportamentais que o sistema deve ter:– Definem qualidades globais ou atributos do

sistema


Requisitos Funcionais*Requisitos Funcionais*

* Systems analysis and design with UML


Requisitos Não-Funcionais*Requisitos Não-Funcionais*



Classificação de RNFs (1/2)Classificação de RNFs (1/2)

Requisitos de desempenho Requisitos de interface Requisitos operacionais Requisitos de recursos Requisitos de verificação Requisitos de aceitação

Segundo o IEEE-Std 830 – 1993

Requisitos de documentação Requisitos de segurança Requisitos de portabilidade Requisitos de qualidade Requisitos de fiabilidade Requisitos de manutenção Requisitos de integridade (safety)


Classificação de RNFs (2/2)Classificação de RNFs (2/2)Non-functional

requirements

Processrequirements

Product requirements Externalrequirements

Deliveryrequirements

implementationrequirements

standards

requirements

Usability requirements

Reliability requirements

Safety requirements

Efficiency requirements

Performance requirements

Capacity requirements

Legalconstraints

Economicconstraints

Interoperabilityrequirements

Segundo G. Kotonya e I. Sommerville


Problemas associados aos requisitosProblemas associados aos requisitos

Os requisitos não reflectem as necessidades reais do cliente

Os requisitos são inconsistentes e/ou incompletos

É caro fazer alterações aos requisitos depois destes terem sido acordados

Dificuldade de comunicação e compreensão entre clientes, analistas dos requisitos, e engs que desenvolvem e mantêm o software


ExercícioExercício

Explicar os problemas que poderiam surgir nos seguintes requisitos da especificação de um sistema de gestão de uma biblioteca

– O sistema deve providenciar uma interface gráfica fácil de usar (easy-to-use) baseada em MS Windows XP

– Utilizadores acreditados devem ter acesso privilegiado aos mecanismos do catálogo do sistema

– O sistema de software deve ser implementado usando módulos separados para catalogação, acesso de utilizadores e arquivo


Métricas para RNFsMétricas para RNFs

Property MetricPerformance 1. Processed transactions per second

2. Response time to user inputReliability 1. Rate of occurrence of failure

2. Mean time to failureAvailability Probability of failure on demandSize KbytesUsability 1. Time taken to learn 80% of the facilities

2. Number of errors made by users in a given timeperiod

Robustness Time to restart after system failurePortability Number of target systems


Documento de RequisitosDocumento de Requisitos

É um documento formal usado para registar e comunicar os requisitos dos/aos stakeholders

Descreve:– Os serviços e funções que o sistema deve providenciar– As restrições nas quais o sistema deve funcionar– Todas as propriedades do sistema, i.e., propriedades emergentes– Definições de outros sistemas, com o qual o sistema alvo deverá

comunicar e ou integrar-se– Informação sobre o domínio de aplicação do sistema– Restrições sobre o(s) processo(s) usado para desenvolver o sistema– Descrição das plataformas computacionais (hardware, redes, ...) sobre

as quais o sistema deverá correr


Utilizadores do Documento de RequisitosUtilizadores do Documento de Requisitos

Clientes do sistema– Especificam os requisitos e/ou leem-nos de para validar da

sua adequação às necessidades Gestores de projecto

– Usam o doc de requisitos para planear os custos e prazos, e para planear o processo de desenvolvimento adequado

Engs de sistema– Usam os requisitos para poderem entender o sistema a

desenvolver Engs de teste do sistema

– Usam os requisitos para desenvolver teste de validação Engs de manutenção do sistema

– Usam os requisitos para o melhor compreender


Estrutura do Documento de RequisitosEstrutura do Documento de Requisitos

O standard IEEE/ANSI 830-1993 propõe uma estrutura para docs de requisitos de software

1. Introdução1.1 Propósito do documento de requisitos1.2 Contexto do produto1.3 Definições, acrónimos e abreviaturas1.4 Referências1.5 Visão geral do documento


Estrutura do Documento de RequisitosEstrutura do Documento de Requisitos

2. Descrição geral2.1 Perspectiva do produto2.2 Funções do produto2.3 Características dos

utilizadores2.4 Restrições gerais2.5 Assunções e

dependências3. Requisitos específicos

Envolve requisitos funcionais, não-funcionais e de interface

4. Apêndices

IEEE/ANSI 830-1993

Exemplo de um documento de requisitos


ExemploExemplo

GamesInc– Rede de 50 lojas de venda de jogos para as

várias consolas. – Actualmente a GamesInc tem um web site com

informação básica sobre a empresa e cada uma das suas lojas (localização, horário de funcionamento, telefone).

– A empresa pretende investir num novo site que permita aos seus clientes consultar informação, consultar disponibilidade de stock, reservar ou encomendar jogos através do web site.


Processo de ERProcesso de ER

Agreedrequirements

Systemspecification

Systemmodels

Requirementsengineering process

Stakeholderneeds

Organisationalstandards

Domaininformation

Regulations

Existingsystems

information

inputs inputs ee outputs outputs


Requirementselicitation

Requirementsanalysis andnegotiation

Requirementsdocumentation

Requirementsvalidation

Requirementsdocument

User needsdomain

information,existing system

information,regulations,

standards, etc.

AgreedrequirementsSystem

specification

Actividades Gerais do Processo de ERActividades Gerais do Processo de ER


Requirements elicitation Requirements analysis andnegotiation

Requirements documentationRequirements validation

Informal statement ofrequirements

Agreedrequirements

Draft requirementsdocument

Requirementsdocument and

validationreport

Decision point:Accept documentor re-enter spiral

START

Modelo Espiral para ERModelo Espiral para ER


Modelo de Maturidade do Processo de ERModelo de Maturidade do Processo de ER

Level 1 - InitialAd-hoc requirements

engineering; requirementsproblems are common

Level 2 - RepeatableStandardised requirements

engineering; fewerrequirements problems

Level 3 - DefinedDefined process basedon best practice; processimprovement in place


Initial level– Não existe processo de ER– Apresenta os seguintes problemas: volatilidade de

requisitos, insatisfação dos stakeholders, custos elevados de alterações

– Muito dependente das capacidades e experiência das pessoas

Repeatable level– São definidas normas para os documentos de requisitos– São definidas normas de políticas e procedimentos para a

gestão de requisitos Defined level

– O processo de ER está definido com base em boas práticas – Existe uma preocupação na melhoria activa do processo

Níveis de Maturidade do PNíveis de Maturidade do Processrocesso de ERo de ER


Definir uma estrutura comum/normalizada do documento de requisitos

Identificar univocamente cada requisito Definir políticas para gestão de requisitos Usar checklists para análise de requisitos Usar cenários para levantar requisitos Especificar requisitos quantitativamente Usar prototipagem para animar requisitos Reusar requisitos

Melhoria do Processo de ERMelhoria do Processo de ER

Exemplos de boas práticasExemplos de boas práticas


Levantamento de RequisitosLevantamento de Requisitos

Dilbert


Requirements elicitation Requirements

analysis

Requirements negotiation

Draft statement of requirements

Requirements document

Requirements problems

Processo de ERProcesso de ER

Levantamento, análise e negociação de requisitosLevantamento, análise e negociação de requisitos


Técnicas de levantamento de requisitosTécnicas de levantamento de requisitos

Questionários Análise de documentos Entrevistas JAD Casos de Utilização (aula sobre Modelos Funcionais)

Etnografia Prótotipagem


Planeamento de QuestionáriosPlaneamento de Questionários

Selecionar participantes– Elementos representativos dos stakeholders

Definir questionário– Seleção das questões

Administrar o questionário– Definir estratégias para obter um bom número de respostas

Follow-up do questionário– Enviar os resultados do questionário aos participantes


Análise de DocumentosAnálise de Documentos

Contém informação do sistema “as-is” Documentos típicos:

– Formulários– Relatórios– Manuais de procedimento

Procurar elementos adicionados aos formulários pelos utilizadores

Procurar elementos não utilizados


Planeamento da entrevistaPlaneamento da entrevista

Ler material de suporte Estabelecer os objectivos da entrevista Decidir quem entrevistar Preparar o entrevistado Decidir os tipos de questões e a sua

estrutura


EntrevistasEntrevistasTypes of Questions Examples

Closed-Ended Questions * How many telephone orders are received per day?

* How do customers place orders?* What additional information would you like the new system to provide?

Open-Ended Questions * What do you think about the current system?* What are some of the problems you face on a daily basis?* How do you decide what types of marketing campaign to run?

Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit more detail?



Estruturar EntrevistasEstruturar Entrevistas

Estrutura em pirâmide– Começar com uma pergunta especifica, fechar com uma pergunta

genérica– Usar com entrevistados relutantes

Estrutura em fúnil– Começar com uma pergunta genérica, fechar com uma pergunta

especifica– Forma amigável de começara a entrevista– Usar quando os entrevistados tem uma relação efectiva com o

assunto

Estrutura em diamante– Combina as aproximações anteriores, por isso demora mais tempo– Mantém o entrevistado interessado usando perguntas variadas


Estruturar EntrevistasEstruturar Entrevistas

Quantas devoluções de encomendas ocorrem por semana?

Como é que se pode melhorar o processamento de encomendas?



Relatório da EntrevistaRelatório da Entrevista

INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________Interviewer _______________Date _______________Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:



Joint Application Design (JAD)Joint Application Design (JAD)

Pode substituir uma série de entrevistas com a comunidade de utilizadores

Permite ao analista efectuar o levantamento de requisitos com os utilizadores


Quando usar JAD?Quando usar JAD?

Se os utilizadores querem algo novo Se a cultura organizacional suporta a

resolução de problemas em grupo A utilização do JAD provoca um aumento de

ideias geradas O workflow organizacional permite que

empregados essenciais se ausentem para assistir às reuniões JAD


Quem está envolvido nas sessões JAD?Quem está envolvido nas sessões JAD?

Analista– Pelo menos 1, mas deve ter um papel passivo

Utilizadores– De 8 a 12 utilizadores– Moderador

O moderador para a sessão deve ser escolhido com base no seu poder de comunicação e não deve ser o analista

Supervisor do moderador da sessão não deve pertencer ao grupo de utilizadores JAD

– 1 ou 2 técnicos especializados que assumem um papel passivo

– Um dos participantes deve registar o conteúdo da sessão Executivo

– Escolher um executivo como patrocinador que irá introduzir e concluir a sessão JAD


Onde realizar as sessões JAD?Onde realizar as sessões JAD?

Organizar entre 2 a 3 sessões de um dia fora do local do trabalho para minimizar interferências

Reservar uma sala para 20 pessoas Planear a comida e as bebidas Só realizar as reuniões se todos os

participantes podem estar presentes


Sala de reuniões Sala de reuniões


Vantagens do JADVantagens do JAD

Menos 15% do tempo em comparação com as entrevistas individuais

Desenvolvimento rápido de sistemas Os utilizadores sentem-se integrados no

desenvolvimento do sistema Desenvolvimento criativo de designs


Desvantagens do JADDesvantagens do JAD

Exige que os vários participantes tenham tempo disponível para todas as sessões

Se a preparação for insuficiente, a sessão pode não ter sucesso

Se o relatório de uma sessão estiver incompleto pode por em risco a próxima sessão

A cultura organizacional pode não ser compatível com a aproximação JAD


EtnografiaEtnografia

É difícil descrever como que se realizam tarefas– Solução: Observar como as

tarefas são realizadas Etnografia – técnica

desenvolvida na área das ciências socias– Útil para determinar o

método de trabalho Divergência entre os

métodos de trabalho usados e a sua definição formal


Etnografia e EREtnografia e ER

Procurar métodos pouco usuais de trabalho Estabelecer uma relação de confiança com os

utilizadores Manter notas detalhadas sobre os métodos de

trabalho. Combinar observação com entrevistas abertas Organisar sessões regulares de esclarecimento Usar outras técnicas de levantamento de requisitos


EtnografiaEtnografia

Perspectiva do contexto do trabalho – Descreve o contexto e a localização fisíca do trabalho e

como as pessoas usam os objectos para realizar tarefas

Perspectiva social e organizacional – Cada individuo tem uma percepção única sobre o trabalho

Perspectiva do fluxo de trabalho– Descrever as actividades que formam um trabalho/tarefa e

o fluxo de informação entre essas actividades.


PrototipagemPrototipagem

Protótipo– Versão inicial de um sistema para experimentação

Permite aos utilizadores identificar os pontos fortes e fracos do sistema

Algo concreto que pode ser criticado Protótipos devem estar disponíveis durante o

levantamento de requisitos


Vantagens da PrototipagemVantagens da Prototipagem

Utilizadores podem experimentar “o sistema” Estabelece a fiabilidade e utilidade do

sistema Essencial para definir o “look and feel” da

interface com o utilizador Pode ser usado nos testes do sistema e no

desenvolvimento de documentação Obriga a estudar com detalhe os requisitos

– Encontrar inconsistências e omissões


Tipos de ProtótiposTipos de Protótipos

Protótipos “Throw-away”– Objectivo: Ajudar o levantamento e

desenvolvimento dos requisitos – Suportar os requisitos mais difíceis de perceber

Protótipos Evolutivos– Objectivo: desenvolvimento rápido de uma versão

inicial do sistema– Suportar os requisitos bem definidos e

conhecidos


Desvantagens da PrototipagemDesvantagens da Prototipagem

Custos de aprendizagem Custos de desenvolvimento Estende a planificação do desenvolvimento São incompletos

– Pode não ser possível protótipar requisitos críticos


Abordagens à prototipagemAbordagens à prototipagem

Prototipagem em papel– Representação em papel do interface do sistema

Prototipagem ‘Wizard of Oz’ – Uma pessoa (wizard) simula as respostas do sistema de

acordo com as entradas do utilizador Prototipagem executável

– Utilização de uma ambiente de desenvolvimemto rápido para desenvolver um protótipo executável


Prototipagem em papelPrototipagem em papel

Características – Representar em papel a funcionalidade e aparência da

interface– Tem custos baixos e é fácil de preparar e alterar

Objectivos– Analisar diferentes representações para a interface com o

utilizador– Fazer o levantamento das reacções dos utilizadores– Fazer o levantamento das modificações (e sugestões)

requeridas pelos utilizadores


Prototipagem em PapelPrototipagem em Papel


Prototipagem ‘Wizard of Oz’Prototipagem ‘Wizard of Oz’

A method of testing a system that does not exist– the voice editor, IBM 1984

The WizardO que o utilizador vê Wizard


Prototipagem ‘Wizard of Oz’Prototipagem ‘Wizard of Oz’

O ‘wizard’ humano simula as respostas do sistema– Interpreta os inputs de um utilizador segundo um algoritmo– Controla computador para simular o output desejado– Usa a interface real ou um “mock-up”

É usado para:– Simular a adição de funcionalidades complexas – Testar ideias futuristicas


Seleção de Técnicas de LevantamentoSeleção de Técnicas de Levantamento**

Interviews JAD Questionnaires Document Observation Analysis

Type of As-Is As-Is As-Is As-Is As-IsInformation Improve. Improve. Improve. To-Be To-Be

Depth of High High Medium Low LowInformation

Breadth of Low Medium High High LowInformation

Integration Low High Low Low Lowof Information

User Medium High Low Low LowInvolvement

Cost Medium Low- Low Low Low- Medium Medium



Exemplo 1Exemplo 1

Considere que é o analista responsável por desenvolver um novo sistema que suporte as decisões estratégicas dos gestores séniors de uma companhia de seguros. Os gestores reúnem-se mensalmente para discutir a evolução do mercado e reajustar a estratégia da empresa. Até agora estas reuniões são suportadas por documentação (extensa) em papel. O novo sistema vem eliminar o tempo perdido a analisar detalhadamente esses documentos, permintindo que os gestores se concentrem apenas nas questões estratégicas da empresa.


Exemplo 2Exemplo 2

É responsável pela especificação de requisitos de um sistema de gestão de cadastro da infra-estrutura de rede física da empresa LxGásNatural, que é uma operadora/distribuidora de gás natural na região da grande Lisboa. Ao sistema que se pretende conceber e desenvolver deu-se o nome de SIG-RedeGásNatural, e o seu objectivo geral é permitir que a gestão dos elementos físicos da rede (e.g., condutas, ramais, juntas, postos de redução) seja suportada por um sistema integrado de informação geográfica.

Existe um sistema de informação legado, em funcionamento, fortemente baseado em papel e em desenhos técnicos (i.e., ficheiros CAD) guardados num servidor de ficheiros partilhados, o qual apenas é acedido e gerido por técnicos do Departamento Técnico da empresa.

A cultura da empresa LxGásNatural é formal, baseada em relações hierárquicas de poder e de responsabilidades bem definidas.


Exemplo 3Exemplo 3

A empresa de distribuição de produtos para animais “Sr. Cão” pretende adquirir um sistema de apoio à decisão de compras de produtos. O “Sr. Cão” é uma empresa familiar gerida por 2 irmãos e os seus filhos, mas que neste momento se encontra em grande expansão quer em número de vendas, quer na variedade de produtos. O sistema que está a ser usado actualmente apenas regista o stock existente em armazém para cada produto, o que dificulta a gestão eficiente do stock. O objectivo do sistema a desenvolver é permitir reduzir os custos das compras e minimizar o nível de stock a manter no armazém. Tendo em consideração estes objectivos, o novo sistema deverá definir semanalmente uma lista de produtos a adquirir, associando a para cada produto a quantidade a comprar e o fornecedor a usar.


Necessitychecking

Consistency andcompleteness

checkingFeasibilitychecking

Unnecessaryrequirements

Conflicting andincomplete

requirementsInfeasible

requirements

Requirementsdiscussion

Requirementsprioritisation

Requirementsagreement

Requirements analysis

Requirements negotiation

Análise e Negociação de RequisitosAnálise e Negociação de Requisitos


Análise de RequisitosAnálise de Requisitos

Objectivos:– Encontrar problemas, falhas e inconsistências

A análise é intercalada com o levantamento de requisitos

A análise é suportada por uma lista de verificação de problemas


Lista de Verificação (1/2)Lista de Verificação (1/2)

Desenho prematuro do sistema– Verificar se o requisito inclui informação prematura sobre o

design ou a implementação Combinação de requisitos

– Verificar se a descrição do requisito descreve um único requisito ou se pode ser dividida em diferentes requisitos

Requisitos desnecessários– Verificar se o requisito é apenas uma adição “cosmética” ao

sistema. Utilização de HW não-standard

– Verificar se o requisito obriga a uso de hardware que não é standard

– Para tomar esta decisão é necessário saber os requisitos da plataforma a supotar


Lista de Verificação (2/2)Lista de Verificação (2/2)

Conformidade com os objectivos de negócio– Verificar se o requisito é consistente com os objectivos do

negócio definidos na introdução do documento de requisitos Requisitos ambíguos

– Verificar se o requisito pode ser lido de forma diferentes por diferentes pessoas

– Quais as interpretações possíveis? Requisitos realistas

– Verificar se o requisito é realista tendo em conta a tecnologia a ser usada para implementar o sistema

Requisitos “testáveis”– Verificar se os engenheiros de teste podem derivar um teste

a partir da descrição do requisito que mostre que o sistema satisfaz esse requisito


Matrizes de interaçãoMatrizes de interação

Objectivos da análise de requisitos:– Determinar as interações entre requisitos – Evidenciar conflitos e sobreposições

Matriz de interação de requisitos– Requisitos em conflito, colocar 1– Requisitos sobrepostos, colocar 1000– Requisitos independentes, colocar 0


Matrizes de InteraçãoMatrizes de Interação

Requirement R1 R2 R3 R4 R5 R6R1 0 0 1000 0 1 1R2 0 0 0 0 0 0R3 1000 0 0 1000 0 1000R4 0 0 1000 0 1 1R5 1 0 0 1 0 0R6 1 0 1000 1 0 0


Negociação de requisitosNegociação de requisitos

Conflitos não são falhas– Refletem diferentes necessidades e prioridades

Negociação de requisitos tenta encontrar uma solução de concordância

A negociação de requisitos pode ser um processo demorado– A planificação de processo de ER deve ter em

conta o tempo dispendido na negociação


Reuniões de negociaçãoReuniões de negociação

Fase de informação– Explicar os problemas associados com os requisitos

a negociar Fase de discussão

– stakeholders devem ter oportunidade de comentar os requisitos que lhes dizem respeito

– Usar esta fase para atribuir prioridades aos requisitos Fase de resolução

– Eliminar, alterar ou refinar o requisito

1 adaptado a partir de gerald kotonya and ian sommerville engenharia de requisitos análise e...

Documents