técnicas essenciais para identificar requisitos faltando?

Question

Um projecto inicial de especificação de requisitos foi concluído e agora é hora de fazer um balanço de requisitos, rever a especificação . Parte deste processo é certificar-se de que não existem lacunas consideráveis ??na especificação. Escusado será dizer que as lacunas levar a estimativas altamente imprecisos, aumento do escopo inevitável mais tarde no projeto e, finalmente, a uma marcha da morte.

O que são os bons, técnicas eficientes para localizar desaparecidos e implícitas requisitos?

• Esta pergunta é sobre techiniques conselhos práticos, não gerais, princípios ou diretrizes.
• requisitos Faltando algo crucial para a integridade do produto ou serviço, mas não pensado ou esquecido,
• exigências implícitas são algo que os usuários ou clientes naturalmente supor vai ser uma parte padrão do software sem ter que ser explicitamente solicitado.

_{Estou feliz de resposta re-visita aceita, contanto que alguém submete melhor, solução mais abrangente.}

Answer 1

avaliar o ciclo de vida dos elementos do modelo em relação a um modelo genérico / total como

acquisition --> stewardship --> disposal

• você sabe onde cada entidade vem e como você está indo para obtê-lo em seu sistema?
• você sabe onde cada entidade, uma vez adquirida, irá residir, e por quanto tempo?
• você sabe o que fazer com cada entidade quando ela não é mais necessária?

para uma análise mais de grão fino do ciclo de vida das entidades no spec, fazer uma matriz de cru para as principais entidades nos requisitos; esta é uma matriz com as operações / aplicações como as linhas e as entidades como as colunas. Em cada célula, colocar um C, se a aplicação cria a entidade, para R Lê, L para Actualizações, D para Exclui, ou E para "edições"; 'E' abrange C, R, L, e D (mais 'mestre tabela de manutenção' aplicações será Es). Em seguida, verificar cada coluna para C, R, L, e D (ou E); se alguém está em falta (exceto E), descobrir se ela é necessária. As linhas e colunas da matriz podem ser rearranjados (manualmente ou utilizando análise de afinidade) para formar grupos de entidades coesivas e aplicações que geralmente correspondem aos subsistemas; isso pode ajudar com distribuição sistema físico mais tarde.

Também é útil para adicionar uma coluna entidade "Usuário" para a matriz bruto e especificar para cada aplicação (ou recurso ou área funcional ou o que você quiser chamá-os de processamento de aspectos / comportamentais dos requisitos) se leva entrada de o utilizador, produz uma saída para o utilizador, ou interage com o utilizador (eu uso eu, o e N para este, e sempre que o usuário da primeira coluna). Isso ajuda a identificar onde interfaces de usuário para entrada de dados e relatórios serão necessários.

o objetivo é verificar a integridade da especificação; as técnicas acima são úteis para verificar se o ciclo de vida das entidades são 'fechado' com respeito às entidades e aplicações identificadas

Answer 2

Continuação comunicação, freqüente, franco e de duas vias com o cliente parece-me ser o principal 'técnica', tanto quanto eu estou em causa.

Answer 3

Depende.

Depende se você está sendo pago para entregar o que você disse que iria entregar ou entregar software de alta qualidade para o cliente.

No primeiro caso, simplesmente eliminar a ambigüidade das especificações e, em seguida, construir o que você concordou. Tente ficar longe de qualquer coisa não mensuráveis ??(como "fast", "cool", "mal-humorado", etc ...).

Neste último caso, o que Galwegian disse + tempo ou simplesmente cortar tudo não absolutamente drop-dead crítica e compilação que tão rapidamente como você pode. Produção tem uma maneira notável de iluminar o que você perdeu em Análise.

Answer 4

Veja como você encontrar os requisitos que faltam.

1. Break os requisitos para baixo em pequenos incrementos pequenos. Muito pequeno. Algo que pode ser construído em duas semanas ou menos. Você vai encontrar um monte de lacunas.

2. Priorizar aqueles em que seria melhor ter primeiro, o que está próximo para baixo ao que realmente não importa muito. Você verá que alguns dos gap-fillers não importava. Você também vai descobrir que alguns dos "requisitos" originais são apenas desejável.

3. Debate as diferenças de opinião quanto ao que é mais importante para os usuários finais e porquê. Dois usuários terão três pareceres. Você verá que alguns usuários não têm nenhum indício, e nenhuma de suas "exigências" são obrigatórios. Você verá que algumas pessoas não têm coluna vertebral, e as coisas não são corajosos o suficiente para dizer em voz alta são "necessárias".

4. Obter um consenso no topo dois ou apenas três. Não discuta a cada nuance. Não é possível software enVision. Não é possível para qualquer um imaginar o software vai ser como e como eles vão usá-lo. A maioria das pessoas "requisitos" são descrições de como a luta para o trabalho em torno do negócio inadequada processa eles estão presos com hoje.

5. Criar a maior prioridade, parte mais importante em primeiro lugar. Dê-lo aos usuários.

6. GOTO 1 e repita o processo.

"Wait", você diz: "E sobre o orçamento global?" O que sobre isso? Você nunca pode saber o orçamento global. Faça o seguinte.

Olhe para cada incremento definido na etapa 1. Fornecer um preço-per-incremento. Em ordem de prioridade. Dessa forma, alguém pode escolher tanto ou tão pouco como eles querem. Não há nenhuma grande, assustador "Big Orçamental Estimativa Com Muitos Zeroes". É tudo negociável.

Answer 5

Tenho vindo a utilizar uma metodologia de modelagem chamado Comportamento Engenharia (BE) que utiliza o texto especificação original para criar o modelo resultante quando você tem o modelo é mais fácil identificar ausentes ou incompletos seções das exigências.

Eu tenho usado o methodolgy em cerca de seis projectos até agora variam de menos de um requisitos houndred para mais de 1300 requerimentos. Se você quiser saber mais Gostaria de sugerir indo para www.behaviorengineering.org há alguns realmente bons trabalhos sobre a metodologia .

A empresa em que trabalho criou uma ferramenta para realizar a modelagem. O ritmo de trabalho para realmente criar o modelo é de cerca de 5 requisitos para um novato e um especialista sobre 13 requerimentos por hora. A coisa legal sobre o methodolgy é que você não precisa saber realmente nada sobre o domínio da especificação é escrito para. Usando apenas o texto do usuário, como substantivos e verbos do modelador vai encontrar lacunas no modelo em um período muito curto de tempo.

Espero que isso ajude

Michael Larsen

Answer 6

Como sobre a construção de um protótipo?

Answer 7

Ao ler toneladas de literatura sobre os requisitos de software, encontrei esses dois livros interessantes:

• Problem Frames: Análise e Estruturação de Problemas de Desenvolvimento de Software por Michael Jackson (e não um cantor! :-).

• Requisitos de Software práticas: Um manual de conteúdo e estilo por Bendjamen Kovitz.

Estes dois autores realmente se destacar da multidão, porque, na minha humilde opinião, eles estão fazendo um bom tentativa de transformar o desenvolvimento de requisitos em um processo muito sistemático - mais como engenharia de arte ou magia negra. Em particular, a definição de quais os requisitos que são realmente de Michael Jackson -. Eu acho que é a mais limpa e mais precisa que eu já vi

Eu não faria um bom serviço para estes autores tentam descrever seu aproach em um curto postagem aqui. Então eu não vou fazer isso. Mas vou tentar explicar, porque a sua abordagem parece ser extremamente relevante para a sua pergunta : ele permite que você se resumem a maioria (não todos, mas a maioria!) De vocês o trabalho de desenvolvimento requisitos para o processamento de um bando de listas de controlo * dizendo o que os requisitos que você tem que definir para cobrir todos os aspectos importantes do problema inteiro do cliente. Em outras palavras, essa abordagem é suposto para minimizar o risco de perder importantes requisitos (incluindo aqueles que muitas vezes permanecem implícitos) .

Eu sei que pode soar como mágica, mas não é. Ele ainda leva um esforço mental substancial para chegar a esses "mágicos" check-lists: você tem que articular o problema do cliente em primeiro lugar, em seguida, analisá-lo completamente, e, finalmente, dissecá-lo para os chamados "quadros problemáticos" (que vêm com aqueles mágica listas de verificação apenas quando eles se aproximam alguns quadros típicos problemáticas definidas por autores). Como eu disse, essa abordagem não prometo fazer tudo simples. Mas definitivamente promete tornar o processo de desenvolvimento de requisitos tão sistemática quanto possível.

Se o desenvolvimento requisitos em seu projeto atual já é muito longe desde o início, pode não ser viável para tentar aplicar a abordagem do problema Frames neste momento (embora isso depende muito de como suas necessidades atuais são organizadas). Ainda assim, eu recomendo ler esses dois livros -. Eles contêm uma grande quantidade de sabedoria que você ainda pode ser capaz de aplicar para o projeto atual

As minhas últimas notas importantes sobre esses livros:

• Tanto quanto eu entendo, o Sr. Jackson é o autor original da idéia de "frames problema". Seu livro é bastante acadêmico e teórico, mas é muito, muito legível e até mesmo entreter.

• Mr. livro Kovitz' tenta demonstrar como ideias Sr. Jackson pode ser aplicado na prática real. Ele também contém toneladas de informações úteis sobre como escrever e organizar as necessidades reais e documentos de requisitos.

Você pode provavelmente começar do livro do Kovitz'(e referem-se ao livro de Mr. Jackson apenas se você realmente precisa cavar mais fundo no lado teórico). Mas estou certo de que, no final do dia, você deve ler os dois livros, e você não vai se arrepender disso. : -)

HTH ...

Answer 8

Eu concordo com Galwegian. A técnica descrita é muito mais eficiente do que a "esperar por cliente para gritar para nós" abordagem.