1) O documento discute engenharia de requisitos, que é o processo de descobrir, analisar, documentar e verificar as funções e restrições de um software. 2) É fundamental ter uma compreensão completa dos requisitos para um desenvolvimento de software bem-sucedido. Aproximadamente 50% dos problemas em projetos de software estão relacionados a problemas no levantamento de requisitos. 3) Os requisitos funcionais descrevem as funções do sistema, enquanto os não funcionais descrevem propriedades como desempenho e segurança.

1. ENGENHARIA DE SOFTWARE
Aula 04
Engenharia de Requisitos
Prof. Cleuber Fernandes
Mestre em Ciência da Computação - UnB
Cleubermf@yahoo.com.br
http://br.groups.yahoo.com/group/ES-2008
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 1

2. 1. Motivação
“Uma COMPREENSÃO COMPLETA DOS REQUISITOS de software
É FUNDAMENTAL para um bem-sucedido desenvolvimento de software. Não importa quão bem
projetado ou quão bem codificado seja, um programa mal analisado e especificado desapontará o
usuário e trará aborrecimentos no desenvolvimento” [Pressman]
Declaração de um cliente:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de
que percebe que aquilo que ouviu não é o que eu pretendia dizer...”
Em uma pesquisa realizada nos EUA em 1995 com 350 empresas americanas em 8000 projetos de
software, foi constatado que AS FALHAS OCORRIDAS foram decorrentes de:
• Pouco envolvimento do usuário (13%)
• Requisitos incompletos (12%)
• Mudanças de requisitos (11%)
• Expectativas irreais (6%)
• Objetivos obscuros (5%)
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 2

3. Analisando os dados da pesquisa, podemos concluir que aproximadamente 50% DAS CAUSAS DE
PROBLEMAS EM UM DESENVOLVIMENTO DE SOFTWARE, ESTÃO EM UM
LEVANTAMENTO DE REQUISITOS RUIM.
2. Definição
Requisitos são FUNÇÕES ou RESTRIÇÕES estabelecidas por clientes e usuários que definem as
diversas propriedades do sistema. Engenharia de Requisitos é o processo de DESCOBRIR,
ANALISAR, DOCUMENTAR E VERIFICAR as funções e restrições do software.
Existem dois níveis de descrição dos requisitos:
• REQUISITOS DE USUÁRIO: declarações, em linguagem natural e diagrama sobre funções e
restrições que o sistema deve atender.
• REQUISITOS DO SISTEMA: estabelecem detalhadamente as funções e as restrições de sistema.
Algumas vezes chamado de especificação funcional, deve ser preciso.
⇒ Diferentes níveis de especificações de sistemas são úteis, porque comunicam informações sobre o
sistema a diferentes tipos de interessados.
Exemplo:
Requisito de usuário
• O software deve permitir checkin de hóspedes.
Especificação dos requisitos de sistema
• O sistema deve exibir aptos disponíveis;
• O usuário deve selecionar apto;
• O usuário deve informar dados do hóspede;
• O sistema deve imprimir comprovante de checkin.
3. Dificuldades
• DESCONHECIMENTO DO DOMÍNIO DE NEGÓCIO;
• FALTA DE CLAREZA E OBJETIVIDADE POR PARTE DO CLIENTE EM DEFINIR OS
OBJETIVOS E REQUISITOS DO SISTEMA;
• POUCO ENVOLVIMENTO E COMPROMETIMENTO DO USUÁRIO;
• MUDANÇAS CONSTANTES NOS REQUISITOS.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 3

4. 4. Atividades
1. LEVANTAMENTO DE REQUISITOS (RECONHECIMENTO DO PROBLEMA)
2. ANÁLISE DE REQUISITOS (SÍNTESE)
3. MODELAGEM (CASOS DE USO)
4. ESPECIFICAÇÃO (DE CASOS DE USO)
5. AVALIAÇÃO E REVISÃO (PELO CLIENTE E USUÁRIOS)
6. GERÊNCIA DE REQUISITOS (GERENCIAR INCLUSÃO DE NOVOS REQUISITOS E
MUDANÇA NOS JÁ EXISTENTES)
5. Requisitos Funcionais, Não Funcionais e de Domínio
• Requisitos Funcionais
São declarações de FUNÇÕES QUE O SISTEMA DEVE FORNECER, como o sistema deve
reagir a entradas específicas e como deve se comportar em determinadas situações. Podem também
declarar o que o sistema não deve fazer.
• Requisitos Não Funcionais
São restrições sobre os serviços ou as funções oferecidas pelo sistema, tais como: RESTRIÇÕES
DE TEMPO, SEGURANÇA, DISPONIBILIDADE, dentre outras.
• Requisitos de Domínio
Originam do domínio de aplicação do sistema e refletem características desse domínio. Podem ser
FUNCIONAIS OU NÃO FUNCIONAIS.
Essas definições são sutis. Um requisito do usuário de que é necessário AUTORIZAÇÃO DE ACESSO,
pode parecer um requisito não funcional de segurança, enquanto na verdade é um requisito funcional.
5.1 Requisitos Funcionais
Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema forneça.
Os requisitos funcionais de usuário são descritos de forma geral, mas os requisitos funcionais de sistema
descrevem as funções de sistema detalhadamente, suas entradas e saída, exceções.
REQUISITOS FUNCIONAIS PODEM SER ESCRITOS EM DIFERENTES NÍVEIS DE
DETALHAMENTO, como segue:
1. O usuário deve ser capaz de incluir novos hóspedes;
2. Cada hóspede terá um identificador único que o identificará nos demais módulos do sistema.
Muitos problemas de engenharia de software se originam de IMPRECISÃO NA ESPECIFICAÇÃO de
requisitos, que muitas vezes PERMITEM INTERPRETAÇÕES AMBÍGUAS.
Dessa forma, a especificação de requisitos funcionais de um sistema deve ser completa e consistente.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 4

5. • A completeza significa que todas as funções requeridas pelo usuário devem estar definidas.
• A consistência significa que os requisitos não devem ter definições contraditórias.
Durante o ciclo de vida do sistema certamente serão identificados novos requisitos, bem como
alguns requisitos inconsistentes. Por isso, o modelo iterativo e incremental (RUP) é mais indicado
que o modelo cascata.
5.2 Requisitos Não Funcionais
Como o próprio nome sugere, são aqueles que não dizem respeito diretamente às funções específicas
fornecidas pelo sistema. Podem estar relacionados a propriedades de sistemas, como
CONFIABILIDADE, TEMPO DE RESPOSTA, USO DE MEMÓRIA. Podem definir
RESTRIÇÕES PARA O SISTEMA.
Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a características
individuais.
Freqüentemente os requisitos não funcionais são mais importantes que os funcionais. Deixar de atender
um requisito funcional pode degradar uma funcionalidade, mas uma falha num requisito não funcional
pode prejudicar todo o sistema. Como exemplo, temos:
SE UM SISTEMA DE AVIAÇÃO NÃO ATENDER AOS REQUISITOS DE
CONFIABILIDADE, NÃO TERÁ AUTORIZAÇÃO PARA OPERAR.
Requisitos não funcionais surgem em razão de restrições de orçamento, políticas organizacionais,
necessidade de interoperabilidade com outros sistemas de software ou hardware, ou devido a
regulamentos de segurança, privacidade, dentre outros fatores externos.
O diagrama abaixo exibe a classificação dos diferentes tipos de requisitos não funcionais.
Requisitos Não
Funcionais
Requisitos do Requisitos Requisitos
Produto Organizacionais Externos
Prazo de Interoperabili-
Eficiência Portabilidade Padrões Legais
Entrega dade
Espaço
Desempenho Privacidade Segurança
Memória/Disco
Os requisitos não funcionais devem ser expressos quantitativamente, utilizando-se métricas que possam
ser objetivamente testadas. As medições podem ser feitas durante o teste de sistema, para determinar se o
sistema cumpre com os requisitos ou não. Segue exemplo:
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 5

6. Meta do sistema: O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de
modo que erros de usuários sejam minimizados.
Um requisito não funcional verificável: Controladores experientes devem ser capazes de utilizar todas
as funções do sistema depois de um total de duas horas de treinamento. Após este treinamento, o número
médio de erros feitos por usuários experientes não deve exceder a dois por dia.
Propriedade Métrica
Velocidade Transações processadas por segundo
Tempo de resposta ao usuário por evento
Tempo de atualização da tela
Facilidade de uso Tempo de treinamento
Número de ajudas on-line
Confiabilidade Tempo médio para falhar
Probabilidade de indisponibilidade
Robustez Tempo de reinício após falha
Porcentagem de eventos que causam falhas
Portabilidade Porcentagem de recursos dependentes de SO/Hardware
Número de SO/Hardware
Alguns requisitos não funcionais podem entrar em conflito com requisitos funcionais, como:
- Requisito funcional: O sistema deve apresentar, em vídeo, gráficos de faturamento mensal;
- Requisito não funcional: O sistema não deve ocupar mais que 512 KB de memória.
5.3 Requisitos de Domínio
São derivados do domínio da aplicação do sistema, em vez de serem obtidos a partir das necessidades
específicas dos usuários. Podem:
- Ser novos requisitos funcionais;
- Restringir os requisitos funcionais existentes;
- Estabelecer regras de negócio, como cálculos específicos.
Requisitos de domínio são importantes por refletirem fundamentos do domínio da aplicação, como:
- Uma rede bayesiana não pode conter ciclos orientados;
X
Y Z
- A probabilidade de uma variável condicionada ao conjunto de variáveis pais é
calculada da seguinte forma:
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 6

7. Y Z
X P( X , Y , Z )
P( X | Y , Z ) =
P(Y , Z )
6. Requisitos de Usuário
Devem descrever requisitos funcionais e não funcionais de modo compreensível pelos usuários do sistema
que não têm conhecimento técnico. Não devem ser definidos utilizando-se um modelo de implementação.
Podem ser escritos usando linguagem natural, formulários ou DIAGRAMAS INTUITIVOS.
Vários problemas podem surgir quando requisitos são escritos em LINGUAGEM NATURAL:
1. Falta de clareza: às vezes, é difícil utilizar a linguagem de maneira precisa e sem ambigüidades.
2. Confusão de requisitos: Os requisitos funcionais e não funcionais, os objetivos do sistema e as
informações sobre o projeto podem não estar bem definidos e até mesmo contraditórios.
3. Fusão de requisitos: Vários requisitos diferentes podem ser expressos juntos como um único
requisito.
Exemplo: Recursos de grade
Para ajudar no posicionamento de entidades em um diagrama, o usuário pode acionar uma grade em
centímetros ou em polegadas, por meio de uma opção no painel de controle. Inicialmente, a grade está
desativada. Ela pode ser ligada ou desligada a qualquer momento durante uma sessão de edição e pode ser
alternada entre polegadas e centímetros a qualquer momento. Uma opção de grade será fornecida na visão
reduzida do diagrama, mas o número de linhas da grade mostrado diminuirá, para evitar preencher o
diagrama menor com linhas de grade.
A descrição em linguagem natural acima mistura três tipos de requisitos:
1. Um requisito funcional conceitual especifica que o sistema de edição deve fornecer uma grade e
apresenta uma base lógica para isso.
2. Um requisito não funcional, que fornece informações detalhadas sobre as unidades da grade
(centímetros ou polegadas).
3. Um requisito não funcional de interface com o usuário, que define como essa grade é ligada e
desligada pelo usuário.
Os requisitos de usuário devem mostrar apenas os recursos principais a serem fornecidos pelo sistema. A
lógica associada com os requisitos é importante, pois ajuda os desenvolvedores e os responsáveis pela
manutenção a compreender por que os requisitos foram incluídos e avaliar o impacto da mudança nos
requisitos.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 7

8. A descrição abaixo, para o requisito de grade, é mais indicada do que a citada acima.
1. Recursos de grade
1.1 O editor deverá fornecer um recurso de grade, em que uma matriz de linhas
horizontais e verticais constitua um fundo da janela do editor. Essa grade deverá
ser uma tela passiva em que o alinhamento de entidades é de responsabilidade do
usuário.
Lógica: uma grade ajuda o usuário a criar um diagrama “limpo”, com entidades bem
espaçadas. Embora uma grade ativa, em que as entidades saltam as linhas de grade, possa
ser útil, o posicionamento é impreciso. O usuário é a melhor pessoa para decidir onde as
entidades devem ser posicionadas.
7. Requisitos de Sistema
Os requisitos de sistema são DESCRIÇÕES MAIS DETALHADAS dos requisitos do usuário. Pode
servir como um contrato destinado à implementação do sistema e, dessa forma, devem ser uma
especificação completa e consistente de todo o sistema. São UTILIZADOS PELOS ENGENHEIROS
DE SOFTWARE como ponto de partida para o projeto de sistema.
A especificação de requisitos de sistema pode incluir diferentes modelos, como modelo de caso de uso
detalhado, encenação de caso de uso e modelo de objetos.
Apesar da linguagem natural ser freqüentemente utilizada para escrever especificações de requisitos de
sistema, alguns problemas podem surgir, tais como:
1. Uso das mesmas palavras expressando conceitos distintos;
2. Uso flexível, dizer a mesma coisa de modos completamente diferentes;
Por estes motivos, o uso da linguagem natural em especificação de requisitos de sistema pode gerar
divergências, pois dá margens a interpretações individuais.
Dessa forma, é indicado o uso de outras formas de especificação que reduzam ambigüidades, como a
Linguagem natural estruturada.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 8

9. 8. Modelo de Casos de Uso
O modelo de casos de uso é um modelo que descreve os requisitos de um sistema em
termos de casos de uso.
É um modelo das FUNÇÕES PRETENDIDAS DO SISTEMA E SUAS VIZINHANÇAS, que serve
como CONTRATO ENTRE O CLIENTE E OS DESENVOLVEDORES. O mesmo modelo de casos
de uso é o resultado da disciplina Requisitos e é usado como entrada para as disciplinas Análise & Design
e Teste.
Os usuários e qualquer outro sistema que podem interagir com o sistema são os atores. Como eles
representam os usuários do sistema, os ATORES AJUDAM A DELIMITAR O SISTEMA e fornecem
uma imagem mais clara do que se espera que seja feito. Os casos de uso são desenvolvidos com base nas
necessidades dos atores. Isso garante que o sistema será o que os usuários esperam.
Conforme eles são revelados, os casos de uso e os atores devem ser descritos brevemente, antes de
descrever os casos de uso detalhadamente, o modelo de casos de uso deve ser revisto pelo cliente para
verificar se todos os casos de uso e os atores foram encontrados e se juntos eles podem fornecer o que o
cliente deseja.
Em um ambiente de desenvolvimento iterativo, você seleciona um subconjunto de casos de uso para
ser detalhado em cada iteração. Essas descrições mostram como o sistema interage com os atores e o
que o sistema executa em cada caso individual.
Como Evitar a Decomposição Funcional
Não é raro que o modelo de casos de uso se torne uma decomposição funcional do sistema. Para evitar
isso, observe os seguintes sintomas:
• Casos de uso quot;pequenosquot; - significa que a descrição do fluxo de eventos é apenas uma ou poucas
frases.
• quot;Muitosquot; casos de uso - significa que o número de casos de uso é algum múltiplo de cem em vez
de um múltiplo de dez.
• Os nomes dos casos de uso que são construções como quot;executar esta operação com esses dados
específicosquot; ou quot;executar esta função com esses dados específicosquot;. Por exemplo, quot;Inserir o Número
de Identificação Pessoal em um caixa eletrônicoquot; não deve ser modelado como um caso de uso
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 9

10. separado para um caixa eletrônico, já que ninguém usaria o sistema para executar apenas isso. Um
caso de uso é um fluxo completo de eventos que resulta em algo de valor para um ator.
Para evitar a decomposição funcional, você deve ter certeza de que o modelo de casos de uso ajuda a
responder perguntas como:
• Qual é o contexto do sistema?
• Por que o sistema foi criado?
• O que o usuário deseja realizar quando usa o sistema?
• Que valor o sistema agrega aos usuários?
Requisitos Não Funcionais
É muito fácil perceber que os casos de uso são uma forma muito boa de capturar os requisitos funcionais
em um sistema. E os requisitos não funcionais? O que são eles e onde são capturados?
Muitos requisitos não funcionais aplicam-se a um caso de uso individual e são capturados dentro das
propriedades desse caso de uso. Nesse caso, eles são capturados dentro do fluxo de eventos do caso de uso
ou como um requisito especial do caso de uso (consulte Diretrizes: Caso de Uso).
Exemplo:
No Sistema da Máquina de Reciclagem, um requisito não funcional específico para o caso de uso
Devolver Itens do Depósito pode ser:
A máquina deve ser capaz de reconhecer os itens de depósito com uma confiabilidade de mais de 95%.
Freqüentemente, os requisitos não funcionais aplicam-se ao sistema inteiro. Esses requisitos são
capturados nas Especificações Suplementares (consulte Artefato: Especificações Suplementares).
Exemplo:
No Sistema da Máquina de Reciclagem, um requisito não funcional que se aplica ao sistema inteiro pode
ser:
A máquina só permitirá um usuário por vez.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 10

11. Dilema “O que” versus “Como”
Os casos de uso ou os requisitos do software devem estabelecer quot;o quequot; o sistema executa, mas não
quot;comoquot; ele executa.
Casos de Uso Concretos e Abstratos
Há uma distinção entre casos de uso concretos e abstratos. Um caso de uso concreto é iniciado por um ator
e constitui um fluxo completo de eventos. quot;Completoquot; significa que uma instância do caso de uso executa
a operação inteira chamada pelo ator.
Um caso de uso abstrato propriamente nunca é instanciado. Os casos de uso abstratos são incluídos em
(consulte Diretrizes: Relacionamento de Inclusão), se estendem para (consulte Diretrizes: Relacionamento
de Extensão) ou generalizam (consulte Diretrizes: Generalização de Casos de Uso) outros casos de uso.
Quando um caso de uso concreto é iniciado, uma instância do caso de uso é criada. Essa instância também
exibe o comportamento especificado por seus casos de uso abstratos associados. Portanto, nenhuma
instância separada é criada de casos de uso abstratos.
A distinção entre os dois é importante porque são os casos de uso concretos que os atores quot;verãoquot; e
iniciarão no sistema.
Você indica que um caso de uso é abstrato escrevendo seu nome em itálico.
Exemplo:
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 11

12. Estruturação do Modelo de Casos de Uso
Há três motivos principais para estruturar o modelo de casos de uso:
• Facilitar o entendimento dos casos de uso.
• Particionar o comportamento comum descrito em muitos casos de uso.
• Facilitar a manutenção do modelo de casos de uso.
No entanto, a estruturação não deve ser feita primeiro. Só faz sentido estruturar os casos de uso quando
você souber um pouco mais sobre o comportamento deles, além de uma breve descrição em uma frase.
Você deve pelo menos ter estabelecido um esquema passo a passo para o fluxo de eventos do caso de uso,
a fim verificar se as suas decisões se basearam em um entendimento bem preciso do comportamento.
Se houver uma parte de um caso de uso base que represente uma função da qual o caso de uso só
depende do resultado, e não do método usado para produzir o resultado, você poderá fatorar essa parte
em um caso de uso adicional. A adição é explicitamente inserida no caso de uso base, usando o
relacionamento de inclusão.
Se houver uma parte de um caso de uso base que seja opcional ou desnecessária para entender a
principal finalidade do caso de uso, você poderá fatorar essa parte em um caso de uso adicional para
simplificar a estrutura do caso de uso base. A adição é implicitamente inserida no caso de uso base,
usando o relacionamento de extensão.
Se houver casos de uso com semelhanças no comportamento, na estrutura e na finalidade, as partes
comuns podem ser fatoradas em um caso de uso base (pai) que é herdado por casos de uso
adicionais (filho). Os casos de uso filho podem inserir um novo comportamento e modificar o existente
na estrutura herdada do caso de uso pai. Consulte também Diretrizes
Você pode usar a generalização do ator para mostrar como os atores são especializações uns dos
outros.
Exemplo:
Considere parte do modelo de casos de uso de um Sistema de Gerenciamento de Ordens.
É útil separar o Cliente comum do Cliente de Internet, já que eles têm propriedades ligeiramente
diferentes. Entretanto, como o Cliente de Internet exibe todas as propriedades de um Cliente, você pode
dizer que esse Cliente de Internet é uma especialização do Cliente, indicado com uma generalização de
ator.
Os casos de uso concretos neste diagrama são a Ordem por Telefone (iniciada pelo ator Cliente) e Ordem
pela Internet (iniciada pelo Cliente de Internet). Esses casos de uso são variações do caso de uso mais
geral Inserir Ordem, que neste exemplo é abstrato. O caso de uso Solicitar Catálogo representa um
segmento opcional de comportamento que não é parte da principal finalidade de Inserir Ordem. Ele foi
fatorado em um caso de uso abstrato para simplificar o caso de uso Inserir Ordem. O caso de uso Fornecer
Dados do Cliente representa um segmento do comportamento que foi fatorado, desde que seja uma função
separada da qual apenas o resultado esteja afetando o caso de uso Inserir Ordem. O caso de uso Fornecer
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 12

13. Dados do Cliente também pode ser reutilizado em outros casos de uso. Tanto o caso de uso Solicitar
Catálogo quanto o Fornecer Dados do Cliente são abstratos neste exemplo.
Este diagrama de casos de uso mostra parte do modelo de casos de uso de um Sistema de Gerenciamento
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 13

14. 9. Especificações em Linguagem Natural Estruturada
É UMA FORMA RESTRITA DA LINGUAGEM NATURAL, QUE SE DESTINA A ESCREVER
REQUISITOS DE SISTEMA.
A vantagem dessa linguagem é que ela mantém a facilidade de expressão e compreensão da linguagem
natural, mas GARANTE QUE ALGUM GRAU DE UNIFORMIDADE seja imposto à especificação,
obtido pelo uso de templates.
O RUP propõe um padrão para especificação de requisitos de sistema, usando linguagem natural
estruturada, chamado “ESPECIFICAÇÃO OU DESCRIÇÃO DE CASO DE USO”, como segue:
Caso de Uso: Fazer checkin de hóspede.
Descrição: Realiza a hospedagem eletrônica do hóspede no sistema.
Fluxo principal:
1. O recepcionista seleciona apto disponível;
2. O recepcionista digita os dados pessoais do hóspede;
3. O recepcionista informa o desconto combinado;
4. O recepcionista confirma checkin.
5. O sistema solicita confirmação de impressão.
6. O sistema registra dados no banco de dados;
7. O sistema imprime comprovante de checkin.
8. O caso de uso termina.
Fluxos alternativos:
1. O recepcionista não informou todos os dados exigidos, o sistema emite uma
mensagem com uma lista de itens não fornecidos e sugere que os forneça.
2. Por algum motivo não é possível realizar as alterações requisitadas. Neste caso o
sistema informa o problema e sugere que o processo seja refeito.
Entradas: Número do apto, dados pessoais do hóspede, valor da diária e desconto.
Origem: Número do apto, dados pessoais do hóspede e desconto são informados pelo
usuário; Valor da diária é obtido da base de dados.
Saída: Confirmação de hospedagem.
Destino: Impressora padrão (usuário) e base de dados.
Pré-condição: A seleção de um apto disponível.
Pós-condição: Dados gravados na base de dados e botão do apto exibido em vermelho,
indicando que está ocupado.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 14

15. 9. O Documento de Requisitos de Software
Às vezes chamado de Especificação de Requisitos de Software é a declaração oficial do que é exigido dos
desenvolvedores de sistema. Ele deve conter os requisitos de usuário e de sistema.
O documento de requisitos tem um conjunto diversificado de usuários, abrangendo desde a alta gerência
da organização até os engenheiros responsáveis pelo desenvolvimento do software. A figura abaixo
mostra os possíveis usuários do documento e como o utilizam.
Especificam os requisitos e os lêem para verificar
Clientes se eles atendem a suas necessidades. Especificam
as mudanças nos requisitos.
Usam o documento de requisitos para elaborar
Gerentes proposta e planejar o processo de desenvolvimento
do sistema.
Usam os requisitos para compreender que sistema
Engenheiros de deve ser desenvolvido.
Sistema
Utilizam os requisitos para desenvolver testes e
Engenheiros de validação para o sistema.
teste
Usam os requisitos para ajudar a compreender o
Engenheiros de sistema e as relações entre suas partes.
manutenção
Pontos-Chave
• Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem
restrições sobre sua operação e implementação.
• Os requisitos funcionais são declarações de funções que o sistema deve fornecer ou são descrições
de como alguns cálculos devem ser realizados. Os requisitos de domínio são requisitos funcionais,
provenientes de características do domínio de aplicação.
• Os requisitos não funcionais são os requisitos do produto, que restringem o sistema a ser
desenvolvido, os requisitos de processo que se aplicam ao processo de desenvolvimento e os
requisitos externos. Eles freqüentemente se relacionam às propriedades emergentes do sistema e,
portanto, se aplicam ao sistema como um todo.
• Os requisitos de usuário se destinam às pessoas envolvidas no uso e na aquisição do sistema. Eles
devem ser escritos utilizando-se linguagem natural, tabelas e diagramas, de modo que sejam
compreensíveis.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 15

16. • Os requisitos de sistema se destinam a comunicar, de modo preciso, as funções que o sistema tem de
fornecer. Para reduzir a ambigüidade, eles podem ser escritos em uma linguagem estruturada de
algum tipo, que pode ser um formulário estruturado de linguagem natural.
• O documento de requisitos de software é a declaração explícita estabelecida dos requisitos do
sistema. Ele deve ser organizado de modo que possa ser utilizado pelos clientes de sistema e pelos
desenvolvedores de software.
________________________________________________________________________
Prof. M.Sc. Cleuber Fernandes 16