¿Cuál es la mejor manera de reunir los requisitos para un proyecto?

Question

¿Cómo recopilar la ingeniería del sistema o los requisitos del producto? Por ejemplo, si queremos hacer un automóvil, ¿cómo debemos reunir los requisitos? Amablemente guíame

Answer 1

Esto es realmente una gran pregunta. La respuesta que plantearía es "depende". Recopilar requisitos es algo muy difícil. La mejor forma de reunir requisitos depende de la metodología de su proyecto. ¿Primero vas a utilizar un enfoque iterativo o un enfoque de cascada? También debe determinar quiénes son los interesados ​​de su proyecto (por ejemplo, el gerente de proyecto, los desarrolladores, el analista de negocios, los clientes, el patrocinador del proyecto ...). Luego, debe hacer que las partes interesadas de su proyecto hablen sobre lo que desean.

Cuando tienes a todos hablando de lo que quieres, el analista de negocios debe ayudar a los clientes a describir lo que quieren. Su analista necesita buscar los requisitos. Muchas veces el cliente no sabe lo que realmente quiere o cómo describir el sistema de una manera que tenga sentido para los desarrolladores.

El primer paso de esta fase es describir el alcance del proyecto. Una vez que se ha identificado un buen alcance, podrá determinar qué requisitos están dentro del alcance o fuera del alcance. Después de eso, la mejor manera de identificar los requisitos es discutir el problema y lo que les gustaría resolver. Trate de no crear una solución durante la fase de requisitos, solo una descripción de lo que el producto final debería hacer.

Tenga en cuenta que no pasar demasiado poco tiempo reuniendo los requisitos. Cuantos más cambios tenga más adelante en el ciclo de vida del proyecto, más costoso será hacer esas modificaciones. Además, no dedique demasiado tiempo a perfeccionar los requisitos o se encontrará en lo que se denomina "parálisis de análisis". Tenga en cuenta que estos puntos solo están arañando la superficie. Aquí hay algunos libros decentes donde leí algo de esta información:

Requisitos de software segunda Edición por Karl E. Wiegers

más sobre los requisitos de software de Karl E. Wiegers

Son libros decentes y hablan de todos los temas, desde la preparación de un SRS para múltiples espectadores hasta "Requirement Elicitation"."

Answer 2

Se llama análisis de sistemas: usted va y habla con los posibles usuarios de su producto.

Answer 3

que probablemente empezar por preparando Gathering Requirements Entonces yo pago y envío Joel On Software y 37Signals. Tienen información decente con respecto a la creación de documentos de requisitos. El sitio de Joel on Software tiene un example de uno.

Answer 4

Utilice un SRS document para registrar los requisitos que obtiene del cliente.

Answer 5

1. Hable con las personas: los interesados ​​en el proyecto y los usuarios en particular.
2. Haga preguntas. Muchos de ellos.
3. Documente sus discusiones y conclusiones.
4. Utilice prototipos para validar las conclusiones.

Answer 6

Normalmente, es útil recordar que están sirviendo a varios amos a la vez:

1. usuario
2. Gestión
3. su entorno de diseño al final y lo limita Impone

Lo mejor es pasar tiempo con todo lo anterior

para ins Tance: Recientemente me contrataron para programar un sistema desde cero para una empresa de envío de paquetes: tuve que complacer a la administración del usuario final (los conductores lo hacen de manera simple y rápida) (queremos saber qué hicieron todos y cuándo/cómo) además de trabajar en un entorno restrictivo (un escáner móvil)

Pasé mucho tiempo con la gerencia, luego di la vuelta y salí a hacer entregas con los conductores. Solo después de eso pude manejarlo.

Una cosa importante para recordar es NO encontrar simplemente una solución que te guste, sino que resuelva los problemas que el cliente enfrenta todos los días. La forma única que alguna vez hará es pasar un momento de calidad con ellos, especialmente mientras están haciendo su trabajo.

También vale la pena clairify ese último punto - mientras ellos son haciendo sus trabajos ... si solo los preguntas, casi con certeza recibirás respuestas incompletas. La mayoría de las personas hace muchas cosas en su trabajo que ya ni siquiera piensan, simplemente se ha convertido en un hábito. Son estas pequeñas peculiaridades laborales las que son difíciles de recoger e incluir en un nuevo sistema sin experiencia de primera mano.

Me disculpo si estuviera pidiendo herramientas en lugar de métodos.

Answer 7

• discusiones regulares con los clientes y sobre todo los futuros usuarios y usuarios clave
• Tome pequeñas notas durante las conversaciones
• Después de cada conversación escribir una lista oficial requisito y presentarlo para la aprobación. Más adelante sería difícil argumentar en contra de toda la documentación acordada
• asegúrate de que tus clientes conozcan aproximadamente cuáles son los gastos aproximados en tiempo y dinero para implementar los requisitos "buenos"
• asegúrate de etiquetar los requisitos como "obligatorios" 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 ...)
• recordar que los requisitos cambian durante el ciclo de vida del software, por lo que la recolección es una cosa, pero la gestión y ejecución otra
• KISS - mantenerlo lo más simple posible
• leer el manifiesto ágil - software que funciona es la única medida para el éxito de un proyecto de software
• estudie también el entorno donde residirá el futuro sistema - hay más y más restricciones tecnológicas de sistemas heredados o circundantes, ya que las empresas no prefieren tirar a la basura el dinero que han invertido durante décadas, incluso si en nuestras mentes modernas el código de 20 años es basura ...