[Php-avanzado] FW: srs_marco

Sab Dic 5 15:42:37 ARST 2009

Hola Marco,

El sáb, 05-12-2009 a las 14:49 -0200, Marco Frontini escribió:
>    Leo, revisa cuando puedas el adjunto, es para ver si entendi la
> idea de lo que necesitas.

	Ok. No sé si soy un "buen cliente" como para que me dejes las cosas tan
abiertas ;-)

	Copio y pego acá la SRS para comentarla. Denoto mis comentarios con un
asterisco (*):

Sistema a desarrollar: Administración y control de pagos de servicios de
hosting.

(*) Lo que te había dicho el jueves quedaba circunscripto a la
"administración y control de cobros" excluyendo los pagos.
Hagamos lo siguiente: trabajemos en una SRS que contemple los cobros
también, y luego vemos si no queda demasiado grande para tesis del
curso.

Requerimientos funcionales:

# El sistema debe permitir gestionar (ABM) servicios.

(*) Ok.

# El sistema debe establecer distintos estados para los servicios. “Leo
necesito que me digas cuales son los posibles estados de tus servicios,
ej: activo, suspendido, vigente, etc.”

(*) Solo 2: Activo o No Activo. De hecho podría no manejarse estados,
sino simplemente se le borra el Servicio al Cliente cuando no lo tiene
activo. Con estados queda más lindo, porque se preserva así la fecha de
alta del servicio y la fecha de baja.

# El sistema debe asignar precios a los distintos servicios.

(*) Como los precios son un atributo del servicio, no vale la pena
plantearlos como un requerimiento aparte, sino simplemente como un
atributo del Servicio especificado en 1)... bueno, en el primero, porque
no los numeraste ;-)

# El sistema debe poder asignar clientes a los servicios.

(*) Entonces antes falta especificar que el sistema debe gestionar
clientes...

# El sistema debe establecer tiempos de duración de los servicios
individualmente.

(*) No entiendo que es esto. Los servicios, mientras estén vigentes,
existen, así que no tienen un tiempo de duración. Si te referís a cada
cuanto se cobran (mensual, bimestral, trimestral, etc, no parece
pertinente llamarlo "tiempo de duración".

# El sistema debe calcular vencimientos a partir de los tiempos de
duración de los servicios. 

(*) Acá queda claro que te referís a la periodicidad del cobro y no a la
duración, como sospechaba en el anterior.
Hay que buscar una palabra o frase que se ajuste mejor a lo que estás
queriendo decir, como "Frecuencia de cobro del servicio" o algo por el
estilo.

# El sistema debe permitir modificar los vencimientos.

(*) No hace falta... en tal caso, basta con que un atributo del servicio
sea el día del mes que se vence, por ejemplo el "10" o el "15".
Todos los servicios comienzan el 1ro de mes y son por mes calendario.
Aclaración irrelevante para la SRS pero sí para entender esto: si un
cliente arranca el 18, se le cobra el proporcional de los 12 días, y
luego sigue con el mes calendario.

# El sistema debe avisar del vencimiento del servicio 10 y 5 días antes.

(*) No hace falta ni que avise ni que mande mails: la salida debe ser un
listado de los servicios que hay que cobrar el mes seleccionado, a
quién, por qué importes.
Si un cliente tiene más de un servicio activo, simplemente aparece dos
veces en este listado.

# El sistema debe dar aviso de un servicio vencido.

(*) No hace falta.

# El sistema debe permitir registrar el pago de los servicios.

(*) Ok. Esto es lo que tal vez recortemos si la SRS indica que el
sistema es demasiado grande para el curso.

# El sistema debe calcular saldos en los pagos de los servicios.

(*) Ok. Idem anterior.

# El sistema debe recalcular precios de los servicios en base a los
saldos de los servicios.

(*) No entiendo qué es este recálculo. :(
Si te referís a que lo que se debe un mes, es el servicio que se venza
ese mes + los adeudado anterior sin pagar, no parece un "recálculo".
A qué te referís?

# El sistema debe permitir ver reportes de históricos del pago de los
servicios.

(*) Ok. Otra cosa posiblemtne para recortar
Esto se redacta mejor con la fórmula "El sistema debe emitir..."
Todo lo que dice la SRS es lo que el sistema "permitirá" hacer, así que
poner "permitir" es redundante y genera ambigüedades.

# El sistema debe permitir ver reportes de servicios pagados en término.

(*) Idem anterior.

# El sistema debe permitir ver reportes de servicios pagados fuera de
término.

(*) Idem anterior.
Estos últimos dos podrían ser el mismo reporte. En realidad con un
"adeuda a la fecha" y poder ver los conceptos adeudados es suficiente,
independientemente de si se pagó en término o no.

	Muy buen inicio!
	Seguimos!!!

PD: el sistema no debe hacer nada "solo" o dependiente de la fecha del
servidor. El operador dice "es 5/12/2009" (que puede estar ya puesto por
el sistema como sugerencia) y se le pide que emita su informe de lo que
hay que facturar o no.
Esto permite hacerlo tarde o por adelantado de ser necesario, por
ejemplo para el 29 o 30 de diciembre armar todas las cosas para el
01/01/2001, y el 02/01 tenerlas listas para ingresar.
-- 

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