requisitos
DESCRIPTION
Unidad 1: Requerimientos de SoftwareTRANSCRIPT
![Page 1: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/1.jpg)
INGENIERÍA DEL
SOFTWAREUnidad 1: Requerimientos del Software.
Trimestre I
Ing. Noretsys Rodríguez
![Page 2: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/2.jpg)
¿QUÉ SON LOS REQUISITOS O REQUERIMIENTOS?
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
Una representación documentada de una condición o necesidad.
![Page 3: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/3.jpg)
QUE SE CONSIDERA COMO UN REQUISITO
Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe
incluir un verificador de ortografía y un comando de corrección’
Una propiedad muy general del sistemaEj.: ‘el sistema debe asegurar que la
información personal nunca se haga disponible sin autorización’
Una restricción específica del sistema Ej.: ‘el sensor debe ser activado 10 veces
por segundo’ Una restricción para el desarrollo del sistema
Ej.: ‘el sistema debe ser desarrollado usando Ada’
Cómo llevar a cabo algún cálculo Ej.: ‘la nota final debe ser calculada
sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada’
![Page 4: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/4.jpg)
QUE SE CONSIDERA COMO UN REQUISITO
Propiedades del dominio: “Cosas” en el dominio de aplicación que son verdaderas independientemente que se construya o no el sistema de software
Requisitos: “Cosas” en el dominio de aplicación que se desean sean verdaderas mediante la construcción del sistema de software
Especificación: descripción de comportamiento (y datos) que el programa tiene que tener para cumplir los requisitos• Sólo puede ser descrito en términos de los
fenómenos compartidos por la máquina y el dominio de aplicación
![Page 5: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/5.jpg)
ACTORES RELACIONADOS CON EL SISTEMA
Llamados Stakeholder. Entidad que será afectada por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema.
Usuarios finales del sistema Gerentes involucrados en los procesos organizacionales influenciados o que influencian al sistema Ingenieros responsables por el desarrollo y mantenimiento del sistema, Clientes de la organización Cuerpos externos tales como autoridades reguladoras o de certificación.
![Page 6: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/6.jpg)
LEVANTAMIENTO DE REQUISITOS
Definición de requisitos Expresa en lenguaje natural o con
diagramas los servicios y restricciones operacionales del sistema. Se genera con la información proporcionada por el cliente.
Especificación de Requisitos Documento estructurado que describe
con detalle los servicios del sistema. A veces llamado especificación funcional. Escrito como contrato con el cliente.
Especificación de software Escrito para los diseñadores. Sirve de
base para el diseño y desarrollo del sistema.
![Page 7: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/7.jpg)
DOCUMENTO DE REQUISITOS
El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software. Nombres:
Especificación funcional, Definición de requisitos, Especificación de los requisitos de software
![Page 8: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/8.jpg)
DOCUMENTO DE REQUISITOS
El documento describe: Los servicios y funciones que el sistema
debería proveer. Las restricciones bajo las cuales el sistema
debe operar Las propiedades generales del sistema, es
decir, restricciones sobre las propiedades emergentes del sistema
Definiciones de otros sistemas con los cuales el sistema se debe integrar.
Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.
Restricciones sobre el proceso usado para desarrollar el sistema
glosario
![Page 9: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/9.jpg)
USUARIOS DEL DOCUMENTO DE REQUISITOS
Clientes del sistemaEspecifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.
Gerentes Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema
y planificar el proceso de desarrollo.
Ingenieros de sistemas Usan los requisitos para entender qué sistema tiene que ser desarrollado.
Ingenieros de prueba de sistemas
Usan los requisitos para desarrollar pruebas de validación para el sistema.
Ing. de mantenimiento de sistemas
Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.
![Page 10: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/10.jpg)
MODELO IEEE/ANSI 830-1998 Introducción
• 1.1.Propósito del documento de requisitos• 1.2.Alcance del proyecto• 1.3.Definiciones, acrónimos y abreviaturas• 1.4.Resumen del resto del documento
Descripción General• 2.1.Perspectiva del producto• 2.2.Funciones del producto• 2.3.Características de los usuarios• 2.4.Limitaciones generales• 2.5.Suposiciones y dependencias
Requisitos Específicos• 3.1.Requisitos funcionales, no funcionales
Apéndices Índice
![Page 11: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/11.jpg)
INGENIERÍA DE REQUISITOS (RE)
RE trata la identificación del propósito de un sistema de software y el contexto en el cual será usado.
RE actúa como un puente entre las necesidades del mundo real de los clientes y otros actores afectados
Trata sobre los objetivos del mundo real para los sistemas de software, servicios provistos y restricciones.
Trata sobre el comportamiento del sistema y su evolución a través del tiempo.
![Page 12: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/12.jpg)
IMPORTANCIA DE LA RE EN EL DESARROLLO DE SOFTWARE Cuanto más tarde en el ciclo de vida se detecta un error,
más cuesta repararlo. Muchos errores permanecen latentes y no son
detectados hasta bastante después de la etapa en que se cometieron. Muchos podrían detectarse tempranamente
Se cometen muchos errores de requisitos
Impacto de los errores en la etapa de requisitos El software resultante puede no satisfacer a los usuarios. Las interpretaciones múltiples de los requisitos pueden
causar desacuerdos entre clientes y desarrolladores. Es imposible que a través del testeo el software
satisfaga sus requisitos. Puede gastarse tiempo y dinero construyendo el sistema
erróneo.
![Page 13: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/13.jpg)
ACTIVIDADES DEL PROCESO DE LA RE
Elicitación
Modelado Análisis Gestión
I dentificación de Fuentes I nform.
Representación Verificación I dentificación de cambios
Recolección de hechos
Organización Validación Análisis de cambios
Comunicación Almacenamiento (registración)
Negociación Realización de cambios
![Page 14: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/14.jpg)
TÉCNICA JAD (JOINT APLICATION DESIGNER)
Permite a los usuarios, diseñar sistemas en forma conjunta, en sesiones grupales.
Gibson y Jackson afirman que los resultados aumentan de un 20% a un 60%.
Promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos de usuarios.
![Page 15: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/15.jpg)
ROLES DEL JAD
Líder de la sesión. Representante de los usuarios. Especialista. Analista. Representante de SS. Patrocinador (sponsor) ejecutivo o dueño del
sistema.
![Page 16: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/16.jpg)
LÍDER DE SESIÓN
Facilitador de JAD. Dirige el proceso. Facilita el debate y la preparación de
documentos. Trata con el sponsor de JAD para acordar
quién debe asistir las reuniones. Acordar la agenda con los participantes.
![Page 17: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/17.jpg)
PLAN JAD
Dura entre uno y cinco días. El líder de la sesión guía a los participantes a
lo largo de ocho tareas predefinidas. Ellas son: Orientación. Definición de requerimientos de alto nivel . Límites y alcances del sistema . Identificar y estimar tiempos de los Diseños JAD. Identificar los participantes de los Diseños JAD. Programar días y horarios para los Diseños JAD. Acordar los puntos y consideraciones de la
documentación a generar del Plan JAD. Concluir la sesión.
![Page 18: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/18.jpg)
DISEÑO JAD. SESIÓN DE DISEÑO
Dura aproximadamente entre tres y diez días. El líder de la sesión guía a los participantes a
lo largo de las siguientes tareas: Orientación. Revisión y refinación de los requerimientos y
alcance del Plan JAD. Desarrollar diagrama de flujo del trabajo. Desarrollar descripción del flujo de trabajo. Identificar funciones y grupos de datos del
sistema. Especificar los requerimientos de procesamiento. Acordar los puntos y consideraciones de la
documentación a generar del Diseño JAD. Concluir la fase de sesión.
![Page 19: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/19.jpg)
LIBROS DE TRABAJO
Formas predefinidas para los grupos, para que sean completadas durante la sesión.
Formularios de participantes. Formularios de resultados. Formularios de estimaciones. Formularios de salidas por pantalla. Formularios de reportes. Formularios de descripción de interfaces y de
descripción de funciones.
![Page 20: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/20.jpg)
JAD Y EL PROCESO DE REQUERIMIENTOS
La articulación del concepto de producto, requerimientos, medición de resultados.
Análisis de problemas. Estudios de factibilidad y análisis de opciones
de costo-beneficio. Análisis y modelado. La documentación de requerimientos.
![Page 21: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/21.jpg)
JAD Y LA COMUNICACIÓN HUMANA
La identificación de varios puntos de vista. La conciliación de los puntos de vista. La revisión por parte del usuario de los
modelos desarrollados. El análisis de los propios problemas del
usuario y la identificación de la necesidad de cambio.
![Page 22: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/22.jpg)
ANÁLISIS DE PUNTOS DE FUNCIÓN (FPA)
Mide el tamaño del software desde el punto de vista del usuario. Medir la funcionalidad del producto.
Es independiente de la tecnología usada para el desarrollo e implementación.
Se aplica a partir de los documentos de requerimientos y a lo largo del ciclo de vida del software.
Los enfoques para estimar Puntos Función (Function Points - FP) facilitan la estimación temprana de un proyecto de software (costo, esfuerzo, cronograma) cuando los requerimientos no están completamente definidos.
![Page 23: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/23.jpg)
MEDICIÓN
Es una práctica de administración Probada en el tiempo.
No se puede administrar lo que no se puede medir.
Un 40% de proyectos fracasan por falta de administración,
Herramienta para determinar el tamaño del requerimiento, extrapolar la productividad y la calidad.
Se mide para entender y mejorar procesos.
![Page 24: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/24.jpg)
CLASES DE MEDICIÓN
Medición: Cuantificación directa. Estatura de una persona.
Cálculo: Cuantificación indirecta. A partir de la combinación de medidas se
obtiene el valor del atributo de interés. Ejemplo: medir la velocidad a partir de la
distancia y el tiempo.
![Page 25: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/25.jpg)
MEDICIÓN DEL SOFTWARE
Se miden las características para saber si los requerimientos son consistentes y completos.
Los administradores de proyectos miden procesos y productos para determinar tiempos de entrega y costos.
Incluyen las siguientes actividades: Estimación de costo y esfuerzo. Medidas de productividad. Recolección de datos. Medidas de calidad y confiabilidad. Performance. Complejidad. Métodos y herramientas.
![Page 26: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/26.jpg)
BENEFICIOS DE LA MEDICIÓN
Entender que está ocurriendo en el desarrollo y mantenimiento para mejorar las relaciones entre actividades.
Control de lo que ocurre en el proyecto, para predecir lo que ocurrirá y los cambios a realizar.
Mejorar los procesos y productos, aumentando las revisiones del diseño se incrementa la calidad.
![Page 27: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/27.jpg)
MEDICIÓN DEL TAMAÑO DEL SISTEMA
Tamaño del procesamiento de información• Entradas• Salidas.• Otros
Tamaño del sistema desde los requerimientos del
usuario
Requerimientos técnicos.• Performance.• Facilidad de
uso.• otros
![Page 28: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/28.jpg)
BENEFICIOS DEL FPA
Mejorará la definición de los requerimientos. Comunicar requerimientos funcionales. Estimar esfuerzo, agenda y costos basado
en requerimientos. Evaluar la factibilidad de un proyecto. Administrar los cambios. Mejorará el mantenimiento y soporte. Medir la productividad. Verificar la completitud.
![Page 29: Requisitos](https://reader036.vdocuments.mx/reader036/viewer/2022070321/558bf6bfd8b42a44578b4747/html5/thumbnails/29.jpg)
RESUMEN DE OBJETIVOS
¿Qué son los requerimientos o Requisitos? Necesidades, objetivos y actores
relacionados con los requerimientos Importancia de la Ingeniería de Requisitos en
la práctica Levantamiento y Recolección de
Requerimientos. Técnicas más usadas: Método JAD y FPA