Recopilación de requisitos

Question

¿Cómo se realiza 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.

Answer 1

Ya casi ha desaparecido sin duda algo. Una gran cantidad de cosas, probablemente. no se preocupe, está bien. Incluso si recordaba todo y cubrió todas las bases, las partes interesadas no van a poder brindarle un muy buen y claro requerimiento ts 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.

Answer 2

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

Answer 3

Ver cómica obligatoria a continuación ...

En general, trato de conseguir una sensación para el modelo de negocio de 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?

vez que se establece el modelo de Businesss general, a continuación, pasar a la "debe" y "debe no tienen" para la aplicación de dictar qué datos puedo recuperar, lo que puede realizar funciones, etc.

lo general, si puede hacer 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. Normalmente la respuesta a eso revela la regla de negocio/datos más loca? Habrá que poner en práctica.

espero que esto ayude!

Answer 4

De acuerdo con Steve Yegge que es el wrong question to ask. Si está reuniendo requisitos, ya es demasiado tarde, su proyecto está condenado.

Answer 5

En primer lugar, reúna los requisitos antes de que comienza la codificación. 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 se debe implementar y debe funcionar correctamente.

Los requisitos deben poder comprobarse. 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.

Realice 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 utilizar un ciclo de vida incremental, eso le dará la capacidad de mejorar algunos requisitos mal recopilados.

Answer 6

Steve Yegge habla divertido, pero hay dinero para hacer en la elaboración de 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 forma 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
• que transformar esto en palabras e imágenes
• a interpretar los dibujos y palabras
• se pinta una imagen en su mente de lo que mi idea original era como

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 usted va señorita.

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

• No tener una pista maldita acerca de lo que está haciendo - obtener algunos expertos en el dominio
• tener demasiados requisitos - característica hoyo. - Question, cull (prioritize;)) funciones 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 utilizarán el personal el sistema y lo que 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 el cliente realmente. Siempre que trabaje para 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 que 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 el programa logre. 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 sencilla que la que ellos creen que necesitan. Si bien no estoy abogando por llamar al cliente un idiota o no escucharlos, siento que vale la pena preguntar siempre por qué quieren una característica en particular para llegar a su propósito subyacente.

Recuerde que, en cualquier caso, es de importancia imperativa eliminar el camino más rápido para satisfacer la necesidad del cliente y ponerlo en un escenario en el que ambos se benefician de la relación.

Answer 7

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

2. Audition una sola descripción de un párrafo del sistema, el martillo hacia fuera

3. maqueta de interfaz de usuario

4. requisitos Formalizar conocido

5. Ahora iterar 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.

Answer 8

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

Conozca la diferencia entre el usuario y el cliente. Los propietarios 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ó). Vaya 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.

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

Prototipo No espere hasta el inicio 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.

Answer 9

Recientemente comencé a usar los conceptos, estándares y plantillas definidos por la organización International Institute of Business Analysts (IIBA).

Tienen un muy buen BOK (Libro del conocimiento) que se puede descargar desde su sitio web. Ellos también tienen un certificado.

Answer 10

Gathering Business Requirements Are Bullshit - Steve Yegge

Answer 11

Guau, 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, existen diferentes tipos de requisitos.

• Objetivos: ¿Qué quiere lograr el usuario?
• 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 restricciones que necesita realizar su programa? (piense en 10 contra 10k usuarios simultáneos, crecimiento, respaldo, etc.)
• Reglas comerciales: ¿Qué restricciones dinámicas debe cumplir? (piense en cálculos, definiciones, preocupaciones legales, etc.)

En tercer lugar, la manera de reunir requisitos de 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 entienden 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.

Answer 12

He estado utilizando el mapeo mental (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 sepas todo el alcance de lo que quieren sin su participación ...usted, como gerente de proyecto/BA, necesita involucrarlos (la parte más importante del trabajo).

Answer 13

• leer el manifiesto ágil - software que funciona es la única medida del éxito de un proyecto de software
• familiarizarse con las prácticas de software ágiles - estudiar Scrum, programación magra, XP, etc - esto le ahorrará gran cantidad de no solo para la recopilación de requisitos, sino también para todo el ciclo de vida de desarrollo de software
• mantenga conversaciones regulares con los clientes y especialmente 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
• Tomar 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 tarde sería difícil argumentar en contra de toda la documentación acordada
• asegurarse de que sus clientes saben aproximadamente lo que son los gastos aproximados de tiempo y dinero para la implementación de "bueno tener" requisitos
• asegúrese de etiquetar los requisitos como "debe tiene "," debería haber "y" bueno 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 lo que sea) ciclo de programación ágil que está utilizando ...)
• recuerde que los requisitos cambian con el ciclo de vida del software, por lo que recopilar es una cosa pero ing e implementar otro
• KISS - mantenerlo lo más simple posible
• estudiar también el entorno donde residirá el futuro sistema - hay más y más restricciones tecnológicas de los sistemas heredados o circundantes, ya que las empresas no prefieren tirar a la basura el dinero que han invertido durante décadas, aunque en nuestra mente modernos a 20 años de edad es de código basura ...

Answer 14

escribí un artículo en el blog sobre el enfoque que utilizo:

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 añadir que esta hoja de cuestionario está orientada solo a las 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

Answer 15

Ingeniería de Requisitos es un poco de un arte, hay un montón de diferentes maneras de ir sobre él, que realmente tiene que adaptar a su proyecto y los actores involucrados. Un buen lugar para comenzar es con Ingeniería de Requisitos de 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,:

• Provocación - para la base de discusión con el negocio
• Análisis y Descripción - una descripción técnica con el propósito de que los desarrolladores
• Elaboración, clarificación, verificación y Negociación - un mayor refinamiento de los requisitos

Además, hay una serie de formas 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.

Por lo general, creo 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 Triángulo de Hierro Roto (http://www.ambysoft.com/essays/brokenTriangle.html).

Answer 16

IMO el primer paso más importante es configurar un dictornary de palabras específicas del 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?

Encuentra las palabras clave en el negocio de las partes interesadas, y deja que te expliquen esas palabras hasta que comprendas su significado en el proceso. Sin eso, tendrá dificultades para tratar de comprender los requisitos.

Answer 17

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

Primera averiguar quiénes son sus usuarios son - el departamento de XYZ,

A continuación, averiguar dónde encajan en la organización - parte de la división Z,

luego averiguar lo que hacen en términos generales - Administrar efectivo

Luego, en términos específicos: recoja el efectivo de cajas y compruebe hasta el fraude.

Luego puede comenzar a hablar con ellos.

Pregunte qué problema quieren que desee resolver; obtendrá una respuesta como escribir un sistema de engaño 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 hasta para conciliar el efectivo.

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

A continuación, acuerden en detalle cómo medirán el éxito del proyecto.

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

Answer 18

Yo sugeriría a leer Roger-Pressman'sSoftware Engineering: A Practitioner's Approach

Answer 19

prefiero mantener mis requisitos de recopilación de proceso lo más simple, directa y completa como sea posible. Puede descargar un documento de muestra que utilizo como plantilla para mis proyectos en esta entrada del blog: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html

Answer 20

Antes de ir a hablar con las partes interesadas/usuarios/cualquier persona, asegúrese de que podrá dejar la información recopilada en un útil y duradero.

• Use un grabador de sonido si está bien con la otra persona y la información es voluminosa.
• Si oyó algo importante y necesita un tiempo razonable para anotarlo, tiene dos opciones: pedirle a la otra persona que espere un segundo o despedirse 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 que acaba de conocer, 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 nuevas ideas. Solo resúmelo bien. Crear recordatorios efectivos para los compromisos.
• Una vez más, 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 creías al final de la reunión. Es entonces cuando podrás formular muchas preguntas significativas para otra reunión.

sé que la pregunta era en la perspectiva de la reunión previa, pero por favor tenga en cuenta que se puede trabajar en esta materia antes de la reunión y terminar con un gran útiles, recopilación completa y de calidad.