ENGENHARIA DE REQUISITOS. 6/5/2014Engenharia de Requisitos2 Fases da Engenharia de Requisitos...

ENGENHARIA DE REQUISITOS

04/11/23 Engenharia de Requisitos 2

Fases da Engenharia de Requisitos

MODELAGEM

ANÁLISEVALIDAÇÃO

ELICITAÇÃO

Aquisição Especificação

Informações elicitadasUniverso das Informações

Informações

Representações

Especificação

de requisitos


Um caso comum !!• - O sistema que queremos deve fazer isto,

isto, ..., e nesse caso também isto...;

• - Sim, Sim, estou anotando...

• - Conversei com os usuários e basicamente este é o sistema que teremos que desenvolver;

• - Sim chefe;

• - Ótimo, começaremos a especificar os requisitos imediatamente.


MOTIVAÇÃO...Quatro meses depois ...

• - Senhores usuários, após o emprego das mais modernas técnicas de especificação, produzimos este documento que descreve minuciosamente o Sistema;

• - Ótimo! Bom! Hum! ... É um documento com 300 páginas e todos estes gráficos, tabelas. Enfim, vamos analisá-los e voltamos a falar;


MOTIVAÇÃO

... Mais um mês e meio ...• - Sr. Analista, nosso pessoal analisou com cuidado

o documento. Tivemos muitas dificuldades em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!!

• - Como não? Tudo que está aí foi fruto de nosso entendimento pessoal. REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!


MOTIVAÇÃO


Componentes da elicitação de requisitos

Problema a ser resolvido

Domínio da

aplicação

Contexto do negócio

Necessidades dos

stakeholders


Elicitação de Requisitos

• ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão;

• identificar os fatos que compõem os requisitos do Sistema a fim de prover o mais correto e mais completo entendimento do que é demandado daquele software.


Elicitação de requisitos: dificuldades

• Usuários podem não ter uma idéia precisa do sistema por eles requerido;

• Usuários têm dificuldades para descreverem seu conhecimento sobre o domínio do problema;

• Usuários e analistas têm diferentes pontos de vista do problema (por terem formações diferentes)

• Usuários podem antipatizar com o novo sistema e se negar a participar da elicitação (ou mesmo fornecer informações errôneas).


Atividades da Elicitação Entendimento do domínio da aplicação

O conhecimento do domínio da aplicação é o conhecimento geral onde o sistema será aplicado

Entendimento do problema Os detalhes específicos do problema do cliente onde o sistema

será aplicado deve ser entendido Entendimento do negócio

Você deve entender como os sistemas interagem e contribuem de forma geral com os objetivos do negócio

Entendimento das necessidades e limitações dos stakeholders sistema


Estágios da Elicitação

• Definir objetivos

• Aquisição de conhecimento do background

• Organização do conhecimento

• Coletar os requisitos dos stakeholders


Checagens da análise

• Checagem da necessidade

• Checagem de consistência e completude

• Checagem de viabilidade


Negociação dos Requisitos

• Discutir os requisitos

• Priorizar os requisitos

• Concordância dos requisitos


Técnicas de Elicitação

• Técnicas especiais que podem ser usadas para coletar conhecimento sobre os requisitos dos usuários

• Este conhecimento deve ser estruturado

• Problemas da elicitação– Tempo– Engenheiros de software– stakeholders


Técnicas de Elicitação• Entrevistas

• Leitura de documentos

• Questionários

• Análise de protocolos

• Participação ativa dos usuários

• Cenários

• Observações e análise sociais

• Prototipação


Escolhendo a técnica• Deve-se selecionar as técnicas a serem

utilizadas e estabelecer a maneira como elas serão integradas

• A escolha das técnicas e seu esquema de integração dependerá do problema e da equipe participante

• É interessante conhecê-las e saber identificar onde uma técnica se aplica melhor que outra


Técnicas específicas de elicitação


Entrevistas

• O Engenheiro de requisitos ou analista discute o sistema com diferentes stakeholders e obtêm um entendimento dos requisitos

• Vantagens: contato direto com o usuário e validação imediata

• Desvantagens: conhecimento tácito e diferenças de cultura


Entrevistas - tipos• Entrevistas fechadas: o analista busca respostas

a um conjunto de questões pré-definidas

• Entrevistas abertas: Não há uma agenda pré-definida e o engenheiro de requisitos discute de forma aberta, o que o stakeholder quer do sistema

• Tutorial: o cliente dá uma aula explicando seu trabalho


Entrevistas: dicas

• Identificar candidatos

• Preparação da entrevista : agendar e preparar questionário (se for o caso)

• O analista não deve ir para a entrevistas com noções pré-concebidas


Entrevistas: condução• Informar aos stakeholders o ponto inicial da

discussão. Isto pode ser uma questão, uma proposta de requisitos ou um sistema existente

• Esperar por respostas incompletas• Repetir frases do entrevistado com suas próprias

palavras• Entrevistadores devem estar cientes da política

organizacional - muitos requisitos reais podem não ser discutidos devido a implicações políticas


Entrevistas: Finalização

• Tempo para rever respostas de todas as perguntas - consolidar informações

• Agradecimentos

• Gerar documento que deve ser assinado pelo entrevistado


Leitura de Documentos

• Abstrações

• Vocabulário da aplicação

• Vantagens: facilidade de acesso e volume de informações

• Desvantagens: dispersão das informações e volume de trabalho


Questionários• Quando existe conhecimento sobre o problema e

grande número de clientes• Quando dados estatísticos são importantes• Dão idéia definida sobre como certos aspectos do

universo de informação são percebidos• Vantagens: padronização das perguntas e

tratamento estatístico das respostas• Desvantagens: limitação do universo de respostas

e pouca iteração


Cenários• Cenários são partes inerentes de alguns métodos de desenvolvimento OO• São estórias que explicam como um sistema poderá ser utilizado. Devem incluir:

– descrição do estado do sistema antes de começar o cenário– o fluxo normal de eventos do cenário– exceções ao fluxo normal de eventos– informações sobre atividades concorrentes– uma descrição do estado do sistema no final do cenário


Cenários

• Cenários são exemplos de interação que descrevem como o usuário interage com o sistema

• A descoberta de cenários expõe interações possíveis do sistema e revela as facilidades que o sistema pode precisar


Análise de protocolos• Analisar o trabalho de determinada pessoa através

da verbalização• Objetivo: estabelecer a racionalidade utilizada na

execução de tarefas• Vantagens: possibilidade de elicitar fatos não

facilmente observáveis e permitir melhor entendimento dos fatos

• Desvantagens: desempenho do entrevistado e “o que se diz é diferentes do que se faz”


Participação ativa dos usuários• Incorporação dos usuários ao grupo de ER• Os usuários precisam aprender a linguagem de

modelagem utilizadas para ler as descrições e criticá-las

• Integração dos usuários na modelagem do sistema• Vantagens: envolvimento dos clientes/usuários• Desvantagens: Tempo em treinamento dos

usuários e falsas expectativas no usuário


Observação e análise social• Difícil descrever os processos, interessante observar• Etnografia: o analista procura ter a mesma

perspectiva do cliente• Processos reais diferem dos processos formais

escritos nos manuais• Vantagens: visão mais completa e perfeitamente

ajustada ao contexto• Desvantagens: custo com tempo e pessoal gasto e

pouca sistematização do processo


Prototipação

• Uma versão inicial de um sistema que poderá ser usado para experimentação

• Protótipos são úteis para elicitar requisitos porque o usuário poderá “experimentar” o sistema e mostrar os pontos fortes e fracos

• Concreto


Tipos de prototipagem

• Descartável– Protótipo serve para requisitos e é descartado

um outro sistema é implementado depois;

• Evolucionária– usado no ciclo espiral– Os requisitos vão aparecendo conforme o

usuário está utilizando o “sistema”


Vantagens• O protótipo permite que os usuários experimentem e

descubram o que eles realmente necessitam para suportar o trabalho deles

• Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados

• Interface• Pode ser usado para teste do sistema e desenvolvimento

da documentação• Força estudo detalhado dos requisitos que revela

inconsistências e omissões


Desvantagens

• Custos de treinamento: pode se optar por ferramentas específicas para prototipação

• Incompletude


Modelagem

• Visa a representação dos requisitos em modelos conceituais que descrevem as necessidades encontradas na elicitação.


Análise de Requisitos

• Analisar o modelo gerado buscando encontrar inconsistências e omissões nos requisitos elicitados

• Intercalar com elicitação pois problemas são descobertos quando os requisitos são elicitados

• Desempenhada apenas pelos analistas


Validação

• Com a ajuda dos clientes/usuários, busca-se validar ou seja, confirmar o conhecimento adquirido.


Documentação Gerada

• O documento de requisitos de software - também chamado de SRS software requirements specification - é o resultado da engenharia de requisitos.

• Deve incluir requisitos do usuário, requisitos do sistema


Requisitos do usuário

• São declarações em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar.


Requisitos do sistema

• Estabelecem detalhadamente as funções e as restrições de sistema.

• Algumas vezes chamado de ESPECIFICAÇÃO FUNCIONAL

• Pode servir como contato entre o comprador e o desenvolvedor do software.


Padrão IEEE/ANSI 830-1998

• 1. Introdução

• 1.1 Propósito• 1.2 Convenções• 1.3 Público Alvo e Orientações para Leitura• 1.4 Escopo do Produto• 1.5 Referências


• 2. Descrição Geral– 2.1 Perspectiva do Produto

– 2.2 Funções do Produto

– 2.3 Classes de Usuários e Características– 2.4 Ambiente Operacional– 2.5 Restrições de Projeto e Implementação

– 2.6 Premissas e Dependências


• 3. Requisitos de Interface Externa

• 3.1 Interfaces do Usuário• 3.2 Interfaces de Hardware

• 3.3 Interfaces com outros Sistemas

• 3.4 Interfaces de Comunicação


• 4. Funcionalidades do Sistema

• 4.x Funcionalidade X• 4.x.1 Descrição e Prioridade

• 4.x.2 Seqüências de Estímulos e Respostas• 4.x.3 Requisitos Funcionais


• 5. Requisitos não Funcionais

• 5.1 Requisitos de Performance• 5.2 Requisitos de Uso com Segurança

• 5.3 Requisitos de Segurança

• 5.4 Atributos de Qualidade

• 5.5 Regras de Negócio• 5.6 Documentação do Usuário


• 6. Outros Requisitos

• Apêndice A: Glossário

• Apêndice B: Modelos de Análise

• Apêndice C: Lista de Pendências

ENGENHARIA DE REQUISITOS. 6/5/2014Engenharia de Requisitos2 Fases da Engenharia de Requisitos...

Documents

Transcript of ENGENHARIA DE REQUISITOS. 6/5/2014Engenharia de Requisitos2 Fases da Engenharia de Requisitos...