[Una breve discusión sobre las principales tareas de la fase de análisis de requisitos del desarrollo de software_upload] Las principales tareas de la fase de requisitos
Una breve discusión de las principales tareas en la fase de análisis de requisitos de desarrollo de software
1. Identificación del problema
Primero, los analistas de sistemas deben estudiar el informe de análisis de viabilidad y Informe de análisis de viabilidad elaborado en la fase de planificación del plan de implementación del proyecto de software. Entiende principalmente el software desde una perspectiva del sistema y revisa si el alcance del software utilizado para generar estimaciones del plan es apropiado, determina los requisitos integrales para el sistema objetivo, es decir, los requisitos del software y propone las condiciones para su realización; requisitos, así como los estándares que deben cumplir los requisitos, y también es resolver los requisitos de lo que debe hacer el software desarrollado y en qué medida. Estos requisitos incluyen:
(1) Requisitos funcionales: enumere lo que el software desarrollado debe hacer funcionalmente. Este es el requisito más importante.
(2) Requisitos de rendimiento: proporcione los indicadores de rendimiento técnico del software desarrollado, incluidos límites de capacidad de almacenamiento, límites de tiempo de ejecución, seguridad, confidencialidad, etc.
(3) Requisitos ambientales: Son los requisitos del entorno en el que se ejecuta el sistema de software. Por ejemplo, en términos de hardware, qué modelo se utiliza, qué dispositivos externos, interfaces de comunicación de datos, etc. se utilizan, en términos de software, qué sistema se utiliza para respaldar el funcionamiento del sistema;
(4) Requisitos de confiabilidad: cuando se ejecutan varios programas, el impacto de la falla es diferente. Durante el análisis de la demanda, se deben plantear requisitos basados en el entorno operativo real con respecto a la probabilidad de que el software desarrollado no funcione mal después de su puesta en funcionamiento. Para aquellos software importantes, o software cuya falla operativa causará consecuencias graves, se deben plantear requisitos de confiabilidad más altos, de modo que se puedan tomar las medidas necesarias durante el proceso de desarrollo para que los productos de software puedan ejecutarse de manera altamente confiable y estable para evitar fallas operativas. pérdidas causadas por el accidente.
(5) Requisitos de seguridad y confidencialidad: el software que funciona en diferentes entornos obviamente tiene diferentes requisitos de seguridad y confidencialidad. Los requisitos en esta área deben especificarse adecuadamente para que el software desarrollado pueda diseñarse especialmente de modo que se pueda garantizar su rendimiento de seguridad y confidencialidad según sea necesario durante la operación.
(6) Requisitos de la interfaz de usuario: la facilidad de uso del software y la interfaz de usuario es una de las claves para que los usuarios utilicen el software de manera conveniente y efectiva. Desde una perspectiva de mercado, el software con una interfaz de usuario amigable tiene un mercado fuerte. competitividad. Por lo tanto, los requisitos que se deben alcanzar para la interfaz de usuario deben especificarse cuidadosamente durante el análisis de requisitos.
(7) Requisitos de uso de recursos: se refiere a los datos, software, memoria, espacio y otros recursos necesarios cuando se ejecuta el software desarrollado. Además, la mano de obra, el software de soporte, el equipo de desarrollo, etc. necesarios para el desarrollo de software son recursos de desarrollo de software y deben determinarse durante el análisis de la demanda.
(8) Requisitos de progreso del desarrollo y consumo de costos del software: una vez aprobado el proyecto de software, los requisitos para el progreso del desarrollo del software y el costo de cada paso deben establecerse de acuerdo con las disposiciones del contrato como base. para la gestión del desarrollo.
(9) Estimar de antemano los objetivos que el sistema podrá alcanzar en el futuro. De esta manera, durante el proceso de desarrollo, se pueden hacer preparativos para una posible futura expansión y modificación del sistema. Una vez que sea necesario, será más fácil realizar adiciones y modificaciones.
Las personas generalmente se preocupan por los requisitos funcionales, pero el análisis de los requisitos no funcionales a menudo se ignora. De hecho, los requisitos no funcionales no son irrelevantes. Sus características principales involucran muchos y amplios aspectos, pero se pasan por alto fácilmente. Los requisitos no funcionales de cualquier software deben determinarse según su tipo y entorno de trabajo.
Otra tarea de identificación de problemas es establecer los canales de comunicación (comunicación) necesarios para el análisis para garantizar que el problema se pueda analizar sin problemas. Los analistas deben establecer relaciones con los usuarios, la dirección de la organización de desarrollo de software y el personal del grupo de desarrollo de software. El líder del proyecto desempeña el papel de coordinador en este proceso. Los analistas discuten con todas las partes a través de este canal de comunicación para identificar el contenido básico del problema de acuerdo con los requisitos del usuario.
Además, si no se ha realizado un análisis de viabilidad antes de realizar el análisis de la demanda, a menudo es necesario complementar esta parte del trabajo para comenzar con la definición del problema y la investigación, y tener un contacto cercano con los usuarios. comprender el problema en detalle, determinar qué problemas resolver y luego realizar investigaciones de mercado e inspecciones in situ en función de las características del sistema de software y los objetivos del usuario. Después de recopilar información cuidadosamente, realizamos análisis de datos y análisis funcionales, establecemos un modelo lógico de alto nivel del sistema y luego realizamos análisis adicionales de costo/beneficio. Finalmente, se presenta un informe de análisis de viabilidad para demostrar la viabilidad desde los aspectos de tecnología, economía y efectos sociales para confirmar si el objetivo de desarrollo de software es factible.
2. Análisis y síntesis
El segundo paso del análisis de la demanda es el análisis del problema y la síntesis de soluciones.
Los analistas deben comenzar desde el flujo de datos y la estructura de datos, refinar gradualmente todas las funciones del software, descubrir las conexiones entre los diversos elementos del sistema, las características de la interfaz y las limitaciones de diseño, y analizar si cumplen con los requisitos funcionales. requisitos ¿Es razonable? Según los requisitos funcionales, los requisitos de rendimiento, los requisitos del entorno operativo, etc., elimine las piezas irrazonables y agregue las piezas necesarias. Finalmente, se sintetiza la solución del sistema y se proporciona un modelo lógico detallado del sistema objetivo.
En este paso se realizan trabajos de análisis y síntesis de forma iterativa. Con base en el análisis del problema actual y la información deseada (entrada y salida), el analista comienza a sintetizar una o varias soluciones, luego verifica si su trabajo se ajusta al alcance especificado en el plan de software, etc., y luego toma modificaciones. En resumen, el proceso de análisis y síntesis del problema continuará hasta que tanto el analista como el usuario se sientan seguros de que las especificaciones del software han sido formuladas correctamente.
Los métodos de análisis de requisitos comúnmente utilizados tienen una estructura orientada al flujo de datos. método de análisis (SA para abreviar), método de Jackson para estructura de datos (JSD para abreviar), método de análisis orientado a objetos (OOA para abreviar), etc., así como diagrama de transición de estados o red de Petri para establecer modelos dinámicos, etc.
3. Preparar documentos de análisis de requisitos
En el modelo en cascada de desarrollo de software, el documento final formado en cada etapa es un hito para la finalización de la etapa. Por tanto, el análisis de requisitos. La etapa prepara los documentos para prepararse. La revisión del siguiente paso también es una de las tareas importantes en esta etapa. Las necesidades identificadas anteriormente deben describirse de forma clara y precisa. El documento que describe los requisitos suele denominarse especificación de requisitos de software. Al mismo tiempo, para expresar con precisión los requisitos de entrada y salida del usuario para el software, también es necesario formular una especificación de requisitos de datos y escribir un manual de usuario preliminar, centrándose en reflejar la interfaz de usuario del software desarrollado y las características específicas. requerimientos del usuario. Además, con base en un análisis más detallado del sistema en la etapa de análisis de requisitos, a partir del modelo refinado del sistema objetivo, se puede estimar con mayor precisión el costo y el progreso del proyecto desarrollado, modificando, mejorando y determinando la implementación del desarrollo de software. plan.
4. Revisión del Análisis de Requisitos
Como método de revisión para la etapa de análisis de requisitos, en el último paso del análisis de requisitos, se verifica la corrección, integridad y claridad de las funciones, así como como otros Necesitan ser evaluados. Los contenidos principales de la revisión son:
(1) Si los objetivos definidos por el sistema son consistentes con los requisitos del usuario;
(2) Si la documentación proporcionada durante los requisitos del sistema la fase de análisis está completa;
p>
(3) Si todas las descripciones en el documento son completas y claras, y si reflejan con precisión los requisitos del usuario;
(4) Si se han descrito las interfaces importantes con todos los demás componentes del sistema;
(5) Si el flujo de datos y la estructura de datos del proyecto desarrollado son suficientes y seguros;
(6) Si todos los diagramas son claros y pueden entenderse sin explicación adicional;
(7) Si las funciones principales están incluidas en el alcance del software especificado y si se pueden explicar completamente;
(8 ) Si las restricciones o restricciones de diseño son realistas;
(9) ¿Cuáles son los riesgos técnicos del desarrollo?
(10) ¿Ha considerado otras soluciones a los requisitos de software?
(11) ¿Ha considerado que se pueden proponer requisitos de software en el futuro?
(12) Si los estándares de inspección se han formulado en detalle y si pueden confirmar con éxito la definición del sistema;
(13) ¿Existen omisiones, duplicaciones o inconsistencias?
(14) Si el usuario ha revisado el manual de usuario preliminar;
(15) ) Si se ha visto afectada la estimación del plan de diseño de desarrollo de software, etc.