Introducción a requerimientos y modelos de negocios Requerimientos de software Introducción a requerimientos y modelos de negocios Requerimientos de software Introducción a requerimientos y modelos de negocios / Requerimientos de software 2 Introducción a requerimientos y modelos de negocios / Requerimientos de software 3 ESCUELA DE CONSTRUCCIÓN E INGENIERÍA Director de Escuela / Marcelo Lucero Yáñez ELABORACIÓN Experto disciplinar / Pablo Celedón Rodríguez Diseñador instruccional / Camila Palacios Dussuel VALIDACIÓN PEDAGÓGICA Jefa de diseño instruccional y multimedia / Alejandra San Juan Reyes Experto disciplinar / Rodrigo Pedrero DISEÑO DOCUMENTO Equipo de Diseño Instruccional AIEP Introducción a requerimientos y modelos de negocios / Requerimientos de software 4 Contenido Aprendizaje esperado de la semana .............................................................................. 6 Ideas clave......................................................................................................................... 6 1. Instrumentos de obtención de los requerimientos funcionales y no funcionales .... 7 1.1 Obtención de requerimientos ..................................................................................................... 7 1.2 ¿Cómo validar los requisitos? ...................................................................................................... 7 1.3 Ejemplificación ............................................................................................................................. 9 2. Técnicas de elaboración de instrumentos efectivos para la toma de requerimientos ........................................................................................................................................... 10 2.1 Técnicas de análisis de documentación ..................................................................................... 10 2.2 Técnicas de observación ............................................................................................................ 10 2.3 Entrevista ................................................................................................................................... 11 2.4 Cuestionario ............................................................................................................................... 12 2.4 Tormenta de ideas (brainstorm) ................................................................................................ 12 3. Validación de requerimientos .................................................................................... 13 4. Tipos de problemática según el tipo de organización ............................................ 14 5. Técnicas de obtención de requerimientos funcionales y no funcionales .............. 15 5.1 Actividades de ingeniería de requerimientos ............................................................................ 15 5.2 Técnicas de obtención de requerimientos ................................................................................ 16 6. Procesos incrementales de mejora............................................................................ 17 Conclusiones .................................................................................................................... 19 Bibliografía........................................................................................................................ 19 Enlaces y material multimedia ....................................................................................... 19 Introducción a requerimientos y modelos de negocios / Requerimientos de software 5 Aprendizaje esperado de la semana Aplican técnicas de identificación y validación de requerimientos en el ámbito de la elaboración del software Ideas clave Estimados y estimadas estudiantes, bienvenidos al contenido de nuestra segunda semana. En esta oportunidad, revisaremos los instrumentos para la obtención de requerimientos, ya sea para requerimientos funcionales o no funcionales. Además, estudiaremos las técnicas para construir instrumentos efectivos para la toma de requerimientos y, como consecuencia, los resultados de estos. Instrumentos de obtención de requerimientos Obtención de requerimientos Validación de requerimientos Problemáticas según tipo de organización Técnicas de análisis de documentos Técnicas de observación Introducción a requerimientos y modelos de negocios / Requerimientos de software 6 1. Instrumentos de obtención de los requerimientos funcionales y no funcionales 1.1 Obtención de requerimientos Para obtener y tomar los requerimientos funcionales, se debe aplicar una serie de interrogantes que permitan aclarar qué es realmente lo que se requiere, iniciando por lo básico. Para esto, escuchamos a nuestros clientes, realizando las siguientes preguntas ejemplos: • ¿Cuál es el proceso básico de la empresa? • ¿Qué datos utiliza o produce este proceso? • ¿Cuáles son los límites impuestos por el tiempo y la carga? • ¿Qué controles de desempeño utiliza? • ¿Cuál es la finalidad de la actividad dentro de la empresa? • ¿Qué pasos se siguen para realizarla? • ¿Dónde se realizan estos pasos? • ¿Quiénes los realizan? • ¿Cuánto tiempo tardan en efectuarlos? • ¿Con cuánta frecuencia lo hacen? • ¿Quiénes emplean la información resultante? Durante proceso de aclaración por medio de cualquier método, ya sea una entrevista, cuestionario, lluvia de ideas u otro, se deben identificar: • • • • • Procesos Flujos de datos entre procesos Datos de cada flujo de datos Bases de datos Datos de las bases de datos 1.2 ¿Cómo validar los requisitos? El proceso de validación de requisitos comprende actividades que generalmente se realizan una vez obtenida una primera versión de la documentación de requisitos. Una vez que se define el requisito, de debe validar con el usuario los requerimientos de acuerdo a sus necesidades. Las técnicas de validación son: • Revisión: está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello, solamente se puede validar la correcta interpretación de la información transmitida. Más difícil es verificar consistencia de la documentación o información faltante. • Auditorías: la revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir, sólo una muestra es revisada. Introducción a requerimientos y modelos de negocios / Requerimientos de software 7 • Matrices de trazabilidad: esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos de este. Es necesario ir viendo qué objetivos cubre cada requisito. De esta forma, se podrá detectar inconsistencias u objetivos no cubiertos. • Prototipos: algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario. Esta técnica tiene el problema de que el usuario debe entender que lo que está viendo es un prototipo y no el sistema final. Introducción a requerimientos y modelos de negocios / Requerimientos de software 8 1.3 Ejemplificación Revisa aquí las ventajas y desventajas de las técnicas en la ingeniería de requerimientos: Técnica Ventajas Entrevistas y Cuestionarios • • • • Lluvia de Ideas • • • Prototipos • Análisis Jerárquico • • • Casos de Uso • • • Mediante ellas, se obtiene una gran cantidad de información correcta a través del usuario. Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten combinarse con otras técnicas. Desventajas • • La información obtenida al principio puede ser redundante o incompleta. Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados. Los diferentes puntos de vista y las • confusiones en cuanto a terminología son aclaradas por expertos. Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto. Es necesaria una buena compenetración del grupo participante. Ayudan a validar y desarrollar nuevos • requerimientos. Permite comprender aquellos requerimientos que no están muy claros • y que son de alta volatilidad. El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado. A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo Permite determinar el grado de importancia de cada requerimiento. Ayuda a identificar conflictos en los requerimientos. Muestra el orden en que deben ser implementados los requerimientos. • Debe construirse un estándar claro de evaluación, que incluya la participación del cliente. Representan los requerimientos desde el punto de vista del usuario. Permiten representar más de un rol para cada afectado. Identifica requerimientos estancados dentro de un conjunto de requerimientos. • En sistemas grandes, toma mucho tiempo definir todos los casos de uso. El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial. • F IGURA: VENTAJAS Y DESVENTAJAS DE LAS TÉCNICAS DE VALIDACIÓN DE REQUERIMIENTOS Introducción a requerimientos y modelos de negocios / Requerimientos de software 9 2. Técnicas de elaboración de instrumentos efectivos para la toma de requerimientos Esta etapa es fundamental para los proyectos de ingeniería de software. Consiste en identificar y documentar los requerimientos de un proyecto. Esto nos permite prevenir futuros errores que pueden significar el fracaso de dicho proyecto. La identificación y documentación de todos los requerimientos de un sistema, a partir de los usuarios, clientes o los interesados (stakeholders), se conoce también como recopilación de requerimientos. Las técnicas que utilizaremos serán: • Análisis de documentación • Observación • Entrevistas • Cuestionarios • Mesas de trabajo • Tormentas de ideas (BRAINSTORM) 2.1 Técnicas de análisis de documentación Esta consiste en obtener la información sobre los requerimientos funcionales y requerimientos no funcionales de software a partir de documentos que ya están elaborados. Es útil cuando los expertos en la materia no están disponibles para ser entrevistados o ya no forman parte de la organización. Utiliza la documentación que sea relevante al requerimiento que se está levantando. Ejemplos de documentación: Planes de negocio, actas de constitución de proyecto, reglas de negocio, contratos, definiciones de alcance, memorándums, correos electrónicos, documentos de entrenamiento, entre otros. 2.2 Técnicas de observación Consiste en estudiar el entorno de trabajo de los usuarios, clientes e interesados de proyecto (stakeholders). Es una técnica útil cuando se está documentando la situación actual de procesos de negocio. Puede ser de dos tipos, pasiva o activa. En observación pasiva, el observador no hace preguntas, limitándose solo a tomar notas y a no interferir en el desempeño normal de las operaciones. En observación activa, el observador puede conversar con el usuario. Introducción a requerimientos y modelos de negocios / Requerimientos de software 10 2.3 Entrevista Esta técnica se usa para entender el problema de negocio, su ambiente de operación, evitar omisión de requisitos, mejorar las relaciones con el cliente. Para preparar la entrevista se debe seguir los siguientes pasos: - Seleccionar participantes, y aprender. - Preparar la entrevista. - Usar patrón de estructura. - Apertura, desarrollo y conclusión. Enviar un memo con los resultados y seguimiento. Los involucrados en la solicitud de requerimiento, ya sen usuarios, interesados o disparadores del proyecto, deben responder a las siguientes interrogantes: ¿qué trabajo realizan?, ¿para quién?, ¿qué interfiere con su trabajo?, ¿qué cosas hacen su trabajo más fácil o difícil? Se deben listar las entradas y salidas: ¿cuál es el problema?, ¿cómo se resuelve ahora?, ¿cómo le gustaría que se resolviera? Definir procesos, es decir, propósito, objetivos y metas, respondiendo a: ¿quién necesita la aplicación?, ¿cuántos usuarios la van a usar y de qué tipo? Se establece la ubicación de los usuarios, lugares involucrados, contexto de los usuarios, entorno de los usuarios, computadoras, plataformas, aplicaciones relevantes existentes, experiencia de los usuarios con este tipo de aplicación, expectativas de tiempo de entrenamiento. Evaluar confiabilidad, desempeño y soporte necesario: ¿cuáles son las expectativas respecto a la confiabilidad y respecto a la performance?, ¿qué tipo de mantenimiento se espera?, ¿qué nivel de control y seguridad?, ¿qué requisitos de instalación existen?, ¿cómo se distribuye el software?, ¿debe ser empaquetado? Existen otras acciones a respaldar como: ¿existen requisitos legales, regulatorios u otros estándares que deban ser tenidos en cuenta? Factores críticos de éxito: ¿qué se considera una buena solución? Se debe tener en consideración que, si el entrevistado comienza a hablar sobre los problemas existentes, no cortarlo con una próxima pregunta luego de la entrevista y mientras los datos aún están en mente, resumir los principales requerimientos. Introducción a requerimientos y modelos de negocios / Requerimientos de software 11 2.4 Cuestionario El uso de cuestionarios permite a los analistas reunir información proveniente de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos más confiables que otras técnicas. Por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas más honestas. El inconveniente es que la respuesta puede ser limitadas, ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario. Es recomendable conseguir apoyo de la alta dirección para solicitar a las personas de la organización que contesten el cuestionario. Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe asegurar que el conocimiento y experiencia de éstos califiquen para dar respuestas a las preguntas. 2.4 Tormenta de ideas (brainstorm) El objetivo principal de esta técnica es lograr un consenso sobre los requisitos, involucrando a todos los participantes del proceso, y abordar más ideas. Esta técnica es para dejar volar la imaginación y generar ideas tantas como sea posible y combinar estas para llegar a una gran idea o más. Los pasos por seguir son los siguientes: - Los principales stakeholders se juntan en un cuarto y se explican las reglas. - Se establece el objetivo: ¿Qué características esperan en el producto?, ¿Qué servicios esperan que provea? Y estos objetivos permiten decidir cuándo terminar. - Se solicita que cada participante escriba sus ideas, luego las ideas son leídas para que otros piensen en ideas relacionadas y de esa forma las ideas mutan y se combinan. - El moderador lee cada idea y pregunta si es válida y si hay cualquier desacuerdo, la idea no se aprueba - Se agrupa ideas en diferentes grupos que se determinan y se escribe una breve descripción lo que la idea significa. En resumen, esta técnica ayuda a tener entendimiento común del requerimiento. Introducción a requerimientos y modelos de negocios / Requerimientos de software 12 3. Validación de requerimientos Para plasmar la información sobre los requisitos, existen diferentes métodos. Es buena práctica utilizar, al menos, dos documentos a distinto nivel de detalle: DRU = Documento de Requisitos de Usuario (en inglés, URD) ERS = Especificación de Requisitos Software (en inglés, SRS) Son declaraciones oficiales de qué deben implementar los desarrolladores del sistema. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos hasta los ingenieros responsables del desarrollo del software. La diversidad de usuarios significa que el documento tiene que presentar un equilibrio exacto de información, por medio de comunicación entre los clientes y desarrolladores. La plantilla para elaborar el documento de requerimientos de software se divide en las siguientes secciones: Propósito: Nombre o título del software que se está especificado en el documento, incluyendo su número de versión. También se describen cuales componentes o partes del alcance del producto están incluidas en el documento, estableciendo si cubre la totalidad del software, sólo una parte del sistema, subsistema o subgrupo de procesos. Alcance del producto / software: Descripción corta del alcance del software que se está especificando, incluyendo propósito u objetivo general, beneficios que brinda al área de negocio y organización, relación de los objetivos del software con los objetivos corporativos y estrategias de negocio. Se puede hacer referencia a otros documentos. Referencias: Aquí, se puede incluir otros documentos impresos, documentos o direcciones electrónicos que complementen la documentación de requerimientos de software. Funcionalidades del producto: Lista de las funcionalidades del software que se están especificando en el documento de requerimientos. Cada funcionalidad puede estar compuesta por uno o varios requerimientos funcionales de software. Solo se incluye una lista numerada de las principales funcionalidades. Clases y características de usuarios: Se clasifica a los usuarios que utilizarán el producto. La clasificación puede ser en función a la frecuencia de uso, grupo de funcionalidades utilizadas, privilegios de seguridad, nivel de experiencia y otros parámetros. Introducción a requerimientos y modelos de negocios / Requerimientos de software 13 Entorno operativo: Se describe el entorno operativo en el que se desenvolverá el sistema, software, módulo o grupo de funcionalidades, mencionando aspectos como la plataforma de hardware, versiones de sistema operativo y otros sistemas o componentes con los que debe coexistir. Requerimientos funcionales: En esta sección de la plantilla, ilustramos como organizar los requerimientos funcionales de software por funcionalidad de producto o sistema. Aquí se listan las funcionalidades y para cada una a su vez se listan los requerimientos funcionales. Los requerimientos funcionales también se pueden documentar en una matriz de trazabilidad de requerimientos. Reglas de negocio: Listado de reglas y principios que aplican a todo el conjunto de requerimientos de software contenidos en el documento. Un ejemplo es cuales individuos o roles pueden desempeñar cierta función bajo ciertas circunstancias. Requerimientos de interfaces externas: Describe las características y atributos de las interfaces con el usuario (GUI), interfaces con el hardware, interfaces con otros sistemas y las interfaces de comunicaciones. Requerimientos no funcionales: Los requerimientos no funcionales son los que especifican criterios para evaluar la operación de un servicio de tecnología de información, en contraste con los requerimientos funcionales que especifican los comportamientos específicos. 4. Tipos de problemática según el tipo de organización Son variados los problemas que se pueden presentar dependiendo de la organización. La complejidad de los procesos al momento de realizar el levantamiento del requerimiento dependerá del área que analice y el proceso que desarrollo dentro de la organización. Es por esto por lo que se debe tener algunas consideraciones para evitar todo tipo de problemáticas: - Entender el problema del negocio Entender el ambiente de la operación Trabajar con el personal especializado, conocedor de los procesos Relación fluida con el cliente, comunicación constante Introducción a requerimientos y modelos de negocios / Requerimientos de software 14 5. Técnicas de obtención de requerimientos funcionales y no funcionales Ahora, veremos cuál es la mejor de forma de poder llegar a definir y realizar el levantamiento de requerimientos respecto a las necesidades del usuario por medio de actividades y técnicas de obtención y posterior documentación y aceptación de requerimientos. 5.1 Actividades de ingeniería de requerimientos Cuando un usuario y/o cliente realiza una solicitud de desarrollo de software, es difícil lograr el éxito, debido a que se debe lograr satisfacción del cliente, finalizando el proyecto en tiempo, forma (alcance definido) y dentro del presupuesto inicial. Por este escenario, la ingeniería de requerimientos es parte importante del trabajo para el responsable del proyecto, debido a que lo ayuda a comprender el requerimiento, definiendo las actividades involucradas, siendo su meta entregar una especificación del requerimiento de software correcta y completa. Para esto, se debe analizar la necesidad, confirmar la viabilidad, negociar una solicitud razonable, especificar la solución de forma clara y sin supuestos, validar la especificación y gestionar los requerimientos y estos se transformen en un sistema operacional disminuyendo riesgos y sobrecostos. Las actividades que debe ejecutar el responsable del proyecto son: Recolección: se analiza y se descubre en conjunto al cliente el problema que el sistema debe resolver, los servicios que debe prestar y las restricciones que debe tener el sistema. Análisis: en esta fase se estudia sobre los requerimientos del cliente los problemas existentes y como solucionarlos. Generalmente se ejecuta este paso después de realizar el bosquejo del documento de requerimientos. Se debe discutir temas con el equipo, se ven alternativas de solución, se investiga y se reúnen con cliente para discutir requerimientos. Especificación: se documentar requerimientos del cliente, detallando cada proceso del requerimiento, la necesidad, mejora a ejecutar y todos los detalles. Esta fase se realiza en conjunto con el análisis aplicando notaciones de modelado como el UML (lenguaje modelado unificado) para levantamiento de caos de uso para la obtención de requerimientos. Validación: en esta etapa se ratifica el requerimiento, es decir que este sea consistente, aceptable y completo a lo que se debe implementar por medio de una descripción. Por medio de este proceso, se obtiene un documento de especificaciones estructurado de los requerimientos, siendo el documento final y de carácter formal. Introducción a requerimientos y modelos de negocios / Requerimientos de software 15 D IAGRAMA DE INGENIERÍA DE REQUERIMIENTOS. (FUENTE : I NGRID Y ÁÑEZ , 2018) 5.2 Técnicas de obtención de requerimientos La obtención de requerimientos involucra a diferentes personas que participan en el proceso, lo que conlleva a dificultades para definir de forma correcta el requerimiento, por lo que, para poder comunicar de forma clara los requerimientos, se requieren técnicas, como se describe a continuación: Entrevistas: por medio de esta técnica, se logra obtener información cualitativa, es decir, opiniones y descripciones. Es necesario que el entrevistador, por medio de una conversación estructurada, realice preguntas abiertas, de forma de plantear una conversación en un tiempo no mayor a dos horas. El entrevistador previamente deberá prepararse por medio de investigación y documentación la situación de la organización y de los aspectos relevantes. Desarrollo de prototipos: consiste en realizar un demo de la aplicación pedida. Esta técnica generalmente se usa cuando la aplicación no está definida o por dudas del usuario en no saber que se quiere. La construcción de prototipos incrementa los costos en las etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores gracias al mejor entendimiento de los requerimientos por parte de los desarrolladores. En algunos casos también se utiliza como un medio para formalizar la aceptación previa del cliente de los requisitos del proyecto. Observación: este método consiste en observar la forma en que llevan a cabo los procesos y verificar si se siguen todos los pasos especificados. Estudio de comunicación: por medio de documentación, procedimientos o reportes. Se analizan principalmente para obtener un dominio de la operación y el vocabulario que se utiliza, ya que por medio de esto no se puede saber cómo realmente se desarrollan las actividades y dónde se encuentra el poder de tomar decisiones. Introducción a requerimientos y modelos de negocios / Requerimientos de software 16 Cuestionario: por medio de cuestionarios, se reúne información de forma estandarizada, asegurándose el encuestador de que los datos proporcionados sean los requeridos. El encuestado debe asegurar que las personas seleccionadas para contestar el cuestionario sean los indicados y parte del proceso. Tormenta de Ideas (Brainstorming): reunión de cuatro a diez personas donde se realiza lista de ideas sin juzgarlas. Después, debemos tomar todas estas ideas y analizar en detalle cada propuesta. Escenarios: estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos específicos. Cada evento de interacción distinto, o la selección de un servicio del sistema, sedo documentos como un escenario de eventos distinto. Los escenarios de eventos incluyen una descripción del flujo de datos y las acciones del sistema, y documenta las excepciones que pueda surgir. Las convenciones para los diagramas utilizados en los escenarios de eventos. Etnografía: es una técnica de observación que se utiliza para entender los requerimientos sociales y organizacionales. 6. Procesos incrementales de mejora Tradicionalmente, la mejora de procesos de software se realiza en un solo ciclo. Esto es más sencillo para los que la administran, pero se complica para el equipo de mejora. No obstante, la mejora incremental permite al equipo de mejora y a la gerencia identificar resultados a corto plazo, con el inconveniente de que genera mayor complejidad en la administración. Sin embargo, los beneficios bien valen la pena. Según la página especializada en desarrollo de SW, SG Software Guru, el proceso incremental de mejora tiene como objetivo asegurar la implantación de la capacidad de los modelos de software a través de ciclos de vida incrementales orientados a organizaciones y objetivos de negocio como se presenta en la figura 1. Esta figura ilustra la arquitectura del proceso, el cuál provee un acercamiento disciplinado para la asignación de tareas y responsabilidades en la organización. Como podrán apreciar, estamos tomando la misma idea del ciclo de vida del Proceso Unificado y aplicándola a la mejora de procesos. La gráfica muestra el esfuerzo variado a través del tiempo como, por ejemplo, en iteraciones tempranas. El esfuerzo se encuentra concentrado en el desarrollo de la iniciativa y en las iteraciones tardías en la entrega. Esta contiene dos dimensiones: • El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso claramente. La primera dimensión ilustra el aspecto dinámico del desempeño del proceso el cual está expresado en términos de fases, el ciclo de vida incremental y los entregables. • El eje vertical representa a las disciplinas que de manera lógica agrupa las actividades por naturaleza. Esta segunda dimensión representa el aspecto estático Introducción a requerimientos y modelos de negocios / Requerimientos de software 17 de la descripción del proceso en términos de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles. Es recomendable que el documento de almacenamiento y distribución sea electrónico y contenga procesador de textos, base de datos y una herramienta de gestión de requisitos. Introducción a requerimientos y modelos de negocios / Requerimientos de software 18 Conclusiones Durante esta semana, pudimos revisar la forma de obtener y validar los requerimientos para la construcción de un software. Este es un proceso ordenado y organizado, de forma de lograr entender de forma óptima lo que se necesita de nuestro proyecto. Para esto, se utilizan herramientas que permitan obtener la información de los requerimientos de parte de los stakeholders. También revisamos el porceso incremental de mejora. Bibliografía • • • • • Young, Ralph R, (Abril 2002). Recommended Requirements Gathering Practices. STSC Gottesdiener, Ellen. (Marzo 2008). Good Practices for Developing User Requirements. STSC Zielczynski, Peter. (2008). Requirements Management Using IBM® Rational® RequisitePro®”, IBM Press. PMBOK® Guide Bittner, K. (2000) Why Use Cases Are Not Functions. USA. SG Software Guru https://sg.com.mx/ Enlaces y material multimedia MÓDULO: Introducción a requerimientos y modelos de negocios Recurso Unidad: Requerimientos de software Descripción En el siguiente video, podrás interiorizarte con los métodos de encuesta y cuestionario: Video https://www.youtube.com/watch?v=W8loPmJu1Vs Para identificar las técnicas de obtención de requerimientos, te invitamos a revisar la siguiente presentación: Presentación https://prezi.com/yzdaezyhmmpf/tecnicas-de-elicitacion-de-requisitos/ Introducción a requerimientos y modelos de negocios / Requerimientos de software 19
