Está en la página 1de 9

Referencias

Casos de Uso

Caso de Uso Simple

Caso de Uso Mediano

Caso de Uso Complejo


Complejida
d

Caso de Uso Muy Complejo

Caso de Uso Extremadamente Complejo

Requerimientos No Funcionales
Requerimientos
No Funcionales

Requerimientos
del Producto Restricciones de
Negocio

Requerimientos
Requerimientos Requerimientos Requerimientos Requerimientos Requerimien
Seguridad de
de Performance de Usabilidad de Interfaz de Entrega de Estándar
Confiabilidad

Utilización de Requerimientos Requerimientos Requerimien


Concurrencia Lógica Física de Portabilidad de Éticos de Legale
Recursos

Tiempo de
Respuesta Hardware Software Usuario Comunicaciones

Del Producto
ría
o
eg
at
C
Organizacionales

Externos

Usabilidad

Incluye tiempos de respuesta específicos. Donde sea aplicable, referenciar a los ca


Tiempo de respuesta para una transacción (promedio, máximo), de principio al fin
Capacidad (el número de clientes o transacciones que el sistema puede soportar).
Modos de Degradación (modo aceptable de operación cuando el sistema ha sido d
Utilización de Recursos (memoria, disco, comunicaciones)

Concurrencia
Performanc
e

Tiempo de Respuesta

Utilización de Recursos

Requerimientos

del

Producto

Confiabilidad
ía
or
g
te
ca
b
Su

Portabilidad
Lógica

Seguridad

Física

De Usuario

De Hardware
De Interfaz

De Software

De Comunicaciones

Entrega

Restricciones Éticos

de Identificar si existen legislaciones nacionales, internacionales, provinciales, etc., apl


aspectos relacionados a los derechos de copia (copyright).
Negocio Legales
Hace referencia a los requerimientos legales que protegen la seguridad y confidenc

Estándares

Restricciones Implementación

Técnicas
Interoperatividad
Referencias
Casos de Uso
Funciones tipo abmc con acceso a una única entidad de datos con hasta 10 campos de entrada, con validaciones simples, o de
lo contrario que contiene diez a quince pasos de caso de uso y como máximo 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
validaciones simples, o de lo contrario funciones que contienen de dieciséis a veinte pasos de casos de uso, llamadas a uno a
más 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, o de lo contrario funciones que contienen de veintiún a veinticinco pasos de caso de uso y una o más llamadas a
otros casos de uso y varias validaciones.
Funciones esenciales, que se corresponden con la resolución de la lógica de negocio en la aplicación, conllevan algoritmos
computacionales complicados. O de lo contrario, funciones que contienen de veintiséis a treinta y cuatro, una o más 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
algoritmos computacionales o su lógica asociada, que va a requerir un tiempo se resolución 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 más de treinta y cinco pasos de caso de uso, una o más llamadas a otros casos de uso y
varias validaciones.

Requerimientos No Funcionales
Requerimientos
No Funcionales

Requerimientos
Restricciones de Restricciones
del Producto
Negocio Técnicas

Requerimientos Requerimientos Requerimientos


Requerimientos Requerimientos Requerimientos
de de de
de Interfaz de Entrega de Estándares
Confiabilidad Iteroperatividad Implementación

Requerimientos Requerimientos Requerimientos


de Portabilidad de Éticos de Legales

ware Software Usuario Comunicaciones

Basado en Definiciones de
Ian Sommerville , Ian
Gorton
y la ISO 9126/1991

Requerimientos no funcionales asociados al funcionamiento del producto. Se clasifican en: requerimientos de usabilidad,
requerimientos de eficiencia (performance y espacio), requerimientos de confiabilidad, requerimientos de portabilidad y de
Interfaz.
Requerimientos no funcionales definidos como restricciones por la organización para la cual se genera el producto.
Requerimientos no funcionales asociados a la relación del sistema con el ambiente en el que 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 capacitación requerido para usuarios normales y expertos para convertirse en productivos en
operaciones particulares.
Especificar tiempos de tareas mensurables para tareas típicas, alternativamente, Requerimientos de usabilidad básica del
nuevo sistema sobre otros sistemas que los usuarios conocen y les agradan.
Especificar requerimientos para conformidad con los estándares comunes de usabilidad, tales como estándares de GUI.
Especificar necesidades de documentación del producto, incluyendo los requisitos expresados respecto al tipo y forma de
presentación de documentación de usuario y sistemas de ayuda para el producto de software a construir.
Ejemplos de esto son:
* Manual de Usuario
* Ayuda en Línea
* Manual de Configuración

s de respuesta específicos. Donde sea aplicable, referenciar a los casos de uso relacionados, por nombre.
puesta para una transacción (promedio, máximo), de principio al fin
número de clientes o transacciones que el sistema puede soportar).
gradación (modo aceptable de operación cuando el sistema ha sido degradado).
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 proceso. Se mide indicando cantidad de equipos en concurrencia, caracterísitcas técnicas de los equipos en
concurrencia, cantidad de equipos en operación normal y en cantidad máxima de equipos en concurrencia.

Hace referencia a los tiempos de respuesta, rendimiento, tiempo de corrida, capacidad del producto u modos de degradación
aceptables. Los tiempos de respuestas se refiere a las unidades de tiempo de espera desde que se produce una acción 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 ejecución de un proceso automático (proceso bach).
Ejemplos de requerimientos de tiempo de respuesta: tiempo medio por transacción, tiempo máximo por transacción.
Ejemplos de requerimientos de capacidad: cantidad de clientes máxima, cantidad de clientes promedio, cantidad de
transacciones máxima, cantidad de transacciones promedio.
Ejemplos de requerimientos
Hace referencia de de
a la utilización rendimiento: cantidad
recursos del de como
producto transacciones por disco,
la memoria, unidad hardware
de tiempo,decantidad de información
comunicaciones. Hace
comunicada por
referencia a la unidad de
eficienca de tiempo.
espacio.
La confiabilidad podría expresarse en término de alguno de estos aspectos:
Disponibilidad: Especificar el porcentaje de disponibilidad de tiempo, horas de uso, acceso de mantenimiento, etc.
Tiempo Mínimo entre fallas: Especificado usualmente en horas, pero también puede especificarse en días, meses y años.
Tiempo Mínimo de Reparación: ¿Cuánto tiempo está permitido que el sistema esté fuera de operación después de una falla?
Certeza: Precisión Específica (resolución) y certeza (sobre un estándar) que es requerida para las salidas del sistema.
Errores (bugs) Máximos o ratios de defecto: usualmente expresados en términos de BUGS/KLOC (miles de líneas de código) o
bugs por casos de uso
Errores (Bugs) o ratios de defectos: Categorizados en términos de bugs menores, significativos y críticos. Los requerimientos
deberán definir lo que quiere decir bug “crítico” (tal como datos completamente perdidos, inhabilitación 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 período de tiempo.

Debe expresar las necesidades de crecimiento del producto hacia otras tecnologías de desarrollo, sistemas operativos y/o
plataformas de hardware. Considera la facilidad de reemplazo por nuevas versiones del producto, la facilidad de instalación, 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 producto de softeware. Se incluyen requerimientos de validación de usuario y control de acceso (autorización) necesarios en
el software.
Se definen aspectos de seguridad de acceso a lugares físicos, requerimientos de integridad de los datos, controles de fraude y
formas de comunicación de los datos en los canales correspondientes, como requerimientos de cifrado o relacionados con la
necesidad de no repudio a información que se trasmita por diferentes canales de comunicación.

Interfaz entre el usuario y el producto, como pantallas y reportes. Hace referencia a las consideraciones generales respecto a
la interfaz requiere el cliente que el producto respecte, como ser: Color de Pantallas, Ubicación de botones, Inclusión de Logos
en pantallas. Se puede incluir una maqueta de ejemplo o referenciar a una existente.

Defina cualquier interfaz de hardware que deberá ser soportada por el producto de software a construir, incluyendo estructura
lógica, direcciones físicas y comportamiento esperado.
Describe las interfaces del software que deberá proveer el producto, ya sea para vincularse con componentes comprados,
componentes reusados de otra aplicación o componentes que están siendo desarrollados por subsistemas fuera del alcance de
esta Especificación de Requerimientos de Software pero con los cuales esta aplicación de software debe interactuar.

Describe las interfaces de comunicación u 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 organización tiene requisitos explícitos respecto a la entrega del producto, entre los cuales podemos mencionar, fechas,
épocas del año, días u horas específicos para por hacer el despliegue del producto, instalaciones on site distribuidas o remotas,
etc., deberán especificarse en este apartado.

Si existen requerimientos que deben considerarse en el contexto del producto que si bien no están legislados, responde a
factores morales o pautas de conducta, deberán especificarse aquí.
xisten legislaciones nacionales, internacionales, provinciales, etc., aplicables y vigentes, que el software deba considerar. También incluya acá
ionados a los derechos de copia (copyright).

a a los requerimientos legales que protegen la seguridad y confidencialidad del producto y toda documentación asociada.
Si la organización contratante (cliente) desea que el producto respete ciertos estándares asociados al producto en sí mismo o a
su proceso de desarrollo, los mismos deberán especificarse en este apartado.

Este apartado deberá especificar cualquier consideración que impacte en la implementación del producto que sea un requisito
planteado por el cliente y que el producto debe respetar. Ejemplos de esto sería la definición de utilizar cierta base de datos o
cierto lenguaje de Programación

Este aspecto implica requisitos vinculados con la necesidad de que el producto de software se comunique con otros productos
de software del exterior, para intercambiar datos o algún otro aspecto.