Objetivo 2: Especificación de los requerimientos.
Textual.
Tradicionalmente la especificación de requisitos se ha realizado usando sobre todo especificaciones textuales en lenguaje natural.
Las herramientas de apoyo a la gestión de requisitos se han enfocado a la manipulación 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 también ser añadidas al grafo de trazabilidad representándolas como texto.
Notación grafica.
Incluye todas las notaciones pueden demostrar el flujo de información entre requisitos apoyándose en diversas imágenes.
Estas notaciones permiten al usuario del sistema tener mayor compresión del software lo que hace y como lo hace.
La más utilizada actualmente es el lenguaje unificado de modelado (UML).
Otra notación que se puede usar es la notación de requerimiento de usuarios (URN).
UML (Lenguaje Unificado de Modelado).
Es un lenguaje para especificar, visualizar, construir y documentar los elementos de un sistema software, así como para modelado de procesos de negocio u otros sistemas no-software. UML reúne una colección de las mejores prácticas en la ingeniería que han sido utilizadas con éxito para modelar sistemas grandes y complejos.
Notación de los requerimientos de 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.
Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de claridad, confusión de requerimientos y conjunción de requerimientos.
Aplicación basada en el software libre para trabajar con UML.
Software Libre para Modelado en UML.
• Poseidon for UML, Herramienta de modelado UML escrita en java que cuenta con una completa versión gratuita denominada Community Edition.
• Día, Puede ser usado para modelar varios tipos de diagramas UML.
• gModeler, Herramienta para modelado de UML basada en Flash (utilizable desde el navegador), que permite generar codigo Action Script 2.0 Compatible.
Técnicas para escribir requerimientos de alta calidad, estándares de documentación.
.
• Uso de estándares de documentación de requisitos
• • IEEE 830-1998
• • IEEE P1233/D3
• • ISO/IEC 12119-1994
• • IEEE 1362-1998
• Indicadores de Calidad
• • Modelo de Calidad del Software (Marco ISO 9126)
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.
Requerimientos del dominio
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.
Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
Atributos de Calidad
Expresan las propiedades de calidad que el sistema debe satisfacer.
• El rendimiento que la aplicación debe tener.
• La confiabilidad que debe poseer.
• La seguridad que debe proveer.
• La utilidad que debe garantizar.
No hay comentarios:
Publicar un comentario