¿Técnicas esenciales para identificar los requisitos faltantes?

Question

Se ha completado un borrador inicial de la especificación de requisitos y ahora es el momento de hacer un inventario de los requisitos, revise la especificación . Parte de este proceso es asegurarse de que no haya brechas considerables en la especificación. No hace falta decir que las brechas conducen a estimaciones altamente inexactas, el alcance inevitable se arrastra más adelante en el proyecto y, en última instancia, a una marcha de la muerte.

¿Cuáles son las técnicas buenas y eficientes para identificar los requisitos faltantes e implícitos?

• Esta pregunta es sobre técnicas prácticas, no consejos generales, principios o directrices.
• Los requisitos que faltan son algo crucial para la integridad del producto o servicio, pero no pensado u olvidado,
• Los requisitos implícitos son algo que los usuarios o clientes suponen naturalmente que será una parte estándar del software sin tener que solicitarlos explícitamente.

_{Me complace volver a visitar la respuesta aceptada, siempre que alguien envíe una solución mejor y más completa.}

Answer 1

evalúe el ciclo de vida de los elementos del modelo con respecto a un modelo genérico / general como

acquisition --> stewardship --> disposal

• ¿Sabes de dónde proviene cada entidad y cómo vas a incorporarla a tu sistema?
• ¿Sabe dónde residirá cada entidad, una vez adquirida, y por cuánto tiempo?
• ¿sabe qué hacer con cada entidad cuando ya no es necesaria?

para un análisis más detallado del ciclo de vida de las entidades en la especificación, haga una matriz CRUDE para las entidades principales en los requisitos; esta es una matriz con las operaciones / aplicaciones como las filas y las entidades como las columnas. En cada celda, coloque una C si la aplicación crea la entidad, R para lecturas, U para actualizaciones, D para eliminaciones o E para " Ediciones " ;; 'E' abarca C, R, U y D (la mayoría de las aplicaciones de 'mantenimiento de la tabla maestra' serán Es). A continuación, compruebe cada columna para C, R, U y D (o E); Si falta uno (excepto E), averigüe si es necesario. Las filas y columnas de la matriz se pueden reorganizar (manualmente o mediante análisis de afinidad) para formar grupos cohesivos de entidades y aplicaciones que generalmente corresponden a subsistemas; esto puede ayudar con la distribución del sistema físico más adelante.

También es útil agregar un " Usuario " columna de entidad a la matriz CRUDO y especifique para cada aplicación (o característica o área funcional o como quiera llamar a los aspectos de procesamiento / comportamiento de los requisitos) si toma Entrada del usuario, produce Salida para el usuario o Interactúa con el usuario (uso I, O y N para esto, y siempre hago al Usuario la primera columna). Esto ayuda a identificar dónde se requerirán las interfaces de usuario para el ingreso de datos y los informes.

el objetivo es verificar la integridad de la especificación; las técnicas anteriores son útiles para verificar si el ciclo de vida de las entidades está 'cerrado' con respecto a las entidades y aplicaciones identificadas

Answer 2

La comunicación continua, frecuente, franca y bidireccional con el cliente me parece la "técnica" principal en lo que a mí respecta.

Answer 3

Depende.

Depende de si se le paga para entregar lo que dijo que entregaría o para entregar software de alta calidad al cliente.

Si es el primero, simplemente elimine la ambigüedad de las especificaciones y luego genere lo que acordó. Trate de mantenerse alejado de todo lo que no se pueda medir (como " rápido " ;, " cool " ;, " snappy " ;, etc ...).

Si es lo último, lo que Galwegian dijo + tiempo o simplemente corta todo lo que no es absolutamente crítico y constrúyelo tan rápido como puedas. La producción tiene una forma notable de iluminar lo que se perdió en el análisis.

Answer 4

Así es como encuentra los requisitos que faltan.

1. Divide los requisitos en pequeños incrementos. Realmente pequeño. Algo que se puede construir en dos semanas o menos. Encontrará muchas lagunas.

2. Priorice a aquellos en lo que sería mejor tener primero, lo que sigue a lo que realmente no importa mucho. Encontrarás que algunos de los rellenos de huecos no importaron. También encontrará que algunos de los "requisitos" originales " son simplemente deseables.

3. Debate las diferencias de opinión sobre lo que es más importante para los usuarios finales y por qué. Dos usuarios tendrán tres opiniones. Verá que algunos usuarios no tienen ni idea, y ninguno de sus "requisitos". son requeridos. Encontrarás que algunas personas no tienen espina dorsal, y las cosas que no son lo suficientemente valientes para decir en voz alta son " obligatorias " ;.

4. Obtenga un consenso sobre los dos o tres primeros solamente. No discutas todos los matices. No es posible visualizar software. Nadie puede imaginar cómo será el software y cómo lo usará. La mayoría de los requisitos de la gente son descripciones de cómo la lucha para evitar los procesos comerciales inadecuados con los que se estancan hoy en día.

5. Cree primero la parte más importante y de mayor prioridad. Dáselo a los usuarios.

6. GOTO 1 y repita el proceso.

" Espera " usted dice: "¿Qué pasa con el presupuesto general?" Que hay de eso Nunca se puede saber el presupuesto global. Haz lo siguiente.

Observe cada incremento definido en el paso 1. Proporcione un precio por incremento. En orden de prioridad. De esa manera, alguien puede elegir tanto o tan poco como quiera. No hay una estimación presupuestaria grande y aterradora '' con un montón de ceros ''. Todo es negociable.

Answer 5

He estado usando una metodología de modelado llamada Behavior Engineering (bE) que usa el texto de especificación original para crear el modelo resultante. Cuando tienes el modelo, es más fácil identificar las secciones faltantes o incompletas de los requisitos.

He utilizado la metodología en unos seis proyectos que van desde los requisitos de menos de uno a los más de 1300. Si desea saber más, le sugiero que vaya a www.behaviorengineering.org allí algunos documentos realmente buenos sobre la metodología .

La compañía para la que trabajo ha creado una herramienta para realizar el modelado. La tasa de trabajo para crear realmente el modelo es de aproximadamente 5 requisitos para un principiante y un experto de 13 requisitos por hora. Lo bueno de la metodología es que no necesitas saber realmente nada sobre el dominio para el que está escrita la especificación. Usando solo el texto del usuario, como sustantivos y verbos, el modelador encontrará huecos en el modelo en un período de tiempo muy corto.

Espero que esto ayude

Michael Larsen

Answer 6

¿Qué hay de construir un prototipo?

Answer 7

Mientras leía toneladas de literatura sobre los requisitos de software, encontré estos dos libros interesantes:

• Cuadros de problemas: análisis y amplificación; Estructurando problemas de desarrollo de software por Michael Jackson (¡no un cantante! :-).

• Requisitos prácticos del software: Manual de contenido y estilo por Bendjamen Kovitz.

Estos dos autores realmente se destacan entre la multitud porque, en mi humilde opinión, están haciendo un muy buen intento de convertir el desarrollo de requisitos en un proceso muy sistemático, más parecido a la ingeniería que al arte o la magia negra. En particular, la definición de Michael Jackson de cuáles son los requisitos realmente: creo que es la más limpia y precisa que he visto.

No haría un buen servicio a estos autores que tratan de describir su enfoque en una breve publicación aquí. Así que no voy a hacer eso. Pero intentaré explicar, por qué su enfoque parece ser extremadamente relevante para su pregunta : le permite reducir la mayoría (¡no todos, sino la mayoría!) De su trabajo de desarrollo de requisitos para procesar un montón de listas de verificación * que le indican qué requisitos debe definir para cubrir todos los aspectos importantes del problema de todo el cliente. En otras palabras, se supone que este enfoque minimiza el riesgo de perder requisitos importantes (incluidos los que a menudo permanecen implícitos) .

Sé que puede sonar como magia, pero no lo es. Todavía se necesita un esfuerzo mental sustancial para llegar a esas "magia" listas de verificación: primero debe articular el problema del cliente, luego analizarlo a fondo y, finalmente, diseccionarlo en los llamados "cuadros de problema". (que vienen con esas listas de verificación mágicas solo cuando coinciden estrechamente con algunos marcos de problemas típicos definidos por los autores). Como dije, este enfoque no promete hacer todo simple. Pero definitivamente promete hacer que el proceso de desarrollo de requisitos sea lo más sistemático posible.

Si el desarrollo de requisitos en su proyecto actual ya está bastante lejos del comienzo, puede que no sea factible intentar aplicar el Enfoque de marcos problemáticos en este momento (aunque depende en gran medida de cómo estén organizados sus requisitos actuales). Aún así, le recomiendo leer esos dos libros: contienen mucha sabiduría que aún puede aplicar al proyecto actual.

Mis últimas notas importantes sobre estos libros:

• Hasta donde yo entiendo, el Sr. Jackson es el autor original de la idea de "marcos problemáticos". Su libro es bastante académico y teórico, pero es muy, muy legible e incluso entretenido.

• Sr. El libro de Kovitz trata de demostrar cómo las ideas del Sr. Jackson pueden aplicarse en la práctica real. También contiene toneladas de información útil sobre cómo escribir y organizar los requisitos reales y los documentos de requisitos.

Probablemente puedas comenzar desde el libro de Kovitz (y referirte al libro del Sr. Jackson solo si realmente necesitas profundizar en el lado teórico). Pero estoy seguro de que, al final del día, deberías leer ambos libros y no te arrepentirás. :-)

HTH ...

Answer 8

Estoy de acuerdo con Galwegian. La técnica descrita es mucho más eficiente que la "espera de que el cliente nos grite". enfoque.