[Php-avanzado] SRS Sistema de Reservas RestoBar

Mie Mar 13 08:42:46 ART 2013

Hola Jorge,

	quedo entonces a la espera de la pasada en limpio, con las
apreciaciones que aparecen acá.
	Fijate el asunto de los "turnos", si tienen horario fijo de inicio y
duración/fin, o si solo tienen duración y comienzan a la hora de inicio
de la reserva, porque tiene impacto en el funcionamiento y en el
almacenamiento.

	Seguimos!

El mié, 13-03-2013 a las 00:40 -0300, Jorge Di Iorio escribió:
> Leo, escribo debajo de tus comentarios....
> 
> Jorge Di Iorio
> 
> 
> > From: leonardot en pegasusnet.com.ar
> > To: php-avanzado en pato2.fi.mdp.edu.ar
> > Date: Tue, 12 Mar 2013 09:43:28 -0300
> > Subject: Re: [Php-avanzado] SRS Sistema de Reservas RestoBar
> > 
> > Hola Jorge,
> > 
> > El lun, 11-03-2013 a las 22:28 -0300, Jorge Di Iorio escribió:
> > > Leo, Buenas Noches, acá va la nueva SRS te la pego acá
> directamente
> > > así la reenviás con tus correcciones. 
> > 
> > Necesito que afinemos algunas cuestiones para que la SRS no tenga
> > inconsistencias:
> > 
> > 
> > > Especificación de Requerimientos 
> > > 
> > > 
> > > Sistema de Gestión de Reservas para Restaurant
> > > 
> > > 
> > > REQUERIMIENTOS FUNCIONALES
> > > 
> > > 
> > > 1. El sistema debe gestionar clientes.
> > > 2. El sistema debe gestionar mesas.
> > 
> > Parece que a la Mesa le falta en el diccionario la cantidad de
> > cubiertos que soporta, porque si no no se sabe qué mesas podés tomar
> > para una Reserva de X cubiertos.
> 
> En realidad yo pensé lo mismo, pero las mesas las asignan ello a su
> criterio y los cubiertos van de la mano de la reserva. La mesa es por
> el mero hecho de la ubicación y para saber que tienen un lugar
> asignado.
> 
> > > 2.1 El sistema debe mostrar un mapa con la ubicación de las mesas
> > > según las coordenadas de la misma dentro de una tabla que simula
> la
> > > superficie del restoaurant.
> > 
> > Me desentona la palabra "tabla" en este RF, porque parece que estás
> > diciendo cómo se va a hacer, y no qué hay que hacer... pero no
> afecta a
> > la SRS en general
> 
> 
> Saco Tabla...
>  
> > > 3. El sistema debe gestionar días no laborales.
> > > 4. El Sistema debe mostrar el Estado[] de las Reservas. 
> > > 5. El sistema debe registrar Reservas con su Cliente[1],
> > > Mesas[2](opcional) y mostrar su Estado[3].
> > 
> > En el diccionario de Reservas aparece el "turno", que me parece que
> es
> > algo que hay que especificar y acotar, ya que además sirve para
> saber
> > durante cuanto tiempo una Reserva impide que se tome otra en la
> misma
> > mesa.
> 
> 
> Son siempre dos turnos, pero dentro de un turno puede tener distintos
> horarios de llegada... Lo agrego, se me pasó...
>  
> > > 5.1. El sistema debe listar las reservas posibilitando filtrarlas
> > > dentro de un rango de fechas. 
> > > 5.1.1 El sistema debe resaltar en el listado las reservas que se
> > > pasaron del horario de llegada sin estar ocupadas. 
> > > 5.1.2 El sistema debe resaltar en el listado las reservas que no
> > > tienen asignadas mesas.
> > > 5.1.3 El sistema debe resaltar en el listado las reservas que
> > > liberaron las mesas que tenían ocupadas.
> > 
> > Momento!
> > Hasta acá todo se refiere a las Reservas, pero en este RF estás
> > introduciendo el concepto de "Mesas ocupadas", y a las mesas no se
> las
> > puede marcar de esa manera ni de ninguna otra.
> > Si con esto te referís a que una Reserva se liberó, y esa Reserva
> hacía
> > referencia a una Mesa, tenés que redactar esto en términos que
> > involucren solamente a la Reserva, es decir, que lo que se libera es
> una
> > Reserva y no una Mesa.
> > Si en cambio esto implica que, además de las Reservas, se ven las
> Mesas
> > ocupadas por comensales que no tienen Reservas, tenés que
> especificar el
> > uso de la Mesa, que es independiente de las Reservas, si bien una
> > Reserva puede convertirse en una Mesa Ocupada.
> 
> 
> Leo por ahí yo me expresé mal y vos te enroscaste demasiado. Como vos
> bien decís al principo, me refiero a una "reserva liberada". Ésto
> pense que vaya determinado según el estado de la reserva. es decir,
> que en el estado se determine si esa mesa se puede reasignar o no. se
> entiende? por ahí yo no lo explique bien, pero olvidate de "ocupado",
> son siempre mesas asignadas.  que no se pueden reasignar a otra
> reserva si ya hay una para ese turno y fecha. A partir de cuando se
> libera el turno se podrían reasignar las mesas.   
> 
> > > 5.2. El Sistema debe permitir filtrar y ordenar los listados por
> todos
> > > sus atributos.
> > 
> > Sacá a palabra "permitir".
> > Este RF se circunscribe a las Reservas, no?
> > En realidad deberías especificar los listados, para saber cuales son
> > sus atributos, y de ahí saber qué se ordena y qué se filtra.
> 
> saco permitir.
> 
> > > 5.3. El sistema debe mostrar el mapa de las mesas del restaurant
> > > cuando se da de alta o se modifica una reserva.
> > 
> > Y si no se da de alta o se modifica no se puede ver????
> > Me parece que este RF se refiere a mostrar un mapa con Reservas de
> las
> > Mesas...
> 
> 
> si no se va a dar de alta una nueva o modificar alguna no se puede
> ver .... lo tendría que mostrar no.... jejejejej. ahora lo agrego. lo
> que pasa que con el solo hecho de poner nueva reserva ya te muestra el
> mapa... entonces lo ven por ahí. Lo hice un poco a las apuradas che!
> ajjaja
> 
> 
> > > 5.4 El sistema debe permitir asignar las mesas disponibles desde
> el
> > > mapa cuando se está gestionando la reserva. 
> > 
> > Sacá a palabra "permitir".
> > Otra vez llevás conceptos de la Reserva a la Mesa, que según esta
> SRS
> > no hace nada de esto.
> > Tal vez este RF sea: El sistema debe asignar opcionalmente a una
> > Reserva una mesa que no tenga otras Reservas para ese momento .
> 
> 
> Si, es correcto lo que decís... lo cambio
> 
> 
> > > 5.5. El Sistema debe impedir la asignación de una mesa que ya ha
> > > sido asignada a otra reserva en el mismo día y turno. 
> > 
> Saco éste ultimo.-
> > 
> > > 5.6. El Sistema debe impedir realizar una reserva para un día no
> > > laboral.
> > > 5.7. El Sistema debe impedir realizar reservas si el Cliente se
> > > encuentra bloqueado.
> > > 5.8. El sistema debe impedir realizar reservas con mas de una
> semana
> > > de anticipación.
> > > 
> > > Diccionario:
> > > • Cliente: Código, Nombre, teléfono, email, observación, bloqueado
> > > (s/n).
> > > • Mesa: Nombre, Coordenada_x, Coordenada_y, Observación.
> > > • Día no Laboral: Fecha, Observación.
> > > • Estado de Reserva: Nombre[Pendiente, Rechazado, Reservado Web,
> > > Reservado Bar, Ocupado, Finalizado, Cancelado Cliente, Cancelado
> > > Bar, Caído].
> > > • Reserva: Cliente, Estado de Reserva[], Fecha, Cubiertos, Turno,
> > > Horario Llegada, descuento, observación, Mesas.
> > > 
> > > REQUERIMIENTOS NO FUNCIONALES 
> > > 
> > > 
> > > 1. El sistema debe ser web.
> > > 2. El sistema debe solicitar loguin para su utilización.
> > > 3. El sistema debe gestionar tipos de usuarios[]. 
> > > 4. El sistema debe gestionar usuarios.
> > > 4.1: El usuario administrador debe poder gestionar todo.
> > > 4.2: El usuario cliente debe poder loguearse o registrarse primero
> en
> > > el caso de no estarlo y hacer una reserva en estado Pendiente. 
> > > 4.3: El usuario adicionista debe poder gestionar clientes y
> reservas. 
> > > 
> > > Diccionario:
> > > • Tipos de usuarios[Administrador, Cliente, Adicionista]
> > > • Usuario: Código, Nombre, Contraseña, Agrega Registros, Modifica
> > > Registros, Elimina Registros, Modifica Usuarios.
> > 
> > 
> > Seguimos en la versión que sigue, que espero sea la definitiva.
> > 
> > PD: esta mezcla en la especificación de las Reservas con las Mesas,
> es
> > la que posiblemente originó esa tabla rara de mesas ocupadas...
> 
> Es que ello en un principio lo unico que llevaban era un listado de
> nombre, turno, cubiertos, hora, que era una reserva. Luego surgió lo
> de ver el "mapita del lugar" y poder asignarle mesas para  que cuando
> van llegando clientes eventuales sin reserva ver si los pueden
> acomodar rápido en alguna mesa y ya lo cargan como una reserva en
> estado ocupado.  
> 
> 
> Mañana la paso en limpio y te la vuelvo a enviar. 
> 
> > -- 
> > 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
> 
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado

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