Requisitos de software

Prof. Marcelo H. Yamaguti (1)
Pontifícia Universidade Católica do Rio Grande do Sul
Faculdade de Informática
Prof. Marcelo H. Yamaguti
Introdução à Engenharia de
Software
DESENVOLVIMENTO DE
SOFTWARE
Requisitos de Software

PUCRS - FACIN
Referências
• Estude para aprofundamento no conteúdo:
– SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. São
Paulo: Pearson, 2011. - Capítulo 4
– PFLEEGER, Shari Lawrence. Engenharia de Software: teoria
e prática. 2ª ed. São Paulo: Prentice-Hall, 2004. - Capítulo 4
– IEEE. Guide to the Software Engineering Body of Knowledge.
SWEBOK. Version 3. IEEE Computer Society. 2014. –
Chapter 1
– SEI. CMMI for Development. 2010. – Chapter Requirements
Management
– SOFTEX. Guia geral MPS de Software. 2012. - Seção 9.1.2
Introdução à Engenharia de Software

PUCRS - FACIN
Conceito
• O que é um “Requisito”?
– Declaração abstrata em alto nível de um serviço que o sistema
deve oferecer ou uma restrição a um sistema. – Nível de
definição abrangente – Requisito de usuário.
– Definição detalhada e formal de uma função de um sistema. –
Nível de definição detalhado – Requisito de sistema.

PUCRS - FACIN
RF, RNF e RN
• Requisitos funcionais (RF), requisitos não-funcionais
(RNF) e regras de negócio (RN) podem ser
confundidos como sinônimos, mas possuem
características diferentes.
• Uma primeira diferença:
– RF e RNF referem-se ao sistema. Ex.: “o sistema deve
permitir que um cliente realize a compra de produtos do
catálogo”.
– RN são independentes do sistema. Ex.: “aqui na empresa só
vendemos para clientes adimplentes”.

PUCRS - FACIN
Requisitos
• Requisitos servem como especificação do que deve ser
implementado.
• Requisitos são descrições do que o sistema deve fazer, os
serviços que oferece e as restrições de seu funcionamento.
• Um requisito pode descrever:
– uma facilidade encontrada no nível do usuário
– uma propriedade geral do sistema
– uma restrição do sistema
– uma restrição ao desenvolvimento do sistema

PUCRS - FACIN
Requisitos
• Há várias classificações possíveis de requisitos.
• Uma classificação é:
– Requisitos de usuário
– Requisitos de sistema
• Outra classificação é:
– Requisitos funcionais
– Requisitos não-funcionais

PUCRS - FACIN
Requisitos funcionais X não-
funcionais
• Requisitos funcionais:
– São declarações de serviços que o sistema deve fornecer.
– Pode-se definir também o que o sistema não deve fazer.
• Requisitos não-funcionais:
– São restrições aos serviços e funções oferecidos pelo sistema.
– Muitas vezes se aplicam por todo o sistema.
• Obs.:
– Um requisito não-funcional pode gerar novos requisitos funcionais.
– Pode haver relacionamento entre os requisitos.

PUCRS - FACIN
RF – Requisito Funcional
• Um Requisito Funcional define uma funcionalidade
ou serviço do sistema.
– Descreve como o sistema transforma entradas em saídas
– Descreve como o sistema se comporta em situações especiais
– Descreve como o sistema NÃO deve se comportar
• Exemplo:
“O sistema deve emitir relatórios de vendas de cada mês”.

PUCRS - FACIN
RF – Requisito Funcional
• Características esperadas:
– Completeza: todos os serviços requeridos pelo usuário devem ser
definidos.
– Consistência: as definições não devem ser contraditórias ou ambíguas.
• Obs.:
– Para sistemas grandes ou complexos garantir a completeza pode ser mais
difícil pela amplitude do sistema ou dos stakeholders envolvidos, que
também pode gerar inconsistências entre os requisitos.

PUCRS - FACIN
RNF – Requisito Não-
Funcional
• Um Requisito Não-Funcional define restrições ou qualidades
do sistema.
– Podem afetar vários requisitos funcionais.
– Existem várias classificações possíveis.
– Uma classificação possível:
• Usabilidade
• Confiabilidade
• Desempenho
• Portabilidade
• Obs:
– Podem afetar a arquitetura do sistema inteiro. Ex.: desempenho.
– Podem gerar requisitos funcionais para o seu cumprimento.

PUCRS - FACIN
RNF – Requisito Não-
Funcional
• Exemplos:
– “A resposta do sistema deve ser em até 3 segundos após uma solicitação”.
– “Os relatórios são gerados em formato PDF não editável”.
• Característica esperada:
– Verificável/testável: declarar o requisito não-funcional de forma que seja
possível identificar uma métrica associada.
– Exemplos:
• Velocidade: transações/segundo
• Facilidade de uso: número de erros na utilização
• Portabilidade: percentual de declarações/bibliotecas dependentes da
plataforma-alvo

PUCRS - FACIN
RN – Requisito ou Regra de
Negócio
• Uma Regra de Negócio define ou restringe aspectos
da organização (empresa).
– É independente do sistema.
– Define as características próprias de como a organização
funciona.
• Podem gerar requisitos não-funcionais e funcionais.
• Exemplos:
“Na nossa empresa só vendemos produtos para clientes
adimplentes”.
“Na nossa empresa não aceitamos pagamento por
cartão de crédito”

PUCRS - FACIN
Processo de engenharia de
requisitos
Elicitação Especificação Validação

PUCRS - FACIN
requisitos
1. Elicitação – levantamento de requisitos:
1. Descoberta - identificação de requisitos
2. Classificação e organização - organização de requisitos
3. Priorização e negociação - resolução de conflitos

PUCRS - FACIN
requisitos
1. Descoberta – identificação de requisitos:
• Os analistas trabalham com o cliente e usuários para descobrir mais
informações sobre o domínio da aplicação, serviços do novo sistema, e
restrições operacionais.
• Stakeholders: usuários finais, gerentes, engenheiros envolvidos em
manutenção, especialistas no domínio, etc.

PUCRS - FACIN
requisitos
– Desafios:
• As pessoas podem não saber o que realmente querem
• Stakeholders expressam requisitos em seus próprios termos
• Stakeholders diferentes podem ter requisitos conflitantes
• Fatores organizacionais e políticos podem influenciar os requisitos do
sistema
• Os requisitos mudam durante o processo de análise. Novos
stakeholders podem surgir e o ambiente de negócio mudar

PUCRS - FACIN
requisitos
2. Classificação e organização - organização de requisitos
• Classificar requisitos identificados por similaridade
• Organizar requisitos em grupos (ex.: “módulos”)
• Vários requisitos identificados podem se tornar apenas um requisito,
com mais de um cenário (conjunto de passos ou atividades para
atingir um resultado).

PUCRS - FACIN
requisitos
3. Priorização e negociação - resolução de conflitos
• Em caso de requisitos conflitantes é necessário negociar com os
stakeholders envolvidos a resolução ou ajuste dos requisitos.
• Priorizar requisitos mais importantes.

PUCRS - FACIN
requisitos
2. Especificação – descrição de requisitos
• Usualmente gera um ‘Documento de Requisitos’, às vezes chamado
de ‘Especificação de Requisitos de Software’ ou SRS (Software
Requirements Specification).

PUCRS - FACIN
Especificação de requisitos
• A especificação de requisitos pode ser realizada de
diversas formas:
– Sentenças em linguagem natural
– Linguagem natural estruturada
– Diagramas
– Tabelas
– Especificações matemáticas

PUCRS - FACIN
• Sentenças em linguagem natural:
– Interessante para a especificação de requisitos do usuário.
– Diretrizes:
• Busque utilizar uma sintaxe padrão. Ex.: <Sujeito> <ação>
<consequência>: “O sistema deve emitir relatório de gastos mensais
no início do mês”; “O usuário deve ser capaz de cadastrar um novo
produto no sistema.”
• Use um subconjunto de verbos para definir requisitos obrigatórios
(ex.: “deve”) e opcionais (ex.: “pode”).
• Evite jargão de informática.
• Sempre que possível associar o ‘racional’ de cada requisito. Ex.: “O
sistema deve emitir relatório de gastos mensais no início do mês (O
setor contábil precisa dos dados até o final da primeira semana e os
gastos podem variar muito de uma semana para outra)”

PUCRS - FACIN
• Linguagem natural estruturada:
– Interessante para permitir que o usuário consiga ler a especificação e a
equipe técnica ter uma base mais detalhada para o desenvolvimento do
software.
– Ex.: Detalhamento textual de caso de uso.
• Diagramas e outras técnicas:
– Podem facilitar o entendimento da equipe técnica, mas dificultar para o
usuário.
– Ex.: Diagrama de Casos de Uso para Requisitos Funcionais.

PUCRS - FACIN
Processo de engenharia de requisitos
3. Validação – garantia da validade dos requisitos:
1. Prototipação, geração de casos de teste, revisões, checklists

PUCRS - FACIN
Gerenciamento de requisitos
• Atividades comuns:
– Identificação e entendimento de requisitos
– Avaliação e comprometimento com os requisitos
– Rastreabilidade bidirecional de requisitos
– Revisão do planejamento em relação aos requisitos
– Gerenciamento de mudanças de requisitos

Pontifícia Universidade Católica do Rio Grande do Sul
Faculdade de Informática
Prof. Marcelo H. Yamaguti
Introdução à Engenharia de
Software
DESENVOLVIMENTO DE
SOFTWARE
Requisitos de Software

Requisitos de software

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Requisitos de software

Requisitos de software