<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Leo, escribo debajo de tus comentarios....<br><br>Jorge Di Iorio<br><br><div><div id="SkyDrivePlaceholder"></div>> From: leonardot@pegasusnet.com.ar<br>> To: php-avanzado@pato2.fi.mdp.edu.ar<br>> Date: Tue, 12 Mar 2013 09:43:28 -0300<br>> Subject: Re: [Php-avanzado] SRS Sistema de Reservas RestoBar<br>> <br>> Hola Jorge,<br>> <br>> El lun, 11-03-2013 a las 22:28 -0300, Jorge Di Iorio escribió:<br>> > Leo, Buenas Noches, acá va la nueva SRS te la pego acá directamente<br>> > así la reenviás con tus correcciones. <br>> <br>> Necesito que afinemos algunas cuestiones para que la SRS no tenga<br>> inconsistencias:<br>> <br>> <br>> > Especificación de Requerimientos <br>> > <br>> > <br>> > Sistema de Gestión de Reservas para Restaurant<br>> > <br>> > <br>> > REQUERIMIENTOS FUNCIONALES<br>> > <br>> > <br>> > 1. El sistema debe gestionar clientes.<br>> > 2. El sistema debe gestionar mesas.<br>> <br>> Parece que a la Mesa le falta en el diccionario la cantidad de<br>> cubiertos que soporta, porque si no no se sabe qué mesas podés tomar<br>> para una Reserva de X cubiertos.<br><br>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.<br><br>> > 2.1 El sistema debe mostrar un mapa con la ubicación de las mesas<br>> > según las coordenadas de la misma dentro de una tabla que simula la<br>> > superficie del restoaurant.<br>> <br>> Me desentona la palabra "tabla" en este RF, porque parece que estás<br>> diciendo cómo se va a hacer, y no qué hay que hacer... pero no afecta a<br>> la SRS en general</div><div><br></div><div>Saco Tabla...</div><div><span style="font-size: 12pt;"> </span><br>> > 3. El sistema debe gestionar días no laborales.<br>> > 4. El Sistema debe mostrar el Estado[] de las Reservas. <br>> > 5. El sistema debe registrar Reservas con su Cliente[1],<br>> > Mesas[2](opcional) y mostrar su Estado[3].<br>> <br>> En el diccionario de Reservas aparece el "turno", que me parece que es<br>> algo que hay que especificar y acotar, ya que además sirve para saber<br>> durante cuanto tiempo una Reserva impide que se tome otra en la misma<br>> mesa.</div><div><br></div><div>Son siempre dos turnos, pero dentro de un turno puede tener distintos horarios de llegada... Lo agrego, se me pasó...</div><div><span style="font-size: 12pt;"> </span></div><div>> > 5.1. El sistema debe listar las reservas posibilitando filtrarlas<br>> > dentro de un rango de fechas. <br>> > 5.1.1 El sistema debe resaltar en el listado las reservas que se<br>> > pasaron del horario de llegada sin estar ocupadas. <br>> > 5.1.2 El sistema debe resaltar en el listado las reservas que no<br>> > tienen asignadas mesas.<br>> > 5.1.3 El sistema debe resaltar en el listado las reservas que<br>> > liberaron las mesas que tenían ocupadas.<br>> <br>> Momento!<br>> Hasta acá todo se refiere a las Reservas, pero en este RF estás<br>> introduciendo el concepto de "Mesas ocupadas", y a las mesas no se las<br>> puede marcar de esa manera ni de ninguna otra.<br>> Si con esto te referís a que una Reserva se liberó, y esa Reserva hacía<br>> referencia a una Mesa, tenés que redactar esto en términos que<br>> involucren solamente a la Reserva, es decir, que lo que se libera es una<br>> Reserva y no una Mesa.<br>> Si en cambio esto implica que, además de las Reservas, se ven las Mesas<br>> ocupadas por comensales que no tienen Reservas, tenés que especificar el<br>> uso de la Mesa, que es independiente de las Reservas, si bien una<br>> Reserva puede convertirse en una Mesa Ocupada.</div><div><br></div><div><font size="3">Leo por ahí yo me expresé mal y vos te </font>enroscaste<font size="3"> 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. </font></div><div><br>> > 5.2. El Sistema debe permitir filtrar y ordenar los listados por todos<br>> > sus atributos.<br>> <br>> Sacá a palabra "permitir".<br>> Este RF se circunscribe a las Reservas, no?<br>> En realidad deberías especificar los listados, para saber cuales son<br>> sus atributos, y de ahí saber qué se ordena y qué se filtra.<br><br>saco permitir.<br><br>> > 5.3. El sistema debe mostrar el mapa de las mesas del restaurant<br>> > cuando se da de alta o se modifica una reserva.<br>> <br>> Y si no se da de alta o se modifica no se puede ver????<br>> Me parece que este RF se refiere a mostrar un mapa con Reservas de las<br>> Mesas...<br><br></div><div>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</div><div><br></div><div>> > 5.4 El sistema debe permitir asignar las mesas disponibles desde el<br>> > mapa cuando se está gestionando la reserva. <br>> <br>> Sacá a palabra "permitir".<br>> Otra vez llevás conceptos de la Reserva a la Mesa, que según esta SRS<br>> no hace nada de esto.<br>> Tal vez este RF sea: El sistema debe asignar opcionalmente a una<br>> Reserva una mesa que no tenga otras Reservas para ese momento .<br><br></div><div>Si, es correcto lo que decís... lo cambio</div><div><br></div><div>> > 5.5. El Sistema debe impedir la asignación de una mesa que ya ha<br>> > sido asignada a otra reserva en el mismo día y turno. <br>> <br>Saco éste ultimo.-<br>> <br>> > 5.6. El Sistema debe impedir realizar una reserva para un día no<br>> > laboral.<br>> > 5.7. El Sistema debe impedir realizar reservas si el Cliente se<br>> > encuentra bloqueado.<br>> > 5.8. El sistema debe impedir realizar reservas con mas de una semana<br>> > de anticipación.<br>> > <br>> > Diccionario:<br>> > • Cliente: Código, Nombre, teléfono, email, observación, bloqueado<br>> > (s/n).<br>> > • Mesa: Nombre, Coordenada_x, Coordenada_y, Observación.<br>> > • Día no Laboral: Fecha, Observación.<br>> > • Estado de Reserva: Nombre[Pendiente, Rechazado, Reservado Web,<br>> > Reservado Bar, Ocupado, Finalizado, Cancelado Cliente, Cancelado<br>> > Bar, Caído].<br>> > • Reserva: Cliente, Estado de Reserva[], Fecha, Cubiertos, Turno,<br>> > Horario Llegada, descuento, observación, Mesas.<br>> > <br>> > REQUERIMIENTOS NO FUNCIONALES <br>> > <br>> > <br>> > 1. El sistema debe ser web.<br>> > 2. El sistema debe solicitar loguin para su utilización.<br>> > 3. El sistema debe gestionar tipos de usuarios[]. <br>> > 4. El sistema debe gestionar usuarios.<br>> > 4.1: El usuario administrador debe poder gestionar todo.<br>> > 4.2: El usuario cliente debe poder loguearse o registrarse primero en<br>> > el caso de no estarlo y hacer una reserva en estado Pendiente. <br>> > 4.3: El usuario adicionista debe poder gestionar clientes y reservas. <br>> > <br>> > Diccionario:<br>> > • Tipos de usuarios[Administrador, Cliente, Adicionista]<br>> > • Usuario: Código, Nombre, Contraseña, Agrega Registros, Modifica<br>> > Registros, Elimina Registros, Modifica Usuarios.<br>> <br>> <br>> Seguimos en la versión que sigue, que espero sea la definitiva.<br>> <br>> PD: esta mezcla en la especificación de las Reservas con las Mesas, es<br>> la que posiblemente originó esa tabla rara de mesas ocupadas...<br><br>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. </div><div><br></div><div>Mañana la paso en limpio y te la vuelvo a enviar. <br><br>> -- <br>> Leonardo Tadei<br>> leonardot@pegasusnet.com.ar<br>> Web: http://leonardo.tadei.com.ar<br>> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key<br>> <br>> _______________________________________________<br>> Php-avanzado mailing list<br>> Php-avanzado@pato2.fi.mdp.edu.ar<br>> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado<br></div> </div></body>
</html>