+ Aula 1 – Introdução e Fundamentos de requisitos (Engenharia de Requisitos) 1.1 Os sintomas e as causas de uma ER inadequada 1.2 As quatro atividades

+Aula 1 – Introdução e Fundamentos de requisitos (Engenharia de Requisitos)

1.1 Os sintomas e as causas de uma ER inadequada1.2 As quatro atividades principais da ER1.3 O papel da comunicação na ER1.4 As competências exigidas de um engenheiro de requisitos1.5 Os três tipos de requisitos1.6 O papel dos requisitos de qualidade

“A melhor maneira de atender significativamente a

produtividade e qualidade do desenvolvimento e teste

de seu software é aprimorar a qualidade dos

seus requisitos”

“Só depende de você, então... Just do It”.

+ O problema da PEDRA

Traga-me uma pedra. Mas quando você lhe entrega a pedra o cliente olha e lhe diz:Sim, mas na verdade, o que eu realmente queria era uma pequena pedra azul”.


Quando você lhe entrega a pequena pedra azul, verifica que o cliente realmente desejava era uma pequena pedra esférica e azul.

No final, concluiu-se que o cliente estava querendo uma pequena pedra de mármore azul – talvez ele não estivesse seguro do que estava querendo, mas um pequeno mármore azul ou talvez quem sabe, um pequeno olho de gato azul de mármore também teria servido.


Provavelmente ele tenha mudado o seu desejo sobre o que queria, entre a entrega da primeira pedra (grande) e a terceira (pequena e azul).

A cada encontro subseqüente com o cliente, é comum que o desenvolvedor pergunte: “O que você quer fazer com isto?”.

O desenvolvedor fica frustrado porque ele pensou em algo totalmente diferente quando realizou o árduo trabalho de produzir uma pedra com as características prescritas;

O cliente fica igualmente frustrado porque, mesmo que ele tenha encontrado dificuldades para articular o que ele queria, ele está convencido de que expressou seus desejos claramente.


Para complicar ainda mais em muitos projetos reais, dois indivíduos estão envolvidos. Além do cliente e o desenvolvedor – que podem naturalmente ter diferençasNormalmente não há tempo suficiente no mundo atual tão competitivo, onde não se permitem gastar, por exemplo 2 anos no “projeto da pedra” e no final ter que refazê-lo.

E O DESENVOLVIMENTO DE SOFTWARE ? COMO FICARIA NESTE CENÁRIO ?

+Exerc

ícios

• Abstrair junto ao seu colega um cadastro onde devemos destacar (Informações sobre um cliente e principalmente a recepcionista/vendedora que atende o mesmo).

• Agora adicione as seguintes informações:

a) Data da última compra do cliente e valor faturado.

b) Lembrando que estamos informatizando uma rede de disk pizzas. Procure adicionar informações ao cadastro que atenda a gerência para elaborar possíveis promoções.

+O são Requisitos

1. Uma necessidade percebida por um stakeholder.

2. Uma capacidade ou propriedade que um sistema deverá ter.

3. Uma representação documentada de uma necessidade, capacidade ou propriedade.

+Quem são os Stakeholder

Uma pessoa ou organização que exerce uma influência (direta ou indireta) sobre os requisitos de um ↑sistema. Influência indireta também inclui situações em que uma pessoa ou organização é impactada pelo sistema.

Treinamento Preparatório Exame CPRE-FL by T&M

+O que é Engenharia de Requisitos(ER)

Uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com as seguintes metas:

(1) Conhecer os requisitos relevantes, alcançar um consenso entre os stakeholders a respeito desses requisitos, documentar o acordo com os padrões estabelecidos e gerencia-lo de forma sistemática,

(2) Compreender e documentar os desejos e necessidades dos stakeholders,

(3) Especificar e gerenciar os ↑requisitos para minimizar o risco de entregar um sistema que não atenda aos desejos e necessidades dos stakeholders.

Observação: As três metas contemplam importantes facetas da ER: (1) a orientação para o processo, (2) o foco no stakeholder e (3) a importância das considerações de risco e valor agregado.

+Qualidade

Dimensão que expressa até que

ponto um conjunto de características inerentes a uma entidade atende aos

requisitos.

A entidade pode ser um sistema, um serviço, um produto, um artefato, um processo, uma pessoa ou

uma organização.

Qualidade nessa definição simplesmente significa adequação para algum

uso pretendido, conforme especificado nos

requisitos.

+A importância da Engenharia de Requisitos(ER)

01) A suposição, por parte dos stakeholders, de que muito do assunto é evidente e não precisa ser declarado explicitamente

02) Problemas de comunicação devido a diferentes níveis de experiência e conheciment

03) Pressão do cliente para construção de um sistema rapidamente e disponibilizá-lo em produção

Uma boa ER é importante, pois já a partir desta fase surgem muitos erros, que quanto mais tarde forem corrigidos, maior o custo. Os sintomas típicos de ER inadequada são requisitos vagos e faltantes. Tipicamente as razões para uma ER inadequada são:

Fonte: Jama Software, The State of Requirements Management Report, 2008

Quais as causas

típicas para um projeto não obter sucesso?

Porque é importante o trabalho do ER?

Qual a distribuição

da origem dos defeitos?


do esforço de retrabalho?

requisitos82%

requisitos41% projeto

28%

outros31%

Fonte: Dean Leffingwell, James MartinFonte: U.S. Air Force Project, F. Sheldon, 1992“Reliability Measurement from Theory to Practice”

Smart Hard requisitos projeto construção testes aceite operação

R$150,77

R$376,92

R$753,85

R$1130,77

R$2261,54

R$4900,00

Qual o custo para correção

de um problema em requisitos?

Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)

72% requisitos pobres ou faltantes

Qual o seu diferencial

profissional?

Fonte: Jama Software, The State of Requirements Management Report, 2008

Quais as causas típicas para um

projeto não obter sucesso?

Justificando: Porque é importante o trabalho do ER/Analista de Sistemas?


da origem dos defeitos?


do esforço de retrabalho?

requisitos82%

requisitos41% projeto

28%

outros31%

Fonte: Dean Leffingwell, James MartinFonte: U.S. Air Force Project, F. Sheldon, 1992“Reliability Measurement from Theory to Practice”

Smart Hard requisitos projeto construção testes aceite operação

R$150,77

R$376,92

R$753,85

R$1130,77

R$2261,54

R$4900,00

Qual o custo para correção de um

problema em requisitos?

Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)

72% requisitos pobres ou faltantes

Qual o seu diferencial

profissional?

Exercícios

+Os sintomas e as causas de uma ER inadequada

+ Desempenho de Projetos de Software

Standish Group Chaos Report

+ 17

Fatores que Impactam no Sucesso dos Projetos

Envolvimento dos usuários

15.9%

Apoio executivo 13.9%

Qualidade dos requisitos

13%

Planejamento apropriado

9.6%

Expectativas realistas

8.2%

Milestones pequenos

7.7%

Equipe competente

7.2%

Propriedade 5.3%

Outros 13.9%

Fonte: Chaos Report 2009, Standish Group

+ 18

Principais Causas de Fracassos de Projetos

Requisitos com baixa qualidade

13.1%

Falta de envolvimento

dos Stakeholders

12.4%

Falta de recursos 10.6%

Expectativas não realistas

9.9%

Falta de apoio executivo

9.3%

Mudanças de requisitos

8.7%

Outros 36%

Fonte: Chaos Report 2009, Standish Group

+Porque Engenharia de requisitos

Porque “pau que nasce torto...morre

vergado”

Porque queremos assegurar a

SATISFAÇÃO de nossos CLIENTES

(e a nossa)!

+Número de Requisitos por Projeto

25,4% (< 100)

75% (>100)

34,3% (100 a 500)

20% (500 a 1000)

16,1% (1000 a 5000)

4.3% (> 5000)

12/2010 Jama, industry survey > 800 industries

+Simtomas e causas de erros não detectados em requisitos

Requisitos não claros Os requisitos que não estão claros

são abertos a diferentes interpretações

(incorretos, incompletos e ambíguos)

Omissão de RequisitosNão reflete

precisamente o que o cliente deseja

problemas de comunicação entre os stakeholders

diferenças na experiência e no conhecimento

Deficiência de requisitos devido ao conhecimento implícito

Características evidentes freqüentemente não são

documentadas

+ 22

Requisitos completos e livres de defeitos é a chave para o sucesso

Estabelece uma estratégia de

comunicação que envolve todos as partes interessadas no projeto

Delineia o escopo e responsabilidades do

projeto

Reduz a quantidade e o impacto das mudanças

dos requisitos

Obtém o comprometimento das

partes interessadas através do consenso e

da priorização das necessidades

Viabiliza um entendimento maior sobre o negócio do

cliente

Reduz os custos dos projetos (erros são

descobertos na fase inicial, onde é mais

barato corrigir)

+Metas de Engenharia de Requisitos

(1) Conhecer os requisitos relevantes, alcançar um consenso entre os stakeholders a respeito desses requisitos, documentar o acordo com os padrões estabelecidos e gerenciá-lo de forma sistemática,

(2) Compreender e documentar os desejos e necessidades dos stakeholders,

(3) Especificar e gerenciar os requisitos para minimizar o risco de entregar um sistema que não atenda aos desejos e necessidades dos stakeholders.

+As Principais Atividades

+Principais atividades

• Garantir que são atendidos os critérios de qualidades dos requisitos

• Preparar os requisitos para a utilização

• Descrever os requisitos por Modelos e Linguagem Natural (textos)

• Elicitar e Refinar os requisitos

Elicitação

Documentação

Validação e Negociação

Gerenciamento de requisitos


+O Papel da Comunicação

+Fundamentos da Teoria da Comunicação

Comunicação é Expressão do Conhecimento Baseada em Linguagem

Os efeitos de Foco e Simplificação

são afetados pelo Meio de

Comunicação

Um Código Comum é

necessário para o sucesso da

transmissão da informação


+As Competências Exigidas

OE 1.4 Conhecer as competências exigidas de um engenheiro de requisitos

+Competências para ER

Raciocínio Analítico

Empatia

Resolução de

ConflitosModeraçã

o

Auto-confiança

Persuasão


+Os Tipos de Requisitos OE 1.5 Conhecer os três tipos de requisitos

+Tipos de Requisitos

Requisitos Funcionais

Um ↑requisito relacionado a um resultado de determinado

comportamento a ser fornecido por alguma função

do ↑sistema (ou de um ↑componente ou serviço).

Requisitos Não Funcionais

Requisitos de Qualidade

Um ↑requisito relacionado a uma questão de qualidade

não coberta pelos ↑requisitos funcionais

Restrições

Um ↑requisito que limita o espaço da solução além do que seria necessário para

cumprir os respectivos ↑requisitos funcionais e

↑requisitos de qualidade.


+Exemplos de Requisitos Funcionais

•‘R1: Se um sensor detectar que um painel de vidro de uma janela foi quebrado ou danificado, o sistema deve informar a empresa de segurança.

•R2: O sistema deve gerar um relatório mensal contento todos as solicitações de acessos autorizadas e recusadas para entrar na residência.

•R3: Cada usuário deve logar no sistema com seu nome de usuário e sua senha para usar o sistema.


+Exemplos de Requisitos de Qualidade

•QR1: A senha do usuário armazenada no sistema deve ser protegida contra roubo de senha.

•QR2:O sistema deve responder a entrada do usuário em 1 segundo.


+Exemplos Restrições

•R4: Devido as condições atuais definidas pela empresa de segurança, é permitido somente que o técnico de segurança desative a função de controle do sistema.

•R5: O sistema deve ser implementado usando web services.

•R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012.


+O Papel dos Requisitos de QualidadeOE 1.6 Conhecer o papel dos requisitos de qualidade

+Categorias de Requisitos de Qualidade

Detalhamento de Funcionalidades• As funcionalidades são as capacidades de um ↑sistema conforme expressas

por seus ↑requisitos funcionaisConfiabilidade• A capacidade de um ↑sistema de conservar um nível especificado de

↑funcionalidade e desempenho quando utilizado em condições especificadas.

Usabilidade• A capacidade de um sistema de ser compreendido, aprendido, utilizado e

apreciado por seus ↑usuários.Eficiência• Característica que expressa até que ponto um resultado é alcançado com

mínimo consumo de recursos.Manutenibilidade• A facilidade com que um ↑sistema de software pode ser modificado para

corrigir ↑defeitos ou para adaptar o sistema a diferentes necessidades. Portabilidade• A facilidade com a qual um ↑sistema pode ser transferido para outra

plataforma (ao mesmo tempo preservando sua ↑funcionalidade).

+Requisitos de Qualidade

Requisito de desempenho

• Um ↑requisito que descreve uma característica de desempenho (por exemplo: prazos, velocidade, volume, capacidade, produtividade). • Requisitos de desempenho são considerados uma subcaracterística dos ↑requisitos de qualidade neste glossário, mas podem também

ser considerados uma categoria própria dos ↑requisitos não-funcionais.

Segurança de uso (Safety)

• A capacidade de um ↑sistema de garantir um nível aceitável de probabilidade de que sua operação não resultará em danos físicos, patrimoniais ou ambientais. Em outras palavras, o sistema não oferece perigos.

• Requisitos de segurança (Safety Requirements) podem ser expressos como ↑requisitos de qualidade ou como ↑requisitos funcionais.

Segurança (Security)

• A capacidade de um ↑sistema de proteger (a) seus dados e recursos contra o uso não-autorizado, e de proteger (b) seus legítimos ↑usuários contra ataques de negação de serviço (denial of service). Em outras palavras, o sistema está protegido de perigos.


+Categorias de Requisitos de Qualidade • As funcionalidades são as capacidades de um ↑sistema

conforme expressas por seus ↑requisitos funcionais• Exemplo: Segurança e segurança de uso, acurácia de

cálculo, interoperabilidade e conformidade com padrões.

Detalhamento de Funcionalidades

• A capacidade de um ↑sistema de conservar um nível especificado de ↑funcionalidade e desempenho quando utilizado em condições especificadas.

• Exemplo: Recuperabilidade, Tolerância a falhas.

Confiabilidade

• A capacidade de um sistema de ser compreendido, aprendido, utilizado e apreciado por seus ↑usuários.

• Exemplo: Inteligibilidade, Atratividade.Usabilidade

• Característica que expressa até que ponto um resultado é alcançado com mínimo consumo de recursos.

• Exemplo: Consumo de recursos, comportamento em relação ao tempo.

Eficiência

• A facilidade com que um ↑sistema de software pode ser modificado para corrigir ↑defeitos ou para adaptar o sistema a diferentes necessidades.

• Exemplo: Facilidade de diagnosticar problemas e causas, testabilidade, estabilidade.

Manutenibilidade

• A facilidade com a qual um ↑sistema pode ser transferido para outra plataforma (ao mesmo tempo preservando sua ↑funcionalidade).

• Exemplo: Adaptabilidade, capacidade para ser instalado , capacidade para substituir.

Portabilidade


+Exemplos Requisitos de Qualidade

•QR1: A senha do usuário armazenada no sistema deve ser protegida contra roubo de senha. (integridade)

•QR2:O sistema deve responder a entrada do usuário em 1 segundo (desempenho).

•QR3:O sistema deve ter a capacidade de recuperar os dados perdidos da última operação que realizou em caso de falha (confiabilidade)


+Perguntas?

40

Documents

+ Aula 1 – Introdução e Fundamentos de requisitos (Engenharia de Requisitos) 1.1 Os sintomas e as causas de uma ER inadequada 1.2 As quatro atividades