You are on page 1of 26

Requisitos de Software

Referência Bibliográfica
s

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. KAR, Pradip ; BAILEY, Michelle. Characteristics of Good Requirements. Publicado no Simpósio INCOSE, 1996. URL: http://www.incose.org/rwg/writing.html.

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)

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.

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; 12% das principais causas de fracassos em projetos são oriundos de requisitos incompletos; 12% das principais causas de sucessos em projetos são oriundos de requisitos consistentes.

s

s

Quando a fase de requisitos de Software inicia ?
D efinição de R equisitos de Teste de Hardware

Contratante
R equis ição do S erviço Definição de R equis itos de S is tema

D efinição de R equisitos de Hardware

P rojeto de Hardware

C ontrato

Projeto de S is tema

R equis itos de Integ ração de S is tema

Oferta

D efinição de R equisitos de S oftware

P rojeto de S oftware

D efinição de R equisitos de Teste de S oftware

Escopo de uma definição de requisitos

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.

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”

Requisitos Funcionais
s s

s

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

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”.

Requisitos Não-Funcionais
s

s

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. Requisitos de processo podem ser também especificados baseados em uma ferramenta CASE, liguagem de programação ou método de desenvolvimento. 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.

Requisitos de Domínio
s s

s

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

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

Levantamento
Levantamento
FAZ FAZ US A US A DE PENDE PE NDE DE US A FAZ

C oleta de Dados

Identif. de fontes de informação

Pes s oal

C omunicação

Métodos Pontos de Vis ta

Ferramentas

Especificação
Es pecificação
FAZ FAZ IDE NTIFIC A FAZ FAZ

Identificação

Validação

Org anização R equis itos Derivados

R edação

Modelagem
Modelag em
US A E S C OLHE FAZ FAZ US A

Ferramentas

B as e do Projeto

Modelos R epres entação G ráfica

Validação

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.

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.

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.

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

Problemas Comuns: Redigir implementações ...
s

s

s

As especificações deveriam estabelecer O QUE é necessário, não COMO a necessidade será atendida. 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. 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.

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. O requisito real seria: – O sistema deve apresentar ao usuário, quando requerido, os relatórios disponíveis para a seleção.

s

Problemas Comuns: Uso de termos incorretos
s

s 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) Usar preferencialmente frases na afirmativa e não na negativa. 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.

Problemas Comuns: Uso de sentenças confusas
s

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 ... Existem duas situações que devem ser evitadas nesse caso: A armadilha do sujeito e textos mal redigidos.

Problemas Comuns: Omissão
s

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 Outra técnica utilizada é o uso de check-lists.