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


¿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


6
2018-04-29 14:02


origen


Respuestas:


Esta es realmente una gran pregunta. La respuesta que plantearía es "depende". Recopilar requisitos es algo muy difícil. La mejor manera 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 tenga a todos hablando de lo que desea, el analista de negocios debe ayudar a los clientes a describir lo que desean. Su analista necesita cavar para 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 construir 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 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". Ten en cuenta que estos puntos son solo arañar la superficie. Aquí hay algunos libros decentes donde leí algo de esta información:

Requisitos de software 2ª edición por Karl E. Wiegers

Más sobre requisitos de software por Karl E. Wiegers

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


7
2018-04-29 14:39



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


1
2018-04-29 14:09



Use una Documento SRS para registrar los requisitos que obtienes del cliente.


1
2018-04-29 14:14



Probablemente empezaría preparando Requerimientos de recolección Entonces yo pagaría Joel en software y 37 Señales. Tienen información decente sobre la creación de documentos de requisitos. El sitio de Joel on Software tiene un ejemplo de uno.


1
2018-04-29 14:10



  • Discusiones regulares con los clientes y especialmente con los futuros usuarios y usuarios clave.
  • 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 tarde sería difícil argumentar contra 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 "debe tener", "debería tener" 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 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 la gestión y la implementación de otra
  • KISS: mantenlo lo más simple posible
  • lea el manifiesto ágil: el software de trabajo es la única medida para el éxito de un proyecto de software
  • estudie también el entorno en el que 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, incluso si en nuestras mentes modernas 20 años código antiguo es basura ...

1
2018-04-29 14:17



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

0
2018-05-02 11:21



Normalmente es útil recordar que está sirviendo a varios maestros a la vez:

  1. El usuario final
  2. administración
  3. Su entorno de diseño y los límites que impone

Lo mejor es pasar tiempo con todo lo anterior

por ejemplo: hace poco fui contratado para programar un sistema desde cero para una empresa de entrega de paquetes; tuve que complacer al usuario final (controladores: hacerlo simple y rápido) (queremos saber qué hicieron todos y cuándo / cómo) así como trabajar en un entorno restrictivo (un escáner móvil)

Pasé mucho tiempo con la administración, luego me di la vuelta y me fui a las entregas con los conductores. Solo después de eso fui capaz de controlarlo realmente.

Una cosa importante para recordar es NO encontrar una solución que  como uno que realmente resuelve los problemas que el cliente enfrenta todos los días. los solamente La forma en que lo hará es pasar un tiempo de calidad con ellos, preferiblemente mientras están haciendo su trabajo.

También vale la pena clarificar ese último punto, mientras están obra sus trabajos ... si solo los preguntas, seguramente obtendrás respuestas incompletas. La mayoría de las personas hacen 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.

Pido disculpas si estuviera pidiendo herramientas en lugar de métodos.


0