[Php-avanzado] SRS version 1 Marco Riedel

Leonardo Tadei - Pegasus Tech Supply leonardot en pegasusnet.com.ar
Mie Mayo 22 10:42:39 ART 2013


Hola Marco,

El mar, 21-05-2013 a las 23:07 -0300, Marco Riedel escribió:
> LEONARDO TE PASO UNOS COMENTARIOS ENTRE LINEAS..
> SALUDOS

	Ok.
	Lo de las mayúsculas es una buena solución. Tu cliente de correo no
marca el texto original como respuesta ?
	En fin, sigamos!
	Dejo solo el texto a responder:

> El 21 de mayo de 2013 10:54, Leonardo Tadei - Pegasus Tech Supply 
>         > 1 El sistema debe gestionar localidades.
>         > 2 El sistema debe gestionar direcciones con sus localidades
>         [1].
>         
> 
> 
>         > 3 El sistema debe gestionar preguntas DE COMPRADORES A
>         VENDEDORES.

	Sí, pero acordate de que esto implica especificar primero Compradores y
Vendedores para hacer referencia a ellos.

>         > 4 El sistema debe gestionar compradores con su dirección [2]
>         y su
>         > localidad [1].
>         > 5 El sistema debe gestionar vendedores con su dirección [2]
>         y su
>         > localidad [1].
>         
>         
>                 No entiendo por qué si tanto los Compradores como los
>         Vendedores tienen
>         una sola dirección, esta no es un mero atributo en el
>         diccionario en vez
>         de ser una entidad que se gestiona independiente.
>                 Me lo explicás?
>  
>         ELIMINO ESTOS DOS RF (1-2)Y LOS AGREGO EN EL DICCIONARIO PARA
>         LOS VENDEDORES Y COMPRADORES? 

	Casi. No veo en la especificación que las direcciones tengan que
manejarse como entidades separadas. Sin embargo, las Localidades sí lo
son y se mantienen especificadas por separado, así que solo
desaparecería el que acá aparece como RF2

>         > 6 El sistema debe responder o rechazar preguntas [3].
>         
>         
>                 Falta la referencia al Vendedor acá.
> YO LO ARMARÍA DE LA SIGUIENTE MANERA PERO HACIENDO REFERENCIA AL
> COMPRADOR "El sistema debe responder o rechazar preguntas de
> compradores". PORQUE SINO DEBERÍA UTILIZAR "El sistema debe permitir
> responder o rechazar preguntas a los vendedores"  Y EN OTRO MAIL ME
> COMENTASTE QUE ESTO ESTARÍA MAL, COMO SE HARIA LA REFERENCIA AL
> VENDEDOR? 

	Dos cosas: una es que tal vez la pregunta sea al Texto que está a la
venta, y no al Vendedor... esto lo tenés que pensar con detenimiento.
	La otra es que podrías redactar algo como: El sistema debe responder o
rechazar preguntas a un Vendedor.

>         > 7 El sistema debe gestionar materias.
>         > 8 El sistema debe gestionar libros con su materia[7].
>         
>         
>                 Tenés en el diccionario una entrada para "Fotos" que
>         no es una
>         funcionalidad separada del Libro: sacala. ELIMINADO
>                 En el diccionario de Libro no falta el precio?
>         AGREGADO

	No está modificado en la versión que me enviás, pero te creo ;-)

>         > 9 El sistema debe gestionar ofertas de compradores [4].
>         
>         
>                 Falta la referencia al Libro. OK
>         
>         > 10 El sistema debe mostrar estados. 
>         > 11 El sistema debe listar ofertas [9] de libros [8], con su
>         estado
>         > [10] Y SU COMPRADOR.
>         
>         
>                 Falta la referencia al Comprador, que es quién hace la
>         Oferta.
>                 No entiendo todos los Estados enumerados en el
>         diciconario. Me queda
>         claro que una Oferta está pendiente, o aceptada o rechazada,
>         pero qué es
>         una "oferta liquidada" o una "oferta entregada" ?
>                 No estás mezclando estados de la Oferta con estados de
>         la compra/venta?
>         
>         SI ESTO LO SEPARO EN DOS RF (ESTADOS DE OFERTAS Y ESTADOS DE
>         PREGUNTAS) ESTARIA BIEN O ESTARIA SIENDO LO MISMO QUE USUARIOS
>         COMPRADORES Y USUARIOS VENDEDORES? 

	Si seguís pensando en usuarios, vas a meter la pata...
	Respecto a los estados, como no son los mismos para las Ofertas que
para las Preguntas, se justifica perfectamente especificarlos por
separado y luego hacer referencia a cada uno dónde corresponde.
	Acordate de ponerlos en el diccionario y de enumerar los estados
posibles de cada uno, porque estos se van a "mostrar" y no a
"gestionar".

>         > 12 El sistema debe modificar la comisión por venta.
>         > 13 El sistema debe registrar ventas de vendedores [5], con
>         su
>         > comprador [4], con su estado [10] y su comisión [12].
>         
>         
>                 Te faltan las referencias a Forma de Pago y Forma de
>         Envío, lo que
>         implica que las tenés que especificar previamente para poder
>         hacer
>         referencia a ellas. OK 
>         
>         > 14 El sistema debe gestionar formas de pago.
>         > 15 El sistema debe gestionar formas de envío.
>         > 16 El sistema debe listar ventas [13] detallando vendedor
>         [5],
>         > comprador [4], forma de pago [14] y forma de envío [15].
>         
>         
>                 Agregá una entrada en el diccionario del listado de
>         ventas... supongo
>         que será entre fechas o por vendedor o algo, porque emitir
>         siempre un
>         listado de _todas_ las ventas es poco útil.
> EL TEMA FILTROS EN LOS LISTADOS COMO SE DETALLA EN LA SRS?  

	El sistema debe listar... filtrando por vendedor, comprador, etc, entre
dos fechas dadas.

>         > 17 El sistema debe marcar las ventas [13] como entregadas
>         para cerrar
>         > la operación.

	No estoy seguro, pero tal vez al especificar la venta, haya que abrir
subrequerimientos para detallar cómo son los cambios de estado.
	Lo vemos...


>         > 18 El sistema debe agrupar comisiones de venta de vendedores
>         [5] en
>         > liquidaciones.
>         
>         
>                 Son entre fechas? Se liquida por periodos fijos ? Cómo
>         se sabe desde
>         cuándo y hasta dónde hacer una liquidación?
> SERIA DE LA SIGUIENTE MANERA TODOS LOS 5 DE CADA MES SE AGRUPAN TODAS
> LAS COMISIONES PENDIENTES DEL MES ANTERIOR EN UNA NUEVA LIQUIDACION.

	Bueno. Especificalo así entonces!

>         > 19 El sistema debe registrar el pago de liquidaciones [18].
>         
>         
>                 Capaz que te conviene agregar una funcionalidad que
>         especifique una
>         limitación a publicar o a vender su hay una deuda de
>         comisiones... o
>         pensás cobrar por adelantado?
> 
> 
> LO HABIA PENSADO DE ESA MANERA PERO NO QUIERO QUE SE EL SISTEMA SE
> AGRANDE DEMASIADO. PODRIA SER UNA MEJORA A FUTURO, PARA ARRANCAR SE
> PODRIA PUBLICAR HAYAS PAGADO O NO.

	El que se pueda publicar sin pagar, me parece además una característica
muy buena para fomentar el uso.
	Sin embargo, creo que estaría bueno agregarle al vendedor un atributo
"habilitado" para poder deshabilitar la publicación en caso necesario,
o, ya que no es tanto trabajo más, tener un límite en $ de deuda que te
permita publicar o no, de forma tal de que se pueda publicar sin pagar
nada, pero llegada a cierta deuda, se deshabilite al vendedor.
	Esto que te digo es solo una sugerencia: el sistema es tuyo y definilo
como quieras.

	Seguimos!

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



Más información sobre la lista de distribución Php-avanzado