Referencias Casos de Uso Funciones tipo abmc con acceso a una nica entidad de datos con Caso de Uso

Simple hasta 10 campos de entrada, con validaciones simples, o de lo contrario que contiene diez a quince pasos de caso de uso y como mximo una llamada a otro caso de uso. Funciones tipo abmc con acceso a varias entidad de datos (para consultas o referencias) con hasta 15 campos de entrada, con Caso de Uso Mediano validaciones simples, o de lo contrario funciones que contienen de diecisis a veinte pasos de casos de uso, llamadas a uno a ms casos de uso y una o dos validaciones. Funciones tipo cabecera detalle o consultas con criterios, con acceso a varias entidades de datos y validaciones de consistencia, Complejidad Caso de Uso Complejo o de lo contrario funciones que contienen de veintin a veinticinco pasos de caso de uso y una o ms llamadas a otros casos de uso y varias validaciones. Funciones esenciales, que se corresponden con la resolucin de la lgica de negocio en la aplicacin, conllevan algoritmos Caso de Uso Muy Complejo computacionales complicados. O de lo contrario, funciones que contienen de veintisis a treinta y cuatro, una o ms llamadas a otros casos de uso y varias validaciones. Este nivel de complejidad se reserva para aquella funcionalidad que realmente trae aparejado un nivel de dificultad tal, por sus Caso de Uso Extremadamente Complejo algoritmos computacionales o su lgica asociada, que va a requerir un tiempo se resolucin importante. Puede que existan proyectos que no tengan este tipo de casos de uso, y de existir,

por lo general son pocos en cantidad. De lo contrario se consideran funciones que contienen ms de treinta y cinco pasos de caso de uso, una o ms llamadas a otros casos de uso y varias validaciones.

Requerimientos no funcionales asociados al funcionamiento del producto. Se clasifican en: Del Producto requerimientos de usabilidad, requerimientos de eficiencia (performance y espacio), requerimientos de confiabilidad, requerimientos de portabilidad y de Interfaz. Requerimientos no funcionales definidos como Categora Organizacionales restricciones por la organizacin para la cual se genera el producto. Requerimientos no funcionales asociados a la relacin del sistema con el ambiente en el que Externos se encuentra. Se clasifican en: requerimientos de interoperatividad, requerimientos legales (seguridad y privacidad), requerimientos ticos.

Algunas consideraciones para medir la usabilidad de un producto de software son: Especificar el tiempo de capacitacin requerido para usuarios normales y expertos para convertirse en productivos en operaciones particulares. Especificar tiempos de tareas mensurables para tareas tpicas, alternativamente, Requerimientos de usabilidad bsica del nuevo sistema sobre otros sistemas que los usuarios conocen y les agradan. Subcategora Requerimientos del Producto Usabilidad Especificar requerimientos para conformidad con los estndares comunes de usabilidad, tales como estndares de GUI. Especificar necesidades de documentacin del producto, incluyendo los requisitos expresados respecto al tipo y forma de presentacin de documentacin de usuario y sistemas de ayuda para el producto de software a construir. Ejemplos de esto son: * Manual de Usuario * Ayuda en Lnea * Manual de Configuracin

Incluye tiempos de respuesta especficos. Donde sea aplicable, referenciar a los casos de uso relacionados, por nombre. Tiempo de respuesta para una transaccin (promedio, mximo), de principio al fin Capacidad (el nmero de clientes o transacciones que el sistema puede soportar). Modos de Degradacin (modo aceptable de operacin cuando el sistema ha sido degradado). Utilizacin de Recursos (memoria, disco, comunicaciones) Hace referencia a la necesidad de ejecutar diferentes procesos en un mismo momento de tiempo, o distintas instancias de un mismo Performance Concurrencia proceso. Se mide indicando cantidad de equipos en concurrencia, caractersitcas tcnicas de los equipos en concurrencia, cantidad de equipos en operacin normal y en cantidad mxima de equipos en concurrencia. Hace referencia a los tiempos de respuesta, rendimiento, tiempo de corrida, capacidad del producto u modos de degradacin Tiempo de Respuesta aceptables. Los tiempos de respuestas se refiere a las unidades de tiempo de espera desde que se produce una accin hasta que el sistema responde. El rendimiento hace referencia a la cantidad de transacciones que se espera que se ejecuten por unidad de

tiempo. El tiempo de corrida es el tiempo que lleva la ejecucin de un proceso automtico (proceso bach). Ejemplos de requerimientos de tiempo de respuesta: tiempo medio por transaccin, tiempo mximo por transaccin. Ejemplos de requerimientos de capacidad: cantidad de clientes mxima, cantidad de clientes promedio, cantidad de transacciones mxima, cantidad de transacciones promedio. Ejemplos de requerimientos de rendimiento: cantidad de transacciones por unidad de tiempo, cantidad de informacin comunicada por unidad de tiempo. Hace referencia a la utilizacin de recursos del Utilizacin de Recursos producto como la memoria, disco, hardware de comunicaciones. Hace referencia a la eficienca de espacio.

La confiabilidad podra expresarse en trmino de alguno de estos aspectos: Disponibilidad: Especificar el porcentaje de disponibilidad de tiempo, horas de uso, acceso de mantenimiento, etc. Tiempo Mnimo entre fallas: Especificado usualmente en horas, pero tambin puede especificarse en das, meses y aos. Tiempo Mnimo de Reparacin: Cunto tiempo est permitido que el sistema est fuera de operacin despus de una falla? Certeza: Precisin Especfica (resolucin) y Confiabilidad certeza (sobre un estndar) que es requerida para las salidas del sistema. Errores (bugs) Mximos o ratios de defecto: usualmente expresados en trminos de BUGS/KLOC (miles de lneas de cdigo) o bugs por casos de uso Errores (Bugs) o ratios de defectos: Categorizados en trminos de bugs menores, significativos y crticos. Los requerimientos debern definir lo que quiere decir bug crtico (tal como datos completamente perdidos, inhabilitacin completa para usar ciertas partes de la funcionalidad del sistema). Backup: Backup requeridos para asegurar la

disponibilidad del sistema. Estabilidad: capacidad del sistema de disminuir la cantidad de cambios realizados en un perodo de tiempo.

Debe expresar las necesidades de crecimiento del producto hacia otras tecnologas de desarrollo, sistemas operativos y/o Portabilidad plataformas de hardware. Considera la facilidad de reemplazo por nuevas versiones del producto, la facilidad de instalacin, la escalabilidad y la adaptabilidad a diferentes plataformas. Hace referencia a los requerimientos de seguridad de acceso a datos y de acceso a las distintas funcionalidades ofrecidas por el Lgica Seguridad producto de softeware. Se incluyen requerimientos de validacin de usuario y control de acceso (autorizacin) necesarios en el software. Fsica Se definen aspectos de seguridad de acceso a lugares fsicos, requerimientos de integridad

de los datos, controles de fraude y formas de comunicacin de los datos en los canales correspondientes, como requerimientos de cifrado o relacionados con la necesidad de no repudio a informacin que se trasmita por diferentes canales de comunicacin. Interfaz entre el usuario y el producto, como pantallas y reportes. Hace referencia a las consideraciones generales respecto a la De Usuario interfaz requiere el cliente que el producto respecte, como ser: Color de Pantallas, Ubicacin de botones, Inclusin de Logos en pantallas. Se puede incluir una maqueta de ejemplo o referenciar a una existente. Defina cualquier interfaz de hardware que De Interfaz deber ser soportada por el producto de De Hardware software a construir, incluyendo estructura lgica, direcciones fsicas y comportamiento esperado. Describe las interfaces del software que deber proveer el producto, ya sea para vincularse con componentes comprados, componentes De Software reusados de otra aplicacin o componentes que estn siendo desarrollados por subsistemas fuera del alcance de esta Especificacin de Requerimientos de Software pero con los

cuales esta aplicacin de software debe interactuar. Describe las interfaces de comunicacin u De Comunicaciones otros o dispositivos, tales como redes de rea local o dispositivos seriales remotos con los que el producto de software a construir deber relacionarse. Si la organizacin tiene requisitos explcitos respecto a la entrega del producto, entre los cuales podemos mencionar, fechas, pocas del Entrega ao, das u horas especficos para por hacer el despliegue del producto, instalaciones on site distribuidas o remotas, etc., debern especificarse en este apartado. Restricciones de Negocio ticos Si existen requerimientos que deben considerarse en el contexto del producto que si bien no estn legislados, responde a factores morales o pautas de conducta, debern especificarse aqu. Identificar si existen legislaciones nacionales, internacionales, Legales provinciales, etc., aplicables y vigentes, que el software deba considerar. Tambin incluya ac aspectos relacionados a los derechos de copia (copyright).

Hace referencia a los requerimientos legales que protegen la seguridad y confidencialidad del producto y toda documentacin asociada. Si la organizacin contratante (cliente) desea que el producto respete ciertos estndares Estndares asociados al producto en s mismo o a su proceso de desarrollo, los mismos debern especificarse en este apartado. Este apartado deber especificar cualquier consideracin que impacte en la implementacin del producto que sea un Implementacin Restricciones Tcnicas requisito planteado por el cliente y que el producto debe respetar. Ejemplos de esto sera la definicin de utilizar cierta base de datos o cierto lenguaje de Programacin Este aspecto implica requisitos vinculados con la necesidad de que el producto de software se Interoperatividad comunique con otros productos de software del exterior, para intercambiar datos o algn otro aspecto.