[Php-objetos] Jorge Re: Tesis - Requerimientos

[Leonardo Tadei - Pegasus Tech Supply]

Hola Jorge,

	Te sumaste a la movida en titular "el sistema debe" y debajo poner los
tópicos. Copiar y pegar no es tanto en documentos digitales, y para tu
próxima entrega y para las de los demás, por favor que toda frase
empiece con "El sistema debe...".

El vie, 27-02-2009 a las 20:49 -0300, Jorge Castorina escribió:
> Aqui va un intento de escribir requerimientos para un sistema de biblioteca.
> Saludos, Jorge

	Es un muy buen primer borrador de la especificación.
	Te marco unas cosas y mañana en clase lo terminamos de acomodar.

> ================================================================================
> 
> El sistema se construye para implementar el control de circulación de una 
> biblioteca.

	Ok. Esto es lo macro de la intención del sistema. Acá abajo tiene que
estar detallada la naturaleza de este control:

> El sistema debe:
> 
> - Gestionar usuarios de la biblioteca

	Perfecto. En el diccionario más abajo está el Usuario. Lo paso acá
arriba para comentar el diccionario en el contexto de este
requerimiento:
-----
> Usuario
> 
> Persona que puede registrar transacciones en el sistema.

	"Transacción" es vocabulario de bases de datos... toda cosa que pase,
pensada así, será una transacción!!!
	La idea es determinar cual es el problema a resolver, el sistema a
construir, en términos del dominio del problema.

> Se requieren procedimientos de alta, modificación y baja de los mismos.

	La frase "Gestión de" hace referencia justamente a las ABM... fijate
que si vas por este camino, tendrías que nombrar el AMB de todo, lo cual
es superfluo.

> Estados posibles: sin préstamos, con préstamos, moroso, suspendido, 
> inhabilitado.

	Que el usuario tenga estados es parte del requerimiento, no del
diccionario. En el diccionario deben ir solo definiciones de términos y
no cosas funcionales.

> Categorías posibles docente, alumno, graduado, empleado (según la categoría 
> se establece las cantidades máximas de ítems a prestar y días de préstamo)
-----

	Si enumerás ejemplos de categorías... pero no hay un requerimiento que
diga que el sistema debe manejar categorías...

	En mi caso "usuario" me resultó algo confuso, porque pensé que eran
usuarios del sistema, como operadores. En el diccionario me hubiera
servido más ver qué era el usuario.

	Por otra parte, no figura en el diccionario qué datos definen al
usuario de la biblioteca (nombre, apellido...)

> - Gestionar el inventario (ítems) la colección

	Los estados y categorías de los items forman parte del requerimiento,
no del diccionario. No figuran los datos que definen los Items... tal
vez requieran una entrada en el diccionario.

> - Gestionar las transacciones ocurridas durante las operaciones diarias

	En el diccionario ponés: "Tipos de transacciones posibles son:
préstamo, devolución, renovación, reserva, sanción, levantar sanción."

	Llegado a esta altura me pregunto: no sería mejor expresar los
requerimientos de la forma

- El sistema debe registrar el préstamo de items por los usuarios...
- El sistema debe aceptar la devolución de items...
- El sistema debe tener un mecanismo para la renovación de un prestamos.
- El sistema debe permitir reservar items para un usuario.
- El sistema debe determinar las sanciones a los usuarios en caso de no
devolución y mora.

	Fijate como así estamos hablando del modelo, del "sistema biblioteca" y
sus procesos en lugar de hablar de un programa de computadoras...

> - Gestionar operadores del sistema

	Todo es multiusuario hoy... esto es superfluo.

> - Gestionar las variables operativas del sistema

	Esto es diseño!!!
El sistema debe administrar los días de sanción para cada categoría de
usuario.
Etc, etc.

> - Permitir cambios globales

	No dice nada... un requerimiento sería:
El sistema debe permitir cambiar todas las fechas de devolución en caso
de feriados o cierre el edificio. El corrimiento de fechas no es
automático.

> - Emitir listados de control

	De control de qué?

> - Emitir comprobantes de préstamo y devolución

	Esto se puede juntar al requerimiento de que "el sistema debe registrar
el préstamo"...

[..]

	No pretendo que la SRS sea perfecta ni mucho menos, sino que obtengan
un buen listado de lo que debe hacer, para después poder modelar algo
razonable.


	Seguimos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key