1.1 Os sintomas e as causas de uma ER inadequada

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 principais da ER 1.3 O papel da comunicação na ER 1.4 As competências exigidas de um engenheiro de requisitos 1.5 Os três tipos de requisitos 1.6 O papel dos requisitos de qualidade Test Approach OH-Trade by T&M V.1.0

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

O problema da PEDRA 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. Quando você lhe entrega a pequena pedra azul, verifica que o cliente realmente desejava era uma pequena pedra esférica e azul.

O problema da PEDRA 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.

O problema da PEDRA 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ças Normalmente 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. Requisito Funcional: Um requisito relacionado a um sistema ou componente de um sistema. Requisito de Qualidade: Um requisito relacionado a uma questão de qualidade não coberta pelos requisitos funcionais. Restrição: 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. Destaques: Em contraste com os requisitos funcionais ou requisitos de qualidade, as restrições não são implementadas. As restrições não pode ser influenciada pelo team de desenvolvimento.

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. Requisito Funcional: Um requisito relacionado a um sistema ou componente de um sistema. Requisito de Qualidade: Um requisito relacionado a uma questão de qualidade não coberta pelos requisitos funcionais. Restrição: 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. Destaques: Em contraste com os requisitos funcionais ou requisitos de qualidade, as restrições não são implementadas. As restrições não pode ser influenciada pelo team de desenvolvimento. 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. Requisito Funcional: Um requisito relacionado a um sistema ou componente de um sistema. Requisito de Qualidade: Um requisito relacionado a uma questão de qualidade não coberta pelos requisitos funcionais. Restrição: 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. Destaques: Em contraste com os requisitos funcionais ou requisitos de qualidade, as restrições não são implementadas. As restrições não pode ser influenciada pelo team de desenvolvimento.

A importância da Engenharia de Requisitos(ER)
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: 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

Porque é importante o trabalho do ER?
Quais as causas típicas para um projeto não obter sucesso? Qual a distribuição da origem dos defeitos? Qual a distribuição do esforço de retrabalho? requisitos 41% 72% projeto 28% requisitos pobres ou faltantes outros 31% requisitos 82% Fonte: U.S. Air Force Project, F. Sheldon, 1992 “Reliability Measurement from Theory to Practice” Fonte: Jama Software, The State of Requirements Management Report, 2008 Fonte: Dean Leffingwell, James Martin 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 Smart Hard Qual o custo para correção de um problema em requisitos? Qual o seu diferencial profissional? Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)

Justificando: Porque é importante o trabalho do ER/Analista de Sistemas?
Exercícios Quais as causas típicas para um projeto não obter sucesso? Qual a distribuição da origem dos defeitos? Qual a distribuição do esforço de retrabalho? requisitos 41% 72% projeto 28% requisitos pobres ou faltantes outros 31% requisitos 82% Fonte: U.S. Air Force Project, F. Sheldon, 1992 “Reliability Measurement from Theory to Practice” Qual o custo para correção de um problema em requisitos? Fonte: Jama Software, The State of Requirements Management Report, 2008 Fonte: Dean Leffingwell, James Martin 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 Smart Hard Qual o seu diferencial profissional? Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)

Os sintomas e as causas de uma ER inadequada
Duração: 1 hora e 15 minutos Termos: Requisito, Stakeholder, Engenharia de Requisitos, Requisito Funcional, Requisito de Qualidade, Restrição Objetivos de Aprendizagem: OA 1.1 Conhecer os sintomas e as causas de uma ER inadequada OA 1.2 Conhecer as quatro atividades principais da ER OA 1.3 Conhecer o papel da comunicação na ER OA 1.4 Conhecer as competências exigidas de um engenheiro de requisitos OA 1.5 Conhecer os três tipos de requisitos OA 1.6 Conhecer o papel dos requisitos de qualidade Engenharia de Requisitos Uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com as seguintes metas: (1) Conhecer os requisitos relevantes, construir um consenso entre os stakeholders a respeito desses requisitos, documentar os requisitos de acordo com determinadas normas e padrões e gerenciar os requisitos de forma sistemática. (2) Conhecer 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. Requisito Uma necessidade percebida por um stakeholder. Uma capacidade ou propriedade que um sistema deverá ter. Uma representação documentada de uma necessidade, capacidade ou propriedade. Stakeholder Uma pessoa ou organização que exerce influencia (direta ou indireta) sobre os requisitos de um sistema.

Desempenho de Projetos de Software
Standish Group Chaos Report

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 Envolvimento do usuário: 15.9% Apoio executivo: 13.9% Declaração de requisitos clara e limpa: 13% Planejamento apropriado: 9.6% Expectativas realistas: 8.2% Milestones pequenos: 7.7% Equipe competente: 7.2% Propriedade: 5.3% Visão e objetivos claros: 2.9% Trabalho duro e equipe focada: 2.4% Outros: 13.9% Fonte: Chaos Report 2009, Standish Group

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% Outros: Falta de planejamento: 8.1% Não precisa mais daquilo: 7.5% Falta de gestão da TI: 6.2% Analfabetismo tecnológico: 4.3% Outros: 9.9% Total: 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
(< 100) 25,4% 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 Omissão de Requisitos Nã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 (incorretos, incompletos e ambíguos)

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. 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. Abreviação: ER 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.

As Principais Atividades

Principais atividades
Elicitação Elicitar e Refinar os requisitos Documentação Descrever os requisitos por Modelos e Linguagem Natural (textos) Validação e Negociação Garantir que são atendidos os critérios de qualidades dos requisitos Gerenciamento de requisitos Preparar os requisitos para a utilização Elicitação: Diferentes técnicas são usadas para obter os requisitos dos stakeholders e de outras fontes, afim de refinar os requisitos em mais detalhes. Documentação: Os requisitos elicitados são descritos adequadamente. Validação e Negociação: Para garantir que um critério de qualidade pre-definido seja encontrado. Gerenciamento; é otogonal a todas as atividades Treinamento Preparatório Exame CPRE-FL by T&M

O Papel da Comunicação Engenharia de Requisitos

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 Codigo comum : glossário Linguagem comum : linguagem natural ou UML Meio de comunicação : verbal ou diagramas Código Comum: Para que a transmissão de informação de um individuo para outro trabalhe corretamente, um código comum é necessário. O emissor tem codificar a sua mensagem e o receptor tem de decodificar a mensagem Alcançado: base de conhecimento, glossário e linguagens de modelo Meio de comunicação: Na comunicação verbal, o sucesso da comunicação recai sobre redundâncias, como linguagem e gestos ou linguagem e entonação, Treinamento Preparatório Exame CPRE-FL by T&M

As Competências Exigidas
Duração: 1 hora e 15 minutos Termos: Requisito, Stakeholder, Engenharia de Requisitos, Requisito Funcional, Requisito de Qualidade, Restrição Objetivos de Aprendizagem: OA 1.1 Conhecer os sintomas e as causas de uma ER inadequada OA 1.2 Conhecer as quatro atividades principais da ER OA 1.3 Conhecer o papel da comunicação na ER OA 1.4 Conhecer as competências exigidas de um engenheiro de requisitos OA 1.5 Conhecer os três tipos de requisitos OA 1.6 Conhecer o papel dos requisitos de qualidade Engenharia de Requisitos Uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com as seguintes metas: (1) Conhecer os requisitos relevantes, construir um consenso entre os stakeholders a respeito desses requisitos, documentar os requisitos de acordo com determinadas normas e padrões e gerenciar os requisitos de forma sistemática. (2) Conhecer 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. Requisito Uma necessidade percebida por um stakeholder. Uma capacidade ou propriedade que um sistema deverá ter. Uma representação documentada de uma necessidade, capacidade ou propriedade. Stakeholder Uma pessoa ou organização que exerce influencia (direta ou indireta) sobre os requisitos de um sistema. OE 1.4 Conhecer as competências exigidas de um engenheiro de requisitos

Resolução de Conflitos
Competências para ER Raciocínio Analítico Empatia Resolução de Conflitos Moderação Auto-confiança Persuasão Treinamento Preparatório Exame CPRE-FL by T&M

Os Tipos de Requisitos Engenharia de Requisitos
Duração: 1 hora e 15 minutos Termos: Requisito, Stakeholder, Engenharia de Requisitos, Requisito Funcional, Requisito de Qualidade, Restrição Objetivos de Aprendizagem: OA 1.1 Conhecer os sintomas e as causas de uma ER inadequada OA 1.2 Conhecer as quatro atividades principais da ER OA 1.3 Conhecer o papel da comunicação na ER OA 1.4 Conhecer as competências exigidas de um engenheiro de requisitos OA 1.5 Conhecer os três tipos de requisitos OA 1.6 Conhecer o papel dos requisitos de qualidade Engenharia de Requisitos Uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com as seguintes metas: (1) Conhecer os requisitos relevantes, construir um consenso entre os stakeholders a respeito desses requisitos, documentar os requisitos de acordo com determinadas normas e padrões e gerenciar os requisitos de forma sistemática. (2) Conhecer 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. Requisito Uma necessidade percebida por um stakeholder. Uma capacidade ou propriedade que um sistema deverá ter. Uma representação documentada de uma necessidade, capacidade ou propriedade. Stakeholder Uma pessoa ou organização que exerce influencia (direta ou indireta) sobre os requisitos de um sistema. OE 1.5 Conhecer os três tipos de requisitos

Tipos de Requisitos Requisitos Funcionais Requisitos Não 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. Requisito Funcional: Um requisito relacionado a um sistema ou componente de um sistema. Requisito de Qualidade: Um requisito relacionado a uma questão de qualidade não coberta pelos requisitos funcionais. Restrição: 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. Destaques: Em contraste com os requisitos funcionais ou requisitos de qualidade, as restrições não são implementadas. As restrições não pode ser influenciada pelo team de desenvolvimento. Treinamento Preparatório Exame CPRE-FL by T&M

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. 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

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. 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

Exemplos Restrições Requisitos Funcionais Requisitos de Qualidade
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. 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

O Papel dos Requisitos de Qualidade
Duração: 1 hora e 15 minutos Termos: Requisito, Stakeholder, Engenharia de Requisitos, Requisito Funcional, Requisito de Qualidade, Restrição Objetivos de Aprendizagem: OA 1.1 Conhecer os sintomas e as causas de uma ER inadequada OA 1.2 Conhecer as quatro atividades principais da ER OA 1.3 Conhecer o papel da comunicação na ER OA 1.4 Conhecer as competências exigidas de um engenheiro de requisitos OA 1.5 Conhecer os três tipos de requisitos OA 1.6 Conhecer o papel dos requisitos de qualidade Engenharia de Requisitos Uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com as seguintes metas: (1) Conhecer os requisitos relevantes, construir um consenso entre os stakeholders a respeito desses requisitos, documentar os requisitos de acordo com determinadas normas e padrões e gerenciar os requisitos de forma sistemática. (2) Conhecer 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. Requisito Uma necessidade percebida por um stakeholder. Uma capacidade ou propriedade que um sistema deverá ter. Uma representação documentada de uma necessidade, capacidade ou propriedade. Stakeholder Uma pessoa ou organização que exerce influencia (direta ou indireta) sobre os requisitos de um sistema. OE 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 funcionais Confiabilidade 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 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento).

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. 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

Categorias de Requisitos de Qualidade
Detalhamento de Funcionalidades 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. Confiabilidade 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. Usabilidade A capacidade de um sistema de ser compreendido, aprendido, utilizado e apreciado por seus ↑usuários. Exemplo: Inteligibilidade, Atratividade. Eficiência 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. Manutenibilidade 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. Portabilidade 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. 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

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) 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. Requisitos de Qualidade R3:O sistema deve responder a entrada do usuário em 1 segundo (requisito de qualidade – desempenho). Restrições Restrição organizacional 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 (Restrição organizacional). Restrição do próprio sistema R5: O sistema deve ser implementado usando web services (Restrição do próprio sistema). Restrição do processo de desenvolvimento R6: O sistema deve estar disponível para o mercado no final do segundo quadrimestre de 2012 (Restrição do processo de desenvolvimento). Treinamento Preparatório Exame CPRE-FL by T&M

Perguntas? 40

1.1 Os sintomas e as causas de uma ER inadequada

Apresentações semelhantes

Apresentação em tema: "1.1 Os sintomas e as causas de uma ER inadequada"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

1.1 Os sintomas e as causas de uma ER inadequada

Apresentações semelhantes

Apresentação em tema: "1.1 Os sintomas e as causas de uma ER inadequada"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback