Programa de
Ingeniería de
Sistemas
INGENIERÍA
DE
SOFTWARE
Sesión 3
Tema:
Gestión de los Requerimientos
en la construcción del software
Requerimientos funcionales no
funcionales y de dominio del
proyecto de software .
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Orientación Universidad
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Busca documentos
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Busca tu universidad
Encuentra los documentos específicos para los exámenes de tu universidad
Video Cursos
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Quiz
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pregúntale a la comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
¡Nuestros e-books salva-estudiantes!
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Gestión de los Requerimientos en la Construcción del Software - Prof. Cabanillas Novoa, Apuntes de Neurología
Este documento aborda la importancia de la gestión eficiente de los requerimientos en el desarrollo de software. Presenta los conceptos clave de requerimientos funcionales, no funcionales y de dominio, y cómo estos elementos son fundamentales para asegurar que el producto final cumpla con las necesidades y expectativas del cliente. El documento también destaca los desafíos comunes en la gestión de requerimientos de dominio y la relevancia de una adecuada gestión de requerimientos para garantizar la calidad y usabilidad del software. Además, se incluye información sobre el modelado de casos de uso del sistema, los actores y los procesos clave del sistema. Este material puede ser valioso para estudiantes de ingeniería de software, programadores y profesionales del área que buscan comprender mejor la gestión de requerimientos en proyectos de desarrollo de software.
Tipo: Apuntes
2021/2022
1 / 41
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Documentos relacionados
Vista previa parcial del texto
¡Descarga Gestión de los Requerimientos en la Construcción del Software - Prof. Cabanillas Novoa y más Apuntes en PDF de Neurología solo en Docsity!
Programa de Ingeniería de Sistemas
INGENIERÍA
DE
SOFTWARE
Sesión 3
Tema: Gestión de los Requerimientos en la construcción del software Requerimientos funcionales no funcionales y de dominio del proyecto de software.
Resultado de
aprendizaje
Diseña la capa de dominio la construcción e implementación de un software para una empresa.
Evidencia de
aprendizaje
Informe Académico individual de: Requerimientos funcionales.
Revisa el siguiente video:
Después de haber visualizado el video en la slide
anterior, reflexionamos y respondemos las
siguientes interrogantes:
0 1 ¿Cuál es la idea principal o el concepto clave que se destaca en el video? 0 2 ¿Cómo se relaciona este tema con otros conceptos dentro del mismo campo de estudio? 0 3 ¿Cuáles son las implicaciones prácticas o aplicaciones de este conocimiento en la vida cotidiana o en el ámbito profesional?
Modelo de casos de uso de sistemas Análisis y diseño de Sistemas - Sesión 3
- Modelo Casos de Uso del Sistema
- (^) El Modelo de Casos de Uso del sistema define y modela todos los elementos que describen los requerimientos funcionales del sistema.
- (^) Modela la forma en que el sistema es usado por sus usuarios, clientes, patrocinadores, etc. Análisis y diseño de Sistemas - Sesión 3
- Modelo Casos de Uso del Sistema
- (^) Estereotipos más importantes en el Modelo de Casos de Uso del Sistema. Actor Caso de Uso Análisis y diseño de Sistemas - Sesión 3
- Modelo Casos de Uso del Sistema
- Identificar los actores del sistema (actors). 1.1 Lista de actores del sistema.
- Identificar los paquetes del sistema. 2.1 Diagrama de Paquetes del Sistema.
- Identificar los casos de uso del sistema (use cases). 3.1 Lista de casos de uso del sistema. 3.2 Diagrama de Casos de Uso del Sistema. Análisis y diseño de Sistemas - Sesión 3
2.3 Casos de uso del sistema
- Un caso de uso del sistema identifica:
- (^) Es un proceso específico del sistema con identidad propia.
- (^) Define una secuencia de acciones que el sistema realiza para un actor en particular.
- (^) Define la interacción con el actor correspondiente.
- (^) Produce un resultado observable y esperado para el actor correspondiente. Nombre del caso de uso Análisis y diseño de Sistemas - Sesión 3
2.3.2 Diagrama Casos de uso Sistema Registrar la venta Análisis y diseño de Sistemas - Sesión 3
Entrevista con Directivos Requerimiento funcionales El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema. R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo. R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema. R3. Nuestro Sistema deberá ser instalado en nuestro servidor Web que manejara la seguridad de acceso para los clientes y los empleados. R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a ingresar son fecha y hora de recepción. R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema. R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio. R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de Cuenta. R8. El sistema deberá ser desarrollado en PHP y como gestor de base de datos MySql. R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos pendientes. R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema. 10/05/2024 (^16) Análisis y diseño de Sistemas - Sesión 3
Entrevista con Directivos Requerimientos no funcionales. El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema. R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo. R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema. R3. Nuestro Sistema deberá ser instalado en nuestro servidor Web que manejara la seguridad de acceso para los clientes y los empleados. R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a ingresar son fecha y hora de recepción. R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema. R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio. R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de Cuenta. R8. El sistema deberá ser desarrollado en PHP y como gestor de base de datos MySql. R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos pendientes. R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema. 10/05/2024 (^17) Análisis y diseño de Sistemas - Sesión 3
Dividir Procesos El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema. Inscripción de Clientes:
- (^) R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo.
- (^) R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema.
- (^) R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a ingresar son fecha y hora de recepción.
- R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema. Servicio de Mantenimiento
- R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio.
- (^) R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de Cuenta.
- (^) R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos pendientes.
- (^) R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema. 19 Análisis y diseño de Sistemas - Sesión 3
Diagrama de Arquitectura Inscripcion de Clientes Servicios de Mantenimiento Análisis y diseño de Sistemas - Sesión 3