Engenharia de Software Software Requirements

(1)

Requisitos

q

o

Engenharia de Software Software Requirements SWEBOK C ít l 2 SWEBOK, Capítulo 2

(2)

Primeira Classificação de Requisito

1. Requisito do usuário: declarações sobre as

f

õ

i t

d

f

funções que o sistema deve oferecer

2. Requisito do sistema: detalhamento das

funções e das restrições (contrato entre

cliente e desenvolvedor)

3. Requisito do projeto de software: detalha

mais o requisito do sistema e serve de base

para o projeto e implementação do software.

(3)

Conceito de Requisito

Requisito é uma condição ou capacidade:

1 N

á i

l

1. Necessária para um usuário resolver um

problema ou alcançar um objetivo;

2. Para satisfazer uma especificação em um

sistema ou em um componente;

3. Com uma representação documentada.

Em: The IEEE Standard Glossary f S ft E i i T i l 1997 of Software Engineering Terminology, 1997.

(4)

Ciclo

Ciclo--de

de--vida dos REQUISITOS

vida dos REQUISITOS

Necessidade

Definição

Gestão _Utilização Gestão _Utilização

(5)

Processo de Engenharia de Requisitos

Informações

Necessidades Necessidades

ç

Elicitação

Elicitação ModelagemModelagem

Validação

Validação AnáliseAnálise

Especificação Especificação Aquisição Aquisição Especificação Especificação dos Requisitos

(6)

Algumas Categorias de Requisitos

g

q

Requisitos de projeto

• Definem atividades que serão executadas no projeto

Requisitos de negócio

Obj ti d lt í l id l li t

Requisitos de usuário

Tarefas q e os s ários são habilitados a reali ar • Objetivos de alto nível requeridos pelos clientes • Tarefas que os usuários são habilitados a realizar

Requisitos funcionais

F i lid d ft d

• Funcionalidade que o software deve prover:

comportamento e propriedade: como o sistema deve se comportar quando recebe um estimulo

comportar quando recebe um estimulo

Requisitos não funcionais

• Restritivos: limitam as possibilidades de solução e nãoRestritivos: limitam as possibilidades de solução e não representam funcionalidade do software

(7)

Como os Projetos Podem Ter Sucesso?

jj

• Análise do Problema

• Entenda o problema

• Análise do Problema

• Entenda o problema • Entenda o problema

• Obtenha concordância dos envolvidos

• Levantamento dos Requisitos

• Entenda o problema

• Obtenha concordância dos envolvidos

• Levantamento dos Requisitos

• Identifique quem usará o sistema (atores)

• Descubra como o sistema será usado (funcionais)

• Levantamento dos Requisitos

• Identifique quem usará o sistema (atores)

• Descubra como o sistema será usado (funcionais) • Descubra como o sistema será usado (funcionais)

e todas as restrições ao seu funcionamento e desenvolvimento (não funcionais).

• Descubra como o sistema será usado (funcionais)

e todas as restrições ao seu funcionamento e desenvolvimento (não funcionais).

• Gerência de Requisitos

• Especifique os requisitos completamente

• Gerência de Requisitos

• Especifique os requisitos completamente • Gerencie expectativas, mudanças e erros • Controle o aumento do escopo

• Gerencie expectativas, mudanças e erros • Controle o aumento do escopo

• Defina a equipe e a mantenha informada • Defina a equipe e a mantenha informada

(8)

Como o Software pode ter qualidade?

A Norma ISO/IEC 9.126 definem-se seis características de qualidade de software:

◦ Funcionalidade (finalidade do produto)

U bilid d ( f tili d

◦ Usabilidade (esforço para utilizar, aprender o produto)

◦ Confiabilidade (freqüência de falhas

◦ Confiabilidade (freqüência de falhas, recuperabilidade)

◦ EficiênciaEficiência (desempenho)(desempenho)

◦ Manutenibilidade (esforço necessário para modificar))

◦ Portabilidade (capacidade de transferir o produto para outros ambientes)

(9)

Gerência de Requisitos

Atividades de:

• Acompanhar o desenvolvimento

• Controlar as mudanças dos requisitos

Controlar as mudanças dos requisitos

Ações:

• Planejamento

• Rastreabilidade

• Diagnóstico e avaliação da

qualidade

(dos

requisitos)

• Análise de impacto das mudanças

• Controle de versões (de requisitos)

(10)

Principais Atividades da Engenharia de Principais Atividades da Engenharia de pp gg Requisitos

(11)

Qual a diferença e a relação

entre Engenharia de

Requisitos e Gerência

Requisitos?

(12)

Qualidade de Requisitos

Corretos

devem caracterizar um

• Corretos – devem caracterizar um

resultado a ser construído

Precisos

interpretação única

• Precisos – interpretação única

• Completos – incluem todas as

especificações decididas

• Consistentes – possíveis e sem conflitos

com os demais

(13)

Qualidade de Requisitos

Priorizáveis

importância estabilidade e

• Priorizáveis – importância, estabilidade e

complexidade

Verificáveis

possibilidade inequívoca de

• Verificáveis – possibilidade inequívoca de

medição

Modificáveis

mudanças de maneira

• Modificáveis – mudanças de maneira

fácil, completa e consistente

• Rastreáveis

antecedentes e

• Rastreáveis – antecedentes e

(14)

Elicitação dos requisitos

ç

q

Nesta fase o engenheiro de requisitos procura captar os requisitos do software (e do sistema), buscando obter conhecimento do

domínio do problema.

ELICITAR: descobrir tornar explícito obter o máximo de

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

A elicitação é a tarefa de identificar os fatos relacionados aos

A elicitação é a tarefa de identificar os fatos relacionados aos requisitos do sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado do software.

Atividades principais: identificação das fontes de informação; coleta de fatos e comunicação.

(15)

Ações para Elicitação dos requisitos

• Obter informação sobre domínio do problema

ç

p

ç

q

(organizacionais e operacionais) e sistema atual (se houver): a equipe de levantamento deve conhecer o vocabulário do domínio do negócio.

• Preparar e realizar reuniões de levantamento e p negociação.

• Identificar e revisar os objetivos do sistema e as

informações que o sistema deverá gerir e armazenar. Id tifi i i it f i i

• Identificar e revisar os requisitos funcionais.

(16)

Elicitação

••

Faz

Coleta de Fatos

••

Faz

Identificação de Fontesç ••

Faz

Comunicação

F

/U

F

/U

F t

••

Faz/Usa

Ferramentas ••

Usa

Pessoal

••

Usa

Métodos e técnicas

Depende de

Pontos de Vista

(17)

Identificação das Fontes de Informação

O que são stakeholders do sistema? Qualquer pessoa Qualquer pessoa afetada de alguma forma pelo sistema

( l

(atores, cliente, usuário final,

desenvolvedor) desenvolvedor)

A análise dos stakeholders ajuda a determinar o impacto que um novo sistema de informação terá.

(18)

Identificação das Fontes de Informação Identificação das Fontes de Informação Identificação das Fontes de Informação Identificação das Fontes de Informação

Outras fontes de Informação:

–Documentação do macro-sistema –Políticas

–Manuais

–Memorandos, atas, contratos –Livros sobre tema relacionado –Outros sistemas da empresa –Sistemas externosSistemas externos

(19)

Id tifi ã d F t d I f ã Id tifi ã d F t d I f ã Identificação das Fontes de Informação Identificação das Fontes de Informação

Importante

◦ Priorizar as Fontes de Informação

◦ Priorizar as Fontes de Informação.

◦ Descubra:

x Atores mais importantesAtores mais importantes

x Documentos mais mencionados x Rede de comunicação entre os

componentes do macro-sistema

(20)

Comunicação

Entre Clientes e os Engenheiros de Software

• Apresentação: A forma como a informação é

Entre Clientes e os Engenheiros de Software

Apresentação: A forma como a informação é apresentada

• Entendimento:Entendimento: Estabelecimento de contextos Estabelecimento de contextos

comuns.

– Ex. Planta; Ordem de 5,10,2,9,8,4,6...; , , , , , ,

• Linguagem

– Nível de Abstração

(21)

Apresentação

Diferentes formas de apresentação ajudam oue e es o as de ap ese ação ajuda ou dificultam o entendimento. Di t ib i ã d V d Distribuição de Vendas 40% 45% 25% 30% 35% 40% e nt ua l Distribuição de Vendas 5% 10% 15% 20% Pe rc e •Produto A •15% •Produto B •40% •Produto C •20% •Produto D •25% 0%

Produto A Produto B Produto C Produto D

(22)

Entendimento

y A comunicação pode ser ruidosa se os y A comunicação pode ser ruidosa se os

indivíduos estiverem dialogando em diferentes níveis de abstração. ç

y Conflito presente entre generalistas e

especialistas.

y Exemplo

:

Devemos conquistar mercados (Diretoria)

X

Distribuir os vendedores Distribuir os vendedores

(23)

Li

Linguagem

A li é fl d lt d

• A linguagem é reflexo da cultura de uma

sociedade.

Para entendermos algo de importante para uma

• Para entendermos algo de importante para uma

sociedade temos que entender sua linguagem.

• Deve-se compreender a linguagem antes de p g g

elicitar as necessidades.

Exemplos

Conta-mãe, Dzero, Fecha a mesa, Passagem de Resultados, Zipar, FTP, TCP/IP

(24)

Retroalimentação

y

Obrigar o receptor da informação a

g

p

ç

recolocar a comunicação até que o

emissor responda positivamente a

p

recolocação.

y

Resumir, parafrasear, confirmar.

, p

,

? a

(25)

Técnicas de Levantamento

•

Entrevistas

•

Entrevistas

•

Questionários

Observação / Visitas instalações

•

Observação / Visitas instalações

(próprias ou outras)

Demonstrações

•

Demonstrações

•

Pesquisa externa

ál

d

ã

•

Análise da Documentação

•

Joint Application Design (JAD) – IBM

•

Brain Storm

(26)

JAD

JAD JointJoint Application Application DevelopmentDevelopment

JAD

JAD -- JointJoint Application Application DevelopmentDevelopment

INTRODUÇÃO DO

Processo Processo

• Usuários e desenvolvedores _{INTRODUÇÃO DO}

TEMA

APRESENTAÇÃO trabalham juntos em uma

reunião com o objetivo de:

• identificar o problema APRESENTAÇÃO DE EXEMPLOS

DISCUSSÃO

• identificar o problema

• propor elementos de solução • negociar diferentes abordagens

PENDÊNCIA IMPASSE • especificar um conjunto preliminar de requisitos de solução CONSENSO • Envolve:

• preparação para reunião a partir

de uma requisição geral do

DOCUMENTAÇÃOO

de uma requisição geral do produto

(27)

Questionários

1.

Fontes sólidas e confiáveis

2

Objetivo dirigido e diferenciado

2.

Objetivo, dirigido e diferenciado

3.

Ênfase em aspectos quantitativos

(28)

A áli

D

t l

A áli

D

t l

Análise Documental

•

Estudo dos registros existentes

(documentos e relatórios, atuais ou (docu e tos e e ató os, atua s ou históricos).

A áli d i f

õ

i

•

Análise das informações em meio

(29)

E t

i t

E t

i t

Entrevistas

•

Obtenção de informações: atitudes

•

Obtenção de informações: atitudes,

comportamento, fatos vivenciados,

tendências e experiências

•

Informações sobre a empresa,

atividades e a funções

•

Visão mais concreta da realidade

Coordenação de informações recebidas

•

Coordenação de informações recebidas

de fontes diversas

Ê f

t lit ti

(30)

A entrevista

- Forma mais comum: pessoal / direta

- Documentação dos resultados: copiar tudo? - Documentação dos resultados: copiar tudo?

gravar? filmar? realizar anotações?

Pessoas certas que estão nos locais certos - Pessoas certas que estão nos locais certos - Perguntas certas, respostas certas

- Seqüência dos entrevistados - Planejamento do tempo

- Planejamento do tempo - Coleta prévia de dados

(31)

Entrevistas

Procedimentos preliminares

- Planejar a entrevista: objetivo,

perguntas e tempo

é

- Escolher o local: privacidade é essencial

- Agendar a entrevista, informando o

entrevistado da agenda

- Obter informações sobre as

características pessoais e funcionais do

entrevistado

(32)

Durante a entrevista

A t - Apresentar-se

- Repassar a agenda (objetivos, patrocinador, motivo da escolha do entrevistado)

da escolha do entrevistado)

- Postura do entrevistador: credibilidade, isenção, discrição; não criar ressentimentos

- Deixar o entrevistado falar (redução da interferência) - Direcionar a discussão para os objetivosDirecionar a discussão para os objetivos

- Evitar perguntas fechadas - Não ultrapassar o tempo - Não ultrapassar o tempo - Notar sinais de impaciência

(33)

Um estilo para entrevistar

- Relacione a parte da entrevista c/ partes do sistema - Obtenha pontos de vista alternativosObtenha pontos de vista alternativos

- Solicite detalhes do item que você estiver interessado - Estabeleça a dependência do assunto com outros

- Confirme os dados obtidos

(34)

Problemas com que lidamos

• Você está tomando tempo demais • Você está ameaçando meu emprego • Você não conhece a nossa empresa • Você não conhece a nossa empresa

• Você está tentando mudar o modo que as coisas são feitas aqui

feitas aqui

• Não queremos esse sistema • Mudei de opinião

• Aqui não há consenso de como a coisa deve ser feita • Aqui não há consenso de como a coisa deve ser feita • Já tentaram fazer isso antes

(35)

B i

t

B i

t

Brainstorm

y Reunião onde todos têm liberdade de

expressar suas opiniões

N h íti é i d f it

y Nenhuma crítica prévia deve ser feita

y São válidas colocações por impulso: o que

vale é a quantidade de idéias vale é a quantidade de idéias

y Relacionadas as idéias, passa-se para a

interpretação dos resultados interpretação dos resultados

(36)

B i

iti

B i

iti

Brainwriting

y Dividir os participantes em grupos de 4 ou 5

pessoas

O b tã

y Os grupos recebem uma questão

O trabalho O trabalho

y Escrever a sua opinião sobre a questão

y Ao terminar, colocar a folha no centro da

mesa

y Pegar a folha de respostas de outro

integrante do grupo integrante do grupo

(37)

Brainwriting

y Criticar todos os trabalhos do grupo, por escrito y Completado o ciclo, o grupo pode receber nova

t pergunta

y O presentes criticam todas as posições dos

grupos grupos Obs:

y Pode haver um relator por grupo

y Cada grupo pode receber uma questão

diferente diferente