Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Requisito funcional
Un requisito funcional define el comportamiento interno del software: clculos, detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo los casos de uso sern llevados a la prctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseo o la implementacin. Como se define en la ingeniera de requisitos, los requisitos funcionales establecen los comportamientos del sistema. Tpicamente, 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 diseo de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional. Un requisito funcional tpico contiene un nombre y un nmero de serie nico y un resumen. Esta informacin 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 ncleo del requisito es la descripcin del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interaccin con usuarios, inversores y otros expertos en la organizacin.
Requisito no funcional
Un requisito no funcional es, en la ingeniera de sistemas y la ingeniera de software, un requisito que especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guarda r, ni funciones a realizar. Los requisitos no funcionales ms habituales son la estabilidad, la portabilidad y el costo.
Ejemplo
Sistema de Informacin de Biblioteca podra ser el siguiente:
Otra forma de realizar la descomposicin, es usando un esquema de anlisis y diseo orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposicin orientada a objetos del Sistema de Informacin de Biblioteca podra ser la siguiente: Algunas de las tareas a realizarse en la etapa de anlisis son las siguientes: 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los contratos de operaciones. Algunas de las tareas a realizarse en la etapa de diseo son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas. 3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interaccin. 5. Definir los diagramas de diseo de clases. 6. Definir el esquema de la base de datos. Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de cdigo barras) y software (el sistema que se ejecuta en la terminal). Suponga que se nos ha contratado para crear este software. Los requerimientos Los requerimientos son una descripcin de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fcilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aqu definir al menos los siguientes puntos: Panorama general Metas Funciones del sistema Atributos del sistema a) Panorama general
Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizar en las ventas al menudeo. b) Metas En trminos generales, la meta es una mayor automatizacin del pago en las cajas registradoras, y dar soporte a servicios ms rpidos, ms baratos y mejores. Ms concretamente, la meta incluye: Pago rpido de los clientes. Anlisis rpido y exacto de las ventas. Control automtico del inventario. c) Funciones del sistema Las funciones del sistema son lo que ste deber de hacer. Hay que identificar estas funciones y listarlas en grupos lgicos. Para verificar que X es en verdad una funcin del sistema, la siguiente frase deber tener sentido: El sistema deber hacer X. Por ejemplo: el sistema deber autorizar pagos a crdito. Las funciones pueden clasificarse en tres categoras: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas tambin deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (errneamente) durante el proceso de obtencin de requerimientos. Las superfluas son opcionales, y su inclusin no repercute significativamente en el costo ni en otras funciones. Las siguientes son algunas de las funciones ms representativas del sistema de punto de venta: Funciones bsicas: Referencia Funcin Categora R1.1 Registra la venta en proceso (actual): los productos comprados. evidente R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente R1.3 Captura la informacin sobre el objeto comprado usando su cdigo de barras y un lector, o usando una captura manual de un cdigo de producto. evidente R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta R1.5 Se registran las ventas efectuadas. oculta R1.6 El cajero debe introducir una identificacin y una contrasea para poder utilizar el sistema. evidente R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta R1.8 Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas. oculta R1.9 Muestra la descripcin y el precio del producto registrado. evidente Funciones de pago: Referencia Funcin Categora
R2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. evidente R2.2 Maneja los pagos a crdito, capturando la informacin crediticia a partir de una lectora de tarjetas, o mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externa) de crditos de la tienda a travs de una conexin por modem. evidente R2.3 Maneja los pagos con cheque, capturando el nmero de RUT y telfono mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externo) de cheques de la tienda a travs de consulta telefnica. evidente R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el monto del pago. oculta d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metfora de interfaz, plataformas. Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simblicos. Por ejemplo: tiempo de respuesta = (psicolgicamente correcto) metfora de interfaz = (grfico, colorido, basado en formularios) Algunos atributos del sistema tambin pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera , generalmente en un rango numrico de valores de un atributo. Por ejemplo: tiempo de respuesta = (dos segundos como mximo) Algunos atributos del sistema de punto de venta son: Atributo Detalles y restricciones de frontera tiempo de respuesta (restriccin de frontera) Cuando se registre un producto vendido, la descripcin y el precio aparecern en un segundo. metfora de interfaz (detalle) Ventanas orientadas a la metfora de un formulario y cuadros de dilogo. (detalle) Maximiza una navegacin fcil con t eclado y no con mouse. tolerancia a fallas (restriccin de frontera) Debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. plataformas del sistema operativo (detalle) Microsoft Windows 95, 98, 2000 y NT. Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Adems, los detalles de
los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo: Ref. Funcin Categora Atributo Detalles y restricciones Categora R1.9 Mostrar la descripcin y el precio del producto registrado. evidente tiempo de respuesta 1 segundo como mximo obligatorio metfora de interfaz Pantallas basadas en formularios. Con colores. obligatorio R2.4 Registrar los pagos a crdito en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el importe del pago. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. obligatorio tiempo de respuesta 10 segundos como mximo obligatorio
sistema, del proyecto o del servicio de soporte, que nos es requerida junto con la especificacin del sistema pero que como ya dije, no se satisface aadiendo cdigo, sino cumpliendo con esta como si de una restriccin se tratara. Ahora, como para el glosario: Requisito no funcional: caracterstica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que seala una restriccin del mismo. Segn el tipo de sistema que estemos desarrollando, los requisitos funcionales sern mejor representados en un documento o en un caso de uso; en tanto que el tamao del proyecto ser lo que haga la diferencia entre tener un documento especifico o un anexo de la visin del sistema. Recordemos que el objetivo de la ingeniera del software es el desarrollo de sistemas apegados a las necesidades del cliente, pero tambin ajustados a otros criterios, como el modelo de negocio, los recursos disponibles y el tiempo de entrega. Es obvio espero, que la ingeniera del software no solo ha de cumplir con la funcionalidad (escribir cdigo ajustado a los requisitos funcionales) sino tambin con las cualidad suplementarias (requisitos no funcionales) o de lo contrario no cumplir con su misin: desarrollar el software que se necesita en el momento y condiciones que se tienen disponibles; o dicho de otra manera, desarrollar software de calidad.