REQUERIMEINTOS DE SW

ESPECIFICACION DE REQUISITOS

• Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de usos que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales. (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
• Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

REQUERIMIENTOS

• Los requerimientos para un sistema son La descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos.
• Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre estos diferentes niveles de descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario y requerimientos del sistema

CARACTERÍSTICAS DE UNA BUENA ERS

• No ambigua: Una ERS es no ambigua si y solo si cada requisito tiene una única interpretación.
• Completa: Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
• Consistente: Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
• Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.
• Correcta: El software debe cumplir con los requisitos de la especificación.
• Trazable: Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
• Priorizable: Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
• Modificable: Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
• Verificable: Debe existir un método finito sin costo para poder probarlo.

REQUERIMIENTOS DEL USUARIO

• Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
• Necesidades que los usuarios expresan verbalmente.

REQUERIMIENTOS DEL SISTEMA

• Establecen con detalle las funciones. Servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificación funcional) debe ser preciso. Debe definir exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el comprador del sistema y los desarrolladores del software.
• Son los componentes que el sistema debe tener para realizar determinadas tareas.

REQUERIMIENTOS FUNCIONALES

• Servicios que el sistema debe proporcionar, son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este 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 declaran explícitamente lo que el sistema no debe hacer.
• Ejemplos de requerimientos funcionales de proceso o área de negocio El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente. Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos. Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema. El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de proyecto. El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto.

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.
• Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente se aplican a características o servicios individuales del sistema
• 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 fuente externas
• Requerimiento 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.
• 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.
• 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.

REQUERIMIENTOS DEL DOMINIO

• características y restricciones de ese dominio pueden ser funcionales o no funcionales. Estos últimos son puestos en un sistema para asegurar que será aceptado por sus usuarios y por el público en general

REQUISITO FUNCIONAL IEE830

• Definición de acciones fundamentales que debe realizar el software al recibir información, procesarla y producir resultados.
• En ellas se incluye:
• ♣ Comprobación de validez de las entradas
• ♣ Secuencia exacta de operaciones
• ♣ Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperación de errores)
• ♣ Parámetros
• ♣ Generación de salidas
• ♣ Relaciones entre entradas y salidas (secuencias de entradas y salidas, fórmulas para la conversión de información)
• ♣ Especificación de los requisitos lógicos para la información que será almacenada en base de datos (tipo de información, requerido)

REQUISITO NO FUNCIONAL IEE830

• Rendimiento, Seguridad, Fiabilidad, Disponibilidad, Mantenibilidad, Portabilidad, Otros.
• Rendimiento Seguridad Especificación de los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que deberá soportar el sistema, etc.
• Todos estos requisitos deben ser mesurables. Por ejemplo, indicando “el 95% de las transacciones deben realizarse en menos de 1 segundo”, en lugar de “los operadores no deben esperar a que se complete la transacción”.
• Seguridad Especificación de elementos que protegerán al software de accesos, usos y sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden especificar:
• • Empleo de técnicas criptográficas.
• • Registro de ficheros con “logs” de actividad.
• • Asignación de determinadas funcionalidades a determinados módulos.
• • Restricciones de comunicación entre determinados módulos.
• •Comprobaciones de integridad de información crítica.
• Fiabilidad: Especificación de los factores de fiabilidad necesaria del sistema. Esto se expresa generalmente como el tiempo entre los incidentes permisibles, o el total de incidentes permisible. Fijan la tasa de fallas para que el sistema sea aceptable. Ejemplo: Si se produce algún fallo al usar un servicio externo (autorización de pago) solucionarlo localmente.
• Disponibilidad: Especificación de los factores de disponibilidad final exigidos al sistema. ! Normalmente expresados en % de tiempo en los que el software tiene que mostrar disponibilidad. ! O bien, factores humanos de consistencia. Ejemplo: Se debe ver fácilmente el texto a una distancia de 30 cm del monitor
• Mantenibilidad: Identificación del tipo de mantenimiento necesario del sistema. ! Especificación de quien debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un desarrollador. Especificación de cuándo debe realizarse las tareas de mantenimiento. Por ejemplo, generación de estadísticas de accesos semanales y mensuales.
• Portabilidad: Especificación de atributos que debe presentar el software para facilitar su traslado a otras plataformas o entornos. Pueden incluirse:
• • Porcentaje de componentes dependientes del servidor.
• • Porcentaje de código dependiente del servidor.
• • Uso de un determinado lenguaje por su portabilidad.
• • Uso de un determinado compilador o plataforma de desarrollo.
• • Uso de un determinado sistema operativo.
• Otros: Cualquier otro requisito que no encaje en ninguna de las secciones anteriores. Por ejemplo: Requisitos culturales y políticos
• Requisitos Legales