Engenharia de Requisitos 2009

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Engenharia de Requisitos - Resumo
Tópicos:
a) Introdução e Definições
b) As Atividades do Processo de Requisitosb) As Atividades do Processo de Requisitos
c) Técnicas da Engenharia de Requisitos
d) Gerência de Requisitos) G r nc a qu s tos
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
2
Introdução Engenharia de Requisitos
É um sub-área da Engenharia de Software que tem
como meta assistir com métodos, técnicas em m m m , n
ferramentas as atividades envolvidas em descobrir,
documentar e gerenciar os requisitos de sistemas
baseados em computadores.
O uso do têrmo “engenharia” implica que técnicas
sistemáticas e repetíveis devem ser usadas para
ti i it d i t j út igarantir que os requisitos do sistema sejam úteis,
consistentes, relevantes, etc.
ƒ As atividades do “Processo de Requisitos” custaƒ As atividades do Processo de Requisitos custa
aproximadamente 15% do custo de desenvolvimento do
sistema. (Sommerville)
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
3
Introdução Engenharia de Requisitos
Requisito (requirement):
ƒ Descrição de uma característica ou necessidade para o 
preenchimento de um objetivo do sistema. p j
ƒ Descrições em forma de sentenças que expressam os 
serviços fornecidos por um software e estabelecem a 
qualidade desejada. (Cysneiros )
ƒ São descrições de como um sistema deve se comportar, 
suas propriedades e seus atributos. (Sommerville )
----------------------------------------------------------------------
Requisitos Funcionais: descrevem o que o sistema deve fazer.
Requisistos Não-Funcionais (RNFs): descrevem sob quais 
condições os requisitos funcionais serão satisfeitos. Está 
sempre associado a um requisito funcional . (Cysneiros )
Requisistos Inversos (R-1): estabelecem a lista de condições 
que nunca podem ocorrer. (Sommerville )
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
4
Introdução Exemplos de Requisitos
Requisitos Funcionais (RFs):
ƒ O sistema deve fornecer uma entrada de dados para resultado 
de exames por paciente. (Cysneiros).
----------------------------------------------------------------------
Requisistos Não-Funcionais (RNFs):
ƒ Dependendo do resultado, alguns exames só poderão ter seus 
l d d f d l d dresultados passados por supervisores [confidencialidade]
ƒ O sistema deve emitir um recibo para o cliente com o tempo 
máximo de 8 segundos após a transação. [RF e RNF de 
desempenho] (Cysneiros)desempenho] (Cysneiros).
™ Podem ser orientados ao produto ou orientados ao processo.
---------------------------------- ------------------------------------
Requisistos Inversos (R-1): 
ƒ O sistema não poderá ficar fora de operação por um intervalo 
maior que cinco minutos [confiabilidade]
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
maior que cinco minutos [confiabilidade].
5
Introdução Problemas com Software
Exemplos de problemas: (Oliveira)
‰ Denver Airport
ƒ Prejuízo de mais de U$ 50 milhões devido a errosj
no sistema de controle de bagagens.
‰ London Ambulance Service
ƒ O sistema foi desativado um dia após a entrega
d id id d d A i i ddevido a quantidade de erros. A maioria dos erros
foi relacionada a requisitos não funcionais tais
como: segurança, confiabilidade e usabilidade.
‰ A cidade de Richmond Virginia contratou a empresa‰ A cidade de Richmond, Virginia, contratou a empresa
Arthur Young em 1984 para o desenvolvimento de um
Sistema de Informação de 1,2 milhões de dólares para
suas aplicações de água e gás. Após gastar quase 1
ó
RNFs são tratados de maneira secundária do ponto 
milhão de dólares, a cidade cancelou o contrato por
não entrega, assumindo as decorrentes lutas judiciais.
RNFs são tratados de maneira secundária do ponto 
de vista da elicitação de requisitos. (Cysneiros )
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
6Quem são os interessados (“stakeholders”)? 
Introdução
‰ CLIENTES • Da contratante
interessados contexto
‰ CLIENTES
• Usuários
• Da contratante
• Nível gerencial
• Nível operacional
• Terceiros
• Dedicados
• Casuais
• Contratante (patrocinador) 
• Parceiros
• Fornecedores
• Fregueses
p
‰ DESENVOLVEDORES
• Internos
• Da contratante
• Terceirizados
• Engenheiros de software
• Controle de qualidade
• Gerência
• Outros
• Parceiros
• Fornecedores
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
7Trabalhar com requisitos é importante? 
Introdução
Fatores de falhas em projetos
• Menosprezo ao problema
• Falta de planejamento• Falta de planejamento
• Falta de envolvimento dos usuários 
• Objetivos não esclarecidos
• Requisitos incompletosq p
• Mudanças em requisitos
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
8
As Atividades do Processo de RequisitosIntrodução
Algumas variações:
Processo de Requisitos: “não existe consenso para a definição 
das atividades do processo de requisitos”.
Algumas variações:
1) Pohl [6] usa elicitação, negociação, especificação e validação. 
2) Lamsweerde [2] usa elicitação, elaboração, organização, 
análise negociação documentação e evoluçãoanálise, negociação, documentação e evolução.
3) Leite [3] adota uma linha mais simples e concisa. Apenas: 
Elicitação, Modelagem e Análise de requisitos e a atividade de 
gerência de requisitos é considerada em paralelo ao processo.g n qu n m p p .
‰ Elicitação significa entender o problema organizacional e 
descobrir os requisitos do sistema.
‰ Modelagem significa representar os requisitos juntos em ‰ Modelagem significa representar os requisitos juntos em 
modelos específicos.
‰ Análise significa verificação e validação dos diagramas e da 
especificação contra as necessidades dos “stakeholders”.
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
9
O Processo As Atividades do Processo de Requisitos
Fontes de Informação:
P 
Priorização da fonte:
R t ti id d• Pessoas e processos
• A organização
• Documentos, livros
• Sistemas existentes 
• Representatividade
• Investimento
• Relevância
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
10
Técnicas
Elicitação dos Requisitos
Técnicas básicas
• Leitura de documentos
• Observação
• Introspecção 
• Entrevistas (abertas e estruturadas)
• Reuniões
Técnicas avançadas
• Pesquisas e Questionários
• Análise de ProtocolosAnálise de Protocolos
• Técnicas de grupo (JAD, “brainstorm”, “workshops”)
• Enfoque Antropológico
• Prototipação
Recuper çã d Desenh (en enh ri revers )• Recuperação do Desenho (engenharia reversa)
Qual técnica utilizar? – Ver contexto e situação.
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
11
Modelagem Modelagem dos Requisitos
Os modelos documentam os requisitos na forma gráfica.
Modelagem Funcional
‰ Diagramas de Fluxos de Dados‰ Diagramas de Fluxos de Dados
‰ SADT 
‰ Orientação a Objetos
‰ Especificações (cenários e casos de uso)
Modelagem de Dados
‰ Modelo Entidades RelacionamentosModelo Ent dades elac onamentos
Modelagem Dinâmica
‰ Modelo de comportamento
D d ã d d‰ Diagramas de transição de estados
Modelagem Orientada a Metas
á é
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
Glossários e Léxicos são importantes para a comunicação.
12
Análise Análise dos Requisitos
Análise = Verificação + Validação
1) Verificação
Questão: Æ Estamos construindo de maneira certa ?
Os resultados dos procedimentos aplicados estão corretos ?Os resultados dos procedimentos aplicados estão corretos ?
Î Inspecionar para a qualidade.
Æ revisões, inspeções, “walkthroughs”
• 2) Validação
Questão: Æ Estamos construindo o produto certo ?
O produto
será o que os clientes esperam ?O produto será o que os clientes esperam ?
Î Comparar com as expectativas dos clientes.
Æ testes, demonstrações, protótipos, “storyboards”
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
13Análise dos Requisitos
Análise
Exemplo parcial de checklist para verificação de requisitos. (Pressman)
Propriedade Questão principalPropriedade Questão principal
legibilidade Os requisitos estão simples e claramente estabelecidos?
rastreável A origem do requisito foi identificada?rastreável A origem do requisito foi identificada?
entrelaçamento Que outros requisitos se relacionam a este requisito?
contextualização O requisito viola alguma restrição de domínio?contextualização O requisito viola alguma restrição de domínio?
testabilidade O requisito pode ser testado?
utilidade O requisito está relacionado com os objetivos do sistema?utilidade O requisito está relacionado com os objetivos do sistema?
completeza Os requisitos foram incorporados ao sistema?
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
14
Gerência Gerência de Requisitos
b Clientes e usuários
Ciclo de DesenvolvimentoEvolução
Objetivos
Modelos
Clientes e usuários
Marketing
Nova característica
Novo requisito
Decisões
aprovadas
Modelos
Código
g
Engenheiros
Novo requisito
Acerto de erros
Testes
g
Testadores
Sistema de 
Pedidos de
Mudanças 
Baseline de
Requisitos 
Processo 
de Gestão de
Mudanças Versão i
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira
q
Versão j
Versão i
15
BIBLIOGRAFIA
(1) Cysneiros, Luiz; Leite, Julio; Neto, Jaime Sabat; A framework for integrating
non-functional requirements into conceptual models; Requirements Engineering
Journal, Vol. 6, Issue 2; pp. 97-115; 2001.
(2) Lamsweerde, A. van; Engineering Requirements for System Reliability and 
S it i S ft S t R li bilit d S it M B J G b Security in Software System Reliability and Security, M. Broy, J. Grunbauer 
and C.A.R. Hoare (eds.), NATO Security through Science Series - D: 
Information and Communication Security, Vol. 9. IOS Press, 196-238 (2007).
(3) Leite, Julio C. S. P.; Oliveira, A de Padua A.; Client Oriented Requirements ( ) , , q
Baseline, Proceedings of the Second International Symposium on Requirements 
Engineering, RE95, IEEE Computer Society Press, (1995), pp. 108-115.
(4) Oliveira, Antonio de Padua A.; "SERBAC : Uma Estratégia para Definição de 
Requisitos" Anais do VIII Simpósio Brasileiro de Engenharia de Software; Requisitos , Anais do VIII Simpósio Brasileiro de Engenharia de Software; 
Sociedade Brasileira de Computação; Out. (1994).
(5) Pressman, R. S.; Engenharia de Software, McGraw-Hill, Hardcover, 6th edition, 
(2006), ISBN 0-07-28318-2.
(6) Pohl, K. Process-Centered Requirements Engineering;Taunton, England, 
Research Studies Press Ltd (1996).
(7) Sommerville, I.; Engenharia de Software, 8a edição; Pearson Addison-Wesley
(2007) ISBN 978-85-88639-28-7(2007) ISBN 978-85-88639-28-7.
UERJ – CTC/IME – Engenharia de Software 09-1 © Prof. A Padua Oliveira