tools source open management for requirements-management

requirements-management - source - case tools for requirements management



Recopilación de requisitos (20)

Antes que nada, reúna los requisitos antes de comenzar a codificar. Puede comenzar el diseño mientras los reúne dependiendo de la vida útil de su proyecto, pero nunca debería comenzar a codificar sin ellos.

Los requisitos son un conjunto de documentos bien escritos que protegen tanto al cliente como a usted. Nunca olvides eso. Si no hay un requisito presente, entonces no se pagó (y por lo tanto requiere una solicitud de cambio formal), si está presente, entonces debe implementarse y debe funcionar correctamente.

Los requisitos deben ser verificables. Si un requisito no puede ser probado, entonces no es un requisito. Eso significa algo así como, "El sistema"

Los requisitos deben ser concretos. Eso significa que "la interfaz de usuario del sistema debe ser fácil de usar" no es un requisito correcto.

Para realmente "reunir" los requisitos, primero debe asegurarse de comprender el modelo de negocio. El cliente le dirá lo que quiere con sus propias palabras, es su trabajo entenderlo e interpretarlo en el contexto correcto.

Haga reuniones con el cliente mientras desarrolla los requisitos. Descríbelas al cliente con sus propias palabras y asegúrese de que usted y el cliente tengan el mismo concepto en los requisitos.

Los requisitos requieren un ejemplo conciso y comprobable, pero haga un seguimiento de cada otra cosa que surja en las reuniones, diagramas, dudas y trate de mantener un registro de cada reunión.

Si puede usar un ciclo de vida incremental, eso le dará la capacidad de mejorar algunos requisitos mal recolectados.

¿Cómo va la fase de recopilación de requisitos? ¿Alguien tiene un buen conjunto de pautas o consejos a seguir? ¿Cuáles son algunas buenas preguntas para los interesados?

Actualmente estoy trabajando en un nuevo proyecto y hay muchas incógnitas. Estoy en el proceso de elaborar una lista de preguntas para formular a los interesados. Sin embargo, no puedo evitar sentir que me falta algo u olvidarme de hacer una pregunta crítica.

Es casi seguro que te pierdas algo. Un montón de cosas, probablemente. No te preocupes, está bien. Incluso si recordaras todo y cubrieras todas las bases, los interesados ​​no podrán darte muy buenos y claros requisitos sin ningún punto de referencia. La mejor manera de hacer este tipo de cosas es obtener lo que pueda de ellos ahora, luego tomar eso y darles algo para reaccionar. Puede ser un prototipo de papel, una maqueta, la versión 0.1 del software, lo que sea. Entonces pueden comenzar a decirte lo que realmente quieren.

Nunca puedes hacer demasiadas o preguntas "estúpidas". Cuantas más preguntas hagas, más respuestas recibirás.

  1. Debates de alto nivel sobre el propósito, el alcance, las limitaciones del entorno operativo, el tamaño, etc.

  2. Audición de una descripción de un solo párrafo del sistema, ejecútelo

  3. Mock up UI

  4. Formalizar requisitos conocidos

  5. Ahora itere entre 3 y 4 con más y más prototipos funcionales y más especificaciones con más detalles. Escriba pruebas sobre la marcha. Haga esto hasta que tenga un software funcional y una especificación de requisitos completa, objetiva y comprobable.

Ese es el sueño La realidad es que después de un par de iteraciones, todo el mundo se cae de cabeza y codifica hasta que queda un mes para probar.

Wow, ¿por dónde empezar?

En primer lugar, hay un conjunto de conocimientos que alguien debería tener que analizar en algunos proyectos, pero realmente depende de lo que está creando para quién. En otras palabras, hace una gran diferencia si está modificando una aplicación empresarial para una corporación Fortune 100, creando una aplicación para iPhone o agregando funcionalidad a una página web personal.

En segundo lugar, hay diferentes tipos de requisitos.

  • Objetivos: ¿Qué quiere el usuario lograr?
  • Funcional: ¿qué debe hacer el usuario para alcanzar su objetivo? (piense en los pasos para alcanzar el / los objetivo / s)
  • No funcional: ¿Cuáles son las limitaciones que su programa necesita realizar dentro? (piense en usuarios simultáneos de 10 vs 10k, crecimiento, respaldo, etc.)
  • Reglas comerciales: ¿qué restricciones dinámicas debe cumplir? (piense en cálculos, definiciones, preocupaciones legales, etc.)

En tercer lugar, la forma de reunir los requisitos de la manera más efectiva, y luego obtener retroalimentación sobre ellos (lo que hará, ¿no?) Es usar modelos. Los casos de usuario y las historias de usuarios son un modelo de lo que el usuario debe hacer. Los modelos de proceso son otra versión de lo que debe suceder. Los diagramas de sistema son solo otro modelo de cómo las diferentes partes del programa interactúan. El buen modelado de datos definirá los conceptos de negocio y le mostrará las entradas, salidas y cambios que suceden dentro de su programa. Los modelos (y hay más de lo que enumero) son realmente la clave de la preocupación que enumera. Algunos buenos modelos capturarán las necesidades y de los modelos puede determinar sus requisitos.

En cuarto lugar, obtener comentarios. Sé que ya lo mencioné, pero no obtendrá todo bien la primera vez, así que obtenga respuestas a lo que quiere su cliente.

Por mucho que aprecie los requisitos y los modelos que los impulsan, los usuarios generalmente no comprenden las ramificaciones de todas sus solicitudes. La comunicación constante con posibilidades de revisión y comentarios le dará a los usuarios una mejor comprensión de lo que está entregando. Además, refinarán su comprensión en función de lo que ven. A menos que esté trabajando para el gobierno, las iteraciones y / o prototipos son útiles.

  • lea el manifiesto ágil: el software de trabajo es la única medida para el éxito de un proyecto de software
  • familiarícese con las prácticas de software ágil - estudie Scrum, programación ligera, xp, etc. - esto le ahorrará una gran cantidad de tiempo no solo para la recopilación de requisitos sino también para todo el ciclo de vida del desarrollo de software
  • mantener conversaciones regulares con los clientes y especialmente con los futuros usuarios y usuarios clave
  • asegúrese de hablar con las personas que entienden el dominio del problema, por ejemplo, especialistas en el campo
  • Tome notas pequeñas durante las conversaciones
  • Después de cada CONVERSACIÓN, escriba una lista de requisitos oficiales y preséntela para su aprobación. Más adelante sería difícil argumentar en contra de toda la documentación acordada
  • asegúrese de que sus clientes conozcan aproximadamente cuáles son los gastos aproximados en tiempo y dinero para implementar los requisitos "agradables para tener"
  • asegúrese de etiquetar los requisitos como "imprescindibles", "deberían tener" y "agradables de tener" desde el principio, asegúrese de que los clientes entiendan las diferencias entre esos tipos también
  • integre todos los documentos en el último y último análisis de requisitos (o el actual para la iteración o cualquier ciclo de programación ágil que esté usando ...)
  • recuerde que los requisitos cambian a lo largo del ciclo de vida del software, por lo que la recopilación es una cosa, pero administrar e implementar otra
  • KISS: mantenlo lo más simple posible
  • estudie también el entorno donde residirá el futuro sistema: cada vez hay más restricciones tecnológicas del sistema heredado o circundante, ya que las empresas no prefieren tirar a la basura el dinero que han invertido durante décadas, incluso si en nuestras mentes modernas 20 años el viejo código es basura ...

Al igual que la mayoría de las etapas del proceso de desarrollo de software, su iteración funciona mejor.

Primero averigua quiénes son tus usuarios: el departamento XYZ,

Luego averigua dónde encajan en la organización, parte de la división Z,

Luego, averigüe qué hacen en términos generales: administre efectivo

Luego, en términos específicos, recoja el efectivo de las cajas y verifique si hay fraude.

Entonces puedes comenzar a hablar con ellos.

Pregúnteles qué problema quieren que quieran resolver: obtendrán una respuesta, como escribir un sistema engañoso utilizando OCR con tecnología de tiburones.

Ignore esa respuesta y haga algunas preguntas más para descubrir cuál es el verdadero problema: no pueden leer los resguardos para conciliar el efectivo.

Acuerde una solución real con los usuarios, obtenga un proveedor de cinta de tinta mejor, o conecte las cajas electrónicas a la red y cargue los registros en un servidor central.

Luego acuerde en detalle cómo medirán el éxito del proyecto.

Entonces, y solo entonces, proponga y acuerde un conjunto detallado de requisitos.

Escribí un artículo de blog sobre el enfoque que uso:

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

Básicamente: preguntas para hacerle a su cliente antes de construir su sitio web.

Debo agregar que esta hoja de cuestionarios solo está orientada a construcciones de sitios web básicos, como una presencia web de negocios. una historia totalmente diferente si se trata de software basado en la web. aunque parte de ella todavía es relevante (por ejemplo, preguntas relacionadas con la apariencia).

  • LM

La ingeniería de requisitos es un poco artística, hay muchas formas diferentes de hacerlo, realmente tiene que adaptarla a su proyecto y a las partes interesadas involucradas. Un buen lugar para comenzar es con Ingeniería de requisitos por Karl Wiegers:

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

y un proceso de ingeniería de requisitos que puede consistir en una serie de pasos, por ejemplo:

  • Elicitación: como base para la discusión con el negocio
  • Análisis y descripción: una descripción técnica para los desarrolladores
  • Elaboración, Aclaración, Verificación y Negociación - mayor refinamiento de los requisitos

Además, hay varias maneras de documentar los requisitos (casos de uso, prototipos, especificaciones, idiomas de modelado). Cada uno tiene sus ventajas y desventajas. Por ejemplo, los prototipos son muy buenos para obtener ideas del negocio y discutir ideas.

En general, considero que escribir un conjunto de casos de uso e incluir prototipos de estructura alámbrica funciona bien para identificar un conjunto inicial de requisitos. A partir de ese punto, es un proceso continuo de trabajo con personas técnicas y personas de negocios para aclarar y elaborar los requisitos. Hacer un seguimiento de lo que se acordó inicialmente y hacer un seguimiento de los requisitos adicionales es esencial para evitar el deslizamiento de alcance. La negociación también juega un papel aquí entre las diversas partes según el Broken Iron Triangle ( http://www.ambysoft.com/essays/brokenTriangle.html ).

OMI: el primer paso más importante es configurar un dictornario de palabras específicas de dominio. Cuando su cliente dice "orden", ¿qué quiere decir? ¿Algo que recibe de sus clientes o algo que envía a sus proveedores? ¿O tal vez los dos?

Encuentre las palabras clave en el negocio de las partes interesadas y permítales explicar esas palabras hasta que comprenda su significado en el proceso. Sin eso, tendrá dificultades para tratar de comprender los requisitos.

Steve Yegge habla de manera divertida, pero hay dinero que se puede hacer para determinar cuáles son los requisitos de otras personas, así que tomaría su artículo con un poco de sal.

La recopilación de requisitos es increíblemente difícil debido a la manera en que funciona la comunicación. Es un proceso de cuatro pasos que es con pérdidas en cada paso.

  • Tengo una idea en mi cabeza
  • Transformo esto en palabras e imágenes
  • Interpretas las imágenes y las palabras
  • Pinta una imagen en su propia mente de cómo era mi idea original

Y los humanos fallan miserablemente en esto con frecuencia preocupante a través de sus adorables imperfecciones.

Agile hace bien en promover el desarrollo iterativo. Llevar las primeras versiones al cliente es importante para identificar qué características son más importantes (lo que se envía en 0.1 - 0.5 ish), ayuda a mantener a ambos en el camino correcto en términos de cómo funcionará la aplicación e identifica rápidamente las características ocultas que te perderás

Los dos escenarios principales de problemas son los dos extremos de las escalas:

  • No teniendo una pista maldita sobre lo que estás haciendo , consigue algunos expertos en el dominio
  • Tener demasiados requisitos : característica pit. - Preguntas, descarte (priorizar;) características y uso desarrollo iterativo

Yegge hace bien en señalar que los expertos en el dominio son esenciales para producir buenos requisitos porque conocen el negocio y han trabajado en él. Pueden ayudar a identificar el deseo central del cliente y ayudarán a explicar cómo usarán el personal el sistema y qué es importante para el personal. Las alternativas y adiciones incluyen tratar de hacer el trabajo usted mismo para entrar en la mentalidad o tener un miembro del personal del cliente de vez en cuando en el sitio, aunque esto último es poco probable que suceda.

El pozo de la característica es el otro lado, en su mayoría lleno de proyectos de TI fallidos del gobierno. Demasiado, muy pronto, falta de pensamiento o aplicación de realismo (¿pero qué espera que tengan solo unos cuatro años para sentirse importantes?). El objetivo aquí es determinar qué quiere realmente el cliente. Siempre y cuando trabaje en conseguir que los componentes principales sean correctos, los clientes eficientes y libres de errores suelen ser tolerantes con las características que faltan que llegan en envíos posteriores, siempre y cuando lleguen. Aquí es donde el desarrollo iterativo realmente ayuda.

Recuerde separar las ideas del cliente sobre cómo será el programa y qué quieren que logre el programa. Algunos clientes pueden crear confusión al comunicar sus requisitos en forma de características de la aplicación que pueden estar poco pensadas o ser redundantes por una funcionalidad mucho más simple que la que ellos creen que necesitan. Si bien no estoy abogando por llamar idiota al cliente o no escucharlos, siento que siempre vale la pena preguntar por qué quieren que una característica en particular llegue a su propósito subyacente.

Recuerde que, en cualquiera de los casos, es de vital importancia eliminar el camino más rápido para satisfacer las necesidades básicas del cliente y ponerlo en un escenario en el que ambos se benefician de la relación.

Antes de hablar con las partes interesadas / usuarios / cualquier persona, asegúrese de que podrá dejar la información recopilada de una manera útil y duradera.

  • Use un grabador de sonido si está bien con la otra persona y la información es voluminosa.
  • Si escuchaste algo importante y necesitas un tiempo razonable para escribirlo, tienes dos opciones: pedirle a la otra persona que espere un segundo o despedirte de esa valiosa información. No lo recordarás bien, pregúntale a cualquier neurocientífico.
  • Si detecta que un punto necesita una revisión más profunda o que necesita algún documento del que acaba de enterarse, asegúrese de comprometerse con la otra persona para enviar ese documento o programar otra reunión con un propósito más específico. Nunca diga "Recordaré pedir ese archivo xls" porque en la mayoría de los casos no lo hará.
  • No mucho después de la reunión, resuma todas sus notas, grabaciones y nuevos pensamientos. Solo resúmelo bien. Crear recordatorios efectivos para los compromisos.
  • De nuevo, justo después de la reunión, es el momento perfecto para entender por qué la reunión que acabas de hacer no fue tan correcta como pensabas al final de la reunión. Es entonces cuando podrás formular muchas preguntas significativas para otra reunión.

Sé que la pregunta fue en la perspectiva de la reunión previa, pero tenga en cuenta que puede trabajar en estos asuntos antes de la reunión y terminar con una reunión muy útil, completa y de calidad.

Aquí hay algunas ideas geniales. Aquí hay algunos requisitos que reúnen los principios que siempre me gusta tener en cuenta:

Sepa la diferencia entre el usuario y el cliente. Los dueños de negocios que aprueban el proyecto brillante suelen ser los clientes. Sin embargo, un error devastador es la tendencia a confundirlos como el usuario. El cliente generalmente es la persona que reconoce la necesidad de su producto, pero el usuario es la persona que realmente usará la solución (y lo más probable es que se queje más adelante sobre un requisito que su producto no cumplió). Ir a más de una persona

Porque todos somos humanos, y tendemos a no recordar cada detalle insoportable. Aumenta la probabilidad de encontrar requisitos perdidos a medida que habla con más personas y realiza controles cruzados.

Evite los especiales Cuando un usuario pide algo muy específico, tenga cuidado. Siempre cuestione los sesgos y vea si esto realmente mejorará su producto.

Prototipo No espere hasta el lanzamiento para mostrar lo que tiene para el usuario. Realice prototipos frecuentes (incluso puede llamarlos versiones beta) y reciba constantes comentarios durante todo el proceso de desarrollo. Probablemente encuentre más requisitos a medida que lo hace.

He estado utilizando mapas mentales (como una estructura de desglose del trabajo) para ayudar a reunir los requisitos y definir las incógnitas (el asesino del proyecto n. ° 1). Comience en un nivel alto y avance hacia abajo. Debe trabajar con los patrocinadores, los usuarios y el equipo de desarrollo para asegurarse de obtener todos los ángulos y no perderse nada. No se puede esperar que conozcan todo el alcance de lo que desean sin su participación ... usted, como gerente de proyecto / BA, necesita involucrarlos (la parte más importante del trabajo).

Ver comic obligatorio debajo ...

En general, intento conocer el modelo de negocio que mi cliente / cliente está tratando de emular con la aplicación que quieren construir. ¿Estamos construyendo un procesador de formularios glorificado? ¿Estamos recuperando datos de múltiples fuentes en una sola aplicación para ahorrar tiempo? ¿Estamos realizando algún tipo de integración?

Una vez que se establece el modelo general de negocios, me muevo al "debo" y "no debo" para que la aplicación dicte qué datos puedo recuperar, quién puede realizar qué funciones, etc.

Por lo general, si puede lograr que el cliente explique su modelo o flujo de trabajo, puede pasar de allí y encontrar preguntas clave adicionales.

La única pregunta que siempre me aseguro de hacer de una forma u otra es "¿Cuál es la cosa más complicada / más molesta que tienes que hacer al hacer X. Por lo general, la respuesta a eso revela la regla de negocio / datos más loca que tendrás que implementar? .

¡Espero que esto ayude!