I
INSTITUTO TECNOLÓGICO SUPERIOR DE LA MONTAÑA
INGENIERÍA EN SISTEMAS COMPUTACIONALES
DOCENTE: MTI. MAURO CASTRO RODRÍGUEZ
ASIGNATURA: INGENIERÍA DE REQUERIMIENTOS TIPOS DE REQUERIMIENTOS
PRESENTA: MELO MARTÍNEZ JULIETA CECILIA GARCÍA CORTES
7° “A”
TLAPA DE COMONFORT, GRO. A 30 DE SEPTIEMBRE DE 2014
Requerimientos funcionales y no funcionales A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio: Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Puede mostrar documentos en diferentes formatos; la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. Sin embargo, el requerimiento está ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada formato. Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y afirmar que se ha cumplido el requerimiento. En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud. Una razón de esto es que es fácil cometer errores y omisiones cuando se redactan especificaciones para sistemas grandes y complejos. Otra razón es que los stakeholders del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es posible que los problemas surjan solamente después de un análisis más profundo o, a veces, después de que se termine el desarrollo y el sistema se entregue al cliente.
Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema. Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la
fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo, el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir. Los requerimientos no funcionales surgen de las necesidades 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 software o hardware, o a factores extremos como regulaciones de seguridad o legislaciones sobre privacidad. La Figura 6.3 es una clasificación de los requerimientos no funcionales. Puede verse en este diagrama que los requerimientos no funcionales pueden venir de las características requeridas del software (requerimientos del producto), de la organización que desarrolla el software (requerimientos organizacionales) o de fuentes externas.
Los tipos de requerimientos no funcionales son: 1. Requerimientos del producto. Estos requerimientos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez de ejecución del sistema y cuánta memoria se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad, y los requerimientos de usabilidad. 2. Requerimientos organizacionales. Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos ejemplos son los estándares en los procesos que deben utilizarse; los 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. 3. Requerimientos externos. Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Éstos pueden incluir los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con sistemas de otras organizaciones; los requerimientos legislativos que deben seguirse para asegurar que el sistema funcione dentro de la ley, y los requerimientos éticos. Estos últimos son puestos en un sistema para asegurar que será aceptado por sus usuarios y por el público en general. Requerimientos del usuario Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento técnico detallado. Únicamente deben especificar el comportamiento externo del sistema y deben evitar, tanto como sea posible, las características de diseño del sistema. Por consiguiente, si se están redactando requerimientos del usuario, no se debe utilizar jerga del software, notaciones estructuradas o formales, o describir los requerimientos por la descripción de la implementación del sistema. Deben redactarse en un lenguaje sencillo, con tablas y formularios sencillos y diagramas intuitivos.
Problemas que surgen cuando se redactan con frases del lenguaje natural en un documento de texto: 1. Falta de claridad. Algunas veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer. 2. Confusión de requerimientos. No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño. 3. Conjunción de requerimientos. Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento. La primera frase mezcla tres diferentes clases de requerimientos. 1. Un requerimiento funcional conceptual que establece que el sistema de edición debe proporcionar una cuadrícula. Se presenta la justificación de esto. 2. Un requerimiento no funcional que proporciona información detallada de las unidades de la cuadrícula (centímetros o pulgadas). 3. Un requerimiento de interfaz de usuario no funcional que define la manera en que la cuadrícula es activada o desactivada por el usuario.
Para minimizar los malentendidos al redactar los requerimientos del usuario, se recomienda seguir algunas pautas sencillas: 1. Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al formato. Estandarizar el formato hace que las omisiones sean menos probables y los requerimientos más fáciles de verificar. El formato utilizado muestra el requerimiento inicial en negrita, incluyendo una declaración del fundamento con cada requerimiento del usuario y una referencia a la especificación más detallada de los requerimientos del sistema. También se puede incluir información sobre quién propuso el requerimiento (la fuente del requerimiento), de modo que se sepa a quién consultar si se tiene que cambiar el requerimiento. 2. Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los requerimientos deseables y los obligatorios. Los requerimientos obligatorios son los requerimientos a los que el sistema debe dar soporte y normalmente se redactan en futuro simple. Los requerimientos deseables no son fundamentales y se redactan en futuro condicional. 3. Resaltar el texto (con negrita, cursiva o color) para distinguir las partes clave del requerimiento. 4. Evitar, hasta donde sea posible, el uso de jerga informática. Sin embargo, inevitablemente se incluirán términos técnicos detallados en los requerimientos del usuario.
Requerimientos del sistema Es el punto de partida para el diseño del sistema. Se agregan detalle y explican cómo el sistema debe proporcionar los requerimientos del usuario. Pueden ser utilizados como parte del contrato para la implementación del sistema y, por lo tanto, deben ser una especificación completa y consistente del sistema entero. Sin embargo, en el nivel de detalle requerido para especificar completamente un sistema software complejo, es imposible, en la práctica, excluir toda la información de diseño. Existen varias razones para esto: 1. Puede tener que diseñar una arquitectura inicial del sistema para ayudar a estructurar la especificación de requerimientos. Los requerimientos del sistema se organizan conforme a los diferentes subsistemas que componen el sistema. 2. En muchos casos, los sistemas deben inter operar con otros ya existentes. Esto restringe el diseño, y estas restricciones imponen requerimientos en el sistema nuevo. 3. Es necesario el uso de una arquitectura específica para satisfacer los requerimientos no funcionales (como la programación por n versiones para conseguir fiabilidad. Un regulador externo que necesita certificar que el sistema es seguro puede especificar que un diseño arquitectónico que ya ha sido certificado sea utilizado. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.
