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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Requisitos de software

Ähnlich wie Requisitos de software (20)

Requisitos de software