Cómo escribir un informe de diseño
Analice el contenido específico de los requisitos:
·Requisitos comerciales: reflejan los requisitos objetivos de alto nivel de la organización o cliente para el sistema y el producto, generalmente en la definición y documentos de alcance Explicar.
·Requisitos del usuario: describe las tareas que los usuarios deben completar para utilizar el producto, que se explican en ejemplos de uso o guiones de escenarios.
·Requisitos funcionales - definen las funciones de software que los desarrolladores deben implementar para que los usuarios puedan utilizar el sistema para completar sus tareas y así satisfacer las necesidades del negocio.
·Requisitos no funcionales - describen el comportamiento que el sistema muestra a los usuarios y las operaciones que realiza. Incluye los estándares, especificaciones y restricciones que el producto debe cumplir, así como los detalles y requisitos específicos. Características estructurales de la interfaz operativa.
·Informe de análisis de requisitos: los requisitos funcionales descritos en el informe describen completamente el comportamiento externo que debe tener el sistema de software. El Informe de análisis de requisitos juega un papel importante en el desarrollo, las pruebas, el control de calidad, la gestión de proyectos y las funciones relacionadas del proyecto.
En el proceso de análisis de la demanda real, los dos tipos de clientes anteriores pueden sentir que no tienen tiempo para discutir con los analistas de la demanda. A veces, los clientes también esperan que los analistas puedan informar las necesidades del usuario sin discutirlas. escribir descripciones de la demanda. A menos que el requisito encontrado sea extremadamente simple, no se puede cumplir. Si su organización quiere que su software tenga éxito, tendrá que pasar días solucionando ambigüedades en los requisitos y aspectos que confunden a los desarrolladores. Los productos de software excelentes se basan en requisitos excelentes, y los requisitos excelentes son el resultado de una comunicación y cooperación efectivas entre clientes y desarrolladores. Sólo cuando ambos participantes comprendan lo que necesitan y lo que requiere una cooperación exitosa, se podrá establecer una buena relación de cooperación
Visión de las necesidades del cliente
Necesidades de comunicación entre clientes y desarrolladores Buen enfoque. A continuación se sugieren 20 reglas que los clientes y desarrolladores pueden revisar y alcanzar para lograr una mejor comprensión. Si se encuentran desacuerdos, se alcanzará un entendimiento mutuo de las respectivas obligaciones mediante la negociación para reducir fricciones futuras (como cuando una parte hace demandas que la otra no quiere o no puede cumplir).
1. Los analistas deben utilizar expresiones que se ajusten a los hábitos lingüísticos del cliente.
Las discusiones sobre requisitos se centran en las necesidades y tareas del negocio, por lo que se debe utilizar terminología. Los clientes deben enseñar a los analistas la terminología relevante (por ejemplo, términos de adquisición como precios, productos impresos, etc.), pero no es necesario que los clientes comprendan la terminología de la industria informática.
2. Los analistas deben comprender el negocio y los objetivos del cliente.
Solo cuando los analistas comprendan mejor el negocio del cliente los productos podrán satisfacer mejor sus necesidades. Esto ayudará a los desarrolladores a diseñar un excelente software que realmente satisfaga las necesidades y expectativas de los clientes. Para ayudar a los desarrolladores y analistas, los clientes pueden considerar invitarlos a observar su flujo de trabajo. Si cambian a un nuevo sistema, los desarrolladores y analistas deben utilizar el antiguo sistema actual para ayudarles a comprender cómo funciona el sistema actual, sus procesos y áreas de mejora.
3. Los analistas deben preparar un informe de requisitos de software.
Los analistas deben organizar toda la información obtenida de los clientes para distinguir los requisitos y especificaciones comerciales, los requisitos funcionales, los objetivos de calidad, las soluciones alternativas y otra información. A través de estos análisis, los clientes pueden obtener un "Informe de Análisis de Requisitos", que permite a los desarrolladores y clientes llegar a un acuerdo sobre el contenido del producto a desarrollar. El informe debe organizarse y redactarse de manera que al cliente le resulte fácil de leer y comprender. El cliente revisará este informe para asegurarse de que su contenido exprese de forma precisa y completa sus necesidades. Un "informe de análisis de necesidades" de alta calidad ayuda a los desarrolladores a desarrollar productos que realmente se necesitan.
4. Solicite una explicación de los resultados del trabajo de requisitos
Los analistas pueden utilizar una variedad de gráficos como explicaciones complementarias para el "Informe de análisis de requisitos" textual porque los gráficos de trabajo pueden ser muy claros. varios gráficos en el informe son de gran valor porque describen ciertos aspectos del comportamiento del sistema; aunque no son difíciles de entender, es posible que el cliente no esté familiarizado con ellos, por lo que puede pedirle al analista que le explique el significado de cada gráfico. . Las funciones, significados de los símbolos y resultados del trabajo de desarrollo de requisitos, así como cómo comprobar los diagramas en busca de errores e inconsistencias, etc.
5. Los desarrolladores deben respetar las opiniones de los clientes.
Si los usuarios y los desarrolladores no pueden entenderse, habrá obstáculos a la hora de discutir los requisitos. La cooperación con el Partido Comunista de China puede permitir que todos "escuchen y comprendan". Los clientes que participan en el proceso de desarrollo de requisitos tienen derecho a pedir a los desarrolladores que los respeten y valoren el tiempo que dedican al éxito del proyecto. De manera similar, los clientes también deben respetar los esfuerzos de los desarrolladores por el objetivo común del éxito del proyecto.
6. Los desarrolladores deben hacer sugerencias y soluciones para los requisitos y la implementación del producto.
Por lo general, lo que los clientes llaman "requisitos" ya es un plan de implementación práctico, y los analistas deben hacer todo lo posible para comprenderlos. necesidades comerciales reales de estas soluciones, y también descubrir las inconsistencias entre el sistema existente y el negocio actual para garantizar que el producto no sea ineficaz o ineficiente, después de aclarar minuciosamente las cosas en el ámbito empresarial, los analistas pueden encontrar mejoras bastante buenas; métodos, y los analistas experimentados y creativos también pueden proponer agregar algunas características valiosas del sistema que los usuarios no han descubierto.
7. Describir las características de uso del producto
Los clientes pueden pedir a los analistas que presten atención a la facilidad de uso del software al implementar requisitos funcionales, debido a estas características de facilidad de uso o calidad. Los atributos pueden permitir a los clientes completar tareas de manera más precisa y eficiente. Por ejemplo: los clientes a veces exigen que los productos sean "compatibles con la interfaz", "robustos" o "altamente eficientes", pero para los desarrolladores esto es demasiado subjetivo y no tiene valor práctico. El enfoque correcto es que los analistas utilicen consultas y encuestas para comprender las características específicas de "amigable, robusto y eficiente" que desean los clientes, y analicen específicamente qué características tienen un impacto negativo en qué características y comparen los costos de rendimiento con los esperados. Beneficios de la solución propuesta. Hacer concesiones entre los requisitos para garantizar compensaciones razonables.
8. Permitir la reutilización de componentes de software existentes.
Los requisitos generalmente tienen un cierto grado de flexibilidad, y Los analistas pueden encontrar que los componentes de software existentes Un componente de software se ajusta bien a los requisitos descritos por el cliente. En este caso, el analista debe proporcionar algunas opciones para modificar los requisitos para que el desarrollador pueda reducir el costo y ahorrar tiempo en el desarrollo del nuevo sistema. sin tener que seguir estrictamente la especificación de requisitos original. Por lo tanto, si desea utilizar algunos componentes comerciales existentes en su producto, pero no son completamente adecuados para las funciones que necesita, un cierto grado de flexibilidad es extremadamente importante. p>
9. Requerir una evaluación verdadera y confiable del costo del cambio
A veces, cuando las personas se enfrentan a una solución mejor y más costosa, tomarán decisiones diferentes. Es necesario evaluar. el impacto para ayudar a las decisiones comerciales, por lo tanto, los clientes tienen derecho a pedir a los desarrolladores que brinden una evaluación verdadera y creíble a través de análisis, incluido el impacto, el costo, las ganancias y las pérdidas, etc. Los desarrolladores no pueden implementar cambios porque no quieren y sienten. No se puede exagerar el coste de la evaluación.
10. Obtener un sistema que cumpla con los requisitos funcionales y de calidad del cliente.
Todos quieren que el proyecto tenga éxito, pero esto requiere algo más que el cliente. para informar claramente a los desarrolladores sobre el problema. Toda la información necesaria para que el sistema "funcione", y también requiere que los desarrolladores puedan comunicarse claramente sobre las compensaciones y limitaciones. Asegúrese de expresar claramente sus suposiciones y expectativas subyacentes. De lo contrario, el desarrollador probablemente desarrollará un producto que no le dejará satisfecho.
11. Explique su negocio a los analistas
Los analistas deben confiar en los clientes para explicar los conceptos y la terminología del negocio, pero los clientes no pueden esperar que los analistas se conviertan en expertos en el campo; y objetivos; no espere que los analistas comprendan los matices del negocio de su cliente; es posible que no conozcan el "sentido común" que los clientes dan por sentado.
12. Tómese el tiempo para explicar claramente y mejorar los requisitos.
Los clientes están muy ocupados, pero es necesario que se tomen el tiempo para participar en las discusiones de la "cumbre del cerebro" y aceptar entrevistas. u otra información. Es posible que algunos analistas comprendan su punto de vista primero, pero luego descubran que todavía necesitan su explicación. En este momento, tenga paciencia con las iteraciones en el proceso de refinar algunos requisitos y requisitos, porque es un fenómeno natural en la comunicación de las personas. sin mencionar que esto es extremadamente importante para el éxito de su producto de software.
13. Indica los requisitos de forma precisa y detallada.
Escribir un documento de requisitos claro y preciso es difícil. Debido a que lidiar con los detalles es molesto y requiere mucho tiempo, es fácil quedarse con requisitos vagos. Pero durante el proceso de desarrollo, esta ambigüedad e inexactitud deben resolverse, y el cliente es la mejor persona para tomar la decisión de resolver estos problemas, de lo contrario, corresponde al desarrollador adivinar correctamente.
Una forma es agregar temporalmente una marca de "pendiente" en el análisis de demanda. Esta marca se puede utilizar para indicar áreas que requieren mayor discusión, análisis o información adicional. A veces puede marcarse como "pendiente" porque una necesidad particular es difícil de resolver o nadie está dispuesto a abordarla. Los clientes deben intentar explicar el contenido de cada requisito lo más claramente posible para que los analistas puedan escribirlos con precisión en el "Informe de requisitos de software". Si los clientes no pueden expresar con precisión durante un tiempo, generalmente requieren el uso de tecnología de prototipo. A través del desarrollo de prototipos, los clientes pueden realizar modificaciones repetidas junto con los desarrolladores para mejorar continuamente la definición de los requisitos.
14. Tome decisiones oportunas
Los analistas pedirán a los clientes que tomen algunas decisiones y elijan métodos de procesamiento propuestos por múltiples usuarios o conflictos en las características de calidad y precisión de la información. compromiso entre otros. Los clientes que tienen el poder de tomar decisiones deben adoptar un enfoque proactivo para procesar y tomar decisiones lo antes posible, porque los desarrolladores generalmente tienen que esperar a que los clientes tomen una decisión antes de poder actuar, y esta espera retrasará el progreso del proyecto. .
15. Respetar las necesidades de los desarrolladores, la viabilidad y la evaluación de costes.
Todas las funciones del software tienen sus costes. Algunas características del producto deseadas por los clientes pueden no ser técnicamente viables o pueden ser extremadamente costosas de implementar, mientras que algunos requisitos pueden intentar lograr un rendimiento que es imposible de lograr en el entorno operativo, o pueden intentar obtener algunos datos que simplemente no están disponibles. . Los desarrolladores harán comentarios negativos sobre esto y los clientes deben respetar sus opiniones.
16. Priorizar los requisitos
La mayoría de los proyectos no tienen suficiente tiempo ni recursos para implementar cada detalle de la funcionalidad. Decidir qué características son necesarias y cuáles son importantes es una parte importante del desarrollo de requisitos. Esto sólo lo puede hacer el cliente, ya que es imposible para los desarrolladores priorizar los requisitos desde el punto de vista del cliente. La priorización proporciona información sobre el costo y el riesgo de cada requisito. Se debe respetar la opinión del desarrollador en cuanto a si se puede lograr una característica deseada y en qué medida, dadas las limitaciones de tiempo y recursos. Aunque nadie quiere que los requisitos deseados no se cumplan en el proyecto, después de todo, tenemos que afrontar la realidad. Las decisiones empresariales a veces tienen que basarse en prioridades para reducir el alcance del proyecto, ampliar la duración, aumentar los recursos o aumentar los recursos. mejorar la calidad. Encontrar un compromiso.
17. Revisar los documentos de requisitos y los prototipos.
La revisión de los documentos de requisitos por parte del cliente es una oportunidad para proporcionar información de retroalimentación a los analistas. Si el cliente cree que el "Informe de análisis de requisitos" preparado no es lo suficientemente preciso, es necesario informar a los analistas lo antes posible y proporcionar sugerencias de mejora. Un mejor enfoque es desarrollar primero un prototipo del producto.
De esta manera, los clientes pueden proporcionar comentarios más valiosos a los desarrolladores para que puedan comprender mejor sus necesidades. El prototipo no es un producto de aplicación real, pero los desarrolladores pueden transformarlo y expandirlo hasta convertirlo en un sistema completamente funcional.
18. Contáctenos inmediatamente si los requisitos cambian.
Los cambios continuos en los requisitos tendrán efectos adversos graves en la calidad de los productos completados dentro del plan programado. Los cambios son inevitables, pero en el ciclo de desarrollo, cuanto más tarde se produzca el cambio, mayor será su impacto no sólo conducirá a retrabajos extremadamente costosos, sino que también retrasará el período de construcción, especialmente después de que se haya completado la estructura general y se hayan asignado recursos adicionales; necesarias nuevas características. Por lo tanto, una vez que el cliente descubra que es necesario cambiar los requisitos, notifique a los analistas de inmediato.
19. Seguir el proceso del equipo de desarrollo para manejar los cambios de requisitos.
Para reducir al mínimo el impacto negativo de los cambios, todos los participantes deben seguir el proceso de control de cambios del proyecto. Esto requiere no abandonar todos los cambios propuestos, analizar cada cambio requerido, considerarlo de manera integral y finalmente tomar las decisiones apropiadas para determinar qué cambios deben introducirse en el proyecto.
20. Respete el proceso de análisis de requisitos utilizado por los desarrolladores.
Lo más desafiante en el desarrollo de software es recopilar requisitos y determinar su exactitud. Los métodos utilizados por los analistas tienen sus propias razones. sexo. Tal vez los clientes piensen que el proceso de recopilación de requisitos no es rentable, pero crean que el tiempo dedicado al desarrollo de requisitos es muy valioso si comprende y respalda las técnicas utilizadas por los analistas para recopilar, redactar documentos de requisitos y garantizar su calidad; Entonces todo el proceso será más sencillo.
¿Qué significa "Confirmación de requisitos"?
Firmar y confirmar en el "Informe de análisis de requisitos" generalmente se considera una señal de que el cliente está de acuerdo con el análisis de requisitos. en la práctica real, los clientes a menudo piensan que "firmar" no tiene sentido. "Me pidieron que firmara la última línea del documento de requisitos, así que lo firmé; de lo contrario, estos desarrolladores no comenzarían a codificar.
Esta actitud generará problemas, por ejemplo, si el cliente quiere". para cambiar los requisitos o Cuando no esté satisfecho con el producto, dirá: "Sí, firmé el informe de análisis de demanda, pero no tengo tiempo para leer todo el contenido. Le creo y usted insistió en preguntar". ".
El mismo problema también les ocurrirá a los analistas que solo consideran la "confirmación de firma" como completar la tarea. Una vez que haya cambios en los requisitos, señalará el "Informe de análisis de requisitos" y diga: "Ya estás en los requisitos." Firmado, así que esto es lo que desarrollamos, si querías algo más deberías habernos dicho antes."
Ambas actitudes están equivocadas. Debido a que es imposible comprender todos los requisitos en las primeras etapas del proyecto, y sin duda habrá cambios en los requisitos, firmar el "Informe de análisis de requisitos" es la forma correcta de finalizar el proceso de análisis de requisitos, por lo que debemos comprender qué medios de firma.
La firma del "Informe de Análisis de Requisitos" se basa en la línea base de un acuerdo de requisitos, por lo que debemos entender la firma así: "Estoy de acuerdo en que este documento de requisitos expresa nuestra comprensión de los requisitos de software del proyecto". Se pueden realizar más cambios desde esta línea de base a través del proceso de cambio definido por el proyecto. Entiendo que los cambios pueden requerir que renegociemos costos, recursos, tareas de la fase del proyecto, etc. "Lograr una cierta comprensión del análisis de requisitos permitirá a ambas partes. Es más fácil tolerar fricciones futuras que surjan de mejoras en el proyecto, discrepancias en los requisitos o nuevos requisitos comerciales y del mercado. La confirmación de requisitos aclara la niebla, revela la verdadera cara de los requisitos, pone fin claramente al trabajo de desarrollo de requisitos inicial y ayuda a formar una relación buena y sostenida entre clientes y desarrolladores, sentando una base sólida para el éxito del proyecto. base de.
Materiales de referencia: colección de Internet