Exposición de maestría de ingeniería de sistemas mención ingeniería de software

1. REQUERIMIENTOS DE
SOFTWARE
- Flores Poma José Luis
- Jara Gaspar Ricardo Junior
- Morales Pinto Flor de María
- Peralta Gamboa José Luis
- Rafael Toledo Yesenia

2. Introducción
 Los requerimientos de software expresan las necesidades y restricciones que
debe satisfacer un producto para contribuir a la solución de un problema real.
 Esta área de conocimiento considera la obtención, análisis, especificación y
validación de los requerimientos, así como el rol que juegan dentro del proceso
de desarrollo de software.
 Un especialista en requerimientos tiene conocimiento y experiencia en técnicas
para obtener, cuantificar, negociar, clasificar, priorizar, modelar, documentar y
validar los requerimientos de software. Además debe saber administrar
adecuadamente los cambios a éstos

3. 1. Fundamentos requerimiento software
 Un requerimiento de software es una propiedad que debe ser mostrada para resolver un problema del mundo
real.
 Una propiedad esencial de todo requerimiento de software, que pueden ser comprobados como una
característica individual o al nivel del sistema. Tienen propiedades de comportamiento como prioridad y estado.
Además se identifican de forma única.
 Requerimiento de un producto es una necesidad o restricción en el software que será desarrollado y el
requerimiento de un proceso es esencialmente una restricción en el desarrollo del software.
 Requerimientos funcionales describen las funciones que el software ejecutara.
 Requerimientos no funcionales son una restricción de la solución. Se conocen como requisitos de calidad.
Pueden clasificarse como requisitos de rendimiento, seguridad, fiabilidad, etc.
 Algunos requisitos representan propiedades emergentes del software, es decir, requisitos que no pueden ser
abordados por un solo componente pero que dependen de cómo interoperan todos los componentes del
software
 Requerimientos deberían ser claros, no ambiguos y cuantificables.
 Los requisitos del sistema son los requisitos para el sistema en su conjunto. En un sistema que contiene
componentes de software, los requisitos de software son derivados de los requisitos del sistema.

4. 2. Requerimiento de procesos
Modelos de proceso:
- No es una actividad discreta de front-end, es un proceso iniciado al comienzo del proyecto y refinado a lo largo del ciclo
de vida.
- Necesita adaptarse al negocio y al contexto del proyecto
- Se refiere a cómo las actividades de elicitación, análisis, especificación, y la validación están configurados para diferentes
tipos de proyectos y limitaciones
Actores de proceso
- Es interdisciplinario, frecuentemente se interactúa con: Clientes, usuarios, reguladores, ingenieros de software.
Proceso de soporte y gestión:
- Establece el contexto para el primer tema (Iniciación y alcance) de la gestión de la ingeniería del software; define el vínculo
entre el proceso de actividades identificadas y los problemas de gestión logística (RR.HH., costos, capacitación,
herramientas).
Proceso de calidad y mejora:
- Involucra la evaluación de la calidad y mejora del proceso de requerimientos: Su propósito es dilucidar el rol clave que
juega el proceso de requerimientos en términos de costos y tiempos con respecto a la satisfacción del cliente, este proceso
está vinculado estrechamente con calidad de software.

5. 3. Elicitación de requerimientos
Fuente de requerimientos:
- Metas
- Dominio de conocimiento
- Stakeholder
- Reglas de negocio
- Entorno operacional
Técnicas:
Por medio del proceso de elicitacion los requerimientos de
software no se diseñaran por si mismos, el ingeniero de software
debe estar sensibilizado para abstraer estos a partir de las
descripciones obtenidas ya que algunos usuarios podrían ser
poco colaborativos. Algunas técnicas son:
- Entrevistas: Es un punto básico y crucial realizar entrevistas a los
stakeholders y es necesario comprender las ventajas y
limitaciones que estas pueden tener
- Escenarios
- Prototipos
- Reuniones facilitadas
- Observación
- Historias de usuario
- Otras técnicas

6. 4. Análisis de Requisitos
El tema aborda analizar requisitos para:
•Resolver conflictos entre requisitos
•Descubrir los limites del software y como debe interactuar
con su organización y con entorno operativo.
•Elaborar los requisitos del sistema para derivarlos a
requisitos de software.
Es Importante describir requisitos con la
suficiente precisión para permitir:
•Que los requisitos puedan ser validados.
•La Implementación sea verificada.
•Los costos puedan ser estimados.

7. 4.1.Clasificación de requerimientos:
•Requisito funcional o No funcional
•Requisito que deriva de uno o mas requisitos de alto
nivel o una propiedad emergente o es impuesto
directamente por un stakeholder.
•El requisito puede estar en el producto o en el
proceso.
•La prioridad del requisito.
Ej. escala de punto fijo: requisito obligatorio, altamente
deseable, deseable u opcional.
•El alcance del requisito que puede afectar a la
arquitectura de software y sus componentes.
•Volatilidad / Estabilidad.
Marcar potencialmente los requisitos volátiles pueden ayudar
a establecer un diseño más tolerante al cambio.
4.2.Modelo conceptual:
•Ayuda a comprender la situación en la que se
produce el problema para reflejar su mundo real,
relaciones y dependencia.
Ej. Modelos de casos de uso, modelo de datos, modelos de
estados, etc.
Factores que influyen en la elección del modelo:
•Naturaleza del problema.
Ej. sofware con análisis de mayor rigor (sotfware en tiempo
real) – modelo paramétrico VS sistema de información –
modelo de actividad o objetos.
•Experiencia del Ing. de software con un tipo de
modelo.
•Los clientes imponen su notación o método preferido
o pueden prohibir si no estén familiarizados.

8. 4.3. Diseño de arquitectura y asignación de requisitos:
•Es el punto en el que el proceso de requisitos se
solapa con el diseño de software.
•El proceso de análisis y la asignación de los
requisitos exige que los componentes de
arquitectura / diseño sean identificados por que
serán responsables de satisfacer los requisitos
definidos.
4.4. Negociación de requerimientos:
•Resolución de conflictos de requisitos entre
partes interesadas sobre características
incompatibles, entre requisitos y recursos u
otros.
•La priorización de requisitos es necesaria para
resolver conflictos y planificar entregas por
etapas.
4.5. Análisis formal
•La expresión formal de los requisitos requieren un lenguaje
con semántica formalmente definida.
•Tiene dos beneficios:
• Requisitos especificados de forma precisa y sin ambigüedades.
• Requisitos que especifica las propiedades deseadas del
software para ser probado.

9. 5. Especificación de requisitos
5.1. Documento de definición del sistema
Hundred_Pacifico_Documento.Analisis.Requerimientos_AdecuacionesSistemaIntermediario
5.2. Especificación de requisitos del sistema
Hundred_Pacifico_Especificacion.CasoUso._RegistroEvaluacionesProveedoresMédicos
5.3. Especificación de requerimiento de software
Hundred_Pacifico_Estimacion_ControlesSeguridad
Hundred_Pacifico_Listado.Requerimientos_ControlesSeguridad
 Se refiere a la producción de documentos que puede ser
revisados sistemáticamente, evaluados y aprobados.

10. 6. Validación de requisitos
 Los documentos de requisitos pueden estar sujetos a
procedimientos de validación y verificación.
6.1. Revisiones de requisitos
6.2. Prototipo
Draw.io
Pencil
6.3. Modelo de Validación
6.4. Pruebas de Aceptación
Hundred_Pacifico_MatrizPrueba_Intermediarios
Hundred_Pacifico_Informe.Pruebas.Internas_Intermediarios

11. 7. Consideraciones prácticas
 El proceso de requisitos abarca todo el ciclo de vida del software.
 No todas las empresas asumen una cultura de documentación y gestión de requisitos.
 La documentación de requisitos y la gestión de cambios son clave para el éxito de
cualquier proceso de requisitos.
7.1 Naturaleza iterativa del proceso de requisitos
• Ciclos de desarrollo cada vez más cortos (Ágiles).
• La mayoría de los proyectos están limitados de alguna manera por su entorno.
• Los requisitos típicamente iteran hacia un nivel de calidad y detalle.
• Hacer explícitas las suposiciones que sustentan los requisitos, así como cualquier
problema conocido.
• La comprensión de los requisitos continúa evolucionando a medida que avanza el
diseño y el desarrollo.

12. 7.2 Gestión del cambio
• Asegurar que los cambios
propuestos pasen por un proceso
definido de revisión y aprobación,
aplicando un seguimiento
cuidadoso de los requisitos, análisis
de impacto y una gestión de la
configuración de software.
7.3 Atributos de Requisitos
• Información auxiliar.
• Identificador.
• Clasificaciones.
• Verificación del plan de prueba de
aceptación.
• Justificación de cada requisito.
• Fuente de cada requisito.
• Historial de cambios.
7.4 Seguimiento de requisitos
• El rastreo es fundamental para
realizar análisis de impacto cuando
cambian los requisitos.
• El seguimiento de requisitos para
un proyecto típico formará un
grafo acíclico dirigido (DAG)
complejo.
7.5 Medición de requisitos
• Tener algún concepto del "volumen"
de los requisitos.
• Medida del tamaño funcional (FSM).

13. 8. Herramientas de requisitos de software
El seguimiento y la gestión de cambios solo son factibles si están respaldados por una herramienta.
https://www.capterra.pe/directory/10018/requirements-management/software

14. ARTÍCULOS CIENTÍFICOS
29148-2018 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Life cycle processes --
Requirements engineering
https://ieeexplore.ieee.org/document/8559686
Specification of Requirements and Software Architecture for the Customisation of Enterprise Software: A
Multi-case Study Based on the RE4SA Model
https://ieeexplore.ieee.org/document/8933645
Requirements engineering practices in small and medium software companies: An empirical study
https://ieeexplore.ieee.org/document/6661742
Aligning Requirements and Testing: Working Together toward the Same Goal
https://ieeexplore.ieee.org/document/7819382
Vision for an Artefact-based Approach to Regulatory Requirements Engineering. In Proceedings of the 15th
ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (ESEM '21).
https://doi.org/10.1145/3475716.3484191
Requirements Elicitation in the Context of Software for Low-Functioning Autistic People: An Initial Proposal of
Specific Supporting Artifacts. In Brazilian Symposium on Software Engineering (SBES '21).
https://doi.org/10.1145/3474624.3477065
Hierarchical Cluster Labeling of Software Requirements using Contextual Word Embeddings. In Brazilian
Symposium on Software Engineering (SBES '21).
https://doi.org/10.1145/3474624.3477067