aula 1 requisitos

Pós Graduação em Desenvolvimento de

Software

Módulo: Engenharia de Requisitos Aula 1: Requisitos

Professor: Licardino Siqueira Pires

O desafio da análise

• São quatro os desafios da análise:

• Compreensão do domínio do problema

• Comunicação interpessoal

• Evolução contínua

• reutilização

Domínio do Problema e Responsabilidade

• Estudo do domínio do problema e a identificação das suas

características;

• Significados: • Problema: [Jogar para frente, empurrar para frente (Grego)]; Uma

questão proposta para solução ou consideração;

• Domínio: [Direito de propriedade, posse (Grego)]; A esfera ou

campo de atividade ou influência; como por exemplo o domínio

da arte ou política.

• Assim: Domínio do Problema. Um campo sob estudo

ou consideração.

• Exemplo: controle do espaço aéreo, a aviônica, as

finanças e as leis.


• Significados: • Sistema: [reunir (Grego)];Um conjunto ou arranjo de elementos

relacionados ou interligados de modo a formar uma unidade ou

um todo orgânico, por exemplo sistema solar e sistema de

irrigação;

• Responsabilidade: [que precisa de uma resposta (Grego)]; A

condição, qualidade, fato ou ocorrência de ser responsável,

exigível, cobrável ou imputável; aplica-se a pessoas, mandados,

ofícios ou dívidas.

• Assim: Responsabilidade do sistema. Uma

organização de elementos relacionados de modo a

formar um todo.


• Um analista precisa especificar requisitos, reunidos

concisamente de forma que as pessoas possam ler e

entender o que o analista acredita que são estes

requisitos.

• Mas o crucial é entender o domínio do problema.

Comunicação

• Todo o trabalho de análise precisa de comunicação;

• Retornar ao cliente o que foi sintetizado para validação;

• Negociar com cliente requisitos que não possam ser

atendidos, devido ao cronograma e custo;

• Engenharia de software baseada fortemente em pessoas;

• Os processos de software são efetivos somente até o

ponto em que ajudam as pessoas a se comunicarem;

Comunicação

Mudança Contínua

• Requisitos sempre mudam;

• “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” afirma Gerard Fischer;

• Agrupar os requisitos estáveis

• Tratar com diferenciação os instáveis

Reutilização

• Reutilizar é o ato de incorporar resultados de análise

anteriores na análise atual;

Tarefas da Engenharia de Requisitos

• O processo é composto de sete funções distintas:

concepção, levantamento, elaboração, negociação,

especificação, validação e gestão.

Concepção

• Como um projeto de software é iniciado?

•Existe um evento único que torna catalisador de um novo

sistema, ou a necessidade evolui com o tempo?

Levantamento

•Parece simples?

• Questione o cliente, o usuário quais os objetivos do

sistema. Pode ser difícil.

Limite mal definido

Requisitos mudam

Elaboração

•Refinamento das informações obtidas do cliente durante a

concepção e levantamento;

•Modelo técnico refinado das funções, características e

restrições de software;

•O resultado final da elaboração define

• Domínio do problema informacional, funcional e

comportamental.

Elaboração

Considere por um momento que lhe foi solicitado especificar todos os requisitos para a

construção de uma cozinha gourmet.

A fim de especificar totalmente o que deve ser construído, você poderia listar todos os

gabinetes e seus eletrodomésticos. Você então poderia especificar o revestimento dos

balcões, peças de encanamento e pavimentação. Essas listas poderiam fornecer uma

especificação útil, mas não fornecem um modelo completo do que você quer.

Para completar o modelo, você poderia criar uma apresentação tridimensional que

mostrasse a posição dos gabinetes, dos eletrodomésticos e relacionamento entre eles.

Construímos modelos de análise por motivos muito semelhantes àqueles pelos quais

desenvolveríamos uma planta ou uma apresentação 3D da cozinha. É importante avaliar

os componentes do sistema em relação uns com os outros, para determinar como os

requisitos se encaixam nesse quadro e avaliar a estética do sistema tal como concebida.

Negociação

•Usuários pedem mais do que pode ser conseguido

•Usuários diferentes possuem requisitos de acordo com seus

interesses.

•O Engenheiro de requisitos deve negociar.

•Não deve haver ganhador e nem perdedor em uma

negociação efetiva.

Especificação

•Pode ser:

• Cenários de uso

• Documento escrito

• Modelo gráfico

•Último produto do engenheiro de requisitos

•Serve como subsídio das atividades subsequentes;

•Descreve a função e o desempenho de um sistema de

computador e as restrições que governarão seu

desenvolvimento.

Validação

•Os produtos de trabalho são avaliados quanto a qualidade

Check list da Validação

• Os requisitos foram claramente

estabelecidos? Eles podem ser mal

interpretados?

• A fonte do requisito foi identificada?

• O requisito está limitado em termos

quantitativos?

• Que outros requisitos se relacionam a

este requisito? Eles foram claramente

anotados em uma matriz de referência

cruzada?

• O requisito viola alguma restrição de

domínio?

• O requisito pode ser testado? Em caso

positivo, podemos exercitar os testes

para exercitar o requisito?

• Pode-se relacionar o requisito a qualquer

modelo de sistema que tenha sido criado?

• O requisito está relacionado aos objetivos

globais do sistema/produto?

• A especificação do sistema está

estruturada de modo que leve a fácil

entendimento, fácil referenciação e fácil

tradução em produtos de trabalho mais

técnicos?

• Foi criado um índice para a especificação?

• Os requisitos relacionados ao

desempenho, ao comportamento e às

características operacionais do sistema

foram claramente declarados? Que

requisitos podem estar implícitos?

Gestão de Requisitos

•A cada requisito é atribuída uma identificação;

•Tabelas de rastreamento são desenvolvidas

Requisitos

• Requisitos tem papel central no processo de software,

sendo considerados um fator determinante para o sucesso

ou fracasso de um projeto de software;

•O processo de levantar, gerenciar e controlar a qualidade

dos requisitos é chamado Engenharia de Requisitos;

Definições

• Requisitos de um sistema são descrições dos serviços

que devem ser fornecidos por esse sistema e as suas

restrições operacionais(SOMMERVILLE, 2007).

• Um requisito de um sistema é uma característica do

sistema ou a descrição de algo que o sistema é capaz de

realizar para atingir seus objetivos (PFLEEGER, 2004).

• Um requisito é alguma coisa que o produto tem de fazer ou

uma qualidade que ele precisa apresentar (ROBERTSON;

ROBERTSON, 2006).

Tipos de Requisitos

• Requisitos Funcionais:

• são declarações de serviços que o sistema deve

prover, descrevendo o que o sistema deve fazer

(SOMMERVILLE, 2007).

• Um requisito funcional descreve uma interação entre o

sistema e o seu ambiente (PFLEEGER, 2004), podendo

descrever, ainda, como o sistema deve reagir a

entradas específicas, como o sistema deve se

comportar em situações específicas e o que o sistema

não deve fazer (SOMMERVILLE, 2007).

Tipos de Requisitos

• Requisitos não Funcionais:

• descrevem restrições sobre os serviços ou funções

oferecidos pelo sistema (SOMMERVILLE, 2007), as

quais limitam as opções para criar uma solução para o

problema (PFLEEGER, 2004).

• Neste sentido, os requisitos não funcionais são muito

importantes para a fase de projeto (design), servindo

como base para a tomada de decisões nessa fase.

Requisitos

Organização de Requisitos

• Requisitos Funcionais

• Evidentes são efetuados com conhecimento do

usuário

• Ocultos são efetuados pelo sistema sem o

conhecimento explícito do usuário.

• Transitórios: podem ser mudados por legislações e

normas, por exemplo. (parametrização)

• Exemplo: Registrar empréstimo.

• Requisitos não-funcionais:

• Obrigatórios

• Desejáveis

• Exemplo: O tempo de registro de cada DVD deve ser

inferior a um segundo.

Exemplo

• Registrar o empréstimo de uma fita é um requisito funcional.

• Estabelecer que o tempo de empréstimo da fita não pode ser

superior a 48 horas é uma restrição, ou requisito não

funcional.

Classificação de requisitos não funcionais

• Sommerville (2007), por exemplo, classifica-os em:

• Requisitos de produto: especificam o comportamento do

produto (sistema). Referem-se a atributos de qualidade .

• Requisitos organizacionais: são derivados de metas,

políticas e procedimentos das organizações do cliente e

do desenvolvedor.

• Requisitos externos: referem-se a todos os requisitos

derivados de fatores externos ao sistema e seu processo

de desenvolvimento.

Níveis de descrição de requisitos

• Requisitos de Usuário: são declarações em linguagem

natural acompanhadas de diagramas intuitivos de quais

serviços são esperados do sistema e das restrições sob as

quais ele deve operar.

• Requisitos organizacionais: definem detalhadamente as

funções, serviços e restrições do sistema.

Documento de Especificação de

Requisitos

1. Introdução

1. Propósito do documento de requisitos

2. Escopo do produto

3. Definições, escopo e abreviaturas

4. Referências

5. Visão geral do restante do documento

2. Descrição Geral

1. Perspectiva do produto

2. Funções do produto

3. Características dos usuários

4. Restrições gerais

5. Suposições e dependências

3. Requisitos específicos

4. Apêndices

5. Índice

Entendendo as necessidades dos usuários

• Identificar as fontes de requisitos dos Envolvidos

• Definir lista de requisitos do sistema

• Pode-se utilizar técnicas de brainstorming para

levantamento dos requisitos junto aos envolvidos.

• Os requisitos podem ser classificados em duas grandes

categorias:

• Requisitos Funcionais que correspondem a listagem

de tudo que o sistema deve fazer.

• Requisitos não-funcionais que são restrições

colocadas sobre como o sistema deve realizar seus

requisitos funcionais.

Quais são as fontes dos requisitos?

Analistas

Parceiros

Usuários

Cliente

Domínio do

Problema

Requisitos Iniciais

Relatórios de Problemas

Solicitações de Mudanças

Visitas no site

Informações dos concorrentes

Legislações

Sistemas legados

Especificações de requisitos

Modelos de negócios

Planos de negócios

Objetivos pessoais

Quais problemas podem ser encontrados

• Envolvidos

• Possuem uma ideia pré-concebida da solução

• Não sabem o que eles realmente desejam

• São inabilitados em articular o que eles desejam

• Pensam que sabem o que eles Desejam, mas não os

reconhecem quando eles são entregues

• Analistas

• Pensam que eles entendem os problemas do usuário

melhor do que o usuário.

• Os outros

• Todo mundo enxerga as coisas do seu próprio ponto

de vista

• Acredita que tudo é motivado politicamente (a equipe

comercial deseja a implementação de requisitos que

atraem mais clientes e a financeira requisitos que

tornem os gastos menores)

Técnicas para elicitação de requisitos

•Revisar as especificações de requisitos dos clientes

•Entrevista

•Leitura de Documentos

•Questionário

•Participação ativa dos usuários

•Brainstorming

•Workshop de requisitos

•Protótipos

•Observações e análises sociais


Workshop de requisitos

• Criar consenso no escopo, riscos e características

chaves do sistema de software.

• São direcionados por um facilitador

• Duração: 3 a 5 dias

• Artefatos produzidos, como:

• Declaração do problema

• Requisitos dos envolvidos

• Características chaves

• Diagrama de caso de uso

• Lista de risco priorizada


Benefícios do Workshop de requisitos

• Provê um framework para aplicar outras técnicas de

elicitação

• Workshop de caso de uso, brainstorming

• Acelera o processo de elicitação

• Reuni todos os envolvidos para uma discussão intensa e

focado no problema

• Promove a participação de todos

• Resultados avaliados imediatamente


Workshop: Planejar e Executar

Pré-workshop Sessão Produção Acompanhamento

Motivar o workshop

Estabelecer equipe

Organizá-lo

Enviar materiais

Preparar agenda

Facilitar

Rastreamento

Registrar

descobertas

Resumir as

conclusões

Sintetizar

descobertas

Condensar info

Apresentar ao

cliente

Planejar próximos

passos

Reunião de Coleta de Requisitos

• Jamie Lazar, Vinod e Ed, membro da

equipe de software; Doug, gerente de

engenharia de software; membros de

marketing; facilitador

• Facilitador (apontando para um quadro):

Então, esta é a lista de objetos e serviços

para a função de segurança residencial.

• Pessoa de Marketing: Isso praticamente

cobre tudo do nosso ponto de vista.

• Vinod: Alguém não mencionou que queria

toda a funcionalidade do CasaSegura

acessível via internet? Isso, incluiria a

função de segurança residencial, não?

• Pessoa de Marketing: É, está certo ...

Vamos ter de acrescentar essa

funcionalidade e os objetos adequados.

• Facilitador: Isso também acrescenta

alguma restrição?

• Jamie: Sim, tanto técnicos quanto legais

• Representante da Produção: O que

significa?

• Jamie: Precisamos estar certos de que uma

pessoa de fora não pode invadir o sistema,

desarmá-lo e roubar o lugar ou pior.

Pesada responsabilidade de nossa parte.

• Doug: Muito Certo

• Marketing: Mas nós ainda precisamos de

conectividade via internet ... Basta nos

certificarmos de impedir a invasão de uma

pessoa de fora.

• Ed: Isso é mais fácil de falar do que fazer...

• Facilitador (interrompendo): Eu não quero

discutir esse ponto agora. Vamos anotá-lo

com um item de ação e prosseguir.

• Facilitador: Estou sentindo que existe

ainda mais a considerar.


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 engenheiro de requisitos busca

respostas para 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 stakeholders quer do sistema.


Entrevistas

• Entrevistadores devem estar de “cabeça aberta” e não

fazer a entrevista com noções pré-concebidas sobre o

que é necessário

• Informar aos stakeholders o ponto inicial da discussão.

Isto pode ser uma questão, uma proposta de requisitos

ou um sistema existente

• Entrevistadores devem estar cientes da política

organizacional - muitos requisitos reais podem não ser

discutidos devido as implicações políticas


Questionário

• Quando existe conhecimento sobre o problema e grande

número de clientes

• Dão idéia definida sobre como certos aspectos universo

de informação/software são percebidos

• Possibilitam análises estatísticas

• Vantagens: padronização das perguntas e tratamento

estatístico das respostas

• Desvantagens: limitação do universo de respostas e

pouca iteração


Modos de comunicação

aula 1 requisitos

Documents