Aula 06 - Requisitos de Software

(1)

Engenharia de Software

Requisitos de Software

Marcelo Marinho

(2)

Objetivos

• Apresentar os conceitos de requisitos de

usuário e de sistema;

• Descrever requisitos funcionais e

não-funcionais;

• Explicar como os requisitos de software

podem ser organizados em um documento de

requisitos;

Eng. de Software - Prof. Marcelo Marinho

(3)

Engenharia de Requisitos

• O processo de estabelecer os serviços que o cliente

requer a partir de um sistema e as restrições sob as

quais ele opera e é desenvolvido.

• Os próprios requisitos são as descrições dos serviços

de sistema e das restrições que são geradas durante

o processo de engenharia de requisitos.

(4)

(5)

Que é um requisito?

• Tanto pode ser

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

serviço;

– Como uma restrição do sistema;

• Quanto

uma

especificação

funcional

matemática detalhada.

(6)

Requisitos funcionais e não-funcionais

• Requisitos Funcionais

– Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.

• Requisitos Não-Funcionais

– Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc.

(7)

Requisitos Funcionais

• Descreve funcionalidade e serviços do sistema

• Depende do

– Tipo do software

– Usuários esperados

– Tipo do sistema onde o software é usado

• Requisitos funcionais de usuário podem ser

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

fazer

• Requisitos funcionais de sistema devem

descrever os serviços do sistema em detalhe.

(8)

Exemplos de R.F.

• [RF001] Usuário pode pesquisar todo ou um

sub-conjunto do banco de dados;

• [RF002]

Sistema

deve

oferecer

visualizadores

apropriados

para

o

usuário

ler

documentos

armazenados;

• [RF003] A todo pedido deve ser associado um

identificador único (PID), o qual o usuário pode copiar

para a área de armazenamento permanente da conta.

(9)

Requisitos Não-Funcionais

• Definem propriedades e restrições do sistema (tempo,

espaço, etc);

• Requisitos não funcionais de usuário podem ser

declarações de alto nível do que o sistema deve fazer;

• Requisitos não funcionais de sistema devem descrever os

serviços do sistema em detalhe;

• Requisitos de processo também podem especificar o uso

de determinadas linguagens de programação, método de

desenvolvimento;

• Requisitos não-funcionais podem ser mais críticos que

requisitos funcionais. Não satisfaz, sistema inútil.

(10)

Requisitos Não-Funcionais

• Devido à sua própria definição, requisitos

não-funcionais são esperados mensuráveis;

• Assim,

deve-se

associar

forma

de

medida/referência a cada requisito

não-funcional elicitado.

(11)

Medidas de Requisitos (Não-funcionais)

Propriedade Medida

Velocidade Transações processadas/seg

Tempo de resposta do usuário/evento

Tamanho K bytes

No_{de chips de RAM}

Facilidade de uso Tempo de treinamento No_{de quadros de ajuda}

Confiabilidade Tempo médio de falhas

Probabilidade de indisponibilidade Taxa de ocorrência de falhas

Robustez Tempo de reinício após falha

Percentual de eventos causando falhas

Probabilidade de corrupção de dados após falha Portabilidade Percentual de declarações dependentes do destino

(12)

Classificação de R. N. F.

• Requisitos do Produto

– Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.);

• Requisitos Organizacionais

– Conseqüência de políticas e procedimentos

organizacionais (padrões de processo usados, requisitos de implementação, etc.);

• Requisitos Externos

– Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.).

(13)

Exemplos de R. N. F.

• Requisitos do Produto

– [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s;

• Requisitos Organizacionais

– [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00;

• Requisitos Externos

– [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema.

(14)

Metas e requisitos

• Requisitos não-funcionais podem ser muito

difíceis de definir precisamente e requisitos

imprecisos podem ser difíceis de verificar.

• Meta:

– Uma intenção geral do usuário tal como facilidade de

uso.

• Requisito não-funcional verificável

– Uma declaração usando alguma medida que pode ser

objetivamente testada.

• Metas são úteis para desenvolvedores quando

exprimem as intenções dos usuários do sistema.

(15)

Exemplos

(16)

Visão dos Requisitos

• Requisitos do Usuário

– Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes;

• Requisitos do Sistema

– Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor;

(17)

Definições e especificações

(18)

Leitores de requisitos

(19)

Requisitos de usuário

• Deve descrever requisitos funcionais e não-funcionais, de tal modo que sejam compreensíveis pelos usuários de sistema que não têm conhecimento técnico detalhado;

• Requisitos de usuário são definidos usando uma linguagem simples, tabelas e diagramas quando estes podem ser compreendidos por todos os usuários;

• Histórias de usuários são similares a requisitos de usuários.

(20)

Problemas com linguagem natural

• Falta de clareza

– É difícil atingir uma precisão sem tornar o

documento difícil de ler.

• Confusão de requisitos

– Requisitos funcionais e não-funcionais tendem a

estar misturados.

• Fusão de requisitos

– Vários requisitos diferentes podem ser expressos

juntos.

(21)

Diretrizes para escrever requisitos

• Inventar um formato padrão e usá-lo para

todos os requisitos.

• Usar a linguagem de uma forma consistente.

Use ‘deve’ para

• Requisitos obrigatórios, e ‘deveria’ para

requisitos desejáveis.

• Realce o texto para identificar as partes

principais do requisito.

• Evitar o uso de jargões de computação.

(22)

Requisitos de sistema

• Mais especificações detalhadas das funções

do sistema, dos serviços e das restrições do

que requisitos de usuário.

• Eles pretendem ser uma base para o

desenvolvimento do projeto de sistema.

• Eles podem ser incorporados no contrato de

sistema.

• Requisitos de sistema podem ser definidos ou

ilustrados usando modelos de sistema;

(23)

Processos de engenharia de

requisitos

• Os requisitos e as formas de obtê-los e

documentá-los variam drasticamente de um

projeto para o outro;

• Contudo, existe uma série de atividades genéricas

comuns a todos os processos;

– Elicitação de requisitos;

– Análise de requisitos;

– Validação de requisitos;

– Gerenciamento de requisitos.

(24)

O Processo da Engenharia de

Requisitos

Estudo de viabilidade Relatório de viabilidade Elicitação de requisitos e análise Modelos do sistema Especificação de requisitos Validação de requisitos Requisitos do usuário e do sistema Documento de requisitos

(25)

Elicitação de requisitos e análise

• Esta atividade divide-se em dois esforços maiores: – Elicitação dos requisitos em si

• Técnicas de elicitação – Análise do que foi elicitado

(26)

Técnicas de Elicitação

• Entrevistas

• Questionários

• Casos de Uso

• Jogo de Funções

• Brainstorming

• Workshop de Requisitos

(27)

Análise de Requisitos

Entendimento do domínio Coleta de requisitos Classificação Definição e especificação de requisitos Resolução de conflito Atrib. Prioridade Validação dos requisitos Entrada do processo Documento de requisitos 1 2 3 4 5 6 7 8

(28)

Entendimento do Domínio

• Desenvolver sistemas envolve domínios além

de software e hardware

• Podemos ter que entender sobre

– Contabilidade

– Saúde

– Supermercados

– Etc.

(29)

Coleta de Requisitos

• Como vimos anteriormente, a coleta de

requisitos é feita através de técnicas

• Nesta etapa, os requisitos são simplesmente

documentados à medida que são coletados

(30)

Classificação dos Requisitos

• Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos • Por exemplo

– Deve ser possível consultar o preço de uma mercadoria

• A consulta deve retornar uma resposta em no máximo 5s

(31)

Problema da Análise de Requisitos

• Stakeholders em geral não sabem o que querem

• Stakeholders expressam requisitos em sua terminologia

(32)

Problema da Análise de Requisitos

• Fatores políticos e organizacionais podem influenciar os requisitos do sistema;

• Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda.

(33)

Resolução de Conflitos

• É normal que ocorram requisitos conflitantes • Por exemplo

– R-23: O sistema deve ...

– R-45: O sistema não deve ...

• Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades);

(34)

Atribuição de Prioridade

• Alguns requisitos são mais urgentes que outros;

• É essencial determinar a prioridade dos requisitos junto ao cliente;

• Requisitos de maior prioridade são considerados em primeiro lugar.

(35)

Prioridade

• Requisitos podem ser vistos em três classes distintas – Essenciais

– Importantes – Desejáveis

• Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

(36)

Exemplo de Prioridade

• [RF001] Consulta X ao B.D. deve retornar dados A, B,

C

– Prioridade: Essencial

• [RNF001] Consulta X ao B.D. deve visualizar dados

segundo padrão Y

– Prioridade: Importante

• [RNF010] Consulta X ao B.D. deve usar cores azuis

nos resultados

(37)

Validação dos Requisitos

• Será que realmente entendi o que o cliente

deseja?

• Devo me certificar de que não houve falha em

nossa interação (comunicação)

(38)

Validação de Requisitos

• Demonstrar que os requisitos definem o

sistema que o cliente realmente deseja

• Custos com erros de requisitos são altos

– Consertar um erro de requisitos após entrega do

sistema pode custar mais de 100 vezes o custo de

um erro de implementação

(39)

Técnicas de Validação de Requisitos

• Revisões de Requisitos

– Análise manual sistemática dos requisitos

• Prototipação

– Uso de modelo executável do sistema para avaliar requisitos

• Geração de Casos de Teste

– Desenvolver testes específicos para os requisitos para avaliá-los

• Análise de Consistência Automática

(40)

Gerenciamento de Requisitos

• Gerenciamento de requisitos é o processo de

controlar as mudanças dos requisitos durante

– O processo da engenharia de requisitos

– E desenvolvimento do sistema

(41)

Gerenciamento de Requisitos

• Requisitos são inevitavelmente incompletos e

inconsistentes

– Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido

– Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

(42)

Rastreamento

• Responsável por dependências entre requisitos, suas origens e projeto do sistema

• Rastreamento de Origem

– Associação entre requisitos e stakeholders que propuseram tais requisitos

(43)

Rastreamento

• Rastreamento de Requisitos

– Associação entre requisitos dependentes

• Rastreamento de Projeto

– Associação dos requisitos com o projeto

• Usar hipertexto ou referência cruzada

(44)

Rastreamento

1.

Rastrear requisitos do usuário nos do sistema

2.

Rastrear requisitos no projeto

3.

Rastrear requisitos nos procedimentos de teste

4.

Rastrear requisitos do usuário no plano

Projeto

Modelos Suítes Teste

Teste 2 3 Req A 1 Requisitos Produto (Caracter.) Requisitos Detalhados (Casos de Uso) Req B Plano Doc. Usuário 4

(45)

 Links dos requisitos devem ser marcados como “revisar”

 Links “revisar” devem ser analisados Req A antes

“if return value > $5” Req B

Req C

“if return value > $2”

Req A depois

Req C Req B

(46)

Documento de Requisitos

• Fonte: IEEE/ANSI (830-1998)

• 1. Introdução

– 1.1 Propósito do documento

– 1.2 Escopo do sistema

– 1.3 Definições, acrônimos e abreviaturas

– 1.4 Referências

(47)

Documento de Requisitos

• Fonte: IEEE/ANSI (830-1998)

• 2. Descrição geral

– 2.1 Perspectiva do produto

– 2.2 Funções do produto

– 2.3 Características dos usuários

– 2.4 Restrições gerais

(48)

Documento de Requisitos

• Fonte: IEEE/ANSI (830-1998)

• 3. Requisitos específicos

– requisitos funcionais, não-funcionais, GUI com o

usuário:

• funcionalidade, interfaces externas,

desempenho, restrições, atributos do sistema,

caract. qualidade, ...

• Apêndices

• Índice

(49)