UML

¿Qué es UML?

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos.

UML y su función en el modelado y diseño orientados a objetos

Hay muchos paradigmas o modelos para la resolución de problemas en la informática, que es el estudio de algoritmos y datos. Hay cuatro categorías de modelos para la resolución de problemas: lenguajes imperativos, funcionales, declarativos y orientados a objetos (OOP). En los lenguajes orientados a objetos, los algoritmos se expresan definiendo 'objetos' y haciendo que los objetos interactúen entre sí. Esos objetos son cosas que deben ser manipuladas y existen en el mundo real. Pueden ser edificios, artefactos sobre un escritorio o seres humanos.
Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.
UML usa las fortalezas de estos tres enfoques para presentar una metodología más uniforme que sea más sencilla de usar. UML representa buenas prácticas para la construcción y documentación de diferentes aspectos del modelado de sistemas de software y de negocios.

La historia y los orígenes de UML

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los conocía, habían desarrollado otras metodologías. Se asociaron para brindar claridad a los programadores creando nuevos estándares. La colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su propio desarrollo de negocios. Ellos, junto con muchas otras personas y compañías, establecieron los recursos necesarios para desarrollar un lenguaje de modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye información sobre UML 2.0 en la segunda edición de 2005.

OMG: Tiene un significado diferente

Según su sitio web, el Object Management Group® (OMG®) es un consorcio internacional sin fines de lucro y de membresía abierta para estándares tecnológicos, fundado en 1989. Los estándares de OMG son promovidos por proveedores, usuarios finales, instituciones académicas y agencias gubernamentales. Los grupos de trabajo de OMG desarrollan estándares de integración empresarial para una amplia gama de tecnologías y una gama incluso más amplia de industrias. Los estándares de modelado de OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un eficaz diseño visual, ejecución y mantenimiento de software y otros procesos.
OMG supervisa la definición y el mantenimiento de las especificaciones de UML. Esta supervisión ofrece a los ingenieros y programadores la capacidad de usar un lenguaje para muchos propósitos durante todas las etapas del ciclo de vida del software en sistemas de cualquier tamaño.

La finalidad de UML según OMG

El OMG define los propósitos de UML de la siguiente manera:

• Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las herramientas para el análisis, el diseño y la implementación de sistemas basados en software, así como para el modelado de procesos de negocios y similares.
• Hacer progresar el estado de la industria permitiendo la interoperabilidad de herramientas de modelado visual de objetos. No obstante, para habilitar un intercambio significativo de información de modelos entre herramientas, se requiere de un acuerdo con respecto a la semántica y notación.

UML cumple con los siguientes requerimientos:

• Establecer una definición formal de un metamodelo común basado en el estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML, sus atributos y sus relaciones, así como las reglas de combinación de estos conceptos para construir modelos UML parciales o completos.
• Brindar una explicación detallada de la semántica de cada concepto de modelado UML. La semántica define, de manera independiente a la tecnología, cómo los conceptos UML se habrán de desarrollar por las computadoras.
• Especificar los elementos de notación de lectura humana para representar los conceptos individuales de modelado UML, así como las reglas para combinarlos en una variedad de diferentes tipos de diagramas que corresponden a diferentes aspectos de los sistemas modelados.
• Definir formas que permitan hacer que las herramientas UML cumplan con esta especificación. Esto se apoya (en una especificación independiente) con una especificación basada en XML de formatos de intercambio de modelos correspondientes (XMI) que deben ser concretados por herramientas compatibles.

UML y el modelado de datos

El UML es popular entre programadores, pero no suele ser usado por desarrolladores de bases de datos. Una razón es sencillamente que los creadores de UML no se enfocaron en las bases de datos. A pesar de ello, el UML es efectivo para el modelado de alto nivel de datos conceptuales y se puede usar en diferentes tipos de diagramas UML. Puedes encontrar información sobre la multidimensionalidad de un modelo de clases orientado a objetos en una base de datos relacional en este artículo sobre Modelado de bases de datos en UML.

Actualizaciones en UML 2.0

El UML se perfecciona continuamente. UML 2.0 extiende las especificaciones de UML para cubrir más aspectos de desarrollo, incluido Agile. La meta era reestructurar y perfeccionar UML de forma que la facilidad de uso, la implementación y la adaptación se simplificaran. Estas son algunas de las actualizaciones de los diagramas UML:

• Mayor integración entre modelos estructurales y de comportamiento.
• Capacidad de definir jerarquía y desglosar un sistema de software en componentes y subcomponentes.
• UML 2.0 eleva el número de diagramas de 9 a 13.

Glosario de términos de UML

Familiarízate con el vocabulario de UML, con esta lista extraída del documento UML 2.4.1, cuya finalidad es ayudar a quienes no son miembros de OMG a entender los términos comúnmente usados.

• Compatibilidad con sintaxis abstracta Los usuarios pueden mover modelos a través de diferentes herramientas, incluso si usan diferentes notaciones.
• Metamodelo de almacén común (CWM) Interfaces estándares que se usan para permitir el intercambio de metadatos de almacén e inteligencia de negocios entre herramientas de almacén, plataformas de almacén y repositorios de metadatos de almacén en entornos heterogéneos distribuidos.
• Compatibilidad con sintaxis concreta Los usuarios pueden continuar usando una notación con la que estén familiarizados a través de diferentes herramientas.
• Núcleo En el contexto de UML, el núcleo comúnmente se refiere al "paquete central", que es un metamodelo completo particularmente diseñado para una alta reutilización.
• Unidad de lenguaje Consiste en una colección de conceptos de modelado estrechamente vinculados que proporciona a los usuarios la capacidad de representar aspectos del sistema en estudio según un paradigma o formalismo en particular.
• Nivel 0 (L0) Nivel de cumplimiento inferior para la infraestructura UML - una sola unidad de lenguaje que hace posible el modelado de tipos de estructuras basadas en clases que se encuentran en los lenguajes más populares de programación orientados a objetos.
• Meta Object Facility (MOF) Una especificación de modelado de OMG que brinda la base para las definiciones de metamodelos en la familia de lenguajes MDA de OMG.
• Metamodelo Define el lenguaje y los procesos a partir de los cuales formar un modelo.
• Construcciones de metamodelos (LM) Segundo nivel de cumplimiento en la infraestructura UML - una unidad adicional de lenguaje para estructuras más avanzadas basadas en clases, usadas para construir metamodelos (por medio de CMOF), tales como el UML mismo. UML solo tiene dos niveles de cumplimiento.
• Arquitectura dirigida por modelos (MDA) Un enfoque y un plan para lograr un conjunto coherente de especificaciones de tecnología dirigida por modelos.
• Lenguaje de restricciones para objetos (OCL) Un lenguaje declarativo para describir reglas que se aplican al Lenguaje Unificado de Modelado. OCL complementa a UML proporcionando términos y símbolos de diagramas de flujo que son más precisos que el lenguaje natural, pero menos difíciles de dominar que las matemáticas.
• Object Management Group (OMG) Es un consorcio sin fines de lucro de especificaciones para la industria de la computación, cuyos miembros definen y mantienen la especificación UML.
• UML 1 Primera versión del Lenguaje Unificado de Modelado.
• Lenguaje Unificado de Modelado (UML) Un lenguaje visual para especificar, construir y documentar los artefactos de los sistemas.
• XMI Una especificación basada en XML de formatos de intercambio de modelos correspondientes.

Ver el documento MOF completo
Descargar el documento de Infraestructura UML 2.4.1completo.

Conceptos de modelado especificados por UML

El desarrollo de sistemas se centra en tres modelos generales de sistemas diferentes:

• Funcionales: Se trata de diagramas de casos de uso que describen la funcionalidad del sistema desde el punto de vista del usuario.
• De objetos: Se trata de diagramas de clases que describen la estructura del sistema en términos de objetos, atributos, asociaciones y operaciones.
• Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados y los diagramas de actividades se usan para describir el comportamiento interno del sistema.

Estos modelos de sistemas se visualizan a través de dos tipos diferentes de diagramas: estructurales y de comportamiento.

Conceptos orientados a objetos en UML

Los objetos en UML son entidades del mundo real que existen a nuestro alrededor. En el desarrollo de software, los objetos se pueden usar para describir, o modelar, el sistema que se está creando en términos que sean pertinentes para el dominio. Los objetos también permiten la descomposición de sistemas complejos en componentes comprensibles que permiten que se construya una pieza a la vez.
Estos son algunos conceptos fundamentales de un mundo orientado a objetos:

• Objetos Representan una entidad y el componente básico.
• Clase Plano de un objeto.
• Abstracción Comportamiento de una entidad del mundo real.
• Encapsulación Mecanismo para enlazar los datos y ocultarlos del mundo exterior.
• Herencia Mecanismo para crear nuevas clases a partir de una existente.
• Polimorfismo Define el mecanismo para salidas en diferentes formas.

Tipos de diagramas UML

UML usa elementos y los asocia de diferentes formas para formar diagramas que representan aspectos estáticos o estructurales de un sistema, y diagramas de comportamiento, que captan los aspectos dinámicos de un sistema.
Diagramas UML estructurales

• Diagrama de clases El diagrama UML más comúnmente usado, y la base principal de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas de clases al crear diagramas de sistemas grandes.
• Diagrama de componentes Muestra la relación estructural de los elementos del sistema de software, muy frecuentemente empleados al trabajar con sistemas complejos con componentes múltiples. Los componentes se comunican por medio de interfaces.
• Diagrama de estructura compuesta Los diagramas de estructura compuesta se usan para mostrar la estructura interna de una clase.
• Diagrama de implementación Ilustra el hardware del sistema y su software. Útil cuando se implementa una solución de software en múltiples máquinas con configuraciones únicas.
• Diagrama de objetos Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.
• Diagrama de paquetes Hay dos tipos especiales de dependencias que se definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de comunicación entre niveles.

Diagramas UML de comportamiento

• Diagramas de actividades Flujos de trabajo de negocios u operativos representados gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los diagramas de actividades se usan como una alternativa a los diagramas de máquina de estados.
• Diagrama de comunicación Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se pasan entre objetos. La misma información se puede representar usando un diagrama de secuencia y objetos diferentes.
• Diagrama de panorama de interacciones Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia en la cual actúan.
• Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia. Representan interacciones para un escenario concreto.
• Diagrama de máquina de estados Similar a los diagramas de actividades, describen el comportamiento de objetos que se comportan de diversas formas en su estado actual.
• Diagrama de temporización Al igual que en los diagramas de secuencia, se representa el comportamiento de los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los objetos se muestran durante ese período de tiempo particular.
• Diagrama de caso de uso Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores (actores) internos/externos.

Cómo crear un diagrama UML: Tutoriales y ejemplos

Para ilustrar cómo crear diferentes tipos de diagramas UML, prueba uno o todos estos tutoriales para guiarte a través del proceso de trazar diagramas tanto estructurales como de comportamiento.
Ejemplos de tutoriales de diagramas estructurales
DIAGRAMAS DE CLASES
Los diagramas de clases representan las estructuras estáticas de un sistema, incluidas sus clases, atributos, operaciones y objetos. Un diagrama de clases puede mostrar datos computacionales u organizacionales en la forma de clases de implementación y clases lógicas, respectivamente. Puede haber superposición entre estos dos grupos.

1. Las clases se representan con una forma rectangular dividida en tercios. La sección superior muestra el nombre de la clase, mientras que la sección central contiene los atributos de la clase. La sección inferior muestra las operaciones de la clase (también conocidas como métodos).
2. Agrega formas de clases a tu diagrama de clases para modelar la relación entre esos objetos. Además, podría ser necesario que agregues subclases.
3. Usa líneas para representar asociación, traspaso, multiplicidad y otras relaciones entre clases y subclases. Tu estilo de notación preferido informará la notación de estas líneas.

DIAGRAMAS DE COMPONENTES
Los diagramas de componentes muestran cómo se combinan los componentes para formar componentes más grandes o sistemas de software. Estos diagramas están diseñados para modelar las dependencias de cada componente en el sistema. Un componente es algo necesario para ejecutar una función de estereotipo. Un estereotipo de componente puede constar de ejecutables, documentos, tablas de bases de datos, archivos o archivos de bibliotecas.

1. Representa un componente con una forma rectangular. Debe tener dos rectángulos pequeños en un lado o mostrar un icono con esa forma.
2. Agrega líneas entre formas de componentes para representar las relaciones pertinentes.

DIAGRAMAS DE IMPLEMENTACIÓN
Un diagrama de implementación modela la implementación física y la estructura de los componentes de hardware. Los diagramas de implementación muestran dónde y cómo operarán los componentes de un sistema en conjunto con los demás.

1. Al trazar un diagrama de implementación, usa la misma notación que usas para un diagrama de componentes.
2. Usa un cubo 3D para modelar un nodo (lo cual representa una máquina física o máquina virtual).
3. Etiqueta el nodo con el mismo estilo que se usa para los diagramas de secuencia. Agrega otros nodos según sea necesario, luego conéctalos con líneas.

Ejemplos de tutoriales de diagramas de comportamiento
Diagrama de actividades
Los diagramas de actividades muestran el flujo de control de procedimiento entre objetos de clases, junto con procesos organizacionales, como los flujos de trabajo de negocios. Estos diagramas se integran con formas especializadas que luego se conectan con flechas. La notación establecida para los diagramas de actividades es similar a la de los diagramas de estados.

1. Empieza tu diagrama de actividades con un círculo negro.
2. Conecta el círculo a la primera actividad, la cual se modela con un rectángulo redondeado.
3. Ahora, conecta cada actividad a otras actividades con líneas que muestren el flujo paso a paso de todo el proceso.
4. También puedes probar usar carriles para representar los objetos que realizan cada actividad.

Diagrama de caso de uso
Un caso de uso es una lista de pasos que definen la interacción entre un actor (un humano que interactúa con el sistema o un sistema externo) y el sistema propiamente dicho. Los diagramas de casos de uso representan las especificaciones de un caso de uso y modelan las unidades funcionales de un sistema. Estos diagramas ayudan a los equipos de desarrollo a comprender los requisitos de su sistema, incluida la función de la interacción humana en el mismo y las diferencias entre diversos casos de uso. Un diagrama de caso de uso podría mostrar todos los casos de uso del sistema o solo un grupo de casos de uso con una funcionalidad similar.

1. Para iniciar un diagrama de casos de uso, agrega una forma ovalada en el centro del dibujo.
2. Escribe el nombre del caso de uso dentro del óvalo.
3. Representa a los actores con una figura humana cerca del diagrama, luego usa líneas para modelar las relaciones entre los actores y los casos de uso.

Diagrama de secuencia
Los diagramas de secuencia, también conocidos como diagramas de eventos o escenarios de eventos, ilustran cómo los procesos interactúan entre sí mostrando llamadas entre diferentes objetos en una secuencia. Estos diagramas tienen dos dimensiones: vertical y horizontal. Las líneas verticales muestran la secuencia de mensajes y llamadas en orden cronológico y los elementos horizontales muestran instancias de objetos en las que se transmiten los mensajes.

1. Para crear un diagrama de secuencia, escribe el nombre de la instancia de clase y el nombre de la clase en un cuadro rectangular.
2. Dibuja líneas entre las instancias de clases para representar al emisor y receptor de los mensajes.
3. Usa puntas de flecha oscuras para simbolizar mensajes sincrónicos, puntas de flecha abiertas para mensajes asincrónicos y líneas discontinuas para mensajes de respuesta.

Lucidchart facilita dibujar diagramas UML

Puedes empezar a crear diagramas UML ahora mismo con Lucidchart. Con nosotros es más sencillo, eficaz e incluso divertido.

• Sencillo de usar Facilidad de uso. Si estás creando un diagrama UML, sabes claramente lo que estás haciendo, pero queremos que realices el trabajo de la forma más sencilla posible. Ahorrarás tiempo con la interfaz refinada y el editor inteligente de arrastrar y soltar de Lucidchart.
• Amplia biblioteca de formas Dibuja diagramas de estados, diagramas de actividades, diagramas de casos de uso y mucho más. Con una amplia biblioteca de formas y conectores, encontrarás todo lo que necesites.
• Integración total Lucidchart está totalmente integrado con G Suite. Una vez que hayas empezado con Lucidchart, podrás encontrarnos directamente en tu conjunto de aplicaciones de productividad de Google junto co

INGENIERIA DE REQUISITOS

INGENIERÍA DE REQUERIMIENTOS.


2. INGENIERÍA DE REQUISITOS

 La ingeniería de requisitos, según Pressman [Pressman 05], es un conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto de un modo sistemático. En definitiva, facilita los mecanismos adecuados para comprender las necesidades del cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. La ingeniería de requisitos permite la gestión adecuada de los requisitos de un proyecto de desarrollo software. Además, mejora la capacidad para realizar planificaciones de los procesos de proyectos de desarrollo software puesto que el conocer qué se tiene que desarrollar permite una efectiva proyección de las actividades, recursos, costos, tiempos, etc. del proyecto. Según Sommerville [Sommerville 05], se puede considerar como el proceso de comunicación entre los clientes, los usuarios del software y los desarrolladores del mismo. Llevar a cabo de manera adecuada el proceso de ingeniería de requisitos disminuye la probabilidad de fracaso de un proyecto. Esto es porque los requisitos bien definidos permiten conocer de un modo conciso que debe ser capaz de realizar el software a desarrollar y hace orientar las actividades, recursos y esfuerzos de manera eficiente permitiendo la disminución de costos y retrasos. Todo ello provoca una mejora en la calidad del software puesto que los requisitos bien especificados podrán probarse de manera efectiva y, por tanto, cumplirse.


2.1. Fases en ingeniería de requisitos

 La definición de las necesidades del sistema juega un papel fundamental en el proceso de desarrollo del software (SPD). Esta definición es un proceso complejo puesto que en él hay que identificar los requisitos que el Patrón de clasificación de tipos de requisitos Página 4 de 107 sistema debe cumplir para satisfacer las necesidades. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. La delimitación de ingeniería de requisitos no es del todo clara puesto que incluso, hay autores que, dentro de la ingeniería de requisitos, generan modelos estáticos de clases que son entendidos por otros autores como tareas de una fase posterior. Dentro de las posibles estructuras que se pueden definir en la fase de ingeniería de requisitos, la propuesta con mayor seguimiento es la establecida por Lowe y Hall [Lowe y Hall 99]. En ella, el proceso de tratamiento de requisitos está compuesto por tres actividades: - Captura de requisitos. - Definición de requisitos. - Validación de requisitos. Se puede representar este proceso de ingeniería de requisitos como un diagrama de actividades en UML, tal como se muestra en la ilustración 1. Es posible plantear el estudio de viabilidad y la gestión de requisitos en el proceso de tratamiento de requisitos. Ilustración 1: Proceso Ingeniería Requisitos Patrón de clasificación de tipos de requisitos Página 5 de 107 El estudio de viabilidad permite definir de modo global la funcionalidad y ver si es factible su ejecución dentro del aspecto económico y del tiempo establecido, elaborando para ello un informe de viabilidad. La gestión de requisitos permite las posibles actualizaciones y cambios que pueden sufrir los requisitos, dando lugar a versiones del documento de requisitos. Esta actividad se desarrolla a lo largo de todo el proceso de desarrollo software.

 2.1.1. Captura de requisitos

La captura de requisitos es la actividad en la que un grupo especializado extrae, de cualquier fuente de información disponible (documentos, aplicaciones existentes, entrevistas, etc.), las necesidades de cubrir dicho sistema. El proceso de captura de requisitos puede resultar complejo, debido a esto existen un conjunto de técnicas que permiten hacer este proceso de una forma más eficiente y precisa, obteniéndose necesidades y modelos del sistema. A continuación se enumeran un grupo de técnicas que son utilizadas para esta actividad: - Entrevistas. Permiten tomar conocimiento del problema y comprender los objetivos de la solución buscada. - Desarrollo de conjunto de aplicaciones. Es una práctica de grupo donde participan usuarios, analistas, administradores del sistema, y clientes y en la que se concretan las necesidades del sistema. - Tormenta de ideas. Consiste en la mera acumulación de ideas sin evaluar las mismas. Ofrece una visión general de las necesidades del sistema pero sin ofrecer detalles concretos. - Mapa conceptual. Grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Estos grafos sirven para aclarar los conceptos relacionados con el sistema a desarrollar, ofreciendo una visión general de las necesidades del sistema. Patrón de clasificación de tipos de requisitos Página 6 de 107 - Casos de uso. Muestran el contorno (actores) y el alcance del sistema (requisitos expresados como casos de uso). Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada función. La ventaja principal de los casos de uso es que resultan muy fáciles de entender para el cliente, sin embargo pueden carecer de a precisión necesaria, es por ello que pueden acompañarse de una información textual. - Cuestionarios. Recoge información del sistema de forma independiente de la entrevista.

 2.1.2. Definición de requisitos

 Para la definición de los requisitos son usados lenguajes naturales que, a pesar de poder ser ambiguos y/o extensos, su coste reducido hace que sean la alternativa común a los lenguajes formales. Es necesario elaborar el documento de requisitos, en el cual, se definen los objetivos y necesidades del sistema. Existe un conjunto de técnicas propuestas para esta actividad: - Lenguajes naturales y formales. Los lenguajes naturales es una técnica muy ambigua en contraposición a los lenguajes formales. - Ontologías. Donde se definen los conceptos que intervienen en la definición del sistema así como las relaciones que existen entre ellos. - Patrones. Define los requisitos mediante el lenguaje natural pero de una manera estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida. Es necesario clasificar el conjunto de requisitos, pudiendo generarse un catálogo distinto dependiendo del estándar utilizado. Patrón de clasificación de tipos de requisitos Página 7 de 107 2.1.3. Validación de requisitos Por último, se procede a la validación de requisitos, llevándose a cabo la valoración de los mismos, comprobando la veracidad, consistencia y completitud de requisitos. Las técnicas existentes para desarrollar esta actividad son: - Revisiones de verificabilidad. Consiste en la lectura y corrección de la documentación o modelado de la definición de requisitos. - Auditorías. Consiste en un chequeo de los resultados. - Matrices de trazabilidad. Consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo que objetivos cubre cada requisito para detectar inconsistencias u objetivos no cubiertos. - Prototipos. Permite que el usuario se haga una idea del sistema. Los requisitos han de ser gestionados mediante el llamado plan de gestión de requisitos que establece las medidas, el método, soporte y técnicas para almacenar los requisitos, gestionar el cambio de éstos (debido a que pueden ser volátiles) y gestionar su trazabilidad.

 2.2. Evolución y negociación de los requisitos

 Desde el principio, se pretende especificar los requisitos de forma detallada pero es casi imposible conocer al principio del proyecto todos los detalles del futuro software. En la práctica, los requisitos son cambiantes dentro del proceso iterativo y evolutivo del software. Pueden existir muchos problemas en los proyectos software por la volatibilidad de los requisitos, muchos clientes desean que se añadan o modifiquen nuevos requisitos por el mismo precio y es tarea del ingeniero negociar esas nuevas funcionalidades no presentadas en el pliego inicial. Es por esto que para llevar con éxito un proyecto, es necesario el contacto continuado entre el cliente y el ingeniero software para conocer las Patrón de clasificación de tipos de requisitos Página 8 de 107 dificultades y necesidades de ambas partes y así buscar una solución de manera conjunta.

2.3. Necesidad del establecimiento y gestión de requisitos

La necesidad de modelar los requisitos dado un sistema tiene una importancia vital puesto que sin éstos el equipo no sabes cuales son las metas a lograr, ni puede inspeccionar y probar su trabajo de modo adecuado, ni puede controlar su productividad, ni puede obtener datos que se adecuen a las pruebas, ni pueden predecir el tamaño y esfuerzo del proyecto. En definitiva, no hay ingeniería completa sin requisitos escritos. Muchos proyectos iniciados no llegan a finalizarse o aquellos que son terminados, incurren en mayores costes y tiempos o no incluyen la totalidad de los requisitos iniciales. Una de las causas de este problema es la deficiente captura y gestión de los requisitos. Otro punto importante de la ingeniería de requisitos es la adecuada gestión de los requisitos que se puede considerar como el factor más relevante para el éxito o el fracaso de un proyecto. Esto es motivado por lo cambiante que son los requisitos. El plan de gestión de requisitos define las medidas, métodos, soportes y técnicas para almacenar los requisitos, gestionar el posible cambio de éstos así como su trazabilidad. La gestión de requisitos no es una tarea sencilla, Chiristel y Kang [Christel y Kang 92], plantean una serie de inconvenientes:  Problemas de alcance. Esto es debido a que es complejo especificar los límites que abarcan los requisitos.  Problemas de comprensión. Esto es debido a que los clientes y usuarios no suelen estar completamente seguros de lo que quieren.  Problemas de volatibilidad. Esto es debido a que los requisitos pueden cambiar con el tiempo puesto que durante el proceso mismo del desarrollo los requisitos evolucionan.