Requisitos De Software

23,775 views

Published on

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
23,775
On SlideShare
0
From Embeds
0
Number of Embeds
93
Actions
Shares
0
Downloads
549
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Requisitos De Software

  1. 1. Requisitos de Software
  2. 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. 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. 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. 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. 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. 7. Escopo de uma definição de requisitos
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×