Especificaciones De Requerimientos

“La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después”. La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando 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. Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación. El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: identificación de requisitos, Análisis de requisitos y negociación, Especificación de requisitos, Modelizado del sistema, Validación y gestión de requisitos.

El Lenguaje Unificado de Modelado (UML)

Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los diseños de forma gráfica. Desde los inicios de  la  informática  se han estado utilizando distintas formas de representar los diseños de una forma más bien personal o con algún modelo gráfico.La falta de estandarización  en la manera de representar gráficamente  un  modelo impedía que los diseños gráficos realizados se pudieran compartir  fácilmente  entre distintos diseñadores. Se necesitaba por tanto un  lenguaje  no sólo  para comunicar las ideas a otros desarrolladores sino también para servir de  apoyo en los procesos de análisis de un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML:  Unified Modeling Language). UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.

¿QUÉ ES UML?

UML es ante todo un  lenguaje. Un  lenguaje proporciona un vocabulario y una  reglas  para  permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Este lenguaje nos indica cómo crear y leer los modelos, pero no dice  cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.

MODELADO VISUAL

Tal  como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema  es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual. El modelado visual permite manejar la  complejidad de los sistemas a analizar o diseñar.

• Construir: A partir de los modelos  especifica- • Diagrama de colaboración.

dos se pueden construir los sistemas diseñados.

• Diagrama de estados.

• Documentar: Los propios  elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura  revisión.

DIAGRAMAS UML

incluye los siguientes diagramas:

• Diagrama de casos de uso.
• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.
• Diagrama de colaboración.
• Diagrama de estados.
• Diagrama de actividades.
• Diagrama de componentes.
• Diagrama de despliegue.

El URN

 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, explicada en la RFC2141 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. Lo interesante de URN es que puede subsumir todos los identificadores bibliográficos existentes tales como ISSN (International Standard Serial Number) para publicaciones seriadas,ISBN (International Standard Books Number) para libros y SICI (Serial Item and Contribution Identifier) que identifica no sólo la revista, sino también el número de un publicación seriada. El primitivo URN, junto con el identificador URL, ha sido uno de los pilares para la creación del URI, que se está convirtiendo en el identificador global más utilizado, ya que engloba a ambos.

Requerimientos del usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar. Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.

ArgoUML 

Argo UML es la principal herramienta libre de modelado UML, incluye el apoyo a todos los estándares de diagramas UML 1.4. Es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java. El Magazine de Desarrollo de Software entrega premios anuales a herramientas de desarrollo de software populares en varias categorías. En 2003 ArgoUML fue una de las finalistas en la categoría "Design and Analysis Tools". ArgoUML recibió un premio "runner-up"(revelación), derrotando a muchas herramientas comerciales.

La licencia BSD 
es la licencia de software otorgada principalmente para los sistemas BSD (Berkeley Software Distribution). Es una licencia de software libre permisiva como la licencia de OpenSSLo la MIT License. Esta licencia tiene menos restricciones en comparación con otras como la GPL estando muy cercana al dominio público. La licencia BSD al contrario que la GPL permite el uso del código fuente en software no libre.

Los Requisitos y la Calidad de Software

Recientemente, durante un taller de requisitos que estoy dictando, surgió la inquietud de qué tipos de requisitos afectan la calidad del software. Por un lado se aseguraba que la calidad estaba definida por los requisitos no funcionales, mientras que por otro lado se aseguraba que ambos tipos de requisitos afectaban la calidad del producto. La confusión, sobre todo, se encontraba en lo que se conoce como necesidades implícitas y explicitas. A continuación reúno algunas definiciones que ayudan a aclarar el tema.
Según el SWEBOK, los requisitos funcionales “... describen las funciones que el sistema ejecutará: por ejemplo la aplicación de un formato a un texto o la modulación de una señal. “Los requisitos no funcionales son aquellos que actúan como restricciones para la solución. Los requisitos no funcionales algunas veces se conocen como requisitos de restricción o requisitos de calidad”.

Estándares en la documentación del análisis

Significa que los símbolos convencionales se usan en todos los diagramas de flujo para prescribir el sistema y que en la documentación se usen formas estandarizadas. Aún cuando las normas de documentación varían de una instalación a otra, es esencial que dentro de una organización, se utilice un solo método. El uso de procedimientos y documentación estandarizada proporciona la base de una comunicación clara y rápida, adiestramiento menos costoso del personal de sistemas, reducción de costos de almacenamiento, y otros.

Ventajas De La Estandarización

Ayuda al entrenamiento del nuevo personal dentro y fuera de la organización de Sistemas. Es útil para cualquiera que tenga la responsabilidad del mantenimiento de los sistemas. Ayuda a los analistas y diseñadores de sistemas en el trabajo de integración de sistemas. Asegura que el sistema opere correctamente. Se utilizan eficientemente los recursos que se dispongan.

Requerimientos Funcionales Y No Funcionales

La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposición (divide y vencerás). La estrategia es dividir el problema en unidades más pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue el análisis y diseño estructurados, donde se trata de descomponer el problema en funciones o procesos. Este método origina una división jerárquica de procesos constituidos por sub-procesos. Por ejemplo, una descomposición por funciones o procesos en análisis y diseño estructurados, de un Sistema de Información de Biblioteca podría ser el siguiente:

Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. 

Algunas de las tareas a realizarse en la etapa de análisis son las siguientes

1. Definir los requerimientos.

2. Definir los casos esenciales de uso.

3. Crear y perfeccionar los diagramas de casos de uso.

4. Crear y perfeccionar el modelo conceptual.

5. Crear y perfeccionar el glosario.

6. Definir los diagramas de secuencia de los sistemas.

7. Definir los contratos de operaciones.

Algunas de las tareas a realizarse en la etapa de diseño son las siguientes:

1. Definir los casos reales de uso.

2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.

3. Perfeccionar la arquitectura del sistema.

4. Definir los diagramas de interacción.

5. Definir los diagramas de diseño de clases.

6. Definir el esquema de la base de datos.

Requerimiento de Dominio

Cuando hablamos de dominio en diseño nos referimos a aquella parte del diseño que es particular al problema que se quiere resolver. Desafortunadamente, por su misma naturaleza, es imposible ofrecer una metodología precisa debido a que cada caso es diferente. Los requerimientos de dominio (particulares) para una página web pueden ser muy diferentes de los de dominio (particulares) para un antivirus, razón por la cual la mayoría de los autores omiten ahondar en ese tema.

Por ejemplo, la mayoría de los armazones de desarrollo de aplicaciones (por ejemplo, las MFC y .NET) te ofrecen "casi todo", menos las clases de dominio, cuyos requerimientos debes tú especificar (como Dios te dé a entender) para desarrollar una aplicación de utilidad.

Atributos De Calidad Del Software

Se pueden tomar estos atributos de en base a un punto vista definido, por ejemplo a la adecuación de los requerimientos funcionales o a la satisfacción de cliente.
Disponibilidad o Está relacionada con la confiabilidad por ejemplo cuando una aplicación no está disponible cuando se necesita no cumple con las expectativas ni los requerimientos funcionales de la misma.

· Modificalidad o Se refiere a que tan fácil es modificar la aplicación y con ello cambiar el comportamiento del software.

· Performance o Generalmente este atributo se puede medir en unidades de rendimiento de procesos (Throughput), tiempo de respuesta y retardos.

 · Seguridad o Se refiere a los permisos de acceder a ciertos procesos de la aplicación y para eso requiere autenticación, autorización y algún nivel de encriptación.