ESPECIFICACIÓN DE REQUERIMIENTOS

TEXTUAL, NOTACIÓN GRÁFICA Y LENGUAJES DE REPRESENTACIÓN (LENGUAJE UNIFICADO DE MODELADO UML), NOTACIÓN DE REQUERIMIENTOS DE USUARIO URN.

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema
Lenguaje de Modelado Unificado (UML)

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. [Enciclopedia Online Wikipedia, 2008c]

Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software, pero no especifica en sí mismo qué metodología o proceso usar.

Los requerimientos deusuario son para el usode la gente relacionadacon la utilización yobtención del sistema.Debe ser redactada conun lenguaje natural con diagramas y tablas

TECNICAS PARA ESCRIBIR REQUERIMIENTOS DE ALTA CALIDAD. ESTANDARES DE DOCUMENTACIÓN

Una buena documentación es esencial para lograr un diseño correcto y un mantenimiento eficiente de los sistemas digitales. Además de ser precisa y completa, la documentación debe ser algo instructiva, de modo que un ingeniero de pruebas, técnico de mantenimiento, o inclusive el ingeniero de diseño original (seis meses después de diseñar el circuito), pueda averiguar como funciona el sistema con solo leer la documentación.

Aunque el tipo de documentación depende de la complejidad del sistema y los entornos en los que se realizan el diseño y la fabricación, un paquete de documentación debe contener (por regla general) al menos los siguientes seis elementos:

1.Una especificación de circuito que se describe exactamente lo que se supone debe hacer el circuito o sistema, incluyendo una descripción de todas las entradas y las salidas (“interfaces”) y las funciones que se van a realizar. Advierta que las “especificaciones” no tienen que especificar como consigue el sistema sus resultados, sino únicamente que resultados genera.

2. Un diagrama de bloques es una descripción pictórica e informal de los principales módulos funcionales del sistema y sus interconexiones básicas.

3. Un diagrama esquemático es una especificación formal de los componentes eléctricos del sistema, sus interconexiones y todos los detalles necesarios para construir el sistema, incluyendo los tipos de CI, indicadores de referencia y números terminales. Se suelen utilizar el término diagrama lógico para referirse a un dibujo informal que no tiene este nivel de detalle. La mayoría de los programas para edición de esquemáticos tiene la capacidad de generar en cuenta de materiales a partir del diagrama esquemático.

4. Un diagrama de temporización muestra los valores de diversas señales lógicas en función del tiempo, incluyendo los retardos, entre causa y efecto, de las señales críticas.

5. Una descripción de dispositivo de lógica estructurada que indica la función interna de un PLD, FPGA o ASIC. Normalmente esta descripción se describe en un lenguaje de descripción hardware (HDL) tal como VHDL O ABEL, pero puede estar en forma de ecuaciones lógicas, tablas de estado o diagramas de estado. En algunos casos se pueden utilizar un lenguaje de programación convencional, como C, para modelar el funcionamiento de un circuito o para especificar su comportamiento.

6. Una descripción del circuito en un documento de texto narrativo que, junto con el resto de la documentación, explica como funciona internamente el circuito. En el caso de que la maquina de estado debe describirse mediante tablas de estado, diagramas de estado, lista de transiciones o archivo de texto en un lenguaje de descripción de maquinas de estado como ABEL o VHDL. La descripción del circuito debe incluir cualquier suposición y cualquier fallo potencial en el diseño y operación del circuito, también debe señalar el uso de cualquier “truco” de diseño que no sea obvio. Una buena descripción de circuito también contiene definiciones de acrónimos y otros términos especializados y tiene referencias o documentos relacionados.

TIPOS DE REQUERIMIENTOS

Requerimientos funcionales

Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.

Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general.

DEL 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.