1. Introducción
1.1 Antecedentes
Descripción:
a. El nombre del sistema de software a desarrollar;
b. El proponente de la tarea, desarrollador, usuario de este proyecto y el centro de cómputo o red informática que implementa el software
C. La interrelación básica entre el sistema de software y otros sistemas u otras organizaciones.
1.2. Materiales de referencia
Enumerar los materiales citados y referenciados en este manual, tales como:
a. La declaración de misión aprobada o contrato de este proyecto, y el documento de aprobación de la autoridad superior;
b. Otros documentos publicados pertenecientes a este proyecto
c. Los documentos y materiales citados a lo largo de este documento incluyen los estándares de desarrollo de software que se utilizarán. Indique el título, número de documento, fecha de publicación y unidad de publicación de estos documentos e información, e indique la fuente de donde se pueden obtener estos documentos e información.
1.3.Supuestos y limitaciones [opcional]
Enumere los supuestos y limitaciones para el desarrollo de este software, como limitaciones de financiación, plazos de desarrollo, condiciones del equipo, preparación de datos del usuario y comunicación. cuestiones, etc.
1.4.Características del usuario [opcional]
Enumere las características de los usuarios finales de este software, describa completamente el nivel de educación y experiencia técnica de los operadores y el personal de mantenimiento, y el software esperado. frecuencia de uso. Éstas son limitaciones importantes para el trabajo de diseño de software.
2. Requisitos funcionales
2.1. Alcance del sistema
Describa de forma clara y breve los requisitos objetivos de alto nivel del usuario para el sistema y el producto, como la intención. del desarrollo del sistema, objetivos de la aplicación, alcance y otro material de antecedentes relevante.
Si el producto definido es un componente de un sistema más grande, se debe explicar la relación entre el producto y otros componentes del sistema. Para ello, se puede utilizar un diagrama de bloques para ilustrar la composición de. el sistema y la conexión e interfaz entre este producto y otras piezas.
2.2. Arquitectura del sistema (esta sección se puede eliminar para sistemas con arquitectura de dos niveles) [Opcional]
Describe la arquitectura general del sistema utilizando una combinación de imágenes y texto.
A continuación se debe proporcionar el diagrama general de la arquitectura del sistema:
A continuación se describe la arquitectura general del sistema:
2.3 Proceso general del sistema
La Figura 1 es el diagrama de flujo general del sistema de gestión de contratos de planificación.
Figura 1
2.4. Análisis de requisitos
El propósito del análisis de requisitos es obtener o describir cada requisito funcional en los requisitos del sistema, y determinar mediante análisis que ¿Qué puede hacer el sistema? ¿Quién utilizará este sistema?
· Establezca un modelo de casos de uso: descubra roles y casos de uso, y determine la relación entre roles, la relación entre casos de uso y la relación entre roles y casos de uso
· Describa Casos de uso: Una especificación de cómo el personaje interactúa con el sistema.
2.4.1. Describir los requisitos funcionales desde la perspectiva del negocio del usuario.
2.4.1.2. Modelado de negocio
Desde una perspectiva visual - diagrama de casos de uso - describir requisitos funcionales
La figura 2 es la edición del contrato de la gestión de planificación integral Sistema Diagrama de casos de uso de los requisitos funcionales del negocio.
Figura 2
2.4.1.3. Descripción del caso de uso
Describe en texto las especificaciones de la interacción entre el rol y el sistema en cada caso de uso.
1. XXXXXX (nombre del caso de uso)
Describe el contenido de la descripción del objeto
Identificador El identificador único del caso de uso
Describe el caso de uso Descripción resumida
Actores Lista de actores asociados con este caso de uso y características del actor
Frecuencia Con qué frecuencia los actores acceden a este caso de uso
Estado Normal Dividido en: en progreso, en espera de revisión, revisión aprobada o revisión fallida
Condiciones previas Una lista de condiciones; si contiene condiciones, estas condiciones deben cumplirse antes de acceder al caso de uso
Postcondiciones Una lista de condiciones que, si se incluyen, se cumplirán después de que el caso de uso se complete exitosamente
Caso de uso extendido El caso de uso que este caso de uso extiende (si existe)
Uso incluido case El caso de uso incluido en este caso de uso (si existe)
La ruta lógica principal seguida por los participantes del proceso de operación básica en el caso de uso, es decir, el trabajo del caso de uso cuando todo el trabajo está se lleva a cabo normalmente Método
La ruta que sigue el proceso de operación opcional cuando se cambian los métodos de trabajo, se producen excepciones o se producen errores
Historial de modificaciones modificado por: Fecha de modificación: Motivo de la modificación:
p>
Emitir, si corresponde, una lista de problemas o elementos de acción relacionados con el desarrollo de este caso de uso
La siguiente es la descripción del caso de uso de adición de contrato en el contrato. edición de requisitos funcionales en el sistema integrado de gestión de planificación:
Describir el contenido de la descripción del objeto
Identificador IPMS0101
Instrucciones para agregar un registro de contrato
Editor de contratos del participante: familiarizado con la gestión de contratos Negocio
Frecuencia
Estado aprobado
Requisitos previos 1. El participante tiene los permisos aumentados por el contrato 2. El el participante ha seleccionado el registro del plan correspondiente 3. Inversión total planificada actual ≥ SUMA (precio del contrato firmado según el plan)
Poscondiciones 1. Agregar una disciplina de contrato a la base de datos 2. Caso de uso para escanear el ejecutable original. contrato 3. Caso de uso para agregar pago al contrato ejecutable 4. Casos de uso de modificación y eliminación de contrato ejecutable
Ninguno de los casos de uso extendidos
Ninguno de los casos de uso incluidos
Para el proceso de operación básico, consulte el contrato en la Figura 3 Proceso de agregar
Proceso de operación opcional Cuando el usuario encuentra una excepción al confirmar la adición del contrato, el sistema le indica que el contrato la adición no es válida
Historial de modificaciones Modificador: Fecha de modificación: Motivo de la modificación:
Pregunta 1. Acuerdo específico sobre codificación de contratos 2. Diseño específico del tipo de contrato, fuente de fondos y cesionario del contrato tabla de diccionario
Figura 3 Proceso de actividad de adición de contrato
2.
2.4.2. XXXXXXX (nombre del requisito funcional)
……
3.Requisitos no funcionales
3.
3.1.1. Precisión [opcional]
Describa los requisitos de precisión para los datos de entrada y salida del software, que pueden incluir precisión durante el proceso de transmisión.
3.1.2.Requisitos de características de tiempo
Explique los requisitos de características de tiempo para el software, tales como: tiempo de respuesta; tiempo de procesamiento de actualización y tiempo de transmisión de actualización de interfaz, etc. Requerir.
3.1.3. Requisitos de entrada y salida
Explicar cada tipo de datos de entrada y salida, y describir elemento por elemento su soporte, formato, rango numérico, precisión, etc.
Explique y dé ejemplos de las salidas de datos y de control del software que deben etiquetarse, incluidas descripciones de informes impresos (salida de resultados normales, salida de estado y salida anormal) e informes gráficos o de visualización.
3.2. Requisitos de capacidad de gestión de datos [opcional]
Describa el número de archivos y registros que deben gestionarse, el tamaño de las tablas y archivos, y el tamaño de los archivos a gestionar. gestionarse en función del crecimiento previsible. Se realizan estimaciones de las necesidades de almacenamiento de los datos y sus componentes.
3.3. Requisitos de seguridad y confidencialidad
Los usuarios tienen requisitos para las capacidades de manejo de fallas del sistema, los métodos de procesamiento, la recuperación del sistema y la recuperación de datos después de fallas, y el sistema para evitar que se guarden datos confidenciales. accedido.Requisitos por intrusión ilegal, modificación y pérdida.
3.4.Requisitos de flexibilidad [opcional]
Describe los requisitos para la flexibilidad del software, es decir, cuando ocurren ciertos cambios en los requisitos, la capacidad del software para adaptarse a estos cambios. tales como:
a. Cambios en los métodos operativos;
b. Cambios en el entorno operativo;
c. Cambios en interfaces con otro software;
d. Cambios en la precisión y el período de validez;
e. Cambios o mejoras planificadas.
Deben identificarse secciones especialmente diseñadas para proporcionar esta flexibilidad.
3.5.Otros requisitos especiales [opcional]
Por ejemplo, requisitos de las unidades de usuario en cuanto a facilidad de uso, mantenibilidad, complementabilidad, legibilidad, confiabilidad y manejo de excepciones, requisitos especiales para la convertibilidad de los entornos operativos, etc.
4. Requisitos del entorno operativo
4.1. Equipo
Enumere el equipo de hardware necesario para ejecutar el software. Describir el nuevo equipo y sus funciones especializadas, incluyendo:
a. Modelo de procesador y capacidad de memoria;
b. Capacidad de almacenamiento externo, en línea o fuera de línea, medios y su formato de almacenamiento, modelo y cantidad de equipos
c. Modelo y cantidad de dispositivos de entrada y salida, en línea o fuera de línea
d. Modelo y cantidad de equipos de comunicación de datos;
e. Teclas de función y otro hardware especial
4.2. Software de soporte
Enumere el software de soporte, incluidas las plataformas de dispositivos de hardware y de red, las plataformas de sistemas operativos, las plataformas de sistemas de bases de datos y los programas de compilación (o ensamblaje). y software de soporte de prueba, etc.
4.3. Interfaz [opcional]
Describe la interfaz, protocolo de comunicación de datos, etc. entre el software y otro software.
4.4.Control [opcional]
Describir los métodos y señales de control para controlar el funcionamiento del software, y explicar las fuentes de estas señales de control.
5. Seguimiento de requisitos
El objetivo principal del seguimiento de la demanda es garantizar que se analicen todos los requisitos y que los requisitos analizados se describan en forma de tabla de correspondencia entre requisitos comprometidos y requisitos analizados. (Tabla PRS_SRS) Cobertura de necesidades comprometidas. Para conocer el formato de la tabla PRS_SRS, consulte la Especificación del proceso de gestión de requisitos de software (SUPL-MANU-SRS-001).