[Php-avanzado] Sugerencia
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Sab Dic 12 00:55:17 ART 2015
Hola Martín,
te paso unas correcciones menores y respuestas, para después verlo con
más tiempo en una nueva versión:
El vie, 11-12-2015 a las 22:52 -0300, Martin Urciuoli escribió:
> Le adjunto version uno y pregunto:
> ¿El diccionario tengo que ponerlo antes que los requerimientos
> funcionales?
Va después, porque es como una aclaración de las funcionalidades;
> Las Compras no se gestionan porque no debo borrarlas, ¿cómo las
> defino?
> El sistema debe ______ compras.
El sistema debe registrar compras con su...
Te repito parte del mail anterior: las Ciudades, Provincias, Tipos de
Cliente y Tipo de comprador lo tenés que especificar _antes_ del
Cliente, porque el Cliente tiene que tener en que especificación
funcional que tiene estas cosas!!!
Los Proveedores tienen algunas: así está incompleto.
Lo que pusiste como 5.1 y 5.2 son subrequerimientos del 4. No se puede
poner entre los RF a qué cosas accede cada quién, porque eso es un RNF
(o no lo pongas [va, pero no se pide], o creá una sección de RNF para
ponerlo)
Los 6.1 y 6.2 son RF independientes.
Si vas a unificar los clientes clasificándolos por tipo, por qué tenés
todavía 2 clientes en el diccionario?
> Gracias!
Por nada!
> El 11 de diciembre de 2015, 19:41, Leonardo Tadei - Pegasus Tech
> Supply <leonardot en pegasusnet.com.ar> escribió:
> Hola Martín,
>
> copio y pego la SRS y te la comento:
>
> Primera cuestión: en los atributos NO van IDs ni nada
> que tenga que ver
> con cómo se hará el software. En la SRS se dice qué software
> se va a
> hacer, no cómo hacerlo (y es una decisión de cómo hacerlo por
> ejemplo
> usar claves artificiales o naturales o ni siquiera usar una
> DB...)
>
> Segunda cuestión: la palabra "permitir" no va, porque
> viola varios
> principios de la SRS. Todo lo que está acá escrito es lo que
> se va a
> permitir hacer!
>
> RF1 y 2: no parece haber diferencias significativas
> entre los dos tipos
> de clientes, para que no se pueda tener un solo tipo que tenga
> como
> atributo "tipo de cliente"... Si se identifica con CUIT o DNI
> podría ser
> también un "tipo de identificación".
> Según el diccionario, te falta especificar _antes_ del
> o los clientes:
> Ciudades, Provincias, Tipos de Comprador al menos.
> No sé que es "regimen que se aplica"...
> Luego en las funcionalidades, hacer mención a todas
> estas cosas como
> parte del cliente.
>
> RF3: te falta especificar _antes_ (no depués) las
> Categorías y hacer
> referencia a ellas "El sistema debe gestionar Productos con
> sus
> Categorías".
> te falta especificar _antes_ (no depués) los
> Proveedores, para poder
> referenciarlos en el Producto.
> Pregunta: un producto tiene un único proveedor?
> Todas las formas de ver Productos ponelas como
> subrequerimientos del
> Producto, no por separado.
>
> RF7: te falta hacer referencia a la Ciudad y
> Provincia.
>
> RF10: está bien, pero "gestor" en un texto que habla a
> cada rato de
> "gestionar" suena confuso... Si querés dejala, porque,
> insisto, está
> bien, pero tal vez sea bueno algún sinónimo como
> "administrador" o
> "encargado" o "responsable".
>
> RF13: esto es una no-funcionalidad. No va acá.
>
> RF14: y los datos del cliente? qué es "detalle de
> compra"? Son los
> productos y sus cantidades? Lo tenemos que adivinar? Hay
> dirección de
> envío?
> Respecto de los Transportistas, si te hacen falta para
> el Remito,
> entonces tenés que especificarlos para gestionarlos... (lo de
> hacer una
> tabla no es tema que nos ocupa acá... dejá de pensar en cómo
> hacerlo
> cuando todavía no sabés qué hacer!)
>
> RF15: y el diccionario? Vas a emitir facturas
> fiscales???
>
> RF16: y el diccionario?
>
> Respecto a tu aclaración final, sirve junto con
> algunas
> funcionalidades, para darse cuenta de que faltó algo, que no
> es menor:
> no especificaste la compra!!!
>
> Está buena como versión 0. Ahora metele pata y hacé
> rápido la versión
> 0.1 para no perder el envión!!!
>
>
>
> -----------------------------------------------------
>
> fleaMarket.com // MercadoDePulgas.com
> -------------------------------------
>
> El proyecto consiste en el desarrollo de una aplicación Web
> que
> permita gestionar la venta de Producto Varios de manera
> online.
>
> 1. El sistema debe gestionar Clientes Minoristas.
> 2. El sistema debe gestionar Clientes Mayoristas.
> 3. El sistema debe gestionar Productos.
> 4. El sistema debe gestionar Categorias de Productos [3].
> 5. El sistema debe listar Productos por Categorías
> [3][4].
> 6. El sistema debe permitir buscar Productos por
> Categorías [3][4].
> 7. El sistema debe gestionar Proveedores.
> 8. El sistema debe permitir buscar Productos por Nombre,
> para ambos
> tipos de Clientes.
> 9. El sistema debe permitir buscar Productos por
> Descripción, para
> ambos tipos de Clientes.
> 10. El sistema debe gestionar Gestores.
> 11. El sistema debe permitir buscar Productos por
> Proveedor, para el
> Gestor. [7][10]
> 12. El sistema debe permitir buscar Productos por fecha de
> alta,
> para el Gestor.[10]
> 13. El sistema debe gestionar Permisos???.
> 14. El sistema debe emitir Remitos
> 15. El sistema debe emitir Facturas
> 16. El sistema debe notificar mediante email al Cliente
> Minorista o
> Mayorista que su pedido fue realizado, junto con un detalle
> del pedido.
>
> Aclaración que no se donde especificarlo: según el tipo de
> cliente que
> se logué vera una lista de precios diferente.
>
> Diccionario
> -----------
>
> Cliente Minorista: ID_CM, DNI, nombre, apellido, dirección,
> ciudad,
> provincia, e-mail, teléfono, contraseña, fecha de “alta de
> cliente”,tipo
> de comprador(asiduo, “podría guardar como un ranking para que
> acceda a
> descuentos por buen cliente”).
>
> Cliente Mayorista: ID_CMY, Nombre/Razón Social, dirección,
> ciudad,
> provincia, cuit, mail, tel, fecha de “alta de
> cliente”,”régimen que se
> le aplica”, plazo de pago .
>
> Producto: ID_Productos, Nombre, Descripción, COD/REF,
> Cantidad por
> Bulto, Categorias ( puede ser una o muchas), Costo,
> Precio_publico,
> Precio_Mayorista , fecha de alta, ID_Prov.
> ## Duda el proveedor puede también ser cliente mayorista, en
> ese caso
> como debo expecificarlo. ¿Agrego otro campo a proveedores?
>
> Categoría: ID_Categoria, Nombre, Descripción. (ej: Novedades,
> Ofertas,Bazar,Herramientas, Jardineria,etc)
>
> Proveedor: ID_prov, Nombre/Razón Social, dirección, ciudad,
> provincia,
> cuit, mail, tel, Saldo.
>
> Gestor: persona que se ocupará de la carga del sistema.
> Creación de los
> Productos, y sus
> correspondientes Categorías. No podrá modificar la estructura
> de la base
> de datos.
>
> Remito: id_remito, numero, Nombre/Razon Social de la
> Empresa(que envía),
> detalle de compra, fecha, ID_CMY.
> ## El remito sería lo que se le envía por mail al cliente.
> ¿Tendria que
> expecificar transportista? Y en ese caso ¿tendría que tener
> una tabla
> de Transportistas?
>
> Factura:
>
> Permisos: ## ¿como los defino?
>
> El vie, 11-12-2015 a las 18:46 -0300, Martin Urciuoli
> escribió:
> > Hola profesor le adjunto la versión 0 de la SRS.
> > Saludos
>
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Web: http://leonardo.tadei.com.ar
> Firma pública:
> http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Lista de correo: Php-avanzado
> Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> Administración Web:
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> Desubscripción:
> php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
>
>
> _______________________________________________
> Lista de correo: Php-avanzado
> Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> Administración Web: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> Desubscripción: php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
--
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