Como você resolver ambiguidades na especificação?

Question

Eu preciso de alguns conselhos sobre como resolver as ambiguidades dentro das especificações de aplicação. Como um exemplo simples,

Quando um usuário não consegue autenticar depois de um número de vezes, enviar uma notificação para TI.

No exemplo acima, não está claro quantas vezes "várias vezes" é. Não está claro e eu não posso simplesmente definir um limite aleatório como 1000 vezes.

Como você iria sobre para resolver porções pouco claras em quaisquer especificações? (Não apenas o que eu mencionei)

E, também, que tipo de tópicos que eu deveria procurar no Google ou em livros para este tipo de situações? Engenharia de software? Desenvolvimento ágil? Não tenho a certeza por onde começar.

Qualquer votos know-how e dicas seria muito apreciada.

Answer 1

Se você está acompanhando suas necessidades de uma maneira formal, você pode fazer seus pressupostos e documento-los como requisitos derivados:

Exemplo:

Requisito Usuário:

Req. 1: Quando um usuário não consegue autenticar depois de um número de vezes, enviar uma notificação para TI

Requisitos Derivados:

Req 1.1 Quando um usuário não consegue autenticar depois de três (3) tentativas, o sistema irá suspender a conta e enviar um email para a mesa de suporte de TI.

Req 1.1.1 O e-mail suspensão da conta vai especificar o seguinte:

• O nome da conta do usuário.
• O endereço IP do computador a partir do qual foram feitas as tentativas de autenticação.

Tenha o cliente, ou parte interessada se o cliente não estiver disponível, analisar e aprovar os requisitos derivados.

Para obter mais informações, "gerenciamento de requisitos" Google ou "engenharia de requisitos". O setor de indústria de defesa é carregado com exemplos e modelos, talvez seja demais;)

Alguns eu já marcada:

• Guia para Especificação Escrita
• escrever software Requisitos Especificações

Answer 2

responder ao cliente com perguntas exatas que você possa ter. Essa é a melhor opção, se disponível. Se não, então torná-lo configurável pelo usuário final (cliente).

Answer 3

comunicar com (preferencialmente por essa ordem):

• Analistas de Negócios
• Cliente (pessoa (s) a pagar para o produto final)
• Usuários Finais

Answer 4

Construir ou protótipo, então mostrá-lo para as pessoas que escreveram o spec.

ambiguidades são muito mais fáceis de limpar, falando sobre a coisa real, em vez de um pedaço de papel que diz como a coisa vai funcionar.

Answer 5

Você está cismar isso.

1. O 'número de vezes' valor pode ser facilmente colocá-lo no web.config
2. Set-lo ao seu valor apropriado assumido. (Não se preocupe com estar errado)
3. Envie um e-mail ao seu gerente com sua suposição, e como eles podem alterá-lo se sua suposição é incorreta.

A parte notificação da especificação pode ser assumida se cada outra notificação aplicativo é um e-mail (que não é irrealista). Caso contrário, pergunte antes de fazer qualquer coisa.

Eu não sou contra pedindo esclarecimentos claro. Mas, eu descobri se uma suposição pode ser feita com pouca ou nenhuma desvantagem , é melhor fazê-lo. Afinal eles contrataram-lo a resolver problemas não trazê-los mais. ;-)

E curiosamente; Você provavelmente vai descobrir que a maioria de seus pressupostos será de qualquer maneira correta.

Answer 6

A partir desse exemplo, eu iria voltar para o cliente e perguntar se eles querem que o "número de vezes" para ser configurável. Ele também pode levar a perguntas como:

1) Quem vai manter o número de vezes configurado. 2) Será que eles vão precisar de uma interface do usuário para exibir essas configurações e alterá-las.

A adoção de um processo de desenvolvimento mais ágil será também ajuda. Por exemplo, mostrando-lhes um exemplo que permite três chances para entrar irá demonstrar a funcionalidade e talvez levá-los a dizer-lhe o número.

A importância de esclarecer as mudanças de requisitos onde a resposta à pergunta afetarão o tempo, a complexidade e custo do projeto.

Answer 7

Existem algumas rotas diferentes que eu assumir as ambiguidades dependendo de quem está disponível:

1) Gerente de Projetos / Analista de Negócios -> Estes são provavelmente o mais próximo para o projeto que pode ser capaz de resolver problemas de ajuda com as especificações rapidamente. Isso pode envolver a pedir aos outros e voltar para você mais tarde, mas que deve ser aceitável.

2) Especialista Analyst / Officer -> Por exemplo, no caso que você menciona onde existem implicações de segurança, se houver um agente de segurança que pode ter uma política para impor sobre isso e deve estar na discussão. Outro exemplo poderia ser ter um analista de redes de olhar para a arquitetura de uma perspectiva de hardware que pode ser útil em alguns casos.

3) Product Owner -> Quem é responsável por definir a aplicação. Note-se que esta não é uma pessoa técnica, de modo a ser específico e com recomendações podem ser úteis se você bater em cima de um "Você sabe, eu não tinha pensado nisso ..." resposta.

4) lidera o Grupo Gestor / Team -.> Se tudo isso falhar, vá para o chefe e pedir esclarecimentos

"Requisitos Gathering" ou "Análise de Requisitos" são termos comuns para esta parte do "Ciclo de Vida de Desenvolvimento de Software" ou "Desenvolvimento de Sistemas do Ciclo de Vida" para jogar fora mais alguns termos que você poderia procurar e encontra vários artigos.

Answer 8

A melhor maneira é escrever breves histórias alternativas de Usuários (Casos de Uso) que descrevem como as diferentes opções que afetam o usuário, e pedir ao cliente para escolher qual (is) precisam de ser apoiados.

Muitas vezes uma ambigüidade na especificação reflete ambigüidade na mente do cliente - eles simplesmente não percebi isso por si próprios, no entanto, assim que esta abordagem ajuda a ambos. (Use notas escritas - nada técnico -. Para descrever as coisas em seus termos)

Answer 9

Se a especificação não é exata, talvez ele simplesmente não importa? Não crucial para qualquer outra coisa para o trabalho? Fazer uma chamada, deixe it ser 1000. Certifique-se de que não está codificado. Uma boa idéia é colocá-lo em algum arquivo de configuração (mas não exponha a interface de usuário final, porque o usuário normalmente tem ainda menos idéia do que você).

Se é uma questão de interoperabilidade, então o que fazer outras caras fazem? É it 200 no Windows? Do que fazer isso 200. Agora você combinar Windows e especificações - não é mau: -)

No caso de você descobrir a sua chamada era ruim e it deveria ter sido 1500, pelo menos você pode dizer a seus usuários como corrigi-lo sem reinstalar você software.

Answer 10

Bem no corporativo Empresa isso significa que ele segue as políticas gerais de Empresa.

Na verdade, quando eu escrevo especificação mim, eu não me incomodo com essas especificações gerais, eu apenas dizer referem-se a políticas e ir direto para o núcleo de necessidades comerciais específicas.

Answer 11

Para que você possa fazer um grupo de foco, ou você pode se comunicar com o cliente / partes interessadas apropriado.