O documento discute requisitos de software, referenciando fontes bibliográficas e definindo termos como requisito, requisitos funcionais e não funcionais. Também aborda características de bons requisitos, problemas comuns e etapas para especificação de requisitos.

1. Requisitos de Software

2. Referência Bibliográfica
s HOOKS, Ivy. Writing Good Requirements. A Requirements Working Group
Information Report. Publicado no Third International Symposium of the
INCOSE – Volume 2, 1993. URL: http://www.incose.org/rwg/writing.html.
s KAR, Pradip ; BAILEY, Michelle. Characteristics of Good Requirements.
Publicado no Simpósio INCOSE, 1996. URL:
http://www.incose.org/rwg/writing.html.

3. O que é um requisito?
 Um requisito pode variar desde uma sentença, em alto
nível, indicando um serviço ou uma restrição de um
sistema até uma especificação matemática detalhada.
 Os requisitos podem servir para uma dupla função:
– Pode ser a base para a formulação de uma proposta a um
contrato (lado do proponente).
– Pode ser a base do contrato propriamente dito (lado do
contratante)

4. Definições
“Something required; something wanted or needed”.
Webster’s Ninth New Colegiate Dictionary
(1) “A condition or capability that must be met or processed by
a system (...) to satisfy a contract, standard, specification, or
other formally imposed document”.
(2) “A condition or capability needed by a user to solve or
achieve an objective”.
IEEE 729
(3) “Uma sentença que identifica uma capacidade,
característica física, ou fator de qualidade que limita um
produto ou necessidade de processo para as quais uma
solução será proposta” IEEE Std 1220-1994.

5. Segundo Miranda (2002 apud SANTOS, 2007, p.12)
s 50% dos principais problemas/defeitos de software são
oriundos da fase de especificação de requisitos;
s 12% das principais causas de fracassos em projetos
são oriundos de requisitos incompletos;
s 12% das principais causas de sucessos em projetos
são oriundos de requisitos consistentes.

6. Quando a fase de requisitos de Software inicia ?
D efinição de
R equisitos de
Teste de
Hardware
D efinição de
P rojeto de
R equisitos de
Hardware
Hardware
Contratante
R equis ição Definição de R equis itos de
Projeto de
do C ontrato R equis itos de Integ ração de
S is tema
S erviço S is tema S is tema
D efinição de
P rojeto de
R equisitos de
S oftware
S oftware
Oferta
D efinição de
R equisitos de
Teste de
S oftware

7. Escopo de uma definição de requisitos

8. Tipos de Requisitos
s Requisitos do Usuário
– Texto em liguagem natural, diagramas do sistema e suas
restrições operacionais. Escritos para o cliente.
s Requisitos do Sistema
– Documento estruturado apresentando uma descrição detalhada
dos serviços que o sistema deve oferecer. Escrito como um
contrato entre o cliente e o contratado.
s Requisitos de Software
– Descrição detalhada do software que serve como base para o
projeto e implementação.

9. Tipos de Requisitos
• Requisitos Funcionais
• Especificação dos serviços que o sistema deve prover,
como o sistema deve reagir a certos inputs, como
deveria ser o comportamento do sistema em certas
situações
• Deve determinar o que se espera que o software faça,
sem a preocupação de como ele faz.
• Exemplos:
• “O software deve possibilitar o cálculo dos gastos diários, semanais,
mensais e anuais com pessoal”.
• “O software deve emitir relatórios de compras”
• “Os usuários devem poder obter o número de aprovações,
reprovações e trancamentos em todas as disciplinas”

10. Requisitos Funcionais
s Descrevem as funcionalidade e serviços que o
sistema deve oferecer.
s Dependem do tipo do software, potenciais
usuários e do tipo de sistema onde o software
será utilizado.
s Requisitos funcionais do usuário podem ser de
alto nível, porém os requisitos funcionais do
sistema devem ser especificados em detalhes.

11. Tipos de Requisitos
•Requisitos não-funcionais
• Restrições aos serviços ou funções oferecidas pelo
sistema tais como restrições de tempo, restrições quanto
ao processo de desenvolvimento, padrões.
• Qualidades globais de um software, como
manutenibilidade, usabilidade, desempenho, custos
• Exemplos:
•“O tempo de resposta do sistema deve ser inferior a 30 segundos”
•“O tempo de desenvolvimento não deve ultrapassar seis meses”
•“O software deve ser operacionalizado no sistema específico”.

12. Requisitos Não-Funcionais
s Definem as propriedades do sistema e suas restrições, isto
é, confiabilidade, tempo de resposta. Restrições podem
ser capacidade de dispositivos de I/O, representações
gráficas, etc.
s Requisitos de processo podem ser também especificados
baseados em uma ferramenta CASE, liguagem de
programação ou método de desenvolvimento.
s Requisitos Não-Funcionais podem ser mais críticos do que
os Funcionais. Se estes não são atendidos o sistema
pode perder sua utilidade.

13. Requisitos de Domínio
s Derivados a partir do domínio da aplicação.
s Descrevem as características do sistema refletindo o
domínio.
s Podem ser novos requisitos funcionais, restrições ou
definir computações específicas.

14. Fases
s A definição de requisitos pode ser encarada
como constituída por três atividades:
– Levantamento (Elicitação)
– Especificação
– Modelagem
– Validação

15. Levantamento
Levantamento
FAZ
FAZ
FAZ
US A
C oleta de Dados Identif. de fontes
US A
US A
de informação
DE PENDE
PE NDE
DE
Pes s oal C omunicação
Métodos Ferramentas
Pontos de Vis ta

16. Especificação
Es pecificação
FAZ
FAZ
FAZ
FAZ
IDE NTIFIC A
Identificação Validação
Org anização R edação
R equis itos
Derivados

17. Modelagem
Modelag em
US A
US A
E S C OLHE
FAZ
FAZ
Ferramentas B as e do Projeto
Modelos Validação
R epres entação
G ráfica

18. Escrevendo Bons Requisitos
s Um bom requisito especifica de maneira Clara algo que é
Necessário, Verificável e Atingível.
Necessário Atingível
– Claro. Cada requisito deve expressar um único
pensamento, ser conciso e simples. Isso é importante para
que o requisito não seja mal interpretado. Deve ser fácil de
se ler e entender.
– Necessário. Se existe alguma dúvida sobre a
Necessário
necessidade de um requisito, então pergunte: Qual é a pior
coisa que pode acontecer se este requisito não for
incluído? Se você não encontrar uma resposta de algum
tipo de conseqüência, então você provavelmente não
necessita do requisito.

19. Escrevendo Bons Requisitos
– Verificável. Da mesma maneira que você escreve um
Verificável
requisito, determine como você irá verificá-lo. Para ser
verificável, o requisito deve conter algo que possa ser
verificado através de exames, análise, teste ou
demonstração. Requisitos subjetivos ou com palavras
subjetivas como “fácil”, “amigável”, não são verificáveis.
Determine o critério para aceitação. Este passo irá
ajudar a garantir que o requisito é verificável.
– Atingível (realizável ou possível). Para ser atingível,
possível)
o requisito precisa ser tecnicamente realizável e
delimitado por um orçamento, prazos e outras
restrições.

20. Escrevendo Bons Requisitos –
Outras características
– Livre de Implementação. As especificações
Implementação
devem refletir O QUE e não COMO o
requisito deve ser satisfeito. O requisito não
deve refletir o projeto, implementação ou
descrever uma operação. Requisitos de
Interface são exceções.

21. Problemas Comuns
s A seguir são apresentados os problemas mais
comuns na redação de requisitos
– Considerações equivocadas
– Redigir implementações (COMO) ao invés de requisitos
(O QUE)
– Descrever operações ao invés de requisitos
– Uso de termos incorretos
– Uso de sentenças confusas
– Omissão
– Super especificação

22. Problemas Comuns: Redigir implementações ...
s As especificações deveriam estabelecer O QUE é
necessário, não COMO a necessidade será atendida.
s Existem nesse caso dois potenciais perigos:
– Forçar prematuramente uma condição projeto quando não
deveria ser essa a intenção.
– Levar a sensação de que todos os requisitos foram
cobertos.
s Apesar de aparentemente claro o conceito, a separação do
O QUE do COMO pode ser difícil especialmente quando se
está falando de diferentes níveis de requisitos.

23. Problemas Comuns: Descrever operações ao ...
s Veja o exemplo abaixo:
– Ao abrir o menu de relatórios, o usuário poderá
selecionar o relatório desejado através da tecla
ENTER.
s O requisito real seria:
– O sistema deve apresentar ao usuário, quando
requerido, os relatórios disponíveis para a seleção.

24. Problemas Comuns: Uso de termos incorretos
s Para especificar um requisito devem ser escritas frases
imperativas, utilizando-se de palavras tais como:
– Português: Deve, Precisa
– Inglês: Shall, Must e Will (Should)
s Usar preferencialmente frases na afirmativa e não na
negativa.
s Evitar as palavras:
– Suporte, adequado, como um mínimo, como aplicável,
fácil, como apropriado, mas não limitado a, efetivo,
prático, etc, e/ou, user friendly, rápido, suficiente.

25. Problemas Comuns: Uso de sentenças confusas
s Os requisitos deveriam ser fáceis de ler e entender. Cada
requisito pode ser usualmente escrito no formato:
– O sistema deve prover ...
– O sistema deve realizar ...
– O sistema deve possuir ...
s Existem duas situações que devem ser evitadas nesse
caso: A armadilha do sujeito e textos mal redigidos.

26. Problemas Comuns: Omissão
s A omissão de itens em uma especificação pode ser
minimizada através do uso de padrões tais como:
– IEEE Std 830-1993 - Recommended Practices for
Software Requirements Specification
– DOD MIL-STD-490A - Specification Practices
– ECSS-E-10-05A – Space Engineering – Functional
Analysis
s Outra técnica utilizada é o uso de check-lists.