Engenharia de requisitos

Engenharia de

Requisitos Mailson de Queiroz Proença

Tópicos

A Engenharia de Requisitos

Importância da Engenharia de Requisitos

O que são requisitos?

Requisitos de usuário e de sistema

Funcionais e não funcionais

Documento e Especificação de requisitos

Desenvolvimento de requisitos

Estudo de viabilidade

Elicitação e análise de requisitos

Validação de requisitos

Gerenciamento de requisitos

Principais eventos

Conclusão


É o ramo da engenharia de software que se

preocupa com:

os objetivos, funções e restrições dos sistemas de

software.

É também o processo de estabelecer quais

serviços e restrições são necessários na

operação e desenvolvimento de um sistema.


Engenharia de Requisitos pode ser dividida em:

Desenvolvimento de Requisitos:

Elicitação

Análise

Especificação

Validação

Gerência de Requisitos

Gerência de Mudanças

Acompanhamento de desenvolvimento e

implementação dos requisitos

Importância da Engenharia de

Requisitos

Alguns fatos

Um trabalho consistente de análise dos requisitos é a

BASE de um projeto de SOFTWARE DE SUCESSO;

Corrigir problemas na fase de especificação de

requisitos pode gerar uma economia até 200 vezes

maior do que em etapas posteriores.


Requisitos

“Entender os requisitos de um problema está entre as

tarefas mais difíceis enfrentadas por um engenheiro de

software.” (Pressman, 2011)


Requisitos Segundo pesquisa realizada pelo Standish Group* as principais

razões que levam a problemas de projeto são identificadas no

gráfico:

* http://blog.standishgroup.com/

0 5 10 15 20 25

23

12,8

12,3

11,8

7,5

7

6,4

5,9

5,3

4,3

3,7

% de Respostas

Fato

res

de P

roje

tos

Crí

ticos


São o ponto de partida para toda a definição

de um sistema.

Fatores decisivos no desenvolvimento do

produto final de um projeto de software.

“Capacidade que o software tem e que o

usuário precisa a fim de resolver um problema

e atingir seu objetivo.” (Dorfman e Thayer -

1990)


Um requisito pode variar de:

Uma declaração abstrata de alto nível de um serviço

a

Uma restrição do sistema para uma especificação

matemática funcional.

Níveis de Requisitos

Requisitos de usuário:

são declarações em uma linguagem natural com

diagramas de quais serviços o sistema deverá

fornecer a seus usuários e as restrições com as quais

este deve operar.

Requisitos de sistema

são descrições mais detalhadas das funções, serviços

e restrições operacionais do sistema de software.

Identificação dos Interessados

Além do cliente e o do desenvolvedor, que podem,

naturalmente, ter diferentes nomes e títulos, existem

provavelmente:

O pessoal de marketing,

O pessoal de testes e garantia de qualidade.

Gerentes de produtos.

Gerente geral.

E uma variedade de “stakeholders” (interessados) que no seu

dia-a-dia serão afetados pelo desenvolvimento do novo

sistema.


Sommerville – 1997 define interessados como:

“Qualquer um que se beneficia de forma direta

ou indireta do sistema que está sendo

desenvolvido.”


Dificuldades:

Cada interessado:

Tem uma visão diferente do sistema;

Obtém diferentes benefícios quando o sistema é

desenvolvido com êxito;

E está sujeito a diferentes riscos caso o trabalho de

desenvolvimento venha a fracassar.


Reconhecimento de diversos pontos de vista:

Gerentes Comerciais

Estão interessados no conjunto de recursos que pode ser

construído dentro do orçamento e que estarão prontos

para atender às oportunidades definidas de ingresso no

mercado.

Pessoal do Marketing

Estão interessados nas funções e recursos que irão suscitar

o mercado potencial, facilitando a venda do sistema.

Busca de Colaboração

Primeiro: identificar áreas em comum

requisitos com os quais os interessados concordam

Segundo: identificar áreas de conflito

requisitos desejados por um interessado, mas que

conflitam com os de outros interessados.

Busca de Colaboração

Colaboração não significa, necessariamente,

que os requisitos são definidos por um

comitê.

Normalmente existe um “poderoso campeão

dos projetos ” (gerente comercial ou técnico

sênior) que pode tomar a decisão final sobre

quais requisitos que passam pelo corte.

Classificação de Requisitos

Com uma breve observação percebemos que há

uma infinidade de objetos envolvidos que são

requisitos de software, os quais devem ser

classificados em dois grandes grupos...

Requisitos Funcionais;

Requisitos Não Funcionais.


Requisitos Funcionais:

Descrevem as funcionalidades e/ou serviços do sistema;

Descrevem como o sistema deve reagir a entradas

específicas;

Podem ser declarações de alto nível do que o sistema

deve fazer;

Devem descrever os serviços de sistema em detalhes;

O que o sistema não deve fazer;

Exemplos de requisitos funcionais

O sistema deve permitir que qualquer usuário possa

consultar e visualizar o perfil de outro usuário do

sistema.

O sistema deve permitir a inclusão, alteração e inativação

dos usuários do sistema.

O sistema deve permitir aos usuários do tipo gerente

visualizar relatórios de projetos em aberto e/ou

finalizados, e seus respectivos feedbacks.

Imprecisão de requisitos

Problemas surgem quando os requisitos não são

precisamente definidos.

Requisitos ambíguos podem ser interpretados de

maneiras diferentes pelos desenvolvedores e

usuários.

Considere o termo “telas apropriadas”:

Intenção do usuário - telas para cada formato de

documento devem ser disponibilizadas.

Intenção do desenvolvedor - disponibilizar uma tela de

texto que mostra o conteúdo do documento.

Requisitos completos e consistentes

A princípio, todos os requisitos devem ser completos e

consistentes:

Completos: Todas as funções requeridas pelo usuário

devem estar definidas.

Consistentes: Não deve haver conflitos ou contradições

nas descrições dos recursos de sistema.

Na prática, é quase impossível produzir um documento de

requisitos completos e consistentes.


Requisitos Não Funcionais:

Definem propriedades e restrições do sistema;

Dizem respeito ao sistema como um todo;

Muitos requisitos não funcionais são também requisitos de

qualidade, como confiabilidade, tempo de resposta e

espaço em disco;

Outros são restrições ou exigências de uso de tecnologia.


Classificação dos Requisitos Não Funcionais:

Especificam ou restringem

o comportamento do

software.

Derivados das políticas e

procedimentos da

organização do cliente e

do desenvolvedor.

Derivados de fatores externos

ao sistema e seu processo.

Exemplos de requisitos não

funcionais

Requisito de Produto:

O sistema deve ser capaz de responder até, em média, a 10

requisições por segundo.

Requisito Organizacional:

Todos os documentos entregues devem seguir o padrão de relatórios

XYZ-00.

Requisito Externo:

O sistema não deve revelar quaisquer informações pessoais sobre os

usuários do sistema, com exceção do nome e número de referência

da biblioteca.


Métricas para elecitar Requisitos Não Funcionais:

Velocidade:

Transações processadas/segundo;

Tamanho:

Megabytes;

Facilidade de uso:

Tempo de treinamento;

Número de frames de ajuda;


Métricas para elicitar Requisitos Não Funcionais:

Confiabilidade:

Probabilidade de indisponibilidade;

Taxa de ocorrência de falhas;

Robustez:

Tempo de reinício após falha;

Percentual de eventos que causam falhas;

Probabilidade de corrupção de dados em caso de falha;

Portabilidade:

Percentual de declarações dependentes do sistema-alvo;

Documento de requisitos de software

e Especificação de requisitos



Variabilidade do documento de requisitos

As informações no documento de requisitos dependem do tipo de

sistema e da abordagem de desenvolvimento usada.

Normalmente, os sistemas desenvolvidos de forma incremental

terão menos detalhes no documento de requisitos.

Os padrões dos documentos de requisitos foram

concebidos, tendo como exemplo, a norma IEEE Std 830-

1998.

Esses são aplicáveis, principalmente, aos requisitos para projetos

de engenharia de sistemas de grande porte.



Requisitos e Métodos ágeis

A produção de um documento de requisitos é um desperdício

de tempo pois esses mudam rapidamente.

Portanto, o documento estará sempre desatualizado.

O XP, por exemplo, usa a engenharia de requisitos incremental

e expressa os requisitos como “estórias de usuário”.

Prático para os sistemas de negócios e problemático para

sistemas que exigem várias análises pré-entrega (por

exemplo, sistemas críticos) ou sistemas desenvolvidos por

várias equipes.



O documento de requisitos tem um conjunto

diversificado de usuários:

Desde a alta administração da organização que está

pagando pelo sistema.

Até os engenheiros responsáveis pelo

desenvolvimento do software.


e Especificação de requisitos Especificação:

É o processo de escrever os requisitos de usuário e de sistema em

um documento de requisitos.

Idealmente, os requisitos de usuário e de sistema devem

ser:

Claros

Inequívocos

De fácil compreensão

Consistentes

Completos

Processos de engenharia de

requisitos

Os processos de engenharia de requisitos

podem incluir quatro atividades de alto nível:

Estudo de viabilidade;

Elicitação e Análise;

Especificação;

Validação.


requisitos

Estudo da

viabilidade

Relatório de

viabilidade

Validação de

requisitos

Especificações

de requisitos

Requisitos de usuários e

de sistema

Elicitação e

análise de

requisitos

Modelos

de sistema

Documentação de

requisitos


requisitos

Estudo de Viabilidade

Decidir se vale a pena ou não gastar tempo e esforço com o

sistema proposto;

Sistemas novos devem começar com um estudo da viabilidade;

Responder Perguntas:

O sistema contribui para os objetivos gerais da organização?

O sistema pode ser implementado com a tecnologia atual dentro das

restrições de custo e de prazo?

O sistema pode ser integrado a outros?

Que contribuição direta o sistema trará para os objetivos da empresa?

Relatório de Viabilidade

O relatório pode:

Propor mudanças no enfoque, no orçamento e/ou no

cronograma;

Sugerir outros requisitos de alto nível para o

sistema;

Simplesmente cancelar o projeto de

desenvolvimento do sistema.

Elicitação e análise de requisitos

Reúne informações sobre o sistema proposto e os

existentes.

O objetivo é descobrir:

O domínio de aplicação;

Serviços que devem ser fornecidos pelo sistema;

Restrições associadas ao domínio ou serviços;

Envolvem diversos stakeholders;

Atividades da Elicitação e análise de

requisitos

1. Descoberta de Requisitos

2. Classificação e organização de requisitos

3. Priorização e negociação de requisitos

4. Especificação de requisitos

Obtendo os requisitos

Técnicas para levantamento de requisitos:

Descoberta de Requisitos(Pontos de vista)

Entrevistas

Cenários

Casos de Uso

Etnografia

Descoberta de Requisitos

Processo que reúne informações sobre o sistema

proposto e os existentes para obter os requisitos de

usuário e de sistema.

Em uma empresa de tamanho médio ou grande, existem

vários stakeholders;

Cada stakeholder tem um ponto de vista diferente

Cada um vê o problema de modo diferente;

Objetivo: conhecer o problema por várias perspectivas.

Descoberta de Requisitos

Stakeholders frequentemente:

Não sabem na realidade o que querem;

Não conseguem expressar claramente o que

desejam;

Fazem pedidos não realistas;

Se expressam com seus próprios termos (técnicos).

Diferentes stakeholders expressam o mesmo

requisito de forma diferente.




Entrevistas

Cenários

Casos de Uso

Etnografia

Entrevistas

Questionar os stakeholders sobre o sistema (ou

processo) atual e sobre o sistema que será

desenvolvido;

Tipos de entrevistas:

Entrevistas fechadas: conjunto pré-definido de

perguntas;

Entrevistas abertas: sem agenda pré-definida; se

adapta para explorar o conhecimento do stakeholder.




Entrevistas

Cenários

Casos de Uso

Etnografia

Cenários

Descreve uma situação de uso do sistema;

Inclui informações como:

Nome do Cenário;

Ator;

Pré-condição;

Fluxo normal;

Fluxos alternativos;

Pós-condição.

Exemplo de Cenário

Nome do Cenário: Sacar dinheiro

Ator: Correntista

Pré-condição: Conta e senha validada

Fluxo normal:

Entrar com valor do saque

Confirmar dados e operação

Debitar valor da conta do cliente

Fluxos alternativo: Saldo insuficiente

Apresentar aviso ao cliente

Pós-condição:

Valor sacado é debitado do saldo do cliente




Entrevistas

Cenários

Casos de uso

Etnografia

Casos de Uso

Introduzida inicialmente no método Objectory

(JACOBSON et al., 1993).

Em sua forma mais simples, identificam:

Os atores envolvidos;

As funcionalidades principais;

A interação entre atores e funcionalidades do sistema.

Casos de Uso

Retirar

Dinheiro

Transferir

Fundos

Depositar

Fundos

Inicializar

o Sistema

Cliente

Operador de

Caixa Eletrônico

Sistema Bancário

Descrição textual;




Entrevistas

Cenários

Casos de uso

Etnografia

Etnografia

É uma técnica de observação utilizada para

compreender os processos operacionais;

O analista (engenheiro de requisitos) se insere

na organização do cliente:

Observa o trabalho no dia a dia;

Anota as tarefas dos funcionários.

Etnografia

É eficaz para descobrir:

maneira como as pessoas realmente trabalham;

da cooperação e conscientização das atividades de

outras pessoas;

Desenvolver um protótipo;

Revelar detalhes importantes que são

ignorados por outras técnicas.

Validação de Requisitos

Custos de erros de requisitos são altos, desse

modo, a validação é muito importante.

Validar é:

Demonstrar se os requisitos definem o sistema que o

cliente realmente quer.


Os diferentes tipos de validação que devem ser

efetuados:

Validade

O sistema fornece as funções que melhor atendem às

necessidades do cliente?

Consistência

Existe algum conflito de requisitos?

Completude

Estão incluídas todas as funções e restrições requeridas pelo

cliente ?


Os diferentes tipos de validação que devem ser

efetuados:

Realismo

Os requisitos podem ser implementados com o

orçamento e a tecnologia disponíveis?

Verificabilidade

Os requisitos podem ser verificados? Pode ser escrito

um conjunto de testes que demonstrem que o sistema

atende a cada requisitos especificado.


Técnicas de Validação de Requisitos:

Revisões de requisitos

Análise manual sistemática dos requisitos.

Prototipação

Usando um modelo executável do sistema para verificar

os requisitos.

Geração de casos de teste

Desenvolvimento de testes para verificar os requisitos

implementados.

Gerenciamento de Requisitos

Usuários muitas vezes mudam os requisitos ou “não sabem

o que querem”...

Requisitos são, inevitavelmente, incompletos e

inconsistentes:

Novos requisitos surgem durante o processo, à medida

que as necessidades de negócio mudam e uma melhor

compreensão do sistema é desenvolvida;

Os diferentes pontos de vista têm requisitos diferentes

e estes são frequentemente contraditórios.


É o processo de gerenciamento de mudanças de

requisitos durante o processo de engenharia de

requisitos e o desenvolvimento de sistema.

É necessário:

Compreender e controlar as mudanças dos requisitos;

Avaliar os impactos das mudanças;


Fatores para a mudança de requisitos

Erros e inconsistência de requisitos

Evolução do conhecimento sobre o sistema

Problemas técnicos, de custo e prazo

Mudança de prioridades

Mudanças organizacionais

Planejamento de gerenciamento de

requisitos

Durante o processo de gerenciamento de requsitos, você

tem de planejar:

A Identificação de requisitos

Como os requisitos são identificados individualmente;

O processo de gerenciamento de mudanças

Avalia o impacto e o custo das mudanças;

Políticas de rastreabilidade

É a quantidade de informações sobre os relacionamentos de requisitos;

Ferramenta de apoio

O apoio de ferramenta requisitada para auxiliar no gerenciamento das

mudanças requisitos.

Planejamento de gerenciamento de

requisitos

Ferramentas:

Caliber RM – comercial – Borland;

QSS requirit – comercial – Quality System & Software;

IBM – Rational RequisitePro – comercial – IBM Rational;

OSRMT – open source;

aNimble – open source.

Principais Eventos

Requirements Engineering Conference 2015

23ª edição

Ottawa – Canadá, de 24 a 28 de Agosto

Qualis A1

Tema:

Requirements for the masses.Requirements from the masses.

Working Conference on Requirements Engineering: Foundation for Software Quality 2015

21ª edição

Essen – Alemanha, de 23 a 26 de Março.

Qualis b3

Workshop em Engenharia de Requisitos - WER 2015

Qualis B3

18ª edição

Lima - Peru, de 22 a 24 de Abril.

Principais Eventos

Principais Tópicos de Interesse:

Elicitação de requisitos, análise, documentação,

validação e verificação;

O gerenciamento de requisitos, pontos de vista,

priorização e negociação;

Modelagem de requisitos, objetivos e domínios;

Relacionando requisitos para objetivos de negócios,

arquitetura e testes;

Requisitos em desenvolvimento ágil, linha de produtos

e modelo-dirigido a desenvolvimento;

Principais Eventos

Principais Tópicos de Interesse:

Requisitos em serviços orientados, virtualização, embarcados, em

nuvem e ambientes móveis;

Requisitos relacionados com a segurança, confiabilidade,

segurança, privacidade e forense digital;

Estudos empíricos, medições e previsão;

Específicas de domínio problemas, experiências e soluções,

incluindo domínios novos e emergentes;

Ferramenta de suporte para engenharia de requisitos;

Evolução dos requisitos ao longo do tempo, as famílias de

produtos, a variabilidade e reutilização.

Conclusão

A engenharia de requisitos define, sem dúvida, um dos

mais importantes conjuntos de atividades a serem

realizadas em projetos de desenvolvimento de software.

Embora não garanta a qualidade dos produtos gerados, é

um pré-requisitos básico para que obtenhamos sucesso

no desenvolvimento do projeto.

Bibliografia

DORFMAN, M., THAYER, R. H., 1990. Standards, Guidelines and

Examples of System and Software Requirements Engineering. Los

Alamitos, CA, IEEE Computer Society Press.

Norma 830-1998 - IEEE Recommended Practice for Software

Requirements Specifications.

PRESSMAN. “Engenharia de Software” 6ª Edição.

SOMMERVILLE, I. Engenharia de software. 8ª edição São Paulo:

Pearson Addison- Wesley, 2007.

SOMMERVILLE, I. Engenharia de Software, 9ª Edição. Pearson

Education, 2011.

Dúvidas

Engenharia de requisitos

Software

Transcript of Engenharia de requisitos