[Php-avanzado] Requerimientos funcionales (Francisco A. Almagro)

Mie Oct 2 19:09:17 ART 2013

Hola Francisco,

	tu planteo es correcto. Como en este sistema hay dos "tipos", habrá que
llamarlos a cada uno por su nombre completo... porque después de todo
siempre son un "tipo de algo".

	Suena bien "tipo de producto" y "tipo de dato".

	Ahora bien: el "tipo de producto" y "tipo de dato" no serán la misma
cosa, una en el sitio web a analizar y otra como parte de la
clasificación de los productos?

	Si son la misma cosa, entonces tendría que estar una sola vez...

El mié, 02-10-2013 a las 19:18 +0000, Francisco Almagro escribió:
> Profe, realizando las correcciones me encontre con una ambiguedad.
> Prefiero primero resolver esta ambiguedad y luego seguir con los RF.
> La ambiguedad es que yo usaba el término "producto" para referirme al
> tipo de producto(ej. Placas de Video, Gabinetes, Monitores) y "modelo"
> para el producto específico(ej. "VIDEO PCIE ASUS GT640 -1GD3-L -
> DVI-D, HDMI, D-SUB"). La ambiguedad se produce cuando yo quiero
> mencionar un producto específico solo.
> Pensé en cambiar las palabras a usar, entonces "producto" pasaría a
> ser "tipo de producto" y "modelo" a "producto". Pero tengo un
> problema, ya que el término "tipo" lo usé para gestionar los tipos de
> datos para diferenciarlos a la hora de indexar el sitio web. 
> Podría existir "tipos de datos" y "tipo de producto", o seguiria
> siendo ambiguo? Se le ocurre algun otro termino?
> 
> 
> Muchas gracias
> 
> 
> 
> > From: leonardot en pegasusnet.com.ar
> > To: php-avanzado en pato2.fi.mdp.edu.ar
> > Date: Wed, 2 Oct 2013 10:26:49 -0300
> > Subject: Re: [Php-avanzado] Requerimientos funcionales (Francisco A.
> Almagro)
> > 
> > Hola Francisco:
> > 
> > > Hola Profe! Envío los Requerimientos funcionales que realice hasta
> > > ahora.
> > 
> > Te respondo intercalado:
> > 
> > > Requerimientos funcionales para script de recolección de datos web
> de
> > > una proveedora de productos informáticas y ofrecer dichos
> productos
> > > 
> > > 1) El sistema debe recolectar datos de otro sitio web.
> > 
> > Tendrías que especificar previamente a esto una gestión del URL
> del/de
> > los sitio(s) web de los que se recolecta la información.
> > De esta forma si el URL cambia o si se agregan en el futuro otros
> > sitios, no hay que modificar el sistema.
> > 
> > > 2) El sistema debe diferenciar y clasificar los datos
> recolectados[1]
> > > segun su tipo.
> > 
> > Tenés que especificar previamente "tipo" para que este RF tenga
> > sentido.
> > 
> > > 3) El sistema debe gestionar los datos recolectados[1-2]. 
> > > 3.1) El sistema debe gestionar productos.
> > > 3.2) El sistema debe gestionar modelos.
> > 
> > Hacé una entrada en el diccionario para Producto y Modelo, para
> definir
> > qué atributos tendrá cada uno.
> > 
> > > 3.3) El sistema debe gestionar precio.
> > > 4) El sistema debe buscar productos[3.1].
> > > 5) El sistema debe buscar modelos[3.2].
> > > 6) El sistema debe mostrar los resultados de las busquedas sea de
> > > productos[4] o de modelos[5].
> > 
> > El RF6 es superfluo, porque es pare del RF4 y RF5.
> > Si querés ser así de claro, poné una entrada en el diccionario para
> > "buscar" y decís que es buscar y mostrar.
> > 
> > > 7) El sistema debe gestionar compradores.
> > 
> > Hacé una entrada en el diccionario para Comprador, para definir qué
> > atributos tendrá,
> > 
> > > 8) El sistema debe gestionar pedidos de productos[3.1] por parte
> de
> > > los compradores[7]. 
> > 
> > Hacé una entrada en el diccionario para Pedido para definir qué
> > atributos tendrá.
> > Está bien que un Pedido se pueda borrar o modificar después de
> hecho?
> > 
> > > 9) El sistema debe presupuestar pedidos[8].
> > 
> > En qué consiste el presupuestado? Una persona le pone valores a un
> > pedido? Con los precios guardados el sistema genera el presupuesto y
> lo
> > muestra o lo manda por mail?
> > 
> > > 10) El sistema debe mostrar estado de los pedidos[10].
> > 
> > El estado especificalo previamente y hacé referencia a él en el
> Pedido.
> > También poné en el diccionario que datos tiene y enumerá todos los
> > estados posibles, porque después no se podrán cambiar y ahora es el
> > momento de validarlos.
> > 
> > > Diccionario:
> > > Gestionar: Alta, baja, modificación, listar en pantalla.
> > > Recoletar: Indexar y almacenar los datos.
> > > Clasificar: Diferenciar los datos recolectados según su tipo.
> > > Tipo: 3 tipos diferentes(productos, modelos, precio)
> > > Pedido: Producto/s deseado/s.
> > > Presupuestar: Costo monetario del pedido.
> > > Estado: 3 estados diferentes(En proceso, anulado, finalizado).
> > > Compradores: Persona que se registra(o logea en caso de ya tener
> un
> > > usuario) para poder realizar pedidos.
> > > 
> > > Muchas gracias.
> > 
> > Por nada!
> > Es una buena primer versión. Mejorando estas cosas y creando un buen
> > diccionario vamos a avanzar rápido.
> > 
> > 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
> > 
> > _______________________________________________
> > 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