[Php-avanzado] SRS version 1 Marco Riedel

Lun Abr 29 22:15:55 ART 2013

Leonardo,
Creo haber comprendido y aplicado varios de los comentarios que me
enviaste.
Te detallo algunas dudas del sistema.

*El sistema es para venta de libros usados escolares por lo que el usuario
vendedor no tiene varias copias del mismo libro, solamente una. Por esto
no existiría el ejemplar.

> 23 El sistema debe liquidar comisiones [22] a las compras [14].
        Y cómo se asigna una comisión de las existentes a una venta?

*La comisión estaría fija en el sistema, por ejemplo el 5% del precio de
venta. Esto seria un proceso automático que se ejecutaría al confirmar la
venta. No se si como lo indique ahora esta bien.

*La oferta seria una opción de compra por menor valor al publicado. Por
ejemplo el libro tiene un valor de $50 y un usuario crea una oferta por $40
la cual puede ser aceptada o rechazada.

Te adjunto la versión 2 del SRS.
Saludos

1 El sistema debe gestionar localidades.
2 El sistema debe gestionar direcciones con sus localidades [1].
3 El sistema debe gestionar preguntas.
4 El sistema debe responder o rechazar preguntas [3].
5 El sistema debe gestionar materias.
6 El sistema debe gestionar libros con su materia[5].
7 El sistema debe gestionar ofertas.
8 El sistema debe listar ofertas [7] pendientes de libros [6], los estados
que puede tener una oferta [7] son pendiente, respondida o rechazada.
9 El sistema debe registrar compras, los estados que puede tener un compra
es pendiente, aceptada, rechazada.
10 El sistema debe gestionar formas de pago.
11 El sistema debe gestionar formas de envío.
12 El sistema debe listar compras [9] detallando su forma de pago [10] y su
forma de envío [11].
13 El sistema debe marcar las compras [14] como entregadas para cerrar la
operación.
14 El sistema debe generar reporte de libros [6] en oferta [7].
15 El sistema debe generar reporte de libros [6] comprados.
16 El sistema debe gestionar comisiones.
17 El sistema debe liquidar comisiones [16] a las compras [14].
18 El sistema debe registrar liquidaciones.
19 El sistema debe asignar forma de pago a las liquidaciones [18]
pendientes.
20 El sistema debe listar liquidaciones [18] pendientes.

  Diccionario:

Localidades: Nombre.

Direcciones: Calle, altura, localidad.

Usuarios: Nombre usuario, clave, Nombres, Apellidos, fecha de
nacimiento, dirección, localidad.

Preguntas: Texto de pregunta, Fecha, Usuario.

Materia: Nombre, descripción.

Fotos: Nombre, ubicación, libro.

Libro: Nombre, materia, descripción, fotos, usuario.

Oferta: Fecha, Libro, usuario, estado.

Forma de pago: Nombre, descripción.

Forma de envío: Nombre, descripción.

Compra: Fecha, Libro, usuario, importe final, forma de pago, forma de
envío, estado.

Reporte de Ofertas: Libro, fecha, usuario, estado.

Reporte de compras: fecha, usuario, importe final, libro.

Comisión: Porcentaje de comisión.

Liquidación: fecha, Importe de venta, porcentaje, importe
liquidación,usuario.

Reporte liquidaciones pendientes: Fecha, usuario, Importe liquidación.

El 29 de abril de 2013 10:25, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola Marco,
>
>         me gustó mucho el tema de tu trabajo final.
>         Te intercalo algunos comentarios:
>
>
> El lun, 29-04-2013 a las 01:07 -0300, Marco Riedel escribió:
> > Leonardo,
> > Te envío el SRS del sistema final...
> > Espero tu comentarios.
> >
> > Saludos
> >
> >
> -------------------------------------------------------------------------------------
> > Sistema de venta on line de libros escolares usados.
> >
> >
> > La pagina web permitirá a los usuarios ofrecer y comprar libros
> > escolares usados. Se guardara un registro de cada operación o compra
> > para luego generar una comisión que sera cobrada al usuario vendedor.
>
>         Cómo habíamos visto en clase, los "usuarios" o no son una
> funcionalidad, o es un término tan ambiguo que usar esa palabra es
> demasiado confuso.
>         No habrá "usuarios" que visiten el sitio y no estén registrados?
> Las
> arañas de los buscadores que pasan a indexarlo no lo usan? No hay un
> usuario que administre?
>         La respuesta a todo esto es "sí", por eso hay que ponerle un nombre
> único a cada cosa que defina su rol funcional (si es que lo tiene)
>
> > 1 El sistema debe gestionar localidades.
> >
> > 2 El sistema debe gestionar direcciones con sus localidades [1].
> >
> > 3 El sistema debe gestionar contraseñas.
>
>         La "contraseña" sola no es algo que se gestione, sino que será un
> atributo de alguna otra cosa. Tenés que especificar esa otra cosa si es
> una funcionalidad, y en ese caso la contraseña será un atributo más del
> diccionario de esta cosa.
>
> > 4 El sistema debe gestionar usuarios con sus direcciones [2] y
> > su contraseña [3].
>
>         Cómo te decía arriba, "usuario" es un término demasiado ambiguo...
>
> > 5 El sistema debe diferenciar entre usuario vendedor [A] y usuario
> > comprador [B].
>
>         Ahhh... entonces sospecho que tendrás la gestión de compradores y
> la
> gestión de vendedores...
>
> > 6 El sistema debe gestionar preguntas.
>
>         Agregale en el diccionario una fecha al menos, para poder
> organizarlas
> de alguna manera...
>
> > 7 El sistema debe permitir responder o eliminar preguntas [6] al
> > usuario vendedor [5A].
>
>         Si las preguntas son a "alguien', te hace falta en el diccionario
> tener
> un atributo que sea ese "alguien".
>
> > 8 El sistema debe gestionar materias.
> >
> > 9 El sistema debe gestionar fotos.
>
>         Me parece que la foto es solo un atributo del Libro, y no hace
> falta un
> RF por separado
>
> > 10 El sistema debe gestionar descripciones.
>
>         Idem.
>
> > 11 El sistema debe gestionar libros con su usuario [4], su materia[8],
> > sus fotos[9] y su descripción [10].
>
>         Esto hay que reformularlo.
>
>         Si de casualidad estás pensando algo que acá no dice, y que es que
> la
> descripción y la foto es de un libro, pero luego un vendedor publica
> para la venta un ejemplar de ese libro, tendrías que especificar por
> separado Libro y Ejemplar, en dónde el Libro es solo descriptivo, y el
> Ejemplar es de un Vendedor en particular.
>
> > 12 El sistema debe gestionar ofertas.
>
>         Si esto es lo que yo arriba llamo Ejemplar, entonces el Libro no
> tendría Vendedor... o hay algo que no entiendo o hay algo que falta.
>         Si esto es el precio que propone el Vendedor para comprar un
> Libro, le
> faltan un montón de cosas.
>
> > 13 El sistema debe permitir al usuario vendedor [5A] ver ofertas
> > [12] pendientes de sus libros [11].
>
>         Faltan especificar los estados de las Ofertas.
>
> > 14 El sistema debe registrar compras.
>
>         Idem.
>
> > 15 El sistema debe permitir al usuario vendedor [5A] confirmar o
> > rechazar ofertas [12] generando así una compra [14].
>
>         Esto hay que reformularlo.
>
> > 16 El sistema debe gestionar formas de pago.
>
>         Falta el diccionario de esto.
>
> > 17 El sistema debe gestionar formas de envío.
>
>         Idem.
>
> > 18 El sistema debe permitir a los usuarios [4] ver compras [14] con su
> > forma de pago [16] y su forma de envío [17].
>
>         No se usa la palabra "permitir" en una funcionalidad, ya que
> justamente
> todo lo que está acá es lo que se permite hacer... y hay que ajustarlo
> para sacarle la ambigüedad del "usuario".
>
> > 19 El sistema debe permitir marcar compras [14] como entregadas al
> > usuario vendedor [5A].
>
>         Idem.
>
> > 20 El sistema debe generar reporte de libros [11] en oferta [10].
> >
> > 21 El sistema debe generar reporte de libros [11] comprados.
> >
> > 22 El sistema debe gestionar comisiones.
> >
> > 23 El sistema debe liquidar comisiones [22] a las compras [14].
>
>         Y cómo se asigna una comisión de las existentes a una venta?
>
> > 24 El sistema debe registrar liquidaciones.
> >
> > 25 El sistema debe permitir al usuario [4] ver y abonar sus
> > liquidaciones [24] pendientes.
>
>         Idem RF18
>
> > 26 El sistema debe generar un reporte de liquidaciones [24] pendientes
> > por usuario [4].
>
>         Esto también habrá que reformularlo.
>
> > Diccionario:
> >
> >
> > Localidades: Nombre.
> >
> > Direcciones: Calle, altura, localidad.
> >
> > Usuarios: Nombre usuario, clave, Nombres, Apellidos, fecha de
> > nacimiento, dirección, localidad.
> >
> > Preguntas: Texto de pregunta.
> >
> > Materia: Nombre, descripción.
> >
> > Fotos: Nombre, ubicación.
> >
> > Descripciones: Detalle de descripción.
> >
> > Libro: Nombre, materia, fotos, descripción, fotos, usuario.
> >
> > Oferta: Fecha, Libro, usuario, estado.
> >
> > Compra: Fecha, Libro, usuario, importe final, forma de pago, forma
> > de envío, estado.
> >
> > Reporte de Ofertas: Libro, fecha, usuario, estado.
> >
> > Reporte de compras: fecha, usuario, importe final, libro.
> >
> > Comisión: Porcentaje de comisión.
> >
> > Liquidación: fecha, Importe de venta, porcentaje, importe liquidación,
> > usuario.
> >
> > Reporte liquidaciones pendientes: Fecha, usuario, Importe liquidación.
>
>
>         Faltan algunas entidades en el diccionario, que te las marcho
> arriba.
>
>         Es una buena 1er versión. Mandame pronto la 2da con las
> correcciones
> así avanzamos!
>
>
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Web: http://leonardo.tadei.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20130429/7bdb8c60/attachment-0001.html>