REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Requisito funcional
Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación. Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema. Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional. Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto. El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

Requisito no funcional
Un requisito no funcional es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guarda r, ni funciones a realizar. Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

Ejemplo
Sistema de Información de Biblioteca podría ser el siguiente:

3. Algunas de las tareas a realizarse en la etapa de diseño son las siguientes: 1. 3. Definir los casos reales de uso. es usando un esquema de análisis y diseño orientado a objetos. Perfeccionar la arquitectura del sistema. Definir los diagramas de interacción. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita. Definir los requerimientos. En este esquema. 5. 6. 6. una descomposición orientada a objetos del Sistema de Información de Biblioteca podría ser la siguiente: Algunas de las tareas a realizarse en la etapa de análisis son las siguientes: 1. Se recomienda aquí definir al menos los siguientes puntos: ‡ Panorama general ‡ Metas ‡ Funciones del sistema ‡ Atributos del sistema a) Panorama general . 2. Definir los casos esenciales de uso. se busca descomponer el problema en objetos. Definir los reportes.Otra forma de realizar la descomposición. 4. Definir los diagramas de diseño de clases. Los requerimientos Los requerimientos son una descripción de las necesidades o deseos de un producto. Crear y perfeccionar los diagramas de casos de uso. la interfaz de usuario y la secuencia de las pantallas. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código barras) y software (el sistema que se ejecuta en la terminal). 2. Definir los diagramas de secuencia de los sistemas. Crear y perfeccionar el glosario. en una forma en que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. 5. Definir el esquema de la base de datos. Crear y perfeccionar el modelo conceptual. 4. Definir los contratos de operaciones. y no en funciones. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Suponga que se nos ha contratado para crear este software. Por ejemplo. 7.

evidente R1.Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo.9 Muestra la descripción y el precio del producto registrado.5 Se registran las ventas efectuadas.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas. b) Metas En términos generales. y su inclusión no repercute significativamente en el costo ni en otras funciones. o usando una captura manual de un código de producto. Para verificar que X es en verdad una función del sistema. ‡ Análisis rápido y exacto de las ventas. ocultas y superfluas. evidente R1. ‡ Control automático del inventario. Las superfluas son opcionales. c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. la meta es una mayor automatización del pago en las cajas registradoras. oculta R1. la siguiente frase deberá tener sentido: ³El sistema deberá hacer X´.2 Calcula el total de la venta actual. Las ocultas también deben realizarse.1 Registra la venta en proceso (actual): los productos comprados. se incluye el impuesto. Las funciones pueden clasificarse en tres categorías: evidentes. y el usuario debe saber que se han realizado. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. oculta R1. evidente R1. Las siguientes son algunas de las funciones más representativas del sistema de punto de venta: Funciones básicas: Referencia Función Categoría R1.4 Reduce las cantidades del inventario cuando se realiza una venta. Por ejemplo: ³el sistema deberá autorizar pagos a crédito´. oculta R1. más baratos y mejores.3 Captura la información sobre el objeto comprado usando su código de barras y un lector.7 Ofrece un mecanismo de almacenamiento persistente. y puede que no sean visibles para el usuario. y dar soporte a servicios más rápidos.6 El cajero debe introducir una identificación y una contraseña para poder utilizar el sistema. oculta R1. evidente Funciones de pago: Referencia Función Categoría . Hay que identificar estas funciones y listarlas en grupos lógicos. evidente R1. la meta incluye: ‡ Pago rápido de los clientes. Más concretamente. Las evidentes deben realizarse.

Por ejemplo: tiempo de respuesta = (dos segundos como máximo) Algunos atributos del sistema de punto de venta son: Atributo Detalles y restricciones de frontera tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido. capturando la información crediticia a partir de una lectora de tarjetas.2 Maneja los pagos a crédito. evidente R2. oculta d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de un formulario y cuadros de diálogo. evidente R2.4 Registra los pagos en el sistema de cuentas por cobrar.1 Maneja los pagos en efectivo. y autorizando los pagos con el servicio de autorización (externo) de cheques de la tienda a través de consulta telefónica. tolerancia a fallas. tiempo de respuesta. tolerancia a fallas (restricción de frontera) Debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas. capturando el número de RUT y teléfono mediante captura manual. Por ejemplo: tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico. es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. plataformas del sistema operativo (detalle) Microsoft Windows 95. confusos o simbólicos. Además. 2000 y NT. metáfora de interfaz. o mediante captura manual. Los atributos tienen un posible conjunto de detalles de atributos. Finalmente.3 Maneja los pagos con cheque. pues el servicio de autorización de crédito debe a la tienda el monto del pago. evidente R2. generalmente en un rango numérico de valores de un atributo. la descripción y el precio aparecerán en un segundo. plataformas. aun cuando se produzcan fallas de energía o del equipo.R2. 98. los detalles de . capturando la cantidad ofrecida y calculando el saldo deudor. que son condiciones obligatorias de frontera . basado en formularios) Algunos atributos del sistema también pueden tener restricciones de frontera del atributo. colorido. y autorizando los pagos con el servicio de autorización (externa) de créditos de la tienda a través de una conexión por modem. los cuales tienden a ser valores discretos. Por ejemplo: facilidad de uso. (detalle) Maximiza una navegación fácil con t eclado y no con mouse.

que las características de esta clase de sistema se encuentran implementadas por medio de la escritura.9 Mostrar la descripción y el precio del producto registrado. para el glosario: Requisito Funcional: característica requerida del sistema que expresa una capacidad de acción del mismo ± una funcionalidad. compilación y ejecución de líneas de código. Un requisito no funcional es una característica ya sea del . por el contrario ellos desean otras cualidades. Por otra parte. entonces se dice que estamos ante un requisito funcional. generalmente expresada en una declaración en forma verbal. si se quieren generalidades. que no son objeto de codificación si bien es cierto que pueden llegar a afectar a esta. Cuando hablamos de una característica requerida de la cual se sabe que va a ser satisfecha por medio de la adición de un subsistema o bloque de código en el software.los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. no todo lo que los clientes nos van a solicitar es funcionalidad pura. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas. obligatorio tiempo de respuesta 10 segundos como máximo obligatorio Tipos de requisitos: Funcional vs.4 Registrar los pagos a crédito en el sistema de cuentas por cobrar. No Funcional 7-07-08 por Iván Garcerant 25 comentarios Generalmente hablamos en este blog de los llamados sistemas intensivos en software. por cuanto es un requisito que denota una funcionalidad del sistema. Es decir. Con colores. por ejemplo. pues el servicio de autorización de crédito debe a la tienda el importe del pago. aun cuando se produzcan fallas de energía o del equipo. donde la funcionalidad esta provista principalmente por la presencia de software apropiadamente programado. Función Categoría Atributo Detalles y restricciones Categoría R1. Llamamos requisito no funcional a todas las exigencias de cualidades que se imponen al proyecto: exigencias de usar un cierto lenguaje de programación o plataforma tecnológica. evidente tiempo de respuesta 1 segundo como máximo obligatorio metáfora de interfaz Pantallas basadas en formularios. Entonces. Por ejemplo: Ref. obligatorio R2.

del proceso de desarrollo. los requisitos funcionales serán mejor representados en un documento o en un caso de uso. pero también ajustados a otros criterios. como el modelo de negocio. no se satisface añadiendo código. Es obvio espero. que la ingeniería del software no solo ha de cumplir con la funcionalidad (escribir código ajustado a los requisitos funcionales) sino también con las cualidad suplementarias (requisitos no funcionales) o de lo contrario no cumplirá con su misión: desarrollar el software que se necesita en el momento y condiciones que se tienen disponibles. sino cumpliendo con esta como si de una restricción se tratara. en tanto que el tamaño del proyecto será lo que haga la diferencia entre tener un documento especifico o un anexo de la visión del sistema. Ahora. o dicho de otra manera. desarrollar software de calidad. que señala una restricción del mismo. del proyecto o del servicio de soporte. como para el glosario: Requisito no funcional: característica requerida del sistema. los recursos disponibles y el tiempo de entrega. Recordemos que el objetivo de la ingeniería del software es el desarrollo de sistemas apegados a las necesidades del cliente. del servicio prestado o de cualquier otro aspecto del desarrollo. que nos es requerida junto con la especificación del sistema pero que como ya dije. Según el tipo de sistema que estemos desarrollando.sistema. .

Sign up to vote on this title
UsefulNot useful