Professor Mário DantasSet/2010

ENGENHARIA DE SOFTWARE

Aula 03 - Agenda Engenharia de Requisitos

Objetivos Conhecer os conceitos e técnicas

relacionadas a engenharia de requisitos, bem como sua aplicação;

Saber as diferenças entre os requisitos de software funcionais e não funcionais;

Entender como os requisitos podem ser organizados em um documento de requisitos.

Seu pior pesadelo Um cliente entra no seu escritório, senta-se,

olha você direto nos olhos e diz:

“Eu sei que você pensa que entende o que eu disse, mas o que você não entende é que, o que eu disse, não é o que eu queria dizer.”

Requisitos

Definições Pfleeger (2004), um requisito é uma

característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos.

Sommerville (2007), as descrições das funções e restrições são os requisitos do sistema.

SWEBOK (2004), um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real.

Definições Uma condição ou capacidade necessária

para um usuário resolver um problema ou alcançar um objetivo.

Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.

Importância dos Requisitos Resultados de um estudo feito pelo

Standish Group em 350 companhias e 8000 projetos de software (Pfleeger, 2004): 31% dos projetos cancelados antes de

estarem completos Em pequenas companhias, somente 16% dos

projetos foram entregues no prazo e no orçamento inicialmente estabelecido

Em grandes companhias, apenas 9% estão de acordo com esses critérios

Importância dos Requisitos O Standish Group classificou os projetos em

3 categorias: Sucesso (16,2%) : Cobre todas as

funcionalidades, em tempo e dentro do custo previsto (cronograma e orçamento)

Problemático (52,7%) : Não cobre todas as funcionalidades exigidas, custo aumentado e/ou com entregas em atraso.

Fracasso (31,1%): Cancelado durante o desenvolvimento

Desafios Compreensão do domínio do problema. Comunicação efetiva com reais usuários

e clientes do sistema. Evolução contínua dos requisitos do

sistema.

Domínio O termo, no contexto da engenharia de

software, é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais, que exibem características similares.

É definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Especificação de Requisitos Estabelece uma base de concordância

entre o cliente e o fornecedor sobre o que o software fará.

Fornece uma referência para a validação do produto final (uma especificação de requisitos de alta qualidade é pré-requisito para um software de alta qualidade).

Reduz o custo do software.

Por que precisamos de requisitos?

Para entender o que o cliente quer

Para documentar o que o cliente quer

Para assegurar a qualidade e a satisfação do cliente

Para entender o problema do negócio

Para documentar o escopo do projeto e definir suas restriçõesPara definir critérios de aceitação e gerenciar as expectativas do cliente

Engenharia de Requisitos

Definição Sommerville (2003), Engenharia de

Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.

Engenharia de RequisitosO processo de descobrir, analisar,

documentar e verificar as descrições dos serviços

fornecidos pelo sistema e as suas restrições operacionais.

Engenharia de Requisitos“Entender os requisitos de um

problema está entre as tarefas mais difíceis enfrentadas por um engenheiro

de software.” (Pressman, R.)

Engenharia de Requisitos Descreve as atividades relacionadas à

investigação e definição de escopo de um sistema de software.

Processo sistemático de produção de requisitos por meio de atividades cooperativas de análise em que os resultados são documentados em uma variedade de formatos e a precisão das observações é constantemente verificada.

Questionamentos Típicos Como seguir um processo pré-

estabelecido se tantos fatores são desconhecidos no início do desenvolvimento do software?

Os fatores desconhecidos serão melhor elucidados e os riscos serão minimizados com um processo sistemático, iterativo e incremental.

Questionamentos Típicos Quantas iterações são necessárias para

verificar a correção e a precisão das observações?

A quantidade de iterações ideal será aquela suficiente para que cliente e fornecedor sintam-se seguros e concordem com o que está definido, mesmo com o que surgir de novo e for aceito para o escopo do projeto.

Questionamentos Típicos Quais representações e notações devem

ser usadas na captura e documentação dos requisitos?

As representações e notações devem estar previstas no processo de software e no método adotado por esse processo. Tipicamente, são usados casos de uso e suas especificações .

Questionamentos Típicos Qual o nível de precisão e formalidade

dos requisitos? Dependerá de quão crítico é o sistema e

das características do cliente.

Questionamentos Típicos Como sabemos que chegamos ao final

do processo? Similarmente à quantidade de iterações,

até que haja uma base sólida de concordância entre o desenvolvedor e o cliente

Visão Geral

Produção de Requisitos

Levantamento

Registro

Obtenção de Comprometimento

Verificação

Gerência de RequisitosControle de Mudança

Gerência de Configuração

Rastreabilidade

Gerência de Qualidade de

Requisitos

Engenharia de Requisitos

Síntese dos Objetivos Estabelecer uma visão comum entre o cliente e

a equipe de projeto sobre os requisitos que serão atendidos;

Registrar e acompanhar requisitos ao longo de todo o desenvolvimento;

Documentar e controlar os requisitos para estabelecer uma base para uso gerencial e da equipe de desenvolvimento;

Manter planos, artefatos e atividades de software coerentes com os requisitos alocados.

Uma Última Questão O que acontece se:

O usuário mudar de idéia em relação a uma funcionalidade?

O ambiente mudar? O usuário perceber novas possibilidades na

automação? O engenheiro de requisitos (ou analista)

não ter entendido corretamente a necessidade do usuário?

Gerência de Mudança É preciso gerenciar as mudanças! Mudanças em requisitos ao longo do

processo fazem parte do desenvolvimento de software.

Alterações em requisitos podem implicar mudanças em artefatos de projeto, de código, casos de testes, etc.

Identificação dos Requisitos Trata-se da identificação dos requisitos em

si para formação da idéia inicial do sistema e compreensão do domínio do problema.

“Trabalhe com os usuários e não contra eles” (AMBLER).

“Temos que aceitar a instabilidade dos requisitos como um fato da vida, e não condená-la como o resultado de um raciocínio mal conduzido” (COAD).

Ações com Foco no Usuário Identificar Objetivos de Negócio (Por que

desenvolver algo?) Identificar Stakeholders (Quem está

envolvido?) Obter diferentes Pontos de Vista (Com que

os stakeholders estão preocupados? Existem conflitos?)

Resolver Conflitos Identificar Cenários (Quais resultados as

pessoas desejam? Sob que circunstâncias?)

Problemas Comuns Escopo: O limite do sistema é mal definido, ou

detalhes técnicos desnecessários confundem os objetivos globais

Entendimento: Os clientes e usuários não estão completamente certos do que é necessário, não tem pleno entendimento do domínio do problema, têm dificuldade de comunicar as necessidades, têm pouca compreensão das capacidades

Volatilidade: Os requisitos mudam com o tempo

Desafios a Suplantar Falta de conhecimento do usuário das

suas reais necessidades e do que um produto de software pode oferecer

Falta de conhecimento do desenvolvedor sobre o domínio do problema

Habilidades do Desenvolvedor Dominar o processo de produção de

requisitos e suas técnicas Ouvir o que os usuários têm a dizer sem

induzi-los a aceitar visões e interpretações já vivenciadas pela equipe

Comunicar adequadamente aos usuários e clientes a evolução do trabalho e suas limitações

A produção de requisitos é um processo social

Classificação de Requisitos Classificação Comum:

Requisitos Funcionais Requisitos Não Funcionais Requisitos do Domínio

Outras Classificações para Requisitos

Requisito do usuário: declarações sobre as funções que o sistema deve oferecer

Requisito do sistema: detalhamento das funções e das restrições (contrato entre cliente e desenvolvedor)

Requisito do projeto: define como o projeto deve ser conduzido e que artefatos devem ser produzidos (escopo do projeto).

Requisitos Funcionais Requisitos diretamente ligados ao

comportamento do software Descrevem as funções que o software

deve executar Descrevem as interações entre o

sistema e seu ambiente

“O software deve permitir que o atendente consulte o relatório com os resultados dos testes clínicos de um paciente”.

Exemplos [RFO1] O software deve permitir que o

atendente efetue cadastro de clientes. [RFO2] O software deve permitir que o

caixa efetue o registro de itens vendidos. [RFO3] O software deve permitir que o

administrador gere o um relatório de vendas por mês.

Exercícios Escreva três requisitos funcionais para

sistemas a serem desenvolvidos para os seguintes domínios:

Vídeo Locadora Apoio Inteligente à Análise de Risco para

Bolsa de Valores Sistema de Caixa de Auto-atendimento

de um Sistema Bancário.

Uma Solução Possível Vídeo Locadora:

O software deve permitir que o administrador efetue o cadastro de clientes

O software deve permitir que o administrador efetue o cadastro de DVDs

O software deve permitir que o atendente efetue o registro de DVDs alocados

Auto-atendimento Bancário: O software deve permitir que o cliente consulte seu

extrato O software deve permitir que o cliente efetue saque; O software deve permitir que o cliente efetue o

pagamento da fatura do cartão de crédito.

Soluções Possíveis Apoio Inteligente à Análise de Risco para

Bolsa de Valores

O domínio da aplicação pode dificultar – e muito – o trabalho de produção dos requisitos!

Requisitos Não Funcionais São requisitos que expressam condições

que o software deve atender ou qualidades específicas que o software deve ter.

Em vez de informar o que o sistema fará, os requisitos não funcionais impõem restrições ao sistema.

Podem ser mais críticos que requisitos funcionais, chegando a tornar um sistema impossível ou inútil.

Exemplos “As consultas ao sistema devem ser

respondidas rapidamente” “As consultas ao sistema devem ser

respondidas em menos de três segundos”

Requisitos Não Funcionais devem ser mensuráveis e estar associados a uma

forma de medida ou referência

Medidas para Requisitos Não Funcionais

Propriedade MedidaVelocidade Transações processadas por

segundoTempo de resposta do usuário/evento

Tamanho KbytesNum. De chips de RAM

Facilidade Tempo de treinamentoNum. Quadros de ajuda

Confiabilidade Tempo médio de falhasProbabilidade de indisponibilidadeTaxa de ocorrência de falhas

Robustez Tempo de reinício após a falhaPercentual de eventos causando falha

Portabilidade Num. de sistemas destino

Classificação dos RNF

Classificação dos RNF RNF do Produto: Produto deve comportar-

se de forma particular (velocidade de execução, confiabilidade, etc.)

RNF Organizacionais: Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)

RNF Externos: Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)

RNF do Produto RNF de usabilidade: usuários devem ser capazes de usar

as funções do sistema após duas horas de treinamento RNF de confiabilidade: o sistema deve estar disponível

99% das vezes RNF de segurança: o acesso aos dados deve ser

protegido, conforme RN RNF de desempenho: o sistema deve processar n

requisições por segundo RNF de capacidade: o sistema deve suportar n usuários

concorrentemente RNF de portabilidade: o sistema deve rodar nas

plataformas X e Y

RNF Organizacionais São procedentes de políticas e procedimentos

nas organizações do cliente e do desenvolvedor: RNF de entrega: um relatório de progresso

deve ser entregue a cada duas semanas RNF de implementação: o sistema deve ser

implementado na linguagem Java RNF de padrões e métodos de

desenvolvimento: uso de métodos orientados a objetos; desenvolvimento utilizando a ferramenta X

RNF Externos Impostos tanto ao produto quanto ao processo

de desenvolvimento em função do ambiente no qual o sistema é desenvolvido:

RNF de interoperabilidade: o sistema deve interagir com os sistemas X e Y

RNF de restrições éticas: o sistema não deverá revelar aos operadores nenhuma informação pessoal dos clientes

RNF de restrições legais: o sistema deverá armazenar as informações de acordo com a Lei número XXYY de ZZ

Exercício Forneça alguns exemplos de requisitos

não funcionais (RNF) para, classifique-os:1. Vídeo Locadora2. Sistema de Auto-atendimento Bancário

Requisitos de Domínio Derivados do domínio da aplicação e

descrevem características do sistema e qualidades que refletem o domínio

Podem ser gerar requisitos funcionais novos ou restrições sobre os existentes

São regras de negócio (RN)

Problemas Entendimento

Requisitos são descritos na linguagem do domínio da aplicação

Não é entendido pelos engenheiros de software que vão desenvolver a aplicação

Aspectos Implícitos Especialistas no domínio entendem a área

tão bem que assumem que os requisitos estão claros para os desenvolvedores

Exemplos [RN1] Os campos referentes a “Orçamento

Projeto Vinculado” só estarão ativos se o tipo de projeto for Vinculado.

[RN2] O campo Valor Total Orçado para o Projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não-vinculado.

[RN3] A soma dos percentuais a ser distribuído entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%

Exercício Forneça alguns exemplos de requisitos

de domínio (RN) para:1. Vídeo Locadora2. Sistema de Auto-atendimento Bancário

Respostas Vídeo locadora:

[RN1] O software deve permitir que o cliente alugue no máximo 2 filmes na primeira locação.

Sistema de Auto-atendimento Bancário: [RN1] O cliente pode sacar o valor máximo

de R$ 100,00 por dia.

Processo de Engenharia de Requisitos

Processo de ER Ambiente ideal: clientes e engenheiros de

software trabalhando juntos na mesma equipe.

Neste caso, a ER é simplesmente uma questão de conduzir conversas entre colegas que são membros bem conhecidos da equipe.

Exemplo: Desenvolvimento ágil de software.

Processo de ER Ambiente real: clientes em cidade ou país

diferente, com uma vaga idéia do que é necessário, opiniões conflitantes sobre o sistema a ser construído, conhecimento técnico limitado, tempo limitado para interagir com o engenheiro de requisitos, etc.

Nada disso é desejável, mas são situações comuns em que a equipe de software é forçada a trabalhar.

Processo de ER Trata dos passos necessários para

conduzir a Engenharia de Requisitos.

Busca colocar o projeto em andamento e mantê-lo em movimento até se alcançar uma solução bem-sucedida.

Identificação dos interessados

Interessado: qualquer um que se beneficie de modo direto ou indireto do sistema que está sendo desenvolvido.

O engenheiro de requisitos deve criar uma lista de pessoas que fornecerão entradas à medida que os

requisitos forem levantados.

Com quem mais vocês acham que eu deveria falar?

Início do Processo

Diferentes pontos de vista

Requisitos inconsistentes e conflitantes

O engenheiro de requisitos deve categorizar todas as informações dos interessados a fim de que os tomadores de decisão escolham um conjunto de requisitos consistente.

Busque a colaboração entre os interessados.

Início do Processo

Primeiras questões Engenheiro de Requisitos:

Quem solicitou? Quais são os usuários? Qual o benefício econômico? Há outra fonte para a solução?

Equipe de Software: Quais são as saídas geradas? Qual o ambiente de negócios da solução? Restrições de desempenho afetarão a solução?

Início do Processo

Primeiras questões

Você é a pessoa certa para responder a essa questões? Suas respostas são “oficiais”?

Alguém mais pode fornecer informações adicionais?

ATENÇÃO: Essas e outras questões ajudam no início da comunicação, entretanto, não abuse delas durante as reuniões.

Início do Processo

Coleta colaborativa de requisitos

Especificar o problema Propor elementos da solução Negociar abordagens Especificar um conjunto inicial de

requisitos

Reuniões

Levantamento de Requisitos

As reuniões são conduzidas e assistidas por engenheiros de software, clientes e outros interessados.

São definidas regras para a preparação e a participação. É sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes, porém suficientemente informal para encorajar o livre fluxo de idéias.

Um “facilitador” (cliente, desenvolvedor ou outra pessoa) controla a reunião.

Levantamento de Requisitos

Um “mecanismo de definição” é usado (folhas de rascunho, flip charts, quadro de avisos eletrônico, fórum virtual, etc).

A meta é identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução.

Levantamento de Requisitos

Quais são os produtos finais desta etapa?

Declaração da necessidade e viabilidade Escopo do problema Clientes, usuários que participaram Lista de requisitos Conjunto de cenários de uso (descrição

de como o sistema será usado) Protótipos

Levantamento de Requisitos

Análise de Requisitos Objetivo

Estabilidade do modelo à medida que ele evolui

Elementos do Modelo de AnáliseElementos baseados em cenários.

Exemplo: casos de usoElementos baseados em classes.

Exemplo: diagramas de classesElementos comportamentais. Exemplo:

diagramas de seqüênciaElementos orientados a fluxo

Negociação Funcionalidades e desempenho podem ser

questionados em função do custo e do prazo

Clientes (necessidades satisfeitas) e desenvolvedores (orçamentos e prazos realistas) ganham.

“Conciliação é a arte de dividir um bolo de tal modo que todos acreditam ter o maior pedaço.”

(Ludwing Erhard)

A arte da negociação

Reconheça que não é uma competição Trace uma estratégia Ouça atentamente Focalize os interesses das outras partes Não deixe a coisa ficar pessoal Seja criativo Esteja pronto a se comprometer

Negociação

Validação

Requisito consistente com o objetivo, sem restrições contraditórias?

Requisitos estão especificados em um nível de detalhes suficiente?

Todas as funções foram incluídas? Há necessidade do requisito? Ambigüidade? Requisitos conflitantes? Requisitos podem ser testados?

Técnicas de Validação

Revisões de requisitos: podem ser formais ou informais. As revisões formais devem ser conduzidas através da verificação da consistência, erros e completeza do requisito.

São verificadas também: facilidade de verificação; facilidade de compreensão; adaptabilidade: alterações no requisito podem

provocar efeitos significativos?

Levantamento de Requisitos

Gerenciamento de Requisitos Requisitos para grandes produtos são

modificados freqüentemente

Diversidade de usuários (diferentes requisitos e prioridades)

Restrições orçamentárias e organizacionais X requisitos dos usuários finais

Modificações na empresa e no ambiente técnico

Impacto das mudanças do requisito (facilidade de rastreamento)

O Processo de Engenharia de Requisitos

Estrutura de um Documento de Requisitos

Prefácio Introdução Glossário Definição dos Requisitos do Usuário Arquitetura de Sistemas Especificação de Requisitos do Sistema Modelos de Sistema Evolução de Sistema Apêndices Índice

Atividade Praticando o Processo de Engenharia de Requisitos.

Cada grupo será responsável por elaborar um documento de requisitos para um dos domínios abaixo: Locadora de Vídeo Universidade Atendimento ao cliente

Algum outro domínio escolhido pelo grupo deve ser apresentado previamente ao professor.

Orientações Gerais Elaborar um documento de requisitos com base

nas tarefas de concepção, levantamento, elaboração, negociação, especificação, validação e gestão de requisitos.

Grupos de até 5 alunos Apresentação na próxima aula Duração: 5 minutos Entregar documento de requisitos (até 4

páginas), conforme o modelo entregue ao Aluno. Dica: definir um papel para cada integrante do

grupo. Exemplo: gerente da empresa, usuário final, engenheiro de software, desenvolvedor, etc.