Quando os requisitos de revisão de especificação que “pecados mortais” precisam ser abordadas? [fechadas]
-
06-07-2019 - |
Pergunta
Ao rever especificação de requisitos (que inclui requisitos funcionais, não funcionais, restrições etc) no entanto pequeno ou grande é o que são os "pecados mortais" cometidos por autores de olhar para fora?
Por favor lista não mais de 7 coisas mais essenciais (em ordem decrescente de gravidade) que está sendo feito (ou não fez) em requisitos de especificação ter efeito adverso sobre a qualidade do produto de software. Menos de 7 é perfeitamente OK.
Solução
OK, isso é mais do que 7, mas bons requisitos têm os seguintes atributos:
- Único . Há qualquer outra requisitos que são semelhantes?
- Identificação , pode a exigência de ser identificada exclusivamente? ela pode ser rastreada em todo o seu processo de desenvolvimento?
- Completo . Falta alguma coisa ou esquecida? É completa? Será que incluem tudo o necessário para fazer -lo ficar sozinho?
- Accurate . Está correto? Será que definir adequadamente o objetivo? Existem erros?
- inequívoca . É a descrição exata e não vago? Existe uma única interpretação? É que seja fácil de ler e entender?
- Consistente . É a descrição do o recurso escrito para que ele não entram em conflito com outros itens a especificação?
- Relevante . É a declaração necessária para o recurso? É extras informação que deve ser deixado de fora? É rastreável a um necessidade do cliente original?
- Viável . Pode ser implementado com o disponível de pessoal, ferramentas e recursos dentro do orçamento especificado e agenda?
- Código-livre . Será que a especificação ficar com a definição do produto e não o design de software subjacente, arquitetura e código?
- Testable . ele pode ser testado? Basta informações, desde que um testador poderia criar testes para verificar se a exigência é satisfeita?
- de Prioridade . É mais ou menos importante que outros requisitos?
- usa o Active Voz . Será que o especificação de usar a voz ativa? Passive voz nem sempre especificar quem ou o que executa a ação.
- categorizados . É a exigência agrupados logicamente com semelhante requisitos? categorias possíveis são: Comportamento, Performance, Interface, Estruturas de Dados / Elements, Implementação, Compliance / Qualidade, Operacional (Confiabilidade, Segurança, Segurança), Derivado / Engineered.
A decentes requisitos ferramenta pode automatizar rastreamento / fazer cumprir alguns dos acima, como identificáveis, priorizados, categorizados, mas apenas uma revisão pela equipe pode verificar o resto. A chave está em treinar sua equipe sobre esses atributos, levando-os a prática através da leitura bons e maus exemplos de exigências, e estabelecer um processo de revisão eficiente que os requisitos de cheques suficientemente cedo no seu ciclo de vida como para ter um impacto sobre as actividades a jusante.
Outras dicas
requisitos em falta - muito mais difícil de pegar. Separando os requisitos em seções claras (por exemplo, segurança, desempenho, estilo, etc) pode tornar mais fácil essa de detectar.
Características, Tempo, Qualidade - escolher dois. certifique-se os requisitos não impõem todos os três em sua equipe.
Empurre para trás requisitos que tentam controlar o seu processo.
Peça priorização clara desde o início.
insistir em uma claros critérios de aceitação para cada requisito.
Requisitos deve ser específica e inequívoca em relação ao que é necessário, mas deve ser menos sobre a forma de cumprir os requisitos.
Fazendo suposições -. Verifique que qualquer coisa que se parece com uma suposição tem realmente sido verificada
mal formulada frases que contenham mais do que uma exigência. Separá-los de um lugar para torná-los mais claro e mais fácil de assinalar fora como feito.
Requisitos que não são fáceis de verificar como sendo atendidas -. Mudar para uma forma que pode ser mais facilmente marcado como conheceu ou não ao rever
A exigência não especifica quem / o que faz a coisa.
"The invoice is reconciled to the purchase order."
Isso significa que o sistema faz algo, ou o usuário?
O pior que eu já vi em um projeto que eu codificado para: -
The system shall interface to SAP as required.
Em primeiro lugar, um requisito com "conforme necessário", em que é estúpido. Que uma linha deve ter custado $ 400k. O cliente manteve apontando para ele e dizendo que diz que você vai fazer, blá, blá, blá.
Com rigorosas -. Se possível especificar tolerâncias relevantes
Requisitos ambíguos são ruins.
Unverifiable e requisitos não quantificáveis ??dobrar-lo.
Naturalmente, tudo isso depende de que tipo de exigência que você começa. Estou acostumado a típica aplicação Gui ou Web, processos batch e
- Coloque standars em primeiro lugar, que não tem que ser definido em cada especificação, se referem a eles
- Faça-o tão pequeno quanto possível - raramente se pode ler um documento de 200 páginas e manter tudo em mente
- Seja específico, mesurable, concreto
- exemplos fazer (desenhos, representando escritos)
- Explicar o propósito antes de descrever o funtction
- padrões inlcude desempenho, standars resiliência, instruções de implementação, documentação para as operações necessárias
Eu também tenho um único conselho para o revisor: sabe seu assunto
Você tem que ter um conhecimento muito detalhado do contexto da exigência, a necessidade do cliente específico, o ambiente técnico e talvez o mais importante que essa exigência será dirigido e qual o nível de compreensão mundial que eles têm.
Eu fiz muito mau experiência em projetos com muitas pessoas a rever as especificações desde o seu conhecimento individual era muito superficial. Você começa o feed back no mesmo nível, principalmente correções formais, mas a profunda falta da especificação só será descoberto muito recentemente no projeto.
Evitar 'palavras de doninhas' -. Qualquer linguagem que pode ser arrancada de seu contexto e feitos para som ruim é ruim
Certifique-se de tudo é absolutamente clara: vaga == Bad Thing (tm)
A minha recomendação e o que sempre faço antes de um novo projeto é verifique a lista de verificação no Página 42,43 de Código de Steve McConnell Conclua
O Wikpedia onisciente tem uma boa sinopse para Requisitos- http: //en.wikipedia. org / wiki / Requisito # Good_requirements . Eu diria que esses pontos, a falta de verificabilidade é o que é mais comum. Compreender a grande figura é importante na vida, no entanto, você precisa para soletrar as coisas de forma explícita em você requisitos, ex. O sistema deve ser responder rapidamente. Em vez disso, o sistema deve responder a todos os pedidos em menos de 2 segundos.
- Separação de arquitetura, interface, requisitos funcionais, não funcionais.
- O uso de notação inequívoca e consistente para descrever entidades
- critérios de entrada e de saída clara para os casos de uso
- diagramas de fluxo tem (mapas mentais têm a mesma finalidade como UML, e são mais fáceis de desenhar)
- Definir o escopo em termos claros, o que é coberto eo que não e onde é encontrar aqueles deixados desconhecido
- Have a rastreabilidade matriz
Você pode considerar ler alguns dos gestão Exigência e noreferrer documentos CMMI .
Também visitar Requisito Checklist e no Google por " critérios de boa Requisito".
Estes são projetados especificamente para criar processos que ajudam no desenvolvimento de software.