Ing. del Software UPTLL - 3er. trayecto

Implementar un software forma parte de la fase final, por así decirlo, del largo proceso de creación, diseño y prueba del mismo. En ella se recopilan todos los resultados positivos obtenidos de las fases anteriores, para así garantizar un correcto funcionamiento para el software en su vida útil.

No obstante, a la hora de implementar un software, es aconsejable seguir una serie de metodologías exactas para que así, al momento de llevar a cabo este indispensable proceso, se haga con la mayor celeridad posible, descantando de la mayor manera márgenes de error que puedan ocurrir en el proceso. A los mismos se les divide como Tipos.

Existe la Metodología Waterfall o cascada, la cual es el método de implantación de un software de gestión más tradicional. Esta técnica de gestión de proyectos está basada en el análisis de los requisitos a cumplir por un programa de gestión desde el inicio. Es decir, una vez detectados los objetivos a alcanzar, el diseño y la planificación de la instalación de la solución van a continuación. Para esta metodología, se acuerdan una serie de fechas y metas a cumplir. El diseño, en cambio, se encarga de asegurar que se cumplan los requisitos y necesidades acordados con la empresa en el inicio del proceso.

Es importante resaltar que el plan estratégico debe ejecutarse y una vez completado, probado e implementado se debe analizar si las necesidades por las que la empresa implantó el software de gestión se han cumplido.

No obstante, la metodología Waterfall posee un común inconveniente a la hora de llevarse a cabo, y es que el cliente no vuelve a comprobar la adecuación del software de gestión a sus necesidades hasta que el proceso termina.

Cabe destacar que esta técnica metodológica impide añadir cambios durante la duración del proceso, dificultando que puedan realizarse a posteriori. Esto es, en muchas ocasiones, la razón principal por la que una solución de Navision puede fallar en sus funciones.

Continuando en el mismo orden de ideas, está la metodología ágil o Scrum que, a diferencia de la metodología Waterfall, cumple con sus objetivos en cortos plazos de tiempo denominados sprints. La misma también se basa en el análisis de las necesidades del cliente, en el diseño y en la planificación de la implementación.

Después de cada sprint, el cliente y los técnicos encargados de llevar a cabo la implantación se reúnen para analizar el resultado e introducir mejoras que hayan podido surgir durante el proceso. Este hecho permite que el cliente esté plenamente involucrado en la gestión del proyecto y puedan realizarse modificaciones a tiempo real y sin dificultades extra, como sí sucedía con el método anterior.

Finalmente, en la tercera metodología tenemos la denominada Sure Step, el cual se lleva a cabo progresivamente y por una determinada cantidad de fases, llevando a cabo los siguientes pasos:

Análisis

Diseño

Construcción

Implementación

Objetivo

La finalidad de la metodología Sure Step es maximizar la productividad y eficiencia de la implementación y asegurar que el futuro ERP o CRM cumplan con las exigencias del cliente.

Posterior a este proceso metodológico, se realiza la implantación de software, verificando que no existan vulnerabilidades a través del método anteriormente llevado a cabo. La implementación de software lleva consigo una cantidad de etapas que deben llevarse a cabo para su efectividad, los cuales son:

La Implantación, el cual, por defecto, habla de implantar cuando una aplicación se instala sin modificar su código fuente. Cuando se realizan modificaciones al código, o se programan nuevos elementos en la aplicación, es propio hablar de implementación. La implantación es una de las fases más complejas del proceso. Incluye las actividades de compilación, instalación y personalización. Tras esto, corresponde realizar la migración de datos, capacitar a los usuarios y aportar los documentos y manuales respectivos que permitirán trabajar de manera productiva y eficaz.

La Compilación, la cual es la traducción del código fuente de la nueva aplicación en lenguaje binario para que pueda ser interpretado por el procesador del computador. Luego, utilizando un programa llamado instalador y un linker (enlazador) se consigue un programa ejecutable final para ser utilizado por el correspondiente sistema operativo.

La Personalización, la cual consiste en adaptar la aplicación a los requerimientos del usuario final mediante un procedimiento llamado parametrización, donde se ajustan los parámetros establecidos en el software a las particularidades que necesita el cliente.

La Migración de datos, la cual no es otra cosa que trasladar al programa nuevo los datos que el cliente desea incorporar. Esta información se encuentra habitualmente dispersa en diversos archivos, formatos y soportes. Habitualmente, corresponde al cliente ingresar esta información. Puede llegar a ser un procedimiento complejo si se trata de una organización que lleva mucho tiempo en funcionamiento.

De esta manera, se cumple con todas las fases de desarrollo de un software: análisis, diseño, implementación, pruebas, implantación y puesta en marcha. Además, es importante preservar la vida de dicho software llevando a cabo un correcto mantenimiento, el cual resulta casi indispensable para que prevalezca por el tiempo que sea estimado o necesario.

El mantenimiento se define como la disciplina cuya finalidad consiste en mantener las máquinas y equipos en un estado de operación, lo que incluye servicio, pruebas, inspecciones, ajustes, reemplazo, reinstalaciones, calibración, reparación, y reconstrucción. Principalmente se basa en el desarrollo de conceptos, criterios y técnicas requeridas para el mantenimiento, proporcionando una gruía de políticas o criterios para toma de decisiones en la administración y aplicación de programas de mantenimientos. 

Si bien es cierto que el diseño e implementación de cualquier sistema organizativo y su posterior informatización debe siempre tener presente que está al servicio de unos determinados objetivos, cualquier sofisticación del sistema debe ser contemplada con gran prudencia en evitar, precisamente, de que se enmascaren dichos objetivos o se dificulte su consecución.

En el caso del mantenimiento su organización e información debe estar encaminada a la permanente consecución de los siguientes objetivos:

Optimización de la disponibilidad del equipo productivo.

Disminución de los costos de mantenimiento.

Optimización  de los recursos humanos.

Maximización de la vida del software.

En las últimas dos entradas hemos mostrado la relevancia de los sistemas a través de su diseño y estructuración, ¿pero qué tan importante es para un software cumplir con determinadas pruebas a la hora de su uso? Antes de comercializar cualquier producto, es indispensable haber cumplido con una serie de pruebas y procesos al pie de la letra que verifiquen el funcionamiento del software, esto con la finalidad de brindar la mejor experiencia al usuario sin arrojar ningún tipo de complicaciones ni problemas a la hora de ser ejecutado el sistema.

Para cumplir con lo anteriormente mostrado, se aplica lo llamado pruebas de software, lo cual se define como un conjunto de procesos con los que se pretende probar un sistema o aplicación en diferentes momentos para comprobar su correcto funcionamiento. Dichas pruebas de software pueden llevarse a cabo en cualquier parte del desarrollo del mismo, pues siempre es recomendable hacer pruebas para evitar posibles errores; esto, a su vez, nos permite tener control de cuándo queremos ejecutarlas o no, ya que algo que caracteriza a las pruebas de software es que pueden ser automáticas o no, es decir, pueden ejecutarse indefinidamente siempre que así lo permita el tester.

Debido a la relevancia de las pruebas de software en la creación de sistemas eficientes, se ha vuelto más complejo el proceso de prueba en los últimos años. En los procesos de prueba de software básicos, se comprende la planificación y el control de pruebas, análisis y diseño de pruebas, implementación y ejecución de pruebas, evaluación de criterios de salida y elaboración de informes, y actividades de cierre de prueba. El “test process”, denominado así en ingles, debe ser meticulosamente llevado a cabo, teniendo presente parámetros como los siguientes definidos a continuación:

Defecto (defect, fault, bug), el cual es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.

Falla (failure), el cual puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

Error (error), el cual es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método, una acción humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de manifestación del defecto en el sistema que se ejecuta. Datos de prueba (test dates): el cual son un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular, un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicación es parcial o completamente satisfactorio.

Verificación, la cual es el proceso a través del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo.

Validación, que se define como el proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

Procesos de Pruebas (test), las cuales son actividades en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso, los resultados se observan y registran para realizar una evolución de dicho proceso.

Referente a la programación una prueba de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación.

Luego de profundizar los fundamentos de procesos de pruebas, es necesario conocer acerca de las técnicas de pruebas más comunes e implementadas a menudo, debido a que son importantes al llevar a cabo una prueba de software con total éxito. El objetivo de las pruebas es la detección de defectos en el software, ya que descubrir un error es el éxito de una prueba.

Existen 3 técnicas de pruebas de software que son las más usadas como un enfoque principal a llevar a cabo. Éstas son las siguientes mencionadas a continuación:

Pruebas de Caja Blanca: Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Las pruebas de caja blanca están dirigidas a las funciones internas.

Entre las técnicas usadas se encuentran:

La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución).

Pruebas sobre las expresiones lógico-aritméticas.

Pruebas de camino de datos (definición-uso de variables).

Comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno).

Pruebas de Caja Negra: Se centra en las funciones, entradas y salidas. Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes categorías:

Funciones Incorrecta o ausente.

Errores de Interfaz.

Errores en estructuras de datos o acceso a base de datos externas.

Errores de rendimiento.

Errores de inicialización y de terminación.

OBJETIVO 2: DISEÑO DE SOFTWARE Y DISEÑO DE INTERFAZ DE SOFTWARE

El desarrollo de un software va más allá de sus funciones y procesos. Detrás de la funcionalidad de un software, se resguardan parámetros de diseño que son de suma relevancia a la hora de ser utilizado, pues la relación entre el usuario y el software debe ser amigable, fácil e intuitiva para mejorar y resguardar los procesos. Por ello, la importancia del diseño de software hace presencia a la hora de crear y desarrollar sistemas.

Brevemente, definimos al diseño de software como un proceso que transforma los requisitos del usuario de una manera conveniente, lo que ayuda al programador en la codificación e implementación del software. Dicho proceso de diseño es evaluado a través de SRS (Software Requirement Specification, en español 'ERS' especificación de requisitos de software), que se crea tanto para codificar como para implementar, esto con la finalidad de tener un panorama más detallado del diseño a llevar a cabo.

El diseño de software es, en primera instancia, lo que lleva al SFDLC (Software Design Life Cycle, en español ciclo de vida del diseño de software), lo que cambia la atención e importancia desde problema de dominio a solución de dominio. Posterior a su aplicación, reúne tres posibles niveles para calificar los resultados obtenidos:

El diseño arquitectónico, el cual es la versión más abstracta del sistema. Identifica el software como un sistema con distintos componentes que interactúan entre ellos.

El diseño de alto nivel, el cual se centra en cómo el sistema junto con todos sus componentes se puede implementar en forma de módulos. Reconoce estructuras modulares de cada sub-sistema y su relación e interacción entre las mismas. El mismo rompe con el concepto de diseño arquitectónico que se refiere a ‘Componente de única entidad múltiple', y por lo contrario, tiene un punto de vista menos abstracto de los sub-sistemas y módulos y representa la existente interacción entre ellos.

El diseño detallado, el cual diseña acuerdos con la parte de implementación de lo que se ve como sistema y sus sub-sistemas con los dos tipos de diseño mencionados con anterioridad. Es más detallado en cuanto a los módulos y a su implementación. Define estructuras lógicas de cada módulo y de sus interfaces para comunicarse con los otros módulos.

Dichos niveles arrojan resultados que concluyen con su diseño, el cual no se cohíbe de estar en constante cambio para su adaptabilidad. La importancia de este proceso de diseño recae en la calidad que el software proporcione en relación a su durabilidad, efectividad y variabilidad.

El Diseño es la única manera de materializar con precisión los requerimientos del cliente, y es por ello que busca implementar todos los requisitos explícitos contenidos en el modelo de análisis y acumular todos los requisitos implícitos que desea el cliente.

El diseño de software no se aleja de diversos problemas, y es que se trata de un proceso complejo que debe ser llevado meticulosamente, de modo que se eviten la menor cantidad de errores a la hora de ser diseñado. Para contrarrestar estas problemáticas, se recomienda en su mayoría, generar patrones de diseño que simplifiquen sus módulos y hagan más sencilla su ejecución.

Los patrones de diseño son unas técnicas para resolver problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Éstas a su vez resultan una solución a los problemas más comunes enfrentados en el diseño, arrojando características claves del software. En su mayoría, una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Finalmente, cuando el diseño del software se ve culminado, lo ideal es aplicar un modelo de diseño que sintetice todo lo mostrado. Los modelos de diseños de software son esa abstracción de la implementación del sistema, que se utiliza para concebir y para documentar el diseño del sistema de software. Es un producto de trabajo integral y compuesto que abarca todas las clases de diseño, subsistemas, paquetes, colaboraciones y las relaciones entre ellos.

Esto, a su vez, lleva la fase de Evaluación del Diseño de Software donde se busca examinar, de manera detallada, el software sintetizado, en busca de problemas que puedan amenazar contra sus funciones, ciclo de vida, entre otros. En esa fase es usual hacer uso de cuestionarios o checklist para llevar un registro de los acontecimientos y cambios en el sistema, para así conocer de antemano cuáles son sus fallas o características desde una perspectiva diferente.

Concluyendo con este proceso, conociendo que el software en conjunto con el sistema funcionan a la par, es esencial crear un vínculo amigable entre los usuarios y la interfaz. Un principio muy importante del diseño de interfaz es captar la diferencia entre accesibilidad y usabilidad, los cuales son meramente similares, pero muy diferentes entre sí.

Cuando decimos que un software posee accesibilidad, nos referimos a un acceso universal, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localización geográfica y capacidades de los usuarios. Un software accesible lo será tanto para una persona con discapacidad, como para cualquier otra persona que se encuentre bajo circunstancias externas que dificulten su acceso a la información.

Por otro lado, la usabilidad comprende la forma en la cual los usuarios perciben el uso de las diferentes funciones del software. En esta parte se toma en cuenta los requisitos del software, ya que son los que guían al usuario en el uso del mismo y en su desenvolvimiento con el software. Un sistema debe poseer usabilidad, pues es un requisito indispensable ser útil y fácil de comprender para los usuarios.

Ambos parámetros comprenden los principios de interfaz de diseño, características indispensables a la hora de llevar a cabo el diseño de un software.

No obstante, es importante considerar aspectos visuales en el diseño de la interfaz que permitan que el software cuente con una mayor comprensión y legibilidad. Entre estos aspectos existe la manera de navegación, colores, iconos, la forma en la que se muestra información textual y audiovisual, entre otros. Estos los podemos enlistar de la siguiente manera:

Disposición o Layout: formatos, proporciones, y mallas (grids); organización: ya sea 2D y 3D.

Tipografía: selección de tipos de letra y estilos, incluyendo la anchura fija y variable.

Color y Textura: color, textura y luminancia aportan información compleja y realidad pictorial.

Imágenes: signos, iconos y símbolos, desde lo fotográficamente real a lo abstracto.

Animación: un display dinámico o cinético: muy importante en la utilización de imágenes relacionadas con el vídeo.

Secuenciamiento: el aproximamiento total del secuenciamiento visual al secuenciamiento lógico.

Sonido: abstracto, vocal, concreto, o musical.

Identidad Visual: las reglas adicionales y únicas que proporcionan consistencia de conjunto a una interfaz de usuario.

Otros factores a tomar en cuenta a la hora del diseño de software son la navegabilidad, la simplicidad, la fácil comprensión de la información mostrada, la claridad y la economización del espacio. Esto se logra mediante items, tipografias, imagenes, figuras y colores adecuados. El último mencionado juega un rol importante, ya que es el color el que transmite diferentes sensaciones y sentimientos a la hora de percibirlo.

Brevemente tomamos en consideración los siguientes términos a la hora de brindarle una definición a lo que es "color":

- Matiz (Hue) es la composición espectral de longitud de onda que produce percepciones de ser azul, naranja, verde, etc. por ejemplo.

- Valor (Value) es la cantidad relativa de claridad u oscuridad del color en un rango desde el negro al blanco (también llamado intensidad).

- Saturación (Chroma) es la pureza del color en una escala desde el gris a la variante mas viva del color percibido.

- Brillo (Brightness) es la cantidad de energía luminosa al crear el color.

Dichas definiciones antes mencionas toman un rol importante en el diseño de interfaz y en cómo se percibe la información transmitida. Estas mismas son las que acarrean diversas leyes y principios a tomar en cuenta; entre ellas, tres más resaltantes, como lo son:

- Organización del color, la cual influye en la consistencia de la organización. El color debe emplearse para agrupar los items relacionados.

- Economía del color, la cual sugiere usar un máximo de 5 +/- 2 colores cuando el significado tiene que ser recordado.

- Comunicación del color, la cual sugiere usar fuertes contrastes en valor y tono para centrar la atención del usuario en la información más importante. Cuando demasiadas figuras o campos del fondo compiten por la atención del usuario se produce cierta confusión. La jerarquía de los estados sobreiluminado, neutro e infrailuminado para todas las áreas de la pantalla deben ser cuidadosamente diseñadas para proporcionar la máxima sencillez y claridad.

Es importante tomar en cuenta que si se produce un cambio en el tamaño de los elementos coloreados, nuestra percepción sobre su luminancia o tono puede cambiar, y tomar las medidas oportunas.

También es preciso usar colores que difieran tanto en valor como en tono. Las combinaciones rojo/verde, azul/amarillo, verde/azul, y rojo/azul deben ser evitadas excepto si se necesita un efecto visual especial. Pueden crear vibraciones, ilusiones, sombras y postimágenes.

De igual forma, para situaciones con poca iluminación se recomienda texto claro, líneas finas y formas pequeñas o medianas sobre un fondo oscuro; para situaciones con iluminación abundante, por el contrario, texto oscuro (azul o negro), líneas finas y formas pequeñas sobre fondo claro.

Finalmente, teniendo en cuenta los principios antes mencionados, es de importancia seguir las siguientes recomendaciones a la hora de diseñar interfaces de software de calidad, efectividad y vida útil:

1.- Usar un máximo de cinco, más menos dos colores. Cuatro colores distintos son apropiados. Permite mayor sitio adicional en la memoria a corto plazo (memoria de trabajo). Los ordenadores pueden proporcionar alrededor de 16 millones de colores, pero los humanos sólo pueden discriminar entre 7,5 millones de colores.

2.- Usar colores centrales y periféricos de forma apropiada. Usar el color azul para áreas grandes, no para detalles o texto. El azul es apropiado para fondos de transparencias y pantallas. Usar el rojo y el verde para captar la atención es una buena medida, el campo visual se adapta fácilmente a esto.

3.- Usar el mismo color para agrupar elementos relacionados. La ciencia cognitiva ha avanzado en la noción de preparar y el proceso preatento. En este contexto, puedes preparar al usuario para eventos relacionados usando un código de color común. Un grupo de imágenes sucesivas puede mostrarse para relacionarse usando el mismo color. Colores similares pueden evocar significados similares. Es preciso mantener el color de fondo a no ser que exista una poderosa razón, por el mismo motivo.

4.- Usar un código de formas redundante de la misma manera que el color. Hace la pantalla más impermeable a distorsiones en el color. Los cambios en la claridad del ambiente pueden provocar cambios en el color percibido.

5.- Evitar azul para el texto, líneas finas, y formas pequeñas. Nuestro sistema visual no está únicamente diseñado para estímulos detallados y precisos en longitudes de onda corta. Sin embargo, el azul es muy aconsejable para el color de fondo, y se percibe de manera idónea en la periferia del campo visual.

6.- Evitar que los colores adyacentes difieran únicamente en la cantidad de azul. Los límites que difieran únicamente en la cantidad de azul se percibirán distintos.

Una de las premisas clave de la Ingeniería es combinar ciertos elementos con determinadas características de una manera tal, que logren una acción en conjunto sin obtener errores. Para la Ingeniería del Software esta filosofía claramente se mantiene, y abarca diferentes áreas donde actualmente es imposible no hacer caso de ellas. Más allá de solo tratarse de sistemas informáticos, también contribuye a través del modelo de negocios para que éstas cumplan con un régimen que las haga funcionales.

De esta forma, un modelo de negocios consiste en expresar el conocimiento preciso de los procesos que lleva la organización y que pueden relacionarse con el sistema que se va a desarrollar. En estos modelos normalmente se requiere una visión general de la organización donde se va a desarrollar dicho modelo, desde sus más pequeños detalles en hardware, software, bases de datos, conexiones a internet, entre otros, para así brindar resultados más concisos y precisos. Esa visión general, además, debe incluir todo lo referente al objetivo del negocio, su estructura organizativa en cuanto a las dependencias y áreas que se involucran directamente con el sistema, procesos y usuarios responsables, volumen de la información del sistema actual, manejada a través de las transacciones o actualizaciones, entre otros.

Finalmente y ya con la cantidad necesaria ya recolectada, con la información obtenida, el equipo del proyecto informático de la empresa, consultores externos contratados por la empresa, elaborará el Modelo de Negocio que consiste en realizar un documento entregable que contiene: el Modelo de casos de usos del Negocio, el Modelo del Dominio y el Modelo de Objetos.

Para destacar brevemente, un modelo de casos de usos del Negocio se refiere a un modelo utilizando  los diagramas de caso de usos que describen los procesos se ejecutan en las diferencias dependencias y que se relacionan con el  sistema a desarrollar; un modelo de dominio se constituye por  un diagrama de clases conceptuales y está compuesto por las "clases" que se han identificado en el análisis del negocio. Luego, en otra disciplina, y por tanto modelo, este diagrama conceptual será "traducido" propiamente a un diagrama de clases; finalmente, los modelos de objetos del dominio están asociados a cada uno de los casos de uso del negocio. 

Para el modelado de negocios es crucial estar consciente de las actividades, componentes, fundamentos y requerimientos de la organización en la que se trabaja, ya que de allí es donde se realizarán las conclusiones pertinentes para llevar a cabo las actividades posteriores de la organización.

A la hora de realizar un modelo de negocios, se deben tener en cuenta factores importantes como la identificación y definición de los procesos de negocio según los objetivos de la organización, definición de un caso de uso del negocio para cada proceso del negocio; identificación de los roles implicados en los diferentes procesos del negocio; el modelo de flujo de tareas asociado a cada proceso de negocio mediante escenarios y diagramas de procesos, que muestren la interacción entre roles para conseguir el objetivo; y la especificación las informaciones y actividades incluidas en cada diagrama de actividad.

Como se pudo observar, para el modelo de negocio se necesita una descripción minuciosa y exhaustiva de los elementos y características que lo componen. Estos, a su vez, pueden verse como los requisitos de los cuales consta una organización para realizar un software optimo. Es por ello que es de importancia resaltar la ingeniería de requisitos a la hora de crear distintos software con vida útil.

Definimos a la ingeniería de requisitos como el proceso de desarrollar una especificación de Software. Dichas especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. Además, trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.

Ante esto, podemos dar por seguro que la ingeniería de requisitos es indispensable para gestionar las necesidades del proyecto en forma estructurada, mejorar la capacidad de predecir cronogramas de proyectos, así como sus resultados, disminuir los costos y retrasos del proyecto, además de mejorar la calidad del software y la comunicación entre equipos. La importancia de la ingeniería de requisitos recae en no sólo su minucioso detalle, sino en los beneficios que trae consigo.

Cabe destacar las características de requisitos que dividen esta ingeniería, ya que, al dividirlo en secciones distintas, es más sencillo llevar a cabo el trabajo. Estos tipos se dividen en: funcionales, no-funcionales, otros.

Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito específica algo que el sistema entregado debe ser capaz de realizar.

Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.

Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto

Observamos entonces, que al dividir los tipos de requisitos en diferentes partes se puede simplificar su elección de acuerdo a sus características, funciones, entre otros aspectos.

De igual manera, así como se dividen los requisitos a partir de su funcionalidad u otros aspectos, se hace también a partir de sus tipos. Estas se hacen a partir de distintas modalidades, de maneras textuales y graficas, y con el fin llegar a conclusiones y especificaciones más precisas. Las mismas se denominan como textual, notación grafica y lenguajes de representación como lo son el lenguaje unificado de modelado UML y notación de requerimientos del usuario URN.

Cuando nos referimos al tipo textual, hablamos de la especificación de requisitos que se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. Estos requisitos expresados textualmente se enlazan formando un grafo de trazabilidad el cual se usa para gestionar los requisitos y su trazabilidad. En este enfoque, las especificaciones generadas en las otras actividades del desarrollo de software pueden también ser añadidas al grafo de trazabilidad representándolas como texto.

Por otra parte, cuando hablamos de notación gráfica, incluimos todas las notaciones que pueden demostrar el flujo de información entre requisitos, apoyándose en diversas imágenes. Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace. La más utilizada actualmente es el Lenguaje Unificado de modelado (UML), lo cual nos lleva al último tipo, los lenguajes de representación.

Definimos como lenguaje de representación a un conjunto de etiquetas y atributos válidos y que ofrecen un significado visual para cada elemento del lenguaje, sino que ofrece un número de reglas sintácticas para poder crear documentos. En base a esto, se derivan dos importantes atributos del lenguaje de representación: el Lenguaje Unificado de Modelado (UML) y la Notación de Requerimiento de Usuario (URN).

El lenguaje Unificado de Modelado, conocido también por sus siglas como UML, Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. Es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación.

Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos Los tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.

Finalmente, tenemos la Notación de Requerimiento de Usuario (URN), la cual fue una iniciativa de la Internet Engineering Task Force IETF, la rama de desarrollo de ingeniería y protocolos de Internet, con la premisa de conseguir una forma universal de identificación de recursos, para que cada recurso fuera único y constante. Se trataba de un identificador paralelo al URL.

Una característica importante de este sistema es que trabaja junto con Uniform Resource Characteristics/Citacion (URC), un sistema para la descripción de metadatos. La sintaxis del URN, consta de 3 bloques separados por dos puntos: el identificador URN, el NID o nombre de la categoría en la que se incluye el documento (por ejemplo, inet para documentos de Internet) y el NSS o cadena específica que indica primero la ruta y a continuación el documento concreto.