slides_gestion - clase (13)

Vista previa del material en texto

EVALUACIÓN
Diseño la 
estrategia
Aprendo
Definición MVP y 
Evaluación
PLANIFICACIÓN IMPLEMENTACIÓN
Analizar la situación
Entiendo el 
problema/ 
la 
necesidad
Entiendo a 
quien esta 
dirigido
Fijo fechas, 
objetivos y formato
Ejecución de 
Sprints
Mido los 
resultados
Armado de 
backlog + needs 
de equipo
Customer problem Customer solution
ETAPAS
Establezco la 
forma de trabajo
¿QUÉ SON
LOS REQUERIMIENTOS?
En ingeniería del software y el desarrollo de sistemas, 
un requerimiento es una necesidad documentada sobre 
el contenido, forma o funcionalidad de un producto o 
servicio.
Los requerimientos son declaraciones que identifican 
atributos, capacidades, características y/o cualidades 
que necesita cumplir un sistema (o un sistema de 
software) para que tenga valor y utilidad para el 
usuario. En otras palabras, los requerimientos muestran 
qué elementos y funciones son necesarias para un 
proyecto.
Nos darán una base para priorizar las tareas y calcular 
el costo de desarrollo de las mismas.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
INGENIERÍA
DE REQUERIMIENTOS
Cuando se da inicio a un proyecto de software siempre 
empezamos por el mismo lugar: los requerimientos.
Los requerimientos son un elemento fundamental en el 
proceso de desarrollo de Software. 
Muchos de los proyectos de software que fracasan es 
por causa de una mala definición, especificación o 
administración de requisitos. 
No siempre lo que el cliente quiere es lo que 
realmente necesita, también muchas veces lo que el 
cliente solicita no es lo que se le transmite al 
programador, la ingeniería de requerimientos se trata 
de que lo que el cliente pide es lo que realmente 
necesita y más importante aún es lo que los analistas y 
programadores desarrollan. 
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
INGENIERÍA DE REQUERIMIENTOS
“La parte más dura de hacer software es, precisamente, decidir lo que hacer. 
Ninguna otra de las partes en que se divide este trabajo es tan difícil como establecer los requisitos técnicos 
detallados, incluyendo todas las interfaces con la personas, las máquinas y los otros sistemas de software. Ninguna 
otra parte del trabajo destroza tanto el resultado final si se hace mal. Ninguna otra parte resulta tan difícil de 
rectificar a posteriori.” 
“Por tanto, la función más importante que realiza el diseñador de software para el cliente es la extracción iterativa y 
el refinamiento de los requisitos del producto. La verdad es que el cliente no sabe lo que quiere. El cliente 
normalmente no sabe que preguntas deben ser respondidas, y casi nunca ha pensado en los detalles del problema 
necesarios para la especificación. Incluso la simple respuesta ("Haz que el nuevo software trabaje como nuestro 
viejo sistema de procesado manual de la información") es de hecho demasiado simple”
by Frederick P. Brooks, Jr.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
INGENIERÍA DE REQUERIMIENTOS ARMADO DE BACKLOG + NEEDS DEL EQUIPOIMPLEMENTACIÓN
REQUERIMIENTOS
FUNCIONALES Y NO FUNCIONALES
Requerimientos funcionales: 
Un requerimiento funcional es una declaración de cómo debe 
comportarse un sistema. Define lo que el sistema debe hacer para 
satisfacer las necesidades o expectativas del usuario. Los requerimientos 
funcionales se pueden considerar como características que el usuario 
detecta.
La especificación de los requisitos funcionales de un sistema debe ser 
completa y coherente. Completa significa que todos los servicios 
solicitados por el usuario y/u otro sistema están definidos. La coherencia 
significa que los requisitos no tienen una definición contradictoria.
Ejemplo:
- El sistema de reservas de vuelos debe permitir a los usuarios 
buscar vuelos por destino, fecha y número de pasajeros.
- El sistema de ecommerce debe permitir a los clientes agregar 
productos a su carrito de compras y proceder al pago.
Requerimientos no funcionales: 
Se trata de requisitos que no se refieren directamente a las 
funciones específicas suministradas por el sistema, sino a las 
propiedades del sistema: rendimiento, seguridad, disponibilidad, 
etc.
La definición de estos requisitos es un factor esencial en el 
desarrollo de una solución total para el cliente que cumpla con 
los objetivos comerciales. Los requerimientos no funcionales se 
utilizan principalmente para impulsar los aspectos operativos de 
la arquitectura; en otras palabras, abordar las principales áreas 
operativas y técnicas del sistema para garantizar la solidez y 
robustez de la aplicación.
Ejemplo:
- El sistema de reserva de vuelos debe tener un tiempo de 
respuesta de búsqueda de vuelos inferior a 3 segundos.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
¿CÓMO IDENTIFICAR Y DOCUMENTAR 
REQUERIMIENTOS FUNCIONALES?
1- Comprender el contexto del sistema: Antes de comenzar a identificar los requerimientos funcionales, es fundamental comprender el 
contexto del sistema. Esto implica conocer los objetivos del sistema, las necesidades de los usuarios y las restricciones o limitaciones 
existentes.
2- Identificar a los actores principales: Identifica a los actores principales que interactuarán con el sistema. Estos pueden ser usuarios 
finales, administradores, sistemas externos u otros elementos del entorno del sistema.
3- Realizar entrevistas y reuniones con los stakeholders: Lleva a cabo entrevistas y reuniones con los stakeholders, como los usuarios, los 
clientes y otros expertos relevantes. Estos encuentros te permitirán obtener información directa sobre las funcionalidades que requieren y 
las expectativas que tienen. Hacerlo mediante entrevistas, workshops, cuestionarios, talleres y observación.
4- Organizar y categorizar los requerimientos: Una vez que hayas recopilado los requerimientos, organízalos y categorízalos de manera 
lógica. Puedes utilizar técnicas como la matriz de trazabilidad o la jerarquización para establecer relaciones entre los requerimientos y 
asegurarte de que no se omita ninguno.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
¿CÓMO IDENTIFICAR Y DOCUMENTAR 
REQUERIMIENTOS FUNCIONALES?
6- Especificar los requerimientos de manera clara y precisa: Documenta los requerimientos de manera clara y precisa utilizando un formato 
estándar. Puedes utilizar plantillas o tablas para registrar cada requerimiento. Asegúrate de incluir una descripción concisa de la 
funcionalidad, los criterios de aceptación, las restricciones y cualquier información relevante.
7- Validar y verificar los requerimientos: Una vez que hayas documentado los requerimientos, realiza un proceso de validación y
verificación. Esto implica revisar los requerimientos con los stakeholders para asegurarte de que se comprendan correctamente y reflejen 
sus necesidades. También verifica que los requerimientos sean coherentes y no contradictorios entre sí.
8- Mantener los requerimientos actualizados: Los requerimientos pueden evolucionar a lo largo del tiempo debido a cambios en las 
necesidades de los usuarios o nuevos requisitos. Es importante mantener los requerimientos actualizados y gestionar los cambios 
adecuadamente para evitar confusiones o malentendidos en el futuro.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
¿CÓMO IDENTIFICAR Y DOCUMENTAR 
REQUERIMIENTOS NO FUNCIONALES?
Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones presupuestarias, políticas organizacionales, la 
necesidad de interoperabilidad con otros sistemas de software o hardware, o factores externos tales como regulaciones de seguridad, 
políticas de privacidad, entre otros.
Existen diferentes tipos de requisitos y se clasifican según sus implicaciones.
- Requisitos del producto: Especifican el comportamiento del producto, como los requisitos de rendimiento sobre la velocidad de 
ejecución del sistema y la cantidad de memoria necesaria, los requisitos de fiabilidad que establecen la tasa de fallos para que el 
sistema sea aceptable, los requisitos de portabilidady los requisitos de usabilidad.
- Requisitos organizativos: Se derivan de las políticas y procedimientos existentes en la organización cliente y en la organización del 
desarrollador: estándares en los procesos a utilizar; requisitos de implementación tales como lenguajes de programación o el 
método de diseño a utilizar; y requisitos de entrega que especifican cuándo se entregará el producto y su documentación.
- Necesidades externas: Se derivan de factores externos al sistema y a su proceso de desarrollo. Incluyen los requisitos de 
interoperabilidad que definen la forma en que el sistema interactúa con los demás sistemas de la organización; los requisitos legales 
que deben seguirse para garantizar que el sistema funciona dentro de la ley; y los requisitos éticos. Estos últimos se imponen al 
sistema para asegurar que será aceptado por el usuario.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
TÉCNICAS DE ESPECIFICACION DE 
REQUERIMIENTOS
Existen varias técnicas de especificación de requerimientos que se utilizan para capturar y documentar los detalles de los requisitos de un sistema de 
manera clara y precisa
1- Casos de Uso: Los casos de uso describen cómo los actores interactúan con el sistema en diferentes escenarios o situaciones. Se centran en los 
objetivos del usuario y muestran las acciones que se realizan y las respuestas esperadas del sistema
2- Historias de Usuario: Las historias de usuario son breves descripciones de una funcionalidad desde la perspectiva del usuario. Se enfocan en los 
objetivos del usuario y suelen seguir una estructura simple: "Como [tipo de usuario], quiero [realizar una acción] para [obtener un beneficio]".
3- Tablas de Decisión: Las tablas de decisión son una técnica para especificar reglas de negocio o lógica de toma de decisiones. Consisten en una tabla 
que enumera las diferentes condiciones y acciones posibles, lo que facilita la especificación de reglas complejas de manera estructurada.
4- Diagramas de Clases: Los diagramas de clases son utilizados en el modelado orientado a objetos para describir la estructura y las relaciones entre las 
clases del sistema. Ayudan a especificar los requerimientos relacionados con los objetos, sus atributos y métodos, y cómo interactúan entre sí.
5- Prototipado: La creación de prototipos es una técnica que implica desarrollar representaciones visuales o interactivas del sistema para ayudar a los 
stakeholders a comprender mejor los requerimientos. Los prototipos pueden ser rápidos y de baja fidelidad al inicio del proceso, y más detallados y 
refinados a medida que se avanza en la especificación de los requerimientos.
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
TÉCNICAS DE ESPECIFICACION DE 
REQUERIMIENTOS - CASOS DE USO
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
TÉCNICAS DE ESPECIFICACION DE 
REQUERIMIENTOS - HISTORIAS DE USUARIO
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
TÉCNICAS DE ESPECIFICACION DE 
REQUERIMIENTOS - TABLAS DE DECISION
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
TÉCNICAS DE ESPECIFICACION DE 
REQUERIMIENTOS - DIAGRAMA DE CLASES
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
VALIDACIÓN DE REQUERIMIENTOS
Validar los requerimientos es un paso crucial. Va más allá de leer los documentos, aprobar y recolectar firmas. Aunque esto es necesario a veces, no es lo más importante. 
Validar correctamente los requerimientos es lo que permitirá que el equipo se enfoque en producir y entregar valor frecuentemente. 
Es el paso en el que encontramos lo valioso y nos deshacemos de lo innecesario.
Características de un requerimiento excelente :
- Correcto: el requerimiento provee una función o capacidad que es acorde con una necesidad de los stakeholders. La función está descripta con claridad.
- Factible: es posible implementar el requerimiento dentro de las capacidades y limitaciones del sistema y el proyecto. Por ejemplo, tenemos y conocemos el 
framework de desarrollo para hacerlo y contamos con el tiempo y el presupuesto necesarios.
- Necesario: el requerimiento ofrece a los stakeholders el valor de negocio esperado, diferencia el producto de software de otros en el mercado, o es necesario para 
adecuarse a una regulación externa. 
- No ambiguo: primeramente, la definición del requerimiento debe ser comprensible; quien lo lee debe ser capaz de comprender lo que fue definido. Después, el 
requerimiento debe ser interpretado de la misma manera por dos o más personas.
- Verificable: el requerimiento es verificable si podemos definir formas de probarlo. 
- Consistente: los requerimientos deben ser atómicos y no entrar en conflicto con otros o contradecirse. 
- Completo: la especificación tiene el detalle suficiente para permitirle al equipo entender lo que se debe desarrollar. 
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
VALIDACIÓN DE REQUERIMIENTOS ARMADO DE BACKLOG + NEEDS DEL EQUIPOIMPLEMENTACIÓN
Historia de Usuario: Como usuario, quiero que la aplicación sea fácil de usar, de 
modo que no tenga que pasar mucho tiempo aprendiendo a usarla.
¿Qué significa ser “fácil de usar”?
¿Fácil para quién?
¿Cómo se mide?
¿Cómo lo rastreas?
¿Cómo se prueba? ¿Contra qué criterios?
❌
Historia de usuario: Como usuario, quiero que se muestre un tutorial al 
iniciar sesión por primera vez, para que pueda ver para qué se utiliza cada 
opción de la pantalla de inicio.
Ya sabes qué mostrar, un tutorial.
Ya sabes lo que hay que comprobar, que explica cada opción en la pantalla 
de inicio.
Usted sabe cuando necesita ser mostrado, en el primer inicio de sesión del 
usuario (puede explicar más adelante si el tutorial puede ser omitido, 
mostrado en otros momentos, accedido desde alguna sección dentro del 
menú, etc.)
✅
Ejemplo de RNF: El sistema debe ser seguro.
¿Qué tan seguro es “seguro”?
¿En qué situaciones?
¿Existe una norma a cumplir?
¿En qué secciones?
¿Qué debe ocurrir si el sistema no puede funcionar tan rápido como se 
requiere?
❌
Ejemplo de RNF: Todas las comunicaciones externas entre los servidores 
de datos, la aplicación y el cliente del sistema deben estar cifradas 
utilizando el algoritmo RSA.
Sabes qué tipo de comunicaciones necesitan ser encriptadas.
Usted sabe qué algoritmo usar y validar.
✅
ARMADO
DE DOCUMENTACIÓN
En la fase de documentación es donde se registran las necesidades 
del negocio (requisitos del cliente y necesidades del usuario) y se 
definen los requerimientos que debe cumplir el producto, sistema 
o software a desarrollar. 
¿Por qué conviene usar una especificación de requisitos de 
software?
Si los desarrolladores no tienen instrucciones claras con respecto a 
cuándo crear un producto nuevo, probablemente termines 
dedicando tiempo para producir un software que coincida con lo 
que tienes en mente.
Dado que la especificación de requisitos de software es un 
documento dinámico, también puede funcionar como centro para 
las comunicaciones entre las diferentes partes interesadas de un 
proceso de desarrollo de productos. 
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
ARMADO DE DOCUMENTACIÓN
1. Introducción
La introducción en esta especificación es exactamente lo que esperas, un panorama global del proyecto en general. Cuando redactes la 
introducción, describe el propósito de la creación del producto, el público que pretendes cautivar y cómo crees que ese público usará el 
software
2. Requisitos funcionales y del sistema
Una vez que hayas terminado la introducción, será hora de volverse más específico. En los requisitos funcionales se desglosan las 
características y funciones que permiten que el sistema se comporte como ha sido previsto.
3. Requisitos de la interfaz externa
Los requisitos de la interfaz externa son tipos de requisitos funcionales con los que se garantiza que el sistema se comunicará correctamente 
con los componentes externos como las interfaces de usuarios, las interfaces de hardware, las interfaces de software, las interfaces para 
comunicaciones
4. Requisitosno funcionales (NRF)
La sección final de los detalles de la especificación de requisitos de software incluye los requisitos no funcionales. Mientras que con los 
requisitos funcionales se le indica al sistema cómo debe comportarse, con los no funcionales (NFR) se determina de qué manera el sistema 
implementará estas funciones
ARMADO DE BACKLOG + NEEDS DEL EQUIPO
IMPLEMENTACIÓN
	Diapositiva 2
	Diapositiva 3
	Diapositiva 4
	Diapositiva 5
	Diapositiva 6
	Diapositiva 7
	Diapositiva 8
	Diapositiva 9
	Diapositiva 10
	Diapositiva 11
	Diapositiva 12
	Diapositiva 13
	Diapositiva 14
	Diapositiva 15
	Diapositiva 16
	Diapositiva 17
	Diapositiva 18
	Diapositiva 19