NOTACIN DE LOS REQUERIMIENTOS DE USUARIO (URN).

Textual:

Tradicionalmente la especificacin de requisitos se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. Las herramientas de apoyo a la gestin de requisitos se han enfocado a la manipulacin de trozos de texto. 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 tambin ser aadidas al grafo de trazabilidad representndolas como texto.

Notacin grfica:

Incluye todas las notaciones que pueden demostrar el flujo de informacin entre requisitos apoyndose en diversas imgenes. Estas notaciones permiten al usuario del sistema tener mayor comprensin del software lo que hace y como lo hace. La ms utilizada actualmente es el Lenguaje Unificado de modelado (UML). Otra notacin que se puede usar es la notacin de requerimientos de usuario (URN).

UML:

Es un lenguaje para la especificacin, visualizacin, construccin y documentacin de los artefactos de un proceso de sistema intensivo. UML, emergi en los aos 90 luego de la bsqueda de un lenguaje de modelamiento que unificara a la industria. A pesar de que UML evolucion de varios mtodos orientados al objeto de segunda generacin (en nivel de notacin), su alcance extiende su uso ms all de sus predecesores.

UML es usado para la comunicacin. Es decir, un medio para capturar el conocimiento (semnticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propsito de la comunicacin. Como un lenguaje para modelamiento, se enfoca en la comprensin de un tema a travs de la formulacin de un modelo del tema (y su contexto respectivo). Cuidando la unificacin, integra las mejores prcticas de la ingeniera de la industria tecnolgica y sistemas de informacin pasando por todos Los tipos de sistemas y los procesos de ciclo de vida.

UML se aplica para especificar sistemas, puede ser usado para comunicar "qu" se requiere de un sistema y "cmo" un sistema puede ser realizado. Se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado. Puede ser usado para guiar la realizacin de un sistema similar a los "planos". Asimismo puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida.

URN:

Fue una iniciativa de la Internet Engineering Task Force IETF, la rama de desarrollo de ingeniera y protocolos de Internet, con la premisa de conseguir una forma universal de identificacin de recursos, para que cada recurso fuera nico y constante. Se trataba de un identificador paralelo al URL. Una caracterstica importante de este sistema es que trabaja junto con Uniform Resource Characteristics/Citacion (URC), un sistema para la descripcin de metadatos. La sintaxis del URN, consta de 3 bloques separados por dos puntos: el identificador URN, el NID o nombre de la categora en la que se incluye el documento (por ejemplo, inet para documentos de Internet) y el NSS o cadena especfica que indica primero la ruta y a continuacin el documento concreto. URN es una notacin pensada para la especificacin, anlisis y validacin de los requisitos de usuario. URN combina dos vistas complementarias: una para definir los objetivos del sistema usando el Goal-oriented Requirement Language (GRL) y otra para definir los escenarios de uso con la notacin Use Case Map (UCM).

TCNICAS PARA ESCRIBIR REQUERIMIENTOS DE ALTA CALIDAD, ESTNDARES DE DOCUMENTACIN.

En todas las tcnicas involucradas en la ingeniera de requerimientos, las actividades y caractersticas resaltantes para obtener o escribir requerimientos de alta calidad son los siguientes:

Identificar las clases de usuario del producto esperado.

Extraer las necesidades de los individuos que representan cada clase de usuario.

Comprender las tareas y metas del usuario y los objetivos de negocio con los que esas tareas se alinean.

Analizar la informacin recibida de los usuarios para distinguir sus objetivos de tarea de requerimientos funcionales, requerimientos no-funcionales, reglas de negocio, y otros.

Destinar partes de los requerimientos de alto nivel a definir componentes de software en la arquitectura sistema.

Comprender la importancia de los atributos de calidad.

Negociar las prioridades de implementacin.

Traducir las necesidades de usuario escritas dentro de las especificaciones y modelos de requerimientos.

Examinar los requerimientos documentados para asegurar el conocimiento comn de los requerimientos presentados por los usuarios y corregir cualquier problema antes de que el grupo de desarrolladores los acepte.

Definir el punto de partida de los requerimientos.

Revisar y evaluar el impacto de cada requerimiento cambiado antes de aprobarlo.

Seguir cada requerimiento en su diseo, cdigo fuente y pruebas.

Agrupar los requerimientos segn rendimiento y actividad de cambio durante todo el proyecto.

La iteracin es una clave para el xito del desarrollo de los requerimientos.

El documento de los requerimientos de software es la declaracin oficial de qu es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificacin detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una nica descripcin. En otros, los del usuario se definen en una introduccin de la especificacin de los del sistema. Si existe un gran nmero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados.

El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organizacin, quienes pagan por el sistema, hasta los ingenieros responsables del software. Una gran variedad de organizaciones han definido estndares para los documentos de requerimientos. Por ejemplo la IEEE sugiere la siguiente estructura para los documentos de requerimientos.

1. Introduccin, propsito del documento de requerimientos, Alcance del producto, Definiciones, acrnimos y abreviaturas, Referencias, Resumen del resto del documento.

2. Descripcin general, Perspectiva del producto, Funciones del producto, caractersticas del usuario, Restricciones generales, Suposiciones y dependencias.

3. Requerimientos especficos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, sta es la parte ms sustancial del documento, pero debido a la amplia variabilidad en la prctica organizacional, no es apropiado definir una estructura estndar para esta seccin. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeo del sistema, especificar los requerimientos lgicos de la base de datos, las restricciones de diseo, las propiedades emergentes del sistema y las caractersticas de calidad.

TCNICA JAD (DISEO DE APLICACIN CONJUNTA).

JAD es una tcnica de definicin de requisitos y de diseo de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunin los temas a tratar se centran ms en el negocio que en el asunto tcnico. Est orientado a proyectos de cliente (o bien sistemas a medida, como tambin se les conoce), y permite recolectar requisitos eficientemente. Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa realidad en cuanto al progreso del proyecto o la productividad. Adems, hay que prestar especial cuidado con las estimaciones tempranas, aquellas que entraan un mayor riesgo por el mayor desconocimiento del sistema y que deben ofrecer una amplitud de rango mayor entre mejor estimacin y estimacin pesimista. Esta tcnica sale beneficiada si se utiliza en modelos incrementales, ya que permite pulir poco a poco el sistema en funcin de las necesidades del cliente. Para su buen funcionamiento es fundamental que cada grupo o rol que participa en las reuniones se implique al mximo. Bien utilizada, esta tcnica permite ver conflictos entre requisitos y eliminar aquellos menos tiles (costosos, poco beneficio o rendimiento logrado, etc.).

La estructura de la tcnica JAD consta de dos fases: planificacin y diseo. Ambas tratan los requisitos, pero a distinto nivel de abstraccin. Si bien en planificacin se tratan los requisitos a un nivel ms alto, estudiando sobre todo la utilidad y la viabilidad de los mismos, en la fase de diseo se realiza un uso intensivo de prototipos y se disea la interfaz de usuario, el presupuesto, la calendarizacin y el esquema de la base de datos (en caso de que esto ltimo sea aplicable al sistema a tratar). Cada una de estas fases llevara en torno a uno y diez das. No confundir la fase diseo-JAD con la fase de diseo del proyecto; JAD es una tcnica que se aplicara en fase de planificacin y anlisis. Cada fase, adems, consta de tres partes: preparacin (decidir quin asistir a cada reunin), sesin o reunin propiamente dicha y conclusin, donde se extraen los principales puntos consensuados durante la sesin y se plasman en algn soporte permanente. El papel est bien, no caigamos ya en la tecnofilia, siempre que sea un soporte permanente, accesible por todos y, sobre todo, refleje un consenso aceptado por todas las partes. Algo as como un contrato. Una vez terminado el proceso de JAD, se sigue con el modelo de desarrollo elegido. Es decir, JAD es independiente del modelo de desarrollo, con lo cual es aplicable siempre. Las sesiones tendrn lugar en lugares apartados, neutrales (s, esto es la guerra: t junta clientes, directivos y desarrolladores y no dejes a mano armas de fuego ni blancas o presenciars una cutre pelcula gore). Adems se facilitar todo lo necesario para centrarse en el trabajo: piscolabis, refrescos, nolotiles, aspirinas, etc.

TCNICA FPA (ANLISIS DE PUNTOS DE FUNCIN).

Es un mtodo utilizado en ingeniera del software para medir el tamao del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin es til en cualquiera de las fases de vida del software, desde el diseo inicial hasta la explotacin y mantenimiento. Existen diferentes metodologas de medicin, de las cuales la ms popular es la mantenida por el International Function Point Users Group (IFPUG).

Se emplea para establecer el tamao y complejidad de los sistemas informticos, basada en la cantidad de funcionalidad requerida y entregada a los usuarios. Los Puntos de Funcin miden el tamao lgico o funcional de los proyectos o aplicaciones de software basado en los requerimientos funcionales del usuario. Para entender las caractersticas de la mtrica, se definen los siguientes conceptos:

Tamao: Es una mtrica de tamao, no de la calidad con la que se hizo ese software, o del valor de ese producto, o del esfuerzo requerido para desarrollarlo.

Aplicaciones: Mide las aplicaciones de software, no considera el hardware que utilizar, ni la administracin del proyecto, ni la documentacin.

Funcionalidad: Se refiere a la capacidad del software para que un usuario pueda realizar transacciones (lectura, escritura y el guardar datos). Si analizamos a detalle, con estos elementos podemos describir cualquier sistema.

Usuario: Quien lo va a usar y no quien lo desarroll o quien lo dise.

Ventajas de la tcnica FPA:

Mide lo que el usuario pide y lo que el usuario recibe.

Medir independientemente de la tecnologa utilizada en la implantacin del sistema.

Se aplica a los productos obtenidos a lo largo de todo el ciclo de desarrollo. Por lo tanto, se pueden refinar a medida que se avanza en el proceso, aumentando la precisin de las mediciones.

Consiste en la disponibilidad de una estimacin del tamao del producto a construir en una etapa muy temprana del proyecto de desarrollo. Esto permite anticipar una amplia gama de decisiones, es decir, entre desarrollar o comprar un producto de software y especialmente cuando se estudia el reemplazo de un sistema en funcionamiento.

Propone la aplicacin de estos mtodos a partir de la especificacin de requerimientos y se menciona la importancia de disponer de contabilizaciones de Puntos Funcin (FP) en las etapas inciales del desarrollo, as como, las ventajas de medir FP en los requerimientos y disponer de un marco de referencia adicional para verificar la completitud de los requerimientos funcionales.

Desventajas de la tcnica FPA:

Resulta arduo formar al personal en su utilizacin y ms todava mantener unos criterios homogneos de recuento.

Carece de precisin cuando se trata de proyectos pequeos. Por debajo de unos 100 pf resulta poco fiable.

Para resultar realmente til, una organizacin de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.

El factor de ajuste calculado a partir de las caractersticas generales del sistema resulta de dudosa utilidad.