Source: https://www.scribd.com/doc/98734466/IREB-Cpre-Syllabus-FL-Es-v21
Timestamp: 2016-07-25 22:56:38+00:00

Document:
UploadSign inJoinBooksAudiobooksComicsSheet MusicEditors' Picks BooksHand-picked favorites from our editorsEditors' Picks AudiobooksHand-picked favorites from our editorsEditors' Picks ComicsHand-picked favorites from our editorsEditors' Picks Sheet MusicHand-picked favorites from our editorsTop BooksWhat's trending, bestsellers, award-winners & moreTop AudiobooksWhat's trending, bestsellers, award-winners & moreTop ComicsWhat's trending, bestsellers, award-winners & moreTop Sheet MusicWhat's trending, bestsellers, award-winners & moreCategoriesArts & IdeasBiography & MemoirBusiness & LeadershipChildren'sComputers & TechnologyCooking & FoodCrafts & HobbiesFantasyFiction & LiteratureHappiness & Self-HelpHealth & WellnessHistoryHome & GardenHumorLGBTMystery, Thriller & CrimePolitics & EconomyReferenceReligionRomanceScience & NatureScience FictionSociety & CultureSports & AdventureTravelYoung AdultCategoriesArts & IdeasBiography & MemoirBusiness & LeadershipChildren'sComputers & TechnologyCooking & FoodFantasyFiction & LiteratureHappiness & Self-HelpHealth & WellnessHistoryHome & GardenHumorLGBTMystery, Thriller & CrimePolitics & EconomyReferenceReligionRomanceScience & NatureScience FictionSociety & CultureSports & AdventureTravelYoung AdultCategoriesAdaptationsChildren’sCrime & MysteryFictionHumorMangaNonfictionRomanceSciFi, Fantasy & HorrorSuperheroesYoung AdultPublishersArcanaArchie ComicsBOOM! StudiosDynamiteIDW PublishingKingstone ComicsMarvel ComicsSpace Goat ProductionsTop Cow ComicsValiant ComicsZenescopeDifficultyBeginnerIntermediateAdvancedMixedInstrumentBrassDrums & PercussionGuitar, Bass, and FrettedPianoStringsVocalWoodwindsGenreClassicalCountryFolkJazz & BluesMovies & MusicalsPop & RockReligious & HolidayStandardsWelcome to Scribd! Start your free trial and access books, documents and more.Find out moreProfesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑Programa de estudios
Versión 2.1 de noviembre de 2011 (Basado en la versión inglesa 2.1, 1 de marzo de 2011)
Condiciones de uso: 1. Los particulares y proveedores de formación pueden utilizar este programa de estudios como base para seminarios, siempre que se citen los derechos de autor y se incluyan en los materiales del seminario. Cualquiera que utilice este documento con fines publicitarios necesita autorización por escrito de IREB para ello. 2. Cualquier persona o colectivo puede utilizar este documento como base para artículos, libros u otra publicación siempre que se citen los derechos de autor y reconociendo al IREB e.V. como fuente y propietario de este documento en dichas publicaciones. Todos los derechos reservados. Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación, o transmitida bajo ninguna modalidad o a través de ningún medio, electrónico, mecánico, fotocopia, grabación o de cualquier otra naturaleza sin el permiso previo y por escrito de los autores o del IREB e.V.
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Agradecimientos
Este programa de estudios ha sido escrito por los siguientes miembros del comité: Karol Frühauf, Emmerich Fuchs, Martin Glinz, Rainer Grau, Colin Hood, Frank Houdek, Peter Hruschka, Barbara Paech, Klaus Pohl y Chris Rupp. Han contado con el apoyo de los miembros de IREB Ian Alexander, Joseph Bruder, Samuel Fricker, Günter Halmans, Peter Jaeschke, Sven Krause, Steffen Lentz, Urte Pautz, Suzanne Robertson, Dirk Schüpferling, Johannes Staub y Thorsten Weyer. La traducción al español del presente programa de estudios ha sido realizada por el equipo integrado por Xavier Franch Gutiérrez, Gustavo Márquez Sosa y Harald Messemer. Dado que el mismo programa se ha traducido, o se está traduciendo, a diversas lenguas, se ha seguido la directriz de respetar lo máximo posible el texto original. En aquellos vocablos cuya traducción puede ser motivo de controversia, se ha optado por introducir una nota a pie de página indicando otras aceptaciones comunes. Agradecemos a todos sus contribuciones.
Copyright © 2009 - 2011. Los derechos de autor de este programa de estudios pertenecen a los autores antes mencionados y se han transferido al IREB (International Requirements Engineering Board) e.V.
Introducción Objetivo del Documento
Este programa de estudios define el nivel básico (“Foundation Level”) de la certificación “Profesional Certificado en Ingeniería de Requisitos” establecida por el “International Requirements Engineering Board” (IREB). IREB ofrece este programa de estudios y los exámenes asociados en distintos idiomas. El programa de estudios puede ser utilizado por parte de los proveedores de formación como base para crear materiales para cursos. Los estudiantes pueden utilizar este documento para prepararse para el examen.
Este programa de estudios de nivel básico aborda las necesidades de aquellas personas involucradas en la temática de ingeniería de requisitos. Esto incluye a personas con roles tales como jefes de proyecto o responsables de tecnologías de la información (TI), expertos en el dominio, analistas de sistemas y desarrolladores de software.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑
El nivel básico expone contenidos fundamentales igualmente válidos para toda área (por ejemplo, sistemas embebidos, sistemas de seguridad crítica, sistemas de información clásicos). Esto no significa que, en un curso, no pueda ser tratada la adecuación de enfoques para áreas particulares considerando sus características especiales. Sin embargo, no es el objetivo presentar la ingeniería de requisitos específica de un dominio determinado. No se propone ningún procedimiento específico ni modelo de proceso asociado que haga afirmación alguna para la planificación, control y secuencia de aplicación de los conceptos aprendidos en la práctica. No se trata de destacar un proceso específico de ingeniería de requisitos ni de ingeniería del software. Se define aquello que constituye el conocimiento de los ingenieros de requisitos, pero no la interfaz exacta con otras disciplinas y procesos de ingeniería del software.
El grado de detalle de este programa de estudios permite una formación y evaluación consistentes a nivel internacional. Para lograr este objetivo, el programa de estudios contiene los siguientes elementos: objetivos educativos generales; contenidos con la descripción de los objetivos educativos; referencias bibliográficas complementarias (cuando sea necesario).
Objetivos Educativos / Niveles Cognitivos
A cada módulo del programa de estudios se le asigna un nivel cognitivo. El nivel superior incluye los niveles inferiores. Al formular los objetivos educativos se utilizan los verbos “saber” para el nivel N1 y “dominar y utilizar” para el nivel N2 que representan los siguientes verbos: N1 (saber): enumerar, caracterizar, reconocer, nombrar, reflejar. N2 (dominar y utilizar): analizar, utilizar, ejecutar, justificar, describir, criticar, mostrar, diseñar, desarrollar, completar, explicar, ilustrar (con un ejemplo), educir, formular, identificar, interpretar, sacar conclusiones, asignar, distinguir, comparar, comprender, sugerir, resumir. Deben conocerse todos los términos definidos en el glosario (N1), incluso aquéllos que no estén mencionados de forma explícita en los objetivos educativos.
En este programa de estudios se utiliza la abreviatura “IR” para “Ingeniería de Requisitos”.
El programa de estudios está formado por 9 capítulos. Cada capítulo cubre una unidad educativa (UE). El título principal de cada capítulo contiene el nivel cognitivo más alto del mismo, que es el nivel más alto de sus secciones. En cada capítulo también se sugiere la duración de su exposición, es decir, el tiempo mínimo que un curso debe invertir en dicho capítulo. Al comienzo de cada capítulo se enumeran los términos importantes para el mismo, que también están definidos en el glosario. Ejemplo: UE 1 Introducción y Fundamentos (N1)
Duración: 1 ¼ horas Términos: Requisito, Implicado, Ingeniería de Requisitos, Requisito Funcional, Requisito de Calidad, Restricción Este ejemplo muestra que el capítulo 1 sólo contiene objetivos educativos de nivel N1 y establece que 75 minutos son suficientes para enseñar el contenido de este capítulo. Cada capítulo puede contener secciones. Sus títulos también contienen el nivel cognitivo de su contenido. Los objetivos educativos son enumerados antes del texto. El esquema de numeración de estos objetivos concuerda con la numeración del capítulo y la sección. Por ejemplo: OE 3.1.2 Este ejemplo muestra que el objetivo educativo OE 3.1.2 está descrito en la sección 3.1.
Este programa de estudios es la base del examen para el certificado de nivel básico. Las preguntas del examen pueden basarse en el contenido de más de un capítulo del programa de estudios. Todos los capítulos (UE 1 - UE 9) pueden ser objeto de evaluación.
El examen consiste en un test de selección múltiple. Los exámenes se pueden realizar inmediatamente después de completar los cursos de formación, pero también de manera independiente de los cursos (por ejemplo, en un centro de evaluación). Puede encontrar una lista de proveedores de evaluación acreditados en la página web http://www.certified-re.de
Versión 2.1 Fecha Noviembre 2011 Comentario Versión inicial, basado en la versión inglesa 2.1
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Contenido
Agradecimientos.................................................................................................................................................................2 Introducción .........................................................................................................................................................................2 Historial de versiones.......................................................................................................................................................4 Contenido ..............................................................................................................................................................................5 EU 1 EU 2 EU 2.1 EU 2.2 EU 3 EU 3.1 EU 3.2 EU 3.3 EU 4 EU 4.1 EU 4.2 EU 4.3 EU 4.4 EU 4.5 EU 4.6 EU 4.7 EU 5 EU 5.1 EU 5.2 EU 6 EU 6.1 EU 6.2 Introducción y Fundamentos (N1)...........................................................................................................7 Sistema y Contexto del Sistema (N2) ......................................................................................................9 Sistema, Contexto del Sistema y Fronteras (N1) ...............................................................................9 Determinación de las Fronteras del Sistema y del Contexto (N2) ..............................................9 Educción de Requisitos (N2) ................................................................................................................... 11 Fuentes de Requisitos (N1) ...................................................................................................................... 11 Categorización de los Requisitos según el Modelo de Kano (N2) ............................................ 12 Técnicas de Educción (N2) ....................................................................................................................... 12 Documentación de Requisitos (N2) ...................................................................................................... 13 Diseño del Documento (N1)..................................................................................................................... 13 Tipos de Documentación (N1) ................................................................................................................ 13 Estructuras de Documento (N1) ............................................................................................................ 14 Uso de los Documentos de Requisitos (N1) ...................................................................................... 15 Criterios de Calidad para los Documentos de Requisitos (N2) ................................................. 15 Criterios de Calidad para los Requisitos (N2) ................................................................................. 16 Glosario (N2) .................................................................................................................................................. 16 Documentación de Requisitos utilizando Lenguaje Natural (N2) ............................................ 18 Efectos del Lenguaje (N2) ......................................................................................................................... 18 Elaboración de Requisitos mediante el uso de Plantillas (N2) .................................................. 18 Documentación de Requisitos basada en Modelos (N2) .............................................................. 20 El termino Modelo (N1) ............................................................................................................................. 20 Modelos de Objetivo (N2) ......................................................................................................................... 21
EU 6.3 EU 6.4 EU 6.5 EU 6.6 EU 6.7 EU 7 EU 7.1 EU 7.2 EU 7.3 EU 7.4 EU 7.5 EU 7.6 EU 8 EU 8.1 EU 8.2 EU 8.3 EU 8.4 EU 8.5 EU 8.6 EU 9 EU 9.1 EU 9.2 EU 9.3 Modelos de Casos de Uso (N2) ................................................................................................................ 22 Tres Perspectivas sobre los Requisitos (N1) .................................................................................... 23 Modelos Estructurales de Requisitos (N2) ........................................................................................ 23 Modelos de Requisitos Funcionales (N2) ........................................................................................... 24 Modelos de Requisitos de Comportamiento (N2)........................................................................... 25 Validación y Negociación de Requisitos (N2) ................................................................................... 26 Conceptos Básicos de la Validación de Requisitos (N1) ............................................................... 26 Conceptos Básicos de la Negociación de Requisitos (N1) ........................................................... 26 Aspectos de Calidad de los Requisitos (N2) ...................................................................................... 27 Principios para la Validación de Requisitos (N2) ........................................................................... 28 Técnicas para Validar los Requisitos (N2) ......................................................................................... 28 Negociación de Requisitos (N1) ............................................................................................................. 28 Gestión de Requisitos (N2)....................................................................................................................... 30 Asignación de Atributos a los Requisitos (N1) ................................................................................. 30 Vistas sobre los Requisitos (N2) ............................................................................................................ 31 Priorización de Requisitos (N2) ............................................................................................................. 31 Trazabilidad de los Requisitos (N2) ..................................................................................................... 32 Versionado de Requisitos (N2) ............................................................................................................... 32 Gestión de Solicitudes de Cambio (N2) ............................................................................................... 33 Apoyo de Herramientas (N1) .................................................................................................................. 35 Tipos de Herramientas (N1) .................................................................................................................... 35 Introducción de Herramientas (N1) ..................................................................................................... 36 Evaluación de Herramientas (N1) ......................................................................................................... 36 Lista de Abreviaturas .............................................................................................................. 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 1 Introducción y Fundamentos (N1)
Duración: 1 ¼ horas Términos: Requisito, Implicado1, Ingeniería de Requisitos, Requisito Funcional, Requisito de Calidad, Restricción Objetivos Educativos: OE 1.1 Conocer los síntomas y los motivos de una IR inadecuada OE 1.2 Conocer las cuatro actividades principales de una IR OE 1.3 Conocer el papel de la comunicación en la IR OE 1.4 Conocer las habilidades de un ingeniero de requisitos OE 1.5 Conocer los tres tipos de requisitos OE 1.6 Comprender el papel de los requisitos de calidad Una buena IR es importante dado que muchos errores ya surgen en esta fase y sólo pueden ser rectificados posteriormente con altos costes. Los síntomas típicos de una IR inapropiada son la ausencia o poca claridad de los requisitos. Algunos de los motivos habituales que conducen a una IR inadecuada son: la suposición errónea por parte de los implicados que muchas cosas se explican por sí mismas y no necesitan ser establecidas de forma explícita; la existencia de problemas de comunicación basados en diferencias de conocimiento y experiencia; la presión sobre el proyecto ejercida por parte del cliente para conseguir a corto plazo un sistema en producción. Las cuatro actividades principales dentro de la IR son la educción, documentación, validación / negociación de requisitos más la gestión de requisitos. El lenguaje natural es el medio más importante para comunicar requisitos. Al mismo tiempo, es particularmente importante acordar una terminología común. Adicionalmente, el medio de comunicación (escrito o hablado) juega un papel importante. Durante la comunicación, todos los participantes tienen que esforzarse en centrar y simplificar el discurso. Esto es especialmente cierto en el caso del rol más importante dentro de la IR: el ingeniero de requisitos. Aparte de habilidades de comunicación, este profesional debe exhibir otras tales como: pensamiento analítico, empatía, capacidad para la resolución de conflictos, capacidad de moderación, seguridad en sí mismo y capacidad de persuasión. Típicamente, distinguimos tres tipos de requisitos: requisitos funcionales, requisitos de calidad y restricciones.
(N.T.) Se ha optado por traducir la palabra inglesa “stakeholder” a “implicado”. Otros términos usados por
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011 Página 7 / 37
El término genérico “requisito no funcional” se utiliza con frecuencia para agrupar los requisitos de calidad y las restricciones. Los requisitos de calidad deben ser documentados de forma explícita. En particular, se deben considerar los aspectos siguientes: Detalle de la funcionalidad, por ejemplo en referencia a la seguridad o la precisión de cálculos Fiabilidad Usabilidad Eficiencia Capacidad de ser mantenido2 Portabilidad Aun cuando los requisitos de calidad son normalmente documentados en lenguaje natural, su relación con otros enunciados debe ser trazable. Su validación debe estar respaldada por declaraciones cuantitativas o deben hacerse operativos a través de su transformación en funcionalidades adicionales.
(N.T.) En este contexto, se ha optado por traducir la palabra inglesa “maintainability” a “capacidad de ser mantenido”. Otra traducción posible sería “mantenibilidad”.
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011 Página 8 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 2 Sistema y Contexto del Sistema (N2)
Duración: 1 ¼ horas Términos: Contexto del Sistema, Frontera del Sistema, Frontera del Contexto Objetivos Educativos: OE 2.1 Conocer el contexto del sistema, la frontera del sistema y la frontera del contexto OE 2.2 Dominar y utilizar la frontera del sistema y la frontera del contexto
EU 2.1 Sistema, Contexto del Sistema y Fronteras (N1)
La fuente de los requisitos de un sistema y, por lo tanto, su justificación, se encuentra en el contexto del sistema planificado. La fuente consiste en el conjunto de todos los aspectos del contexto que han originado o influido en la definición de los requisitos. Entre los aspectos potenciales residentes en el contexto del sistema están: Personas (implicados o grupos de implicados) Sistemas en producción (sistemas técnicos, software y hardware) Procesos (procesos técnicos o físicos, procesos de negocio) Eventos (técnicos o físicos) Documentos (por ejemplo, leyes, estándares, documentación del sistema) La función de la frontera del sistema es determinar los aspectos que deben estar cubiertos por el sistema planificado y aquéllos que son parte del entorno del sistema. La frontera del contexto identifica la parte del entorno que tiene una conexión con el sistema a desarrollar.
EU 2.2 Determinación de las Fronteras del Sistema y del Contexto (N2)
Frecuentemente la frontera del sistema no se acaba de definir con precisión hasta llegar al final mismo del proceso de requisitos. Hasta entonces, la funcionalidad requerida y aspectos de calidad del sistema planificado pueden ser conocidos de forma incompleta, o totalmente desconocidos. Por ello existirá una zona gris donde se acabará ubicando la frontera del sistema. Además del desplazamiento de la frontera del sistema dentro de esta zona gris, también es posible que esa misma zona se desplace durante el proceso de la IR, por ejemplo, cuando a partir del desplazamiento de la frontera del sistema ciertos aspectos del entorno adquieran importancia. La frontera del contexto también puede desplazarse con el tiempo; por ejemplo, cuando resulta que un requisito legal que previamente se consideraba importante, finalmente no tiene ningún impacto sobre el nuevo sistema, entonces el contexto del sistema es reducido en esa área.
También puede haber una zona gris para la frontera del contexto. Se trata de aquellos aspectos del entorno del sistema para los cuales aún no está claro si tienen relación con el sistema planificado o no. Para documentar el contexto del sistema (especialmente las dos fronteras, la del sistema y del contexto) se suelen utilizar diagramas de casos de uso o diagramas de flujo de datos. En el modelado del contexto, basado en diagramas de flujo de datos, se modelan las fuentes y sumideros del entorno del sistema, mostrando respectivamente la fuente y el destino de los flujos de datos entre el sistema considerado y el entorno. Los diagramas de casos de uso modelan los actores (es decir, por ejemplo personas u otros sistemas) del entorno del sistema a desarrollar y sus relaciones de uso con el mismo.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 3 Educción3 de Requisitos (N2)
Duración: 1 ½ horas Términos: ninguno Objetivos Educativos: OE 3.1.1 Conocer distintos tipos de fuentes de requisitos OE 3.1.2 Conocer el significado de las fuentes de requisitos y las consecuencias de ignorar fuentes de requisitos OE 3.1.3 Conocer la información más importante de documentación de los implicados OE 3.1.4 Conocer los principios importantes en el trato con los implicados (derechos y obligaciones de los implicados) OE 3.2.1 Dominar y utilizar el contenido e importancia del modelo de Kano OE 3.3.1 Conocer los factores que influyen en la selección de las técnicas de educción OE 3.3.2 Conocer las ventajas y desventajas de las técnicas de educción OE 3.3.3 Dominar y utilizar los siguientes tipos de técnicas de educción y aportar ejemplos para cada una de ellas: técnicas de prospección, técnicas creativas, técnicas basadas en la documentación, técnicas de observación y técnicas de soporte
EU 3.1 Fuentes de Requisitos (N1)
La educción de los requisitos del sistema a desarrollar es una actividad fundamental de la IR. Los elementos básicos de la educción de requisitos están determinados por el contexto del sistema y por las fuentes de los requisitos. Se distinguen distintos tipos de fuentes de requisitos, entre los que podemos citar los implicados, documentación o sistemas legados. Es tarea de la IR la recopilación de objetivos y requisitos de las distintas fuentes. Ignorar fuentes de requisitos podría tener consecuencias negativas significativas sobre el curso del proyecto en su conjunto. La documentación de las fuentes de los requisitos con respecto a los implicados debería contener, al menos, la siguiente información: Nombre Función (rol) Información personal y de contacto adicional Disponibilidad (cuándo y dónde se encuentra durante el transcurso del proyecto) Relevancia del implicado Áreas y nivel de conocimiento Objetivos e intereses respecto del proyecto
(N.T.) Se ha optado por traducir la palabra inglesa “elicitation” a “educción”. Otros términos usados por otros autores o traductores son: “obtención", “extracción” o incluso el neologismo “elicitación”.
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011 Página 11 / 37
Dependiendo de la cultura de la compañía, puede ser adecuado definir conjuntamente con cada implicado un acuerdo (verbal o por escrito) respecto de sus tareas, responsabilidades, nivel de autoridad, etc. De tales acuerdos resultan los derechos y las obligaciones de los implicados. Un tratamiento efectivo con los implicados protege contra una carencia de motivación y conflictos. Los implicados deberían estar involucrados en el proyecto, y no solamente afectados por el mismo.
EU 3.2 Categorización de los Requisitos según el Modelo de Kano (N2)
Para la educción de los requisitos es importante conocer la importancia de los mismos para lograr la satisfacción de los implicados. De acuerdo con el modelo del Dr. Kano, esta satisfacción se puede clasificar en tres categorías: Factores básicos Factores de desempeño4 Factores de entusiasmo
EU 3.3 Técnicas de Educción (N2)
Las técnicas de educción cumplen con el objetivo de averiguar los requisitos conscientes, inconscientes y subconscientes de los implicados. La elección de la técnica de educción está determinada por factores importantes tales como factores de riesgo, influencias humanas, influencias propias de la organización, influencias función-contenido y el grado de detalle deseado de los requisitos. Son necesarias varias técnicas para los distintos productos de la IR: Técnicas de prospección (por ejemplo, entrevistas, cuestionarios) Técnicas creativas (por ejemplo, tormenta de ideas y su variante paradoja, cambio de perspectiva, analogías) Técnicas basadas en la documentación (por ejemplo, arqueología de sistema, lectura basada en la perspectiva, reutilización de requisitos) Técnicas de observación (por ejemplo, observación de campo, aprendizaje) Técnicas de soporte (por ejemplo, mapas mentales, talleres, tarjetas CRC, grabaciones de audio y vídeo, modelado de casos de uso, prototipos) La aplicación de la técnica de educción apropiada es una habilidad clave para un proyecto. Los mejores resultados se logran con la combinación de varias técnicas de educción.
(N.T.) En este contexto, se ha optado por traducir la palabra inglesa “performance” a “desempeño”. Otra traducción posible sería la más clásica “eficiencia”.
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011 Página 12 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 4 Documentación de Requisitos (N2)
Duración: 2 horas Términos: Documento de Requisitos, Especificación de Requisitos Objetivos Educativos OE 4.1.1 Conocer las razones principales para documentar los requisitos OE 4.2.1 Conocer las tres perspectivas de los requisitos funcionales OE 4.2.2 Conocer las ventajas y desventajas de la documentación de requisitos en lenguaje natural OE 4.2.3 Conocer la forma más importante de documentación de requisitos basada en modelos OE 4.2.4 Conocer las ventajas de la combinación de formas de documentación de requisitos OE 4.3.1 Conocer las ventajas de las estructuras estandarizadas de documentos OE 4.3.2 Conocer una estructura de documento de amplia difusión OE 4.3.3 Conocer los puntos importantes para una estructura estándar adaptada OE 4.4.1 Conocer actividades que se basan en, o dependen de, los documentos de requisitos OE 4.5.1 Dominar y utilizar criterios de calidad para los documentos de requisitos OE 4.6.1 Dominar y utilizar de criterios de calidad para los requisitos OE 4.6.2 Conocer las dos reglas de estilo más importantes para los requisitos OE 4.7.1 Dominar y utilizar los contenidos e importancia de un glosario OE 4.7.2 Dominar y utilizar las normas para gestionar el glosario
EU 4.1 Diseño del Documento (N1)
Durante la IR es necesario documentar toda información relevante. Toda forma de representación más o menos formal de los requisitos, desde escritura en prosa hasta diagramas con semántica formal, se denomina “técnica de documentación”. Muchas personas están involucradas en la documentación durante el ciclo de vida de un documento de requisitos. La documentación juega una función de apoyo orientada a los objetivos en la comunicación. Los siguientes factores hacen que este apoyo sea necesario: los requisitos son de larga duración, relevantes desde un punto de vista legal, y deberían ser accesibles a todos. Los documentos de requisitos son complejos.
EU 4.2 Tipos de Documentación (N1)
Los documentos de requisitos incluyen, entre otras cosas, requisitos funcionales que normalmente representan las tres perspectivas siguientes de un sistema. Perspectiva de datos Perspectiva del comportamiento Perspectiva funcional
Página 13 / 37
Las tres perspectivas pueden documentarse mediante requisitos en lenguaje natural, mientras los modelos de tipo conceptual están especializados para una de estas perspectivas. Para documentar pueden usarse las formas siguientes: Documentación de requisitos en lenguaje natural Modelos conceptuales de requisitos tales como diagramas de casos de uso, diagramas de clase, diagramas de actividad y diagramas de estado (ver capítulo 6) Formas combinadas de documentación de requisitos
EU 4.3 Estructuras de Documento (N1)
Los requisitos del sistema en consideración son los elementos esenciales del documento de requisitos. Además de los requisitos mismos, y dependiendo del objetivo del documento, los documentos de requisitos también contienen información sobre el contexto del sistema, las condiciones de aceptación o, por ejemplo, características de la implementación técnica. Con el objetivo de asegurar la capacidad de gestión de los documentos de requisitos, éstos deben estar estructurados de forma apropiada. Las estructuras de referencia para documentos de requisitos proponen estructuras de contenido más o menos completas y más o menos flexibles que han sido contrastadas en la práctica. Una referencia habitual de estructura para documentos de requisitos es el estándar IEEE 830-1998 (Estructura de referencia para “Especificación de Requisitos Software”). En la práctica, el uso de estructuras de referencia para documentos de requisitos aporta una gran cantidad de resultados positivos. Por ejemplo, el uso de estructuras de referencia simplifica el uso de los documentos de requisitos en tareas de desarrollo subsiguientes (por ejemplo, en la definición de casos de prueba). En general las estructuras de referencia no pueden ser trasladadas a otros documentos de requisitos en su forma original, dado que la estructura del contenido tiene que ser adaptada a condiciones específicas del dominio, compañía o proyecto.
Página 14 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 4.4 Uso de los Documentos de Requisitos (N1)
Los documentos de requisitos son la base para un gran número de tareas durante la vida de un proyecto, tales como: Planificación Diseño de arquitectura Implementación Pruebas Gestión del cambio Uso y mantenimiento del sistema Gestión de contratos
EU 4.5 Criterios de Calidad para los Documentos de Requisitos (N2)
Para poder servir como base de las actividades posteriores en el proceso de desarrollo, un documento de requisitos debe cumplir ciertos criterios de calidad. En particular, entre estos criterios se incluyen: Ausencia de ambigüedad y consistencia Estructura clara Capacidad de ser modificado y capacidad de ser ampliado Completitud Trazabilidad
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 4.6 Criterios de Calidad para los Requisitos (N2)
Además de los criterios de calidad de los documentos, cada uno de los requisitos individuales debe cumplir con ciertos criterios de calidad, en particular: Consensuado Evaluado No ambiguo Válido y actualizado Correcto Consistente Verificable Realizable Trazable Completo Comprensible Además de estos criterios de calidad, existen dos reglas básicas de estilo para los requisitos expresados en lenguaje natural que ayudan a su legibilidad: frases y párrafos cortos; sólo un requisito por frase.
EU 4.7 Glosario (N2)
Un motivo frecuente por el que surgen conflictos durante la IR es la diferente interpretación de los términos por parte de las personas involucradas. Para evitar este problema es necesario recopilar los términos relevantes en un glosario. Un glosario es un conjunto de definiciones sobre: términos técnicos específicos del contexto; abreviaturas y acrónimos; palabras de uso común que tienen un significado concreto en el contexto del proyecto; sinónimos; homónimos.
El manejo de un glosario requiere el cumplimiento de las reglas siguientes: El glosario debe administrarse de forma centralizada Deben definirse claramente las responsabilidades sobre el mantenimiento del glosario El glosario debe mantenerse a lo largo de todo el proyecto El glosario debe estar accesible a todas las personas involucradas en el proyecto El uso del glosario debe ser obligatorio El glosario debe identificar el origen de los términos El glosario debe ser consensuado entre los implicados Las entradas del glosario deben tener una estructura consistente Es recomendable comenzar el desarrollo del glosario tan pronto como sea posible con el objeto de reducir el esfuerzo posterior de adaptación.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 5 Documentación de Requisitos utilizando Lenguaje Natural (N2)
Duración: 1 hora Términos: Plantilla de Requisitos Objetivos Educativos: OE 5.1 Dominar y utilizar los cinco procesos de transformación en la percepción y redacción de requisitos en lenguaje natural, así como sus consecuencias en la formulación de requisitos OE 5.2 Dominar y utilizar los cincos pasos para la formulación de requisitos utilizando una plantilla de requisitos
EU 5.1 Efectos del Lenguaje (N2)
Dado que el lenguaje natural es frecuentemente ambiguo e interpretable, es necesario prestar especial atención precisamente a estos aspectos al utilizarlo. Durante los procesos de percepción y redacción, tienen lugar los denominados “procesos de transformación”. El hecho de que estos procesos de transformación sigan ciertas reglas puede ser utilizado por el ingeniero de requisitos para educir exactamente aquello que el autor del requisito ha querido realmente decir. Los cinco procesos de transformación más importantes para la IR son: Nominalización Sustantivos sin índice de referencia Cuantificadores universales Condiciones especificadas de manera incompleta Palabras de proceso especificadas de forma incompleta
EU 5.2 Elaboración de Requisitos mediante el uso de Plantillas (N2)
Las plantillas de requisitos son una aproximación a la construcción de requisitos fácil de aprender y aplicar cuyo objetivo es reducir los efectos del lenguaje en la formulación de requisitos. La plantilla de requisitos ayuda eficazmente al autor de los mismos a crear requisitos de alta calidad.
Página 18 / 37
Los cinco pasos para la formulación de requisitos a través de una plantilla son: Determinar la obligatoriedad5 Establecer el núcleo del requisito Caracterizar la actividad del sistema Incluir objetos Determinar condiciones lógicas y temporales El establecimiento de la obligatoriedad a través del uso de los verbos “deberá (shall)”, “debería (should)”, y el “futuro imperfecto del modo indicativo de cada verbo (will)” se puede realizar en el texto del requisito. Si la obligatoriedad cambia, el requisito también cambia. El uso de atributos es otra posibilidad para documentar la obligatoriedad del requisito. Se obtendrán mejores resultados sin hacer obligatorio el uso de la plantilla, sino formando a los ingenieros de requisitos en el método y tratamiento de las plantillas de requisitos como herramienta complementaria.
(N.T.) Se ha optado por traducir la expresión inglesa “legal obligation” por “obligatoriedad”.
Programa de estudios Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Versión 2.1, de noviembre de 2011 Página 19 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 6 Documentación de Requisitos basada en Modelos (N2)
Duración: 5 horas Términos: Modelo Objetivos Educativos: OE 6.1.1 Conocer el término modelo y las propiedades de los mismos OE 6.1.2 Conocer los elementos de definición de un lenguaje de modelado conceptual OE 6.1.3 Conocer las ventajas de los modelos de requisitos OE 6.2.1 Conocer la importancia de los objetivos en ingeniería de requisitos OE 6.2.2 Conocer los dos tipos de descomposición de objetivos OE 6.2.3 Dominar y utilizar el modelado de objetivos en forma de árboles Y/O OE 6.3.1 Dominar y utilizar los diagramas de casos de uso OE 6.3.2 Dominar y utilizar las especificaciones de casos de uso OE 6.4.1 Conocer las tres perspectivas de los requisitos OE 6.5.1 Conocer el foco de la perspectiva de datos sobre requisitos OE 6.5.2 Dominar y utilizar diagramas de entidad-relación y diagramas UML de clases OE 6.6.1 Conocer el foco de la perspectiva funcional de requisitos OE 6.6.2 Dominar y utilizar diagramas de flujo de datos y diagramas UML de actividad OE 6.7.1 Conocer el punto de vista del comportamiento de requisitos OE 6.7.2 Dominar y utilizar diagramas UML de estado Nota: en este capítulo el nivel cognitivo N2 (“Dominar y utilizar”) no incluye los verbos “crear”, “diseñar”, “desarrollar” y “formular”.(Los estudiantes deben ser capaces de comprender los modelos. La creación de tales modelos es parte del módulo de nivel avanzado de IREB “modelado de requisitos”).
EU 6.1 El termino Modelo (N1)
El uso de modelos facilita la comprensión selectiva de la información de los hechos y sus relaciones, así como su registro de forma más rápida y documentación de forma no ambigua. Un modelo es una abstracción de una realidad existente o de una realidad nueva que se pretende crear. Los modelos tienen tres características importantes: Característica de representación: los modelos representan la realidad Característica de reducción: los modelos reducen la realidad representada Característica pragmática: los modelos se desarrollan con un propósito específico
Con frecuencia la IR hace uso de una variedad de modelos conceptuales que normalmente representan la realidad utilizando un conjunto de elementos gráficos. Se utilizan lenguajes de modelado conceptual para el desarrollo (modelado) de modelos conceptuales que son definidos por su sintaxis (elementos de modelado y sus combinaciones válidas) y su semántica (significado de los elementos de modelado). Los modelos de requisitos son modelos conceptuales que definen los requisitos del sistema que se va a desarrollar. La documentación de los requisitos en términos de modelos conceptuales aporta, en contraste a la documentación en lenguaje natural, las siguientes ventajas (entre otras): La información presentada en forma de imágenes se entiende y memoriza con mayor rapidez Los modelos de requisitos permiten un modelado orientado de una perspectiva de los requisitos Al definir un lenguaje de modelado para un propósito concreto, se puede especificar una abstracción apropiada de la realidad La combinación de lenguaje natural y modelos de requisitos aporta las ventajas de ambos tipos de documentación.
EU 6.2 Modelos de Objetivo (N2)
Un objetivo es la descripción intencional de una propiedad característica, deseada por un implicado, del sistema a desarrollar o del proyecto de desarrollo asociado. Los objetivos pueden ser documentados en lenguaje natural o en forma de modelos. Una parte integrante de la documentación de objetivos es la descripción de relaciones de refinamiento (relaciones de descomposición) entre objetivos superiores y subordinados. A este respecto se distinguen dos tipos de descomposición: “Descomposición de tipo Y” (se deben alcanzar todos los sub-objetivos para cumplir el objetivo superior  llamado súper objetivo) “Descomposición de tipo O” (se debe cumplir al menos uno de los sub-objetivos para cumplir el súper objetivo) Estas relaciones de descomposición entre objetivos se modelan frecuentemente en la forma de árboles Y/O.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 6.3 Modelos de Casos de Uso (N2)
Los casos de uso ayudan a examinar y documentar un sistema planificado o ya existente desde la perspectiva de los usuarios. La aproximación de casos de uso se basa en dos técnicas de documentación complementarias: Diagramas de casos de uso Especificaciones de casos de uso Los diagramas de casos de uso son modelos simples para documentar la funcionalidad del sistema desde el punto de vista de los usuarios, y documentar las interrelaciones de las funciones de un sistema y las relaciones entre estas funciones y el contexto del sistema. Los elementos de modelado más habituales de los diagramas de casos de uso son: Actores (personas u otros sistemas) en el contexto del sistema La frontera del sistema Casos de uso Diferentes tipos de relaciones entre los anteriores elementos Las especificaciones de los casos de uso complementan la visión global proporcionada por los diagramas de casos de uso a través de una especificación más precisa de las características esenciales de los casos de uso individuales. Con este propósito se cumplimenta separadamente una plantilla predefinida para cada caso de uso relevante. Algunas secciones típicas de estas plantillas son: Una designación única del caso de uso El nombre del caso de uso Una descripción del caso de uso El evento desencadenante Los actores El resultado Precondiciones y pos condiciones Varios tipos de escenarios. Estos escenarios describen secuencias típicas de eventos que conducen a la ejecución exitosa del caso de uso (escenario principal, escenarios alternativos) o describen de forma explícita cómo, durante la ejecución del caso de uso, deberían ser tratadas situaciones excepcionales (escenarios de excepción).
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 6.4 Tres Perspectivas sobre los Requisitos (N1)
En el ámbito de la documentación basada en modelos, los requisitos para el sistema a desarrollar son modelados en tres perspectivas solapadas: Perspectiva de datos Perspectiva funcional Perspectiva de comportamiento Ejemplos típicos de lenguajes de modelado conceptual para la perspectiva datos son los modelos entidad-relación (E-R) y los diagramas UML de clases. Para la perspectiva funcional, se utilizan con frecuencia los diagramas de flujo de datos o los diagramas UML de actividades (incluido el de flujo de objeto entre acciones). Para la perspectiva de comportamiento, ejemplos típicos de lenguajes de modelado conceptual son las máquinas finitas de estados y los diagramas de estados.
EU 6.5 Modelos Estructurales de Requisitos (N2)
En la perspectiva de datos, por ejemplo, se documenta la estructura de los datos así como el uso y las relaciones de dependencia dentro del contexto del sistema. Tradicionalmente la perspectiva de datos se modela utilizando diagramas entidad-relación, que documentan la estructura de la realidad mediante tres elementos de modelado: Tipos de entidad Tipos de relación Atributos Además, se puede documentar la frecuencia con la cual una instancia (entidad) de un tipo de entidad participa en una relación de un tipo de relación específica utilizando cardinalidades. Además, se puede documentar el número de instancias (entidades) de un tipo de entidad que pueden participar en una relación de un tipo de relación específica utilizando cardinalidades. Los diagramas UML de clases son una propuesta habitual para modelar la perspectiva de datos de los requisitos. Un diagrama de clases consiste en un conjunto de clases y asociaciones entre ellas. En este contexto, los elementos de modelado de los diagramas UML de clases utilizados con frecuencia son: Clases Asociaciones (con multiplicidades y roles) Relaciones de agregación y composición Relaciones de generalización
Página 23 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 6.6 Modelos de Requisitos Funcionales (N2)
La perspectiva funcional de los requisitos se ocupa de la transformación de los datos de entrada recibidos del entorno del sistema en datos de salida entregados a dicho entorno. Los enfoques para modelar la perspectiva funcional incluyen modelos de función. Con frecuencia, como por ejemplo en el “Análisis Estructurado” de Tom DeMarco, los diagramas de flujo de datos son utilizados como modelos de función. Los elementos de modelado de los diagramas de flujo de datos son: Procesos Flujos de datos Almacenes de datos Fuentes / sumideros Puesto que en los diagramas de flujo no se presenta el flujo de control o las características internas de los procesos, los diagramas de flujo son complementados con formas estructuradas de descripción adicionales. Por ejemplo, en las “mini-especificaciones” propias del análisis estructurado, se define el comportamiento interno de los procesos. En UML 2.0 el flujo de datos está representado por el modelado explícito del flujo de objetos en diagramas de actividades y, por lo tanto, éstos concuerdan de mejor manera con los diagramas de flujo de datos. Entre otras cosas, los diagramas de actividad modelan nodos de actividad y flujos de control entre éstos. Los flujos de objeto representan una forma especial de flujo de control. Las barras de sincronización en los diagramas de actividad permiten el modelado de flujos de control y de objeto concurrentes. Se pueden describir flujos alternativos de control y de objeto haciendo uso de nodos de decisión. En UML 2.0, los elementos de modelado más importantes en los diagramas de actividad son: Acciones Nodos de inicio y final Flujo de control Flujo de objeto Nodos de decisión Fusión de flujos de control alternativos División (“concurrencia”) Unión (“concurrencia”) Elementos de jerarquización
Página 24 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 6.7 Modelos de Requisitos de Comportamiento (N2)
En el modelado de requisitos, el comportamiento dinámico de un sistema es modelado desde la perspectiva del comportamiento. En esta perspectiva, el centro de atención se encuentra en los distintos estados en los que se puede encontrar un sistema y en los eventos que son responsables de un cambio de estado. En los diagramas UML de estados, basados en los principios de las máquinas finitas de estado, se utilizan los siguientes elementos de modelado: Estado Estados inicial y final Transición de estado Concurrencia
Página 25 / 37
Validación y Negociación de Requisitos (N2)
Duración: 2 ½ horas Términos: ninguno Objetivos Educativos OE 7.1.1 Conocer el significado de la validación requisitos OE 7.2.1 Conocer el significado de los conflictos con respecto a los requisitos OE 7.3.1 Conocer tres aspectos de calidad de los requisitos OE 7.3.2 Dominar y utilizar criterios de validación para los aspectos de calidad “contenido”, “documentación” y “nivel de acuerdo” OE 7.4.1 Conocer los seis principios de la validación de requisitos OE 7.4.2 Dominar y utilizar los seis principios de validación de requisitos OE 7.5.1 Conocer técnicas para la validación de requisitos OE 7.5.2 Dominar y utilizar las técnicas de validación siguientes: comentarios (opinión de experto), inspección, revisiones guiadas, lectura basada en la perspectiva, validación mediante prototipos y el uso de listas de comprobación OE 7.6.1 Conocer actividades de negociación de requisitos OE 7.6.2 Conocer los tipos de conflictos entre requisitos OE 7.6.3 Conocer distintas técnicas de resolución de conflictos OE 7.6.4 Conocer la documentación para la resolución de conflictos
EU 7.1 Conceptos Básicos de la Validación de Requisitos (N1)
El principal objetivo de la validación de requisitos es determinar si éstos cumplen los criterios de calidad que han sido fijados previamente (por ejemplo, corrección o completitud) con el objetivo de detectar y corregir posibles anomalías tan pronto como sea posible. Puesto que los documentos de requisitos son la base para todas las actividades de desarrollo posteriores, cualquier tipo de error no detectado en los requisitos afecta todas las actividades subsiguientes de tal manera que el esfuerzo de corregir un error no detectado en un requisito se eleva de forma significativa en el curso de un desarrollo. Esto se debe a que no basta con corregir el error en el requisito, sino que deben reconstruirse todos aquellos artefactos basados en el mismo, por ejemplo el diseño de arquitectura, la implementación, los casos de prueba.
EU 7.2 Conceptos Básicos de la Negociación de Requisitos (N1)
Los conflictos no resueltos en los requisitos pueden significar, por ejemplo, que algunos requisitos de un grupo de implicados no puedan ser implementados o que el sistema en operaciones sea poco o no aceptado o utilizado. El objetivo de la negociación de requisitos consiste en alcanzar un entendimiento común y consensuado de los requisitos del sistema a desarrollar entre todos los implicados relevantes.
Página 26 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 7.3 Aspectos de Calidad de los Requisitos (N2)
Distinguimos entre tres aspectos de calidad para los requisitos: el contenido, la documentación y el nivel de consenso. Por lo tanto, la calidad de cada requisito o grupo de requisitos puede ser valorado con respecto a cada uno de estos tres aspectos utilizando un conjunto de criterios de validación. Los ocho criterios de validación para el aspecto de calidad “contenido” son: Completitud del documento de requisitos Completitud de cada requisito individual Trazabilidad Corrección y adecuación Consistencia Ausencia de decisiones de diseño prematuras Verificabilidad Necesidad Los cinco criterios de validación para el aspecto de calidad “documentación” son: Conformidad con el formato del documento Conformidad con las estructuras de documento Comprensibilidad Ausencia de ambigüedad Conformidad con las normas de documentación Los tres criterios de validación para el aspecto de calidad “nivel de consenso” son: Acuerdo Acuerdo después de cambios Conflictos resueltos
Página 27 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 7.4 Principios para la Validación de Requisitos (N2)
La validación de requisitos se basa en una serie de principios. Estos principios aseguran que durante la validación se puedan identificar tantos errores en los requisitos como sea posible. Los seis principios que rigen la validación de requisitos son: Intervención de los implicados adecuados Separación de los procesos de diagnóstico y corrección de errores Validación desde distintos puntos de vista Cambio adecuado del tipo de documentación Construcción de artefactos de desarrollo basados en los requisitos Validación reiterada
EU 7.5 Técnicas para Validar los Requisitos (N2)
Existen varias técnicas para la validación sistemática de requisitos que pueden combinarse, al menos parcialmente, con el objetivo de verificar la adecuación de los requisitos con respecto a los criterios de validación definidos de la forma más completa posible. Entre estas técnicas podemos mencionar: Comentarios (opinión de experto) Inspecciones Revisiones guiadas También pueden utilizarse técnicas como: Lectura basada en la perspectiva Validación mediante prototipos Uso de listas de comprobación
EU 7.6 Negociación de Requisitos (N1)
La negociación de requisitos tiene por objetivo alcanzar un entendimiento consensuado de los requisitos entre todos los implicados relevantes. Las tareas a llevar a cabo durante la negociación son: Identificación de conflictos Análisis de conflictos Resolución de conflictos Documentación de las resoluciones de conflictos
Página 28 / 37
Durante el análisis de conflictos, se distinguen los diferentes tipos de conflictos (con respecto a requisitos) y después se aplican distintas estrategias de resolución según el tipo. Los tipos de conflictos son: Conflictos sobre el contenido Conflictos de intereses Conflictos de valor Conflictos en las relaciones Conflictos estructurales En la práctica, los conflictos frecuentemente se deben a una combinación de causas. Cuando se intenta resolver el conflicto se debería tener en cuenta a todos los implicados relevantes. Hay disponibles una serie de técnicas para la resolución de conflictos: Consenso Compromiso Votación Formulación de variaciones Criterio de autoridad Tener en cuenta todos los hechos (circunstancias) ”Más-menos interesante” Matriz de decisión Tras resolver un conflicto, el resultado debe documentarse de forma adecuada. Esta documentación debería incluir, en particular, la causa del conflicto, los implicados involucrados, sus opiniones, los medios utilizados para resolverlo, posibles alternativas, las decisiones tomadas y la justificación de dichas decisiones.
Página 29 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 8 Gestión de Requisitos (N2)
Duración: 2 ½ horas Términos: ninguno Objetivos Educativos OE 8.1.1 Conocer el propósito y definición de los esquemas de atributos OE 8.1.2 Conocer tipos importantes de atributos de los requisitos OE 8.2.1 Dominar y utilizar vistas sobre los requisitos OE 8.3.1 Conocer métodos para priorizar requisitos OE 8.3.2 Dominar y utilizar técnicas para priorizar requisitos OE 8.4.1 Conocer las ventajas de la trazabilidad de los requisitos OE 8.4.2 Dominar y utilizar distintos tipos de relaciones de trazabilidad OE 8.4.3 Dominar y utilizar formas de representación de las relaciones de trazabilidad OE 8.5.1 Dominar y utilizar el versionado de requisitos OE 8.5.2 Dominar y utilizar la formación de configuraciones de requisitos OE 8.5.3 Dominar y utilizar la formación de líneas base de requisitos OE 8.6.1 Conocer la importancia de los cambios de requisitos OE 8.6.2 Conocer las funciones y miembros del Comité de Gestión de Cambios OE 8.6.3 Dominar y utilizar los elementos de una solicitud de cambio de requisito OE 8.6.4 Dominar y utilizar distintos tipos de solicitudes de cambio OE 8.6.5 Dominar y utilizar un proceso para gestionar solicitudes de cambio
EU 8.1 Asignación de Atributos a los Requisitos (N1)
Para gestionar los requisitos durante todo el ciclo de vida del sistema, es necesario recoger información sobre los mismos de la forma más estructurada posible mediante atributos. La definición de la estructura de atributos para los requisitos se lleva a cabo mediante un esquema de atributos, que puede definirse en forma tabular o creando un modelo de información. Los atributos habituales son: Identificador Nombre Descripción Fuente Estabilidad Criticidad Prioridad La obligatoriedad también puede registrarse como información adicional del requisito mediante un atributo.
Frecuentemente, los esquemas de atributos se definen y adaptan según las necesidades de un proyecto específico en base a condiciones específicas. Entre ellas se encuentran: Propiedades específicas del proyecto Restricciones de la organización Reglas de dominio Restricciones del proceso de desarrollo
EU 8.2 Vistas sobre los Requisitos (N2)
En la práctica, se observa que tanto el número de requisitos en un proyecto, como el número de dependencias entre los mismos, crece constantemente. Para mantener la complejidad de los requisitos manejable por el equipo del proyecto, es necesario permitir un acceso selectivo a los mismos, mediante el filtrado de los requisitos dependiendo de la actividad actual. Distinguimos dos clases de mecanismo de filtrado para la formación de vistas: Vistas selectivas: muestran un subconjunto de valores de atributos de requisitos seleccionados en base a ciertos criterios de selección Vistas comprimidas: muestran información sintética sobre requisitos seleccionados en base a ciertos de criterios de selección
EU 8.3 Priorización de Requisitos (N2)
Los requisitos se priorizan, en diferentes momentos y durante actividades distintas, de acuerdo con diversos criterios. La preparación de la priorización de requisitos se basa en un proceso sencillo: Definir los objetivos y restricciones de la priorización Definir los criterios de priorización Seleccionar los implicados relevantes Elegir los artefactos a priorizar A partir de los resultados de estas actividades se puede utilizar una o más técnicas de priorización y llevar a cabo la priorización misma. Entre estas técnicas mencionamos: Ordenación y técnica de los diez mejores Clasificación por un solo criterio Clasificación de Kano Matriz de priorización de Wiegers
Página 31 / 37
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 8.4 Trazabilidad de los Requisitos (N2)
Durante la gestión de los requisitos, se debe registrar, organizar y mantener información de trazabilidad. Los beneficios que ofrece la trazabilidad de requisitos son: Simplificación de la verificabilidad Permite la identificación de características del sistema que no son necesarias Permite la identificación de requisitos que no son necesarios Apoyo al análisis de impacto Apoyo a la reutilización Apoyo a la identificación de responsabilidades Apoyo al mantenimiento y administración del sistema Hay tres clases de relaciones de trazabilidad que se deberían tener en cuenta: Trazabilidad pre-especificación de requisitos Trazabilidad pos-especificación de requisitos Trazabilidad entre requisitos Sólo se debería mantener aquella información de traza para la que exista un uso claro. La trazabilidad de requisitos se puede representar de diversas maneras. Algunas formas típicas son: Referencias basadas en texto e hipervínculos Matrices de trazabilidad Grafos de trazabilidad
EU 8.5 Versionado de Requisitos (N2)
El versionado y configuración de requisitos posibilita, a lo largo del ciclo de vida de un sistema o producto, el registro de los estados de los requisitos y los documentos de requisitos disponibles. El número de versión de un requisito incluye al menos dos componentes: Versión Incremento Una configuración de requisitos comprende un conjunto de requisitos relacionados desde un punto de vista lógico. En una configuración de requisitos dada sólo puede haber como máximo una versión de cada requisito individual. Las configuraciones de requisitos se forman según dos dimensiones: Dimensión del producto: los requisitos individuales del fundamento de los requisitos Dimensión de la versión: las diferentes estados de cambio de un requisito
Página 32 / 37
Una configuración de requisitos tiene varias propiedades típicas: Vínculo lógico entre los requisitos de una configuración Consistencia de los requisitos de una configuración Existencia de un identificador único para la configuración Inmutabilidad de los requisitos de una configuración Punto de partida para la vuelta a versiones anteriores de la base de requisitos Las líneas base de requisitos son configuraciones específicas de requisitos, que se caracterizan por contener versiones estables de los requisitos y que frecuentemente definen los incrementos de distribución del sistema (entrega del sistema).
EU 8.6 Gestión de Solicitudes de Cambio (N2)
Los requisitos cambian y evolucionan a lo largo del ciclo de vida de un sistema. Los cambios en los requisitos son gestionados y tratados en proceso de gestión de cambio sistemático. En este proceso, el Comité de Control de Cambios es responsable de gestionar las solicitudes de cambio entrantes. Las tareas del Comité de Control de Cambios son: Clasificación de las solicitudes de cambio entrantes Determinación del esfuerzo necesario para realizar el cambio Evaluación de la relación esfuerzo-beneficio de la petición de cambio Definición de nuevos requisitos en base a la solicitud de cambio Decisión de aceptar o rechazar una solicitud de cambio Priorizar las solicitudes de cambio aceptadas Asignar las solicitudes de cambio aceptadas a proyectos de cambio Algunos integrantes típicos del Comité de Control de Cambios son: el gestor del cambio, clientes, arquitectos, representantes de los usuarios, el gestor de la calidad y los ingenieros de requisitos. Cuando los cambios en requisitos se consideran necesarios, éstos deben documentarse en la forma de solicitud de cambio y enviarse al Comité de Control de Cambios. Una solicitud de cambio incluye como mínimo la información siguiente: Identificador de la solicitud de cambio Título de la solicitud de cambio Descripción del cambio necesario Motivos que justifican la necesidad del cambio Fecha de la solicitud de cambio Solicitante del cambio Prioridad del cambio según la percepción del solicitante
Se pueden distinguir tres tipos de cambios: Cambio correctivo Cambio adaptativo Cambio excepcional El proceso de gestión de cambios contempla los siguientes pasos: Análisis de impacto y evaluación del cambio Asignación de prioridad a la solicitud de cambio Asignación del cambio a un proyecto de cambio Respuesta al solicitante respecto de la aceptación o rechazo de su solicitud de cambio
Página 34 / 37
Apoyo de Herramientas (N1)
Duración: 1 hora Términos: ninguno Objetivos Educativos OE 9.1 Conocer las ocho características de una herramienta de gestión de requisitos OE 9.2 Conocer los cinco aspectos a tener en cuenta al introducir herramientas de requisitos OE 9.3 Conocer las siete vistas de las herramientas de gestión de requisitos
EU 9.1 Tipos de Herramientas (N1)
Se pueden utilizar como apoyo a la IR muchas herramientas de desarrollo de sistemas, por ejemplo, herramientas de gestión de pruebas, herramientas de gestión de la configuración, Wikis, software de ofimática y herramientas de visualización. También las herramientas de modelado son importantes para la IR con el propósito de crear y analizar información en forma de modelos. Las herramientas de gestión de requisitos son herramientas desarrolladas específicamente para la IR. Estas herramientas deberían ofrecer las características siguientes: Gestionar distintos tipos de información Gestionar las relaciones lógicas entre la información Identificar artefactos de forma unívoca Hacer que la información sea accesible de forma flexible y segura, por ejemplo a través del control de acceso Soportar distintas vistas de los datos Organizar la información, por ejemplo, mediante la asignación de atributos o la formación de jerarquías Generar informes sobre la información recopilada Generar documentos a partir de la información Las herramientas ofimáticas estándar ofrecen todas estas funcionalidades pero de manera limitada. Las herramientas especializadas de IR refinan estas funcionalidades, por ejemplo, mediante gestión de la trazabilidad.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ EU 9.2 Introducción de Herramientas (N1)
Sólo debe buscarse una herramienta de IR cuando ya se hayan implantado los procedimientos y las técnicas de IR. La introducción de una herramienta requiere responsabilidades y procedimientos en la IR claramente establecidos. En el proceso se deberían considerar los siguientes aspectos: Considerar los recursos necesarios Evitar riesgos utilizando antes la herramienta en proyectos piloto Evaluar las herramientas utilizando criterios predefinidos Tener en cuenta los costes más allá de los costes de licencia Formar a los empleados
EU 9.3 Evaluación de Herramientas (N1)
Hay muchos aspectos que deben considerarse cuando se evalúa una herramienta de IR. Este proceso puede estructurarse utilizando las siete vistas siguientes: Vista del proyecto (por ejemplo, apoyo a la planificación del proyecto) Vista del usuario (especialmente la usabilidad) Vista del producto (funcionalidad) Vista del proceso (soporte metodológico) Vista del proveedor de la herramienta (por ejemplo, servicios que ofrece el proveedor) Vista técnica (por ejemplo, interoperabilidad, escalabilidad) Vista económica (costes) Para cada una de estas vistas se debería establecer una serie de criterios de evaluación claros.
Profesional Certificado en Ingeniería de Requisitos de IREB ‑ Nivel Básico ‑ Apéndice
MER IR IREB L1 L2 OE UE UML
Modelo Entidad Relación Ingeniería de Requisitos International Requirements Engineering Board Nivel Cognitivo 1 Nivel Cognitivo 2 Objetivo Educativo Unidad Educativa Unified Modeling Language
Página 37 / 37
More From This Userggtytytyhghgghghavg_v1b.pdfPuntos Funcionales IntroducciónhjhvnvhLibro La Caja de Herramienta de La ProspectivaffhfghfghEtslatercerizacionnoestaprohibidaenlanuevaleydeltrabajoLey Organica Del Trabajo Los Trabajadores y Las Trabajadorasanalisis_impactoPhuyuyhPor Que Fallan Los Proy de SoftElModeloTeoria de Restricciones Toc Fundamentos y Aplicaciones1_Gestión de Proyectos Con La Nueva ISO 21500 PMScrum y Xp Desde Las TrincherasGP Llorens 1Gest Ional Can CeRe Sum Engram Ti CalCambios_AutomaticosRobert Glover - No More Mr Nice Guysnort_manual
IREB Cpre Syllabus FL Es v21 by Luis Riobueno61 viewsEmbedDownloadRead on Scribd mobile: iPhone, iPad and Android.Copyright: Attribution Non-Commercial (BY-NC)Download as PDF, TXT or read online from ScribdFlag for inappropriate contentMore informationShow less

References: resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución