Ingeniería de software Dahua: análisis de requisitos y diseño de software (5)
La ingeniería de requisitos es el primer paso en la construcción de un sistema de información de gestión. Consiste en investigar la situación actual y las necesidades de los clientes, y registrar y analizar de forma completa y precisa las necesidades de los clientes de acuerdo con los métodos y estándares de ingeniería. Sus resultados son la base para la ingeniería de diseño posterior.
1. Definición
La ingeniería de requisitos se refiere al uso de métodos y estándares de ingeniería para recopilar, registrar y analizar los requisitos de información del cliente y, en última instancia, determinar las funciones que el sistema necesita implementar, así como las características y restricciones relevantes del funciones. La ingeniería de requisitos consta de tres partes principales: investigación de la demanda, análisis de la demanda y gestión de la demanda.
Nota: Acerca de la gestión de requisitos
La gestión de requisitos es un contenido muy importante en la ingeniería de requisitos, incluido el seguimiento, control, cambio, gestión de versiones, etc. de requisitos. Garantiza que el sistema sea un medio importante. En términos de contenido, calidad y progreso, el contenido de la gestión de la demanda se centra más en la gestión de procesos de software.
2. Función
La función de la ingeniería de requisitos se puede resumir en una frase: recopilar lo que los clientes quieren hacer y finalmente determinar qué se hace realmente.
Para el desarrollo de una aplicación software, la calidad de los resultados de la ingeniería de requisitos afecta en gran medida los resultados del diseño del software y es el vínculo principal que determina el éxito o el fracaso. Se obtiene, registra, analiza y completa. Los requisitos confirmados por el cliente y pasados correctamente a proyectos posteriores es una habilidad esencial de un analista de requisitos. Las especificaciones de requisitos formadas por los resultados del análisis de la ingeniería de requisitos no solo son la base para el diseño y desarrollo posteriores, sino también la base para que los clientes completen la evaluación y aceptación del sistema.
Por otro lado, el contenido de la ingeniería de requisitos también afecta mucho a muchos aspectos como el coste, la tecnología, el ciclo, los recursos, la calidad y la satisfacción del cliente final del desarrollo de software. Los resultados de la ingeniería de requisitos no sólo afectarán los resultados finales obtenidos por los clientes, sino que también afectarán los intereses finales de los desarrolladores de software.
El trabajo principal de la ingeniería de requisitos es la investigación y el análisis de la demanda, y hay dos entregables finales principales.
1) Resultados de la encuesta de demanda (resumen de los datos de la encuesta de demanda)
Datos de demanda de primera mano recopilados de los sitios de los clientes a través de encuestas cara a cara, incluidos gráficos, texto, tablas, etc. Registre los datos originales para formar un resumen de los datos de la investigación de la demanda.
2) Resultados del análisis de requisitos (especificaciones de requisitos)
A partir del análisis de los datos de investigación antes mencionados, se identifica todo el contenido que finalmente necesita ser desarrollado y, a través de la confirmación del cliente, finalmente se forman los requisitos. Las especificaciones son la base para los procesos posteriores de diseño y desarrollo.
1. Recopilación y confirmación de requisitos
En el proceso desde los requisitos originales poco claros de los clientes hasta el desarrollo de la codificación, la parte que más contribuye a la convergencia es ② la ingeniería de requisitos, mientras que la parte que es más fácil de estandarizar y estandarizar es ③ ~Parte 5. ② Clasifique el contenido complejo de ① y forme una especificación de requisitos clara. ③ Extraiga y convierta aún más los resultados de ② en los resultados de diseño de arquitectura, función y datos. ④ Extraiga y convierta aún más los resultados de ③ en componentes y mecanismos. ⑤ Desarrollar los resultados de ④ en el software final en forma de codificación.
Se puede ver en los avances y cambios de los gráficos que la ingeniería de requisitos ② es responsable de clasificar el contenido de los requisitos originales ① y formar una especificación de requisitos clara y confirmable y ③~ ⑤ Para un; En una serie de trabajos, las últimas partes son más simples, menor es la complejidad y más convergentes son las cosas por hacer. ② La ingeniería de requisitos es pionera. Se encarga del trabajo más complicado, desordenado y agotador, y desempeña el papel más importante en la convergencia de los cinco pasos desde los requisitos originales del cliente hasta la codificación. ② Cuanto mayor sea la convergencia de algunos gráficos (la pendiente del trapecio es grande), ③ cuanto más cerca estén los gráficos que se diseñarán y desarrollarán en el futuro de un rectángulo recto, más suave será el trabajo. ⑤ son todos trapecios con pendientes grandes, lo que significa que se requiere ingeniería. Si no está implementada, se seguirán descubriendo problemas con los requisitos iniciales en el diseño y desarrollo posteriores, lo que resultará en reelaboraciones.
Nota: Respecto al significado de "convergencia"
La convergencia se refiere al proceso de integración de requisitos originales complejos en operaciones estandarizadas. El contenido del trabajo estandarizado no se ve afectado por la demanda y su contenido es fijo independientemente de si la demanda es compleja.
2. No todos los requisitos provienen de la investigación de los clientes
¿Se obtienen todos los requisitos para construir sistemas de información de los clientes? Esta pregunta refleja cuánto contenido del sistema completo proponen los ingenieros de software (incluyendo consultoría, requisitos, diseño, desarrollo, implementación, etc.). Estas propuestas a menudo contienen requisitos más avanzados, más valor agregado y más requisitos. fuentes.
1) Necesidades básicas
Las necesidades básicas provienen de la "investigación" de los clientes. Este tipo de necesidades son principalmente requisitos funcionales, y básicamente se diseñan y desarrollan según los deseos de los clientes. El contenido La mayoría de ellos se determinan durante las etapas de investigación y análisis de necesidades.
2) Requisitos intermedios
Los requisitos intermedios no son requisitos funcionales propuestos directamente por los clientes, sino que se transforman en requisitos comerciales propuestos por los clientes durante la etapa de análisis de requisitos y la etapa de diseño comercial. generadas en el proceso de optimización, llenado de brechas y mejora son las necesidades que se generan para mejorar el negocio.
3) Requisitos avanzados
Los requisitos avanzados son propuestos principalmente por ingenieros de software en función de las necesidades objetivo del cliente, nuevos conceptos de diseño, nuevas tecnologías, etc. En otras palabras, los requisitos avanzados son requisitos diseñados por ingenieros de software, por ejemplo, “diseño de proceso de búsqueda de empleo (arquitectura)”, “diseño de componentes según tareas (función)”, “reutilización de datos (datos)”, etc. Los "requisitos de diseño" requieren que los ingenieros de software tengan conocimientos y capacidades suficientes.
El orden de dificultad para obtener las tres fuentes de demanda anteriores es demanda avanzada > demanda intermedia > demanda básica.
Los ingenieros de software deben darse cuenta de que una vez completada la ingeniería de requisitos (investigación y análisis), no significa que se complete todo el trabajo de adquisición de requisitos, sino que se completen los requisitos propuestos directamente por los clientes, y Según los requisitos de la ingeniería de diseño, las excavaciones aún no han comenzado.
Nota: Los requisitos avanzados afectarán los costos de desarrollo. Aquí solo consideramos cómo descubrir requisitos valiosos y no consideramos los costos de desarrollo causados por nuevos requisitos.
Los requisitos generalmente se dividen en dos categorías: requisitos funcionales y requisitos no funcionales.
Los requisitos funcionales son las funciones de procesamiento empresarial que el sistema debe proporcionar y también son el cuerpo principal de los requisitos del software. En términos generales, los requisitos sin adjetivos delante se refieren a requisitos funcionales.
Los requisitos obtenidos se pueden dividir en tres categorías. Existe una relación de conversión entre ellos según el orden de conversión, se dividen en: requisitos objetivo, requisitos comerciales y requisitos funcionales.
Requisitos objetivo: Información de objetivos, conceptos, esperanzas y valores propuestos por los clientes.
Requisitos comerciales: El sistema propuesto por el cliente debe corresponder al contenido, proceso, reglas, etc.
Requisitos funcionales: Determine las funciones y descripciones específicas de las funciones que el sistema debe proporcionar para manejar los requisitos comerciales.
Los requisitos no funcionales se refieren al establecimiento de algunas condiciones indicadoras para juzgar el funcionamiento del sistema, en lugar de requisitos funcionales específicos para un determinado proceso de negocio. Se utilizan para juzgar si el sistema en ejecución puede cumplir con los siguientes requisitos: Condiciones. : seguridad, confiabilidad, interoperabilidad, robustez, facilidad de uso, mantenibilidad, portabilidad, reutilización, escalabilidad, etc.
Los resultados de la consulta previa a la venta contienen muchos aportes muy importantes para el análisis de la demanda y el diseño comercial. En particular, muchos "requisitos objetivo" provienen de esto, y los requisitos objetivo son cruciales para la planificación y el desarrollo generales. de los sistemas de información posteriores tiene un impacto muy importante
1. Contenido de la consulta de preventa
Antes de ingresar al proyecto de diseño, el propósito de toda comunicación y comunicación con los clientes es obtener los requisitos. Especialmente para proyectos grandes, generalmente hay una etapa de consulta de preventa. En esta etapa, los proveedores de software generalmente enviarán consultores más experimentados (como consultores expertos) para comunicarse con los clientes y discutir qué soluciones se pueden brindar de acuerdo con las necesidades del cliente. La consulta en esta etapa tiene las siguientes características.
● El contrato aún no se ha firmado y el contenido específico del sistema de información aún no se ha determinado. La posibilidad de firmar el contrato depende del resultado de la consulta.
● En este momento, la mayoría de los clientes participantes son altos ejecutivos corporativos, como operadores, altos directivos y gerentes de información.
●Las necesidades de los clientes son principalmente necesidades específicas, necesidades comerciales e incluso dificultades y puntos débiles, etc., y los requisitos funcionales rara vez se analizan.
● Los requisitos involucrarán la estrategia de desarrollo de la empresa, los principales problemas existentes y las expectativas de informatización de la empresa.
● El contenido discutido en la comunicación puede ser relativamente abstracto y las necesidades son en su mayoría implícitas. Para que puedan convertirse en necesidades reales se requiere orientación, juicio y confirmación por parte de los consultores. La consulta previa a la venta generalmente habla de requisitos relativamente altos. Son la principal fuente de "requisitos objetivo" en el análisis de demanda posterior y son las expectativas de valor de los gerentes comerciales para los sistemas de información (aunque pueden proponerse de manera implícita). En la etapa posterior llamada "investigación de la demanda", es posible que a menudo no haya oportunidad de escuchar directamente las necesidades de los ejecutivos corporativos, por lo que el contenido de esta parte debe registrarse como una demanda muy importante y servir como material de referencia importante para análisis posterior de la demanda.
2. Consulta de preventa e ingeniería de requisitos
El método de consulta de preventa depende en gran medida de la capacidad y el encanto personal del consultor. No tiene entregables ni plantillas particularmente estandarizados y estándar, por lo que el trabajo de consultoría no lo es. Enumerado claramente cuando se trata de ingeniería de requisitos (diferentes proveedores de software pueden tener diferentes métodos de división), el enfoque de los dos es diferente.
(1) Consulta previa a la venta: El objetivo es proponer soluciones y ayudar al departamento de ventas en la firma de contratos a través de actividades de consulta previa a la venta.
(2) Ingeniería de requisitos: el objetivo es ingresar al sitio del cliente y realizar una investigación detallada sobre el contenido determinado del contrato. Aunque el objetivo principal de la consulta es facilitar la firma de un contrato, la información recopilada durante la etapa de consulta es un objeto muy importante del análisis de ingeniería de requisitos, especialmente los "requisitos objetivo".
3. El papel de los consultores
(1) Los consultores representan el nivel profesional más alto de las empresas de software. Debería ser la tarjeta de presentación de las empresas de software.
(2) Los consultores son evangelistas que explican de manera integral las ideas y propuestas del proveedor de software.
(3) Si el punto de partida establecido por el consultor es alto, el punto de partida de todo el proyecto será alto y el valor total será alto (tanto para el proveedor de software como para el cliente).
(4) Los consultores deben poder utilizar su conocimiento y experiencia acumulados para servir como consultores y consultores para los tomadores de decisiones de sus clientes.
(5) El enfoque del trabajo del consultor es comunicarse con los tomadores de decisiones del proyecto del cliente y obtener las metas, expectativas y otras necesidades del cliente.
4. Requisitos de capacidad del consultor
Para los consultores expertos que realizan consultas de preventa, los requisitos para él son relativamente altos, lo que se refleja principalmente en los siguientes aspectos (sin limitarse a esto).
1) Capacidad de comunicación El objetivo de la comunicación incluye el nivel de toma de decisiones del cliente, producción, finanzas y otros mandos intermedios. Los requisitos de capacidad son relativamente altos, por ejemplo,
●. Comprensión: ¿puedes entender la esencia de la conversación en la cima, las demandas subyacentes?
● Visualización: ¿Se pueden demostrar plenamente las capacidades de servicio y de producto de la empresa de software?
● Persuasión: ¿Puede convencer a los clientes, por ejemplo, de que necesitan realizar los cambios correspondientes en la organización o en el sistema de gestión después de introducir el sistema? etc.
2) Capacidad profesional Para un consultor, los requisitos de su capacidad profesional son amplios.
● ¿Tiene conocimientos básicos de consultoría industrial?
● ¿Está familiarizado con el negocio principal y los conocimientos comerciales auxiliares del cliente?
● Si tiene conocimientos básicos de las últimas tecnologías, casos coincidentes, soluciones, etc. en la industria del software.
La descomposición del proyecto de ingeniería de requisitos se divide en dos etapas, a saber, la etapa de investigación de requisitos y la etapa de análisis de requisitos.
Hay dos tareas principales en la etapa de investigación de requisitos: investigación de la demanda. y recopilación de datos.
(1) Investigación de la demanda: utilice cuestionarios, diagramas de estado, registros de entrevistas y formularios existentes para recopilar las necesidades de los clientes.
(2) Resumen de datos: resuma los datos recopilados durante el proceso de investigación para formar un resumen de datos de investigación de la demanda, que sirve como base para el análisis en la etapa de análisis de la demanda.
Hay dos tareas principales en la etapa de análisis de la demanda: análisis de la demanda y recopilación de datos.
(1) Análisis de la demanda: analice las necesidades del cliente en función de los datos de la investigación de la demanda y finalmente confirme las funciones que el sistema debe implementar.
(2) Resumen de datos: resuma los datos de los resultados del análisis para formar una especificación de requisitos, que se utilizará como entrada para cada etapa de diseño posterior.
1. Investigación de la demanda
El propósito de la investigación de la demanda es principalmente recopilar y registrar las necesidades de información de los clientes. La atención se centra en el "registro" del contenido, en lugar del "análisis" o el "diseño", para evitar la necesidad. Para que el análisis y el diseño se integren a las necesidades, según la opinión personal del analista, los datos en la etapa de investigación de la demanda deben mantener su "originalidad" (el uso de plantillas de demanda es para estandarizar y formatear el contenido del registro).
2. Análisis de la demanda
Basándonos en la comprensión de los datos de la investigación de la demanda, los extrajimos, clasificamos y clasificamos. Al mismo tiempo, completamos los puntos de interrupción durante la investigación basada en el análisis y los llevamos a cabo. En una expresión más estandarizada, lo importante es que el analista de demanda agrega comprensión personal a través del análisis de las necesidades de alto nivel, como las necesidades de los objetivos y las necesidades comerciales, así como opiniones valiosas sobre cómo mejorar la informatización empresarial, por lo que habrá una brecha. entre los resultados del análisis de demanda y los registros originales. De manera diferente, la comprensión del analista de requisitos representa la comprensión del equipo de desarrollo de software y, en base a esto, se confirma con el cliente y el borrador final constituye los datos de entrada para el siguiente. enlace de diseño.
Por tanto, la capacidad del analista de la demanda afectará en última instancia al contenido, la tecnología, el coste y el ciclo del sistema de información.
3. La relación entre los dos
Ambos se describen en términos de diseño no técnico, la investigación de la demanda se registra en "términos del cliente" y el análisis de la demanda utiliza "términos de diseño empresarial" para expresar los resultados del análisis. Los dos son diferentes en términos de propósitos de trabajo: el diagrama de procesos de negocios producido por el análisis de requisitos debe tener integridad comercial y ajustarse a la expresión estándar de los procesos de negocios, mientras que el diagrama de procesos de negocios recopilado por la investigación de requisitos puede estar fragmentado e inconsistente. Cuenta corriente continua. El análisis de requisitos extrae y clasifica el contenido de las entidades de demanda y establece una tabla del sistema de demanda; la etapa de investigación de la demanda no requiere esta clasificación, solo se requiere la recopilación y el registro originales (debe conservarse el estado original). Los resultados del análisis de la demanda tienen dos funciones: confirmar a los clientes del front-end y enviar la base del diseño al back-end; los resultados de la investigación de la demanda solo proporcionan información para el análisis de la demanda. Las mayores diferencias entre los dos son las siguientes.
(1) Investigación de la demanda: centrarse en la recopilación y registro de las necesidades originales.
(2) Análisis de la demanda: centrándose en la comprensión, recopilación y confirmación generales, el análisis de la demanda no es una repetición de la investigación de la demanda.
El impacto de los datos completados en la etapa de ingeniería de requisitos en las etapas de diseño posteriores
(1) Investigación de la demanda: recopile y clasifique las necesidades originales de los clientes.
(2) Análisis de la demanda: los datos de la investigación solo se proporcionan para el análisis de la demanda y no pueden ser citados directamente por el diseño (se puede hacer referencia a ellos).
(3) Diseño del esquema: Es necesario cubrir completamente los resultados del análisis de la demanda y dar un plan.
(4) Diseño de detalle: En principio, el diseño de detalle se lleva a cabo en base a los resultados del diseño del esquema.
(5) Diseño de aplicaciones: proporcione métodos de implementación del sistema para los requisitos de la aplicación en el análisis de la demanda.
(6) Diseño técnico: Responder a requisitos no funcionales y requisitos técnicos en los resultados del análisis de requisitos.
(7), (8) Desarrollo ~ Pruebas: los resultados del análisis de la demanda no se pueden utilizar como base para el desarrollo y las pruebas (puede consultarlos).
(X) Aceptación del sistema: La aceptación final del sistema por parte del cliente se basa en la especificación de requisitos. ?
La investigación de la demanda no se realiza según el orden de trabajo ni la relación entre los contenidos de la investigación, por lo que no existe una descomposición del trabajo en sentido estricto, sino que se divide según las diferentes formas de expresión de la demanda. La forma de expresión de la demanda se divide en tres tipos.
(1) Gráficos: incluye gráficos que expresan el estado comercial del cliente, necesidades expresadas a través de interfaces, etc.
(2) Tipo de texto: necesidades expresadas en palabras recogidas a través de cuestionarios y registros de entrevistas.
(3) Tipo de formulario: informe real y requisitos de documentos proporcionados por el cliente.
Estos tres tipos de datos no tienen correlación ni orden necesarios entre sí y pueden recopilarse al mismo tiempo.
Después de clasificar los resultados de la encuesta de demanda, los requisitos no funcionales restantes son requisitos funcionales. Se pueden dividir en: requisitos objetivo, requisitos comerciales y requisitos funcionales según la definición de requisitos funcionales. Estos tres tienen una relación de conversión de requisitos objetivo → requisitos comerciales → requisitos funcionales. Estrictamente hablando, no son tres tipos de requisitos sino tres niveles de requisitos. Al final, sólo se pueden implementar en el sistema los requisitos funcionales que se convierten en la tercera capa. En este orden se determina el desglose del trabajo de la fase de análisis.
(1) El primer nivel de trabajo: análisis de las necesidades del objetivo y conversión a las necesidades del negocio.
(2) El segundo nivel de trabajo: análisis de requisitos comerciales y conversión a requisitos funcionales.
(3) Tercer nivel de trabajo: análisis y determinación de requisitos funcionales.
Establecer un sistema de demanda correspondiente. Sin este sistema de demanda, utilizaremos la experiencia personal para resolver los problemas de los clientes. Con este sistema, podemos utilizar la experiencia y la sabiduría colectivas para resolver los problemas de los clientes. El sistema de demanda aquí se refiere principalmente al establecimiento de "requisitos comerciales".
Establecer un sistema de demanda puede aportar mucho valor. A continuación se muestran algunos ejemplos.
1. Acumulación sistemática de conocimiento
(1) Los resultados de la investigación y la práctica se pueden acumular de manera ordenada, incluyendo: conceptos, métodos, estándares, normas, etc.
(2) Acumulación de valor para el cliente, incluyendo: diferentes campos de negocio, industrias, sectores, sistemas, módulos, funciones, etc.
2. La necesidad de escala comercial
(1) Mejorar el valor de las empresas de software y proporcionar a los clientes soluciones sistemáticas.
(2) Extraer, planificar y establecer nuevos modelos de negocio para responder rápidamente a las necesidades de los clientes.
3. Reducir costes y mejorar la eficiencia
(1) El conocimiento acumulado se puede reutilizar y compartir de forma eficaz, reduciendo costes.
(2) Puede acortar en gran medida el ciclo de desarrollo y ayudar a reducir el fenómeno de la "distorsión de la demanda".
4． La medida principal para evitar riesgos
(1) La mejor manera de evitar riesgos es informar a todos qué hacer con anticipación. Esto se puede hacer con el soporte del sistema.
(2) Los problemas con capacidades humanas insuficientes y poco tiempo de investigación y análisis se pueden resolver con la ayuda de bases de conocimiento.
5. Un atajo para cultivar talentos rápidamente Como analista de demanda, se requieren muchas habilidades, como "capacidad comercial", "capacidad de comunicación", "capacidad abstracta", "capacidad de desempeño", etc., pero esto es demasiado abstracto. , difícil de entender y no se puede lograr en un día. Establecer una base de conocimientos que pueda proporcionar referencia directa e intercambio para la mayoría de las personas puede hacer que los necesitados sean "ordenados y fáciles de seguir". Es como una "plataforma empresarial" que permite a todos brindar experiencia, compartir conocimientos y ser * para todos *. *Mismo mantenimiento.
Se puede decir que la ingeniería de requisitos es un conocimiento básico para todos los involucrados en la industria del software. Porque su contenido principal es:
(1) ¿Cómo comunicarse con los demás, cómo comprender rápidamente las ideas de los demás, cómo transmitir ideas a los demás, etc.?
(2) ¿Cómo encontrar rápidamente un punto de entrada para un objeto de investigación complejo y desconocido?
(3) ¿Cómo expresar un objeto poco claro en lenguaje sencillo, gráficos o tablas?
(4) ¿Cómo convertir las necesidades expresadas en términos de cliente (conocimiento, experiencia) en expresiones en términos de diseño empresarial? etc.
? La cantidad de requisitos del sistema de información de gestión y el valor agregado de los requisitos dependen del propósito de informatización del cliente y de la capacidad del analista de demanda. La posición del analista de demanda generalmente se encuentra entre la "consultoría". posición al frente entre el "ingeniero" y el "diseñador de negocios" detrás, cuando la empresa de software tiene estas dos posiciones o el proyecto está configurado con estas dos posiciones, el impacto de las propias habilidades del analista de requisitos en el proyecto puede ser. controlado hasta cierto punto, si la empresa de software no tiene otras dos posiciones o el proyecto no configura estas dos posiciones, entonces el analista de requisitos determinará el nivel más alto del proyecto (generalmente se determina el nivel más alto de los proyectos de gestión empresarial). por el diseñador de negocios), por lo que debe dominar ciertos conocimientos de consultoría y diseño de negocios.
La ingeniería de requisitos toma los aportes del diseño como estándar de requisitos
La ingeniería de requisitos no es solo un "conocimiento", sino también una "tecnología" que se puede implementar cualitativa y cuantitativamente. Tiene plantillas. Existen procesos y estándares y, lo que es más importante, tienen una estricta relación de transmisión y herencia con el diseño posterior. Dado que el alcance, contenido, formato, etc. del diseño se utilizan como estándares de salida de la ingeniería de requisitos, el contenido a ser. Lo que se hace en ingeniería de requisitos es muy específico y estandarizado, y la operatividad de la ingeniería de requisitos como "tecnología" ha mejorado enormemente. Establecer un método que utilice datos de diseño como estándares de ingeniería de requisitos puede mejorar la calidad del diseño, la calidad del producto y la eficiencia del trabajo.