[Php-avanzado] SRS Sistema de Reservas RestoBar

Jorge Di Iorio jorgediiorio en hotmail.com
Lun Mar 18 15:21:07 ART 2013


Leo, 
       Buenas tardes, te adjunto la SRS modificada. Le hice los retoques que habíamos visto. Si está todo ok te envío el DER. Saludos!

Jorge Di Iorio

> From: leonardot en pegasusnet.com.ar
> To: php-avanzado en pato2.fi.mdp.edu.ar
> Date: Wed, 13 Mar 2013 08:42:46 -0300
> Subject: Re: [Php-avanzado] SRS Sistema de Reservas RestoBar
> 
> 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
> 
> _______________________________________________
> 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/20130318/a7a8196e/attachment-0001.html>
------------ próxima parte ------------
An embedded and charset-unspecified text was scrubbed...
Name: SRS.txt
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20130318/a7a8196e/attachment-0001.txt>


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