fatto consultoria e sistemas · software, tratam questões como: frequência e gravidade de falha...

FATTO CONSULTORIA E SISTEMAS

Guilherme Siqueira Simões

13/06/2017

1

Requisitos Não Funcionais

© 2017 FATTO Consultoria e Sistemas | www.fattocs.com

Dê preferência ao uso de uma conexão de banda larga

O evento não fará uso do vídeo (webcam), somente slides e áudio

Se necessário, ajuste o idioma da sala na barra de ferramentas superior

O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas

Você pode mandar suas perguntas pelo chat ao longo da apresentação

Para quem possui a certificação PMP, o evento vale 1 PDU

A apresentação será gravada e o vídeo publicado posteriormente no site e

redes sociais:

ORIENTAÇÕES INICIAIS

2© 2017 FATTO Consultoria e Sistemas | www.fattocs.com

MISSÃO

Estimativas e Medição de Projetos de Software

Implantação da Análise de Pontos de Função (IFPUG, NESMA , COSMIC)

Auditoria de Medições de Projetos de Software Medidos com APF

Benchmarking e Análises de produtividade

Avaliação para Melhoria dos Processos de Software

Engenharia de Requisitos

Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade)

Construção e Monitoramento de Contratos de Software baseados em Resultados

Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando

Métricas Funcionais

DIRECIONAMENTO ESTRATÉGICO COM:

Apoiar nossos clientes a estabelecer modelos de negócios em que eles tenham

o controle e trazer visibilidade do desempenho para a gestão de seus

processos de software.


Engenharia de Requisitos

de Software

24 horas

Estimativa de Software:

Fundamentos e Técnicas

24 horas (EAD e presencial)

Oficina de Contagem

de Pontos de Função

Sessões de 8 ~ 40 horas

Gestão de Riscos em

Projetos

16 horas

Oficina de Requisitos

Sessões de 8 ~ 40 horas

Introdução ao

Gerenciamento de Projetos

16 horas

Medição e Estimativa de

Software com o Método

COSMIC

16 horas (Presencial)

Preparação para

o Exame CFPS


APF: Fundamentos,

Benefícios e Implantação


Capacitação em APF:

Medição e

Estimativa de Software

16 horas (EAD e

presencial)

Workshop APF:

Metodologia

e Práticas de Medição

16 horas (Presencial)

FORMAÇÃO PROFISSIONAL

Preparação para

o Exame COSMIC



Agenda

As duas dimensões do software

Requisitos funcionais

Requisitos não funcionais

ISO/IEC 25010

FURPS+

Checklists


• Os requisitos do software subdividem-se em:

Duas dimensões do software

Descrevem o quê o software faz: processos ou tarefas da solução (e

da transição) que suportam uma prática ou procedimento de uma

parte interessada

Expressam atributos ou restrições inerentes aos

requisitos funcionais e comoeles serão atendidos

Não

Funcionais

“como”

“o quê”

Funcionais


• Descrevem o quê a solução (ou transição) deve fazer

em termos das tarefas ou serviços do usuário

• Não aborda a implementação

• Doc. Visão

• Lista requisitos

• Historia usuário

• Caso de Uso

• Modelos

Requisitos Funcionais


Níveis de Objetivo dos RFs(Granularidade)

https://youtu.be/WDNrLH7vwgQ

Efetuar gestão dos cursos

Emitir certificado de participação

Somente alunos com frequência ≥ 75% podem emitir seu certificado


https://youtu.be/WDNrLH7vwgQ

•Abordam COMO as funcionalidades serão

oferecidas ao usuário

• Incluem aspectos relacionados a

– Qualidade: usabilidade, confiabilidade, eficiência, portabilidade,

facilidade de manutenção

– Implementação: plataforma de software, hardware, linguagem

de programação.

– Ambiente: interoperabilidade, segurança, privacidade, sigilo

– Organização: locais para operação, hardware alvo, aderência a

padrões. Exemplo de padrões no governo federal:

• Padrões Web em Governo Eletrônico – e-PWG

• Modelo de Acessibilidade de Governo Eletrônico – e-Mag

• Arquitetura de Interoperabilidade de Governo Eletrônico – e-PING

Requisitos Não Funcionais – O que


• Em geral costuma-se ter boa visibilidade destes requisitos

já em fases iniciais do projeto

• Costumam ser constante entre os projetos, ou mudam

pouco de um projeto para outro na mesma organização, o

que também facilita sua identificação

• Em geral são menos numerosos que os Requisitos

Funcionais

• Para organizações que possuem uma metodologia

madura de desenvolvimento de software, a identificação de

boa parte dos RNFs fica facilitada pois muitos aspectos

técnicos e de qualidade dos projetos são padronizados

pela metodologia



•A classificação dos tipos de requisitos não funcionais é útil

para apoiar o seu trabalho de identificação

•Não há consenso na literatura quanto à essa classificação

–Cada organização pode definir categorias para o seu

contexto

•Alguns modelos podem ser usados para essa definição

local:

– ISO/IEC 25010 (SQUaRE)

– FURPS e FURPS+

• Não se preocupe se classificar incorretamente o requisito;

o importante é que ele seja identificado!



Qualidade do Sistema/Software

Adequação Funcional

CompletudeFuncional

Correção Funcional

ConformidadeFuncional

Eficiência

Tempo de resposta

Utilização de Recursos

Capacidade

Compatibilidade

Coexistência

UsabilidadeConfiabilidade

SegurançaPortabilidade

Manutenibilidade

Reconhecimento Adequado

Facilidade de Aprendizado

Operabilidade

Proteção aErros de Usuário

Estética da Interface

Acessibilidade

Maturidade

Disponibilidade

Tolerância a erros

Recuperabilidade

Confidencialidade

Integridade

Irrefutabilidade

Responsabilidade

Autenticidade

Modularidade

Reusabilidade

Análise

Mudanças

Teste

Adaptação

Instalação

TrocaInteroperabilidade

ISO/IEC 25010SQuaRE (Systems and software Quality Requirements and

Evaluation)


Functionality (Funcionalidade)

Usability (Usabilidade)

Reliability (Confiabilidade)

Performance (Desempenho)

Supportability (Suportabilidade)

FURPS e FURPS+

Parte do IBM Rational Unified Process (RUP)

Já abordado

anteriormente

+

Restrições de projeto

Restrições de implementação

Restrições de interface

Restrições físicas


Avalia a facilidade de uso. Possui diversas

subcategorias, entre elas:

Fatores humanos

Estética

Consistência na interface do usuário

Ajuda on-line e contextual

Assistentes

Documentação

Materiais de treinamento

Exemplos:

A leitura do código de barras deve ser automática para diminuir a

digitação de dados, agilizando a transação e evitando erros

Documentação quanto ao uso e funcionamento deve ser fornecido por

meio de ajuda on-line aos agentes arrecadadores

FURPS - Usabilidade


Integridade, conformidade e interoperabilidade do

software, tratam questões como:

Frequência e gravidade de falha

Possibilidade de recuperação

Previsibilidade

Exatidão

Tempo médio entre falhas

Exemplos:

O Word recupera documento não salvo após desligamento inesperado do

computador

Se o processo de importação de contas arrecadadas for interrompido por

uma falha, o sistema deve permitir recuperar os dados já importados e

continuar a partir do ponto em que ocorreu a falha

FURPS - Confiabilidade


Usa como medida diversos aspectos da

aplicação, entre eles

Velocidade

Eficiência

Taxa de transferência

Tempo de resposta

Uso de recursos

Exemplos:

O sistema deve suportar até 100 usuários simultâneos sem se

degradar

O tempo de resposta de qualquer tela do sistema não deve exceder 2

segundos

FURPS - Desempenho


Facilidade de efetuar mudanças no sistema após sua

entrega. Agrupam várias características como:

Exemplos:

A instalação do software deve ser realizada de forma semiautomática,

ou seja, com o mínimo de intervenção humana

A solução deve oferecer suporte aos idiomas: inglês, português e

espanhol

O sistema deve rodar em browser Internet Explorer, Firefox e Chrome

FURPS - Suportabilidade

Testabilidade Configurabilidade

Adaptabilidade Instalabilidade

Manutenibilidade Escalabilidade

Compatibilidade Localizabilidade



O que é Checklist?

O uso de Checklist, ou também chamado de lista de verificação, é uma das técnicas mais eficazes para levantar requisitos não funcionais

Consiste em um conjunto de perguntas/afirmações que tratam sobre o critério de qualidade de um determinado artefato de software

Proporciona uma forma estruturada para a identificação de erros em projetos, evidenciando que uma ou mais questões da lista não foram atendidas

O conjunto de questões abordadas na lista refletem lições aprendidas de projetos passados e boas práticas de mercado

18


Surgimento dos Checklists

A técnica Checklist surgiu durante a fase final de avaliações de aeronaves sob a especificação do Exército dos EUA, em 1934

Um acidente em um voo de teste foi o gatilho para a adoção de checklist

Quatro listas de verificação (Checklists) foram desenvolvidas: decolagem, voo, antes do pouso e após o desembarque

Com seu uso, um planejamento cuidadoso e rigoroso treinamento, a aeronave conseguiu voar 290 mil km sem um único acidente

19


Exemplo Checklist para Confiabilidade

Pergunta Observação

1. O software terá usuários externos à empresa?

2. O software deverá funcionar apenas em dias úteis e horário comercial?

3. O funcionamento do software deverá ser 24x7?

4. É necessário prover alguma contingência em caso de falha de alguma interface externa?

5. É aceitável interromper a operação para atualização de versão do software?

6. Há algum processo que pode degradar o desempenho do software e prejudicar a operação normal?

…

20


Exemplo Checklist para Desempenho

Pergunta Observação

1. Qual é o tempo médio (em segundos) de resposta para transações interativas? (Duração entre o comando de início e a resposta final)

2. Qual é a quantidade de transações processadas por minuto (throughput)?

3. Quanto tempo de CPU se utiliza para concluir uma transação em relação ao tempo total?

4. Quanto tempo de E/S se utiliza para concluir uma transação com respeito ao tempo total?

5. Quantas solicitações de transações online podem ser processadas por segundo?

6. Quantos usuários podem acessar o sistema de maneira simultânea por minuto?

…

21


Benefícios do Checklist

Projetos que utilizam checklists economizam tempo da

equipe

Checklists são facilmente delegáveis

Permitem o compartilhamento de conhecimento e

experiência entre os membros da equipe

Padronizam a execução da atividade de levantamento

São simples de se aplicar

22

• O requisito não funcional descreve o COMO as

funcionalidades são entregues ao usuário

• Boa visibilidade em etapas iniciais do projeto

• Mudam pouco entre projetos da mesma

empresa

• A categorização ajuda na sua identificação

• Podem ser facilmente levantados via checklists

Conclusão


Para saber mais

• Curso: Engenharia de Requisitos: Software Orientado ao

Negócio

– http://www.fattocs.com/pt/ereq-ead

– Vitória: 26 a 28/06

– Brasília: 04 a 06/07

– Fortaleza: 07 a 11/08

– São Paulo: 22 a 24/08

– Rio de Janeiro: 19 a 21/09

– Belo Horizonte: 02 a 06/10


http://www.fattocs.com/pt/ereq-ead

AVALIAÇÃO DO EVENTO


PRÓXIMOS EVENTOS

• WEBINARS:

Tutorial prático da análise dos pontos de função IFPUG de um app

Google

Data: 04/07/17 às 20h Inscrição: https://goo.gl/yz3YVU

Visão prática do BDD (Behaviour Driven Design) para agilizar o

processo de desenvolvimento

Data: 16/08/17 às 20h Inscrição: https://goo.gl/DV0Rza


https://goo.gl/yz3YVU

https://goo.gl/DV0Rza

PERGUNTAS?

Brasília: (61) 4063-7484

São Paulo: (11) 4063-4658

Vitória: (27) 3026-6304

Rio de Janeiro: (21) 4063-5311

Obrigado pela sua atenção!

Guilherme Siqueira Simõ[email protected]

www.linkedin.com/in/guilhermesimoes

Skype: guilherme.s.simoes


fatto consultoria e sistemas · software, tratam questões como: frequência e gravidade de falha...

Documents