<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, <div><br></div><div> 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!</div><div><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: Wed, 13 Mar 2013 08:42:46 -0300<br>> Subject: Re: [Php-avanzado] SRS Sistema de Reservas RestoBar<br>> <br>> Hola Jorge,<br>> <br>> quedo entonces a la espera de la pasada en limpio, con las<br>> apreciaciones que aparecen acá.<br>> Fijate el asunto de los "turnos", si tienen horario fijo de inicio y<br>> duración/fin, o si solo tienen duración y comienzan a la hora de inicio<br>> de la reserva, porque tiene impacto en el funcionamiento y en el<br>> almacenamiento.<br>> <br>> Seguimos!<br>> <br>> <br>> El mié, 13-03-2013 a las 00:40 -0300, Jorge Di Iorio escribió:<br>> > Leo, escribo debajo de tus comentarios....<br>> > <br>> > Jorge Di Iorio<br>> > <br>> > <br>> > > 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á<br>> > 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<br>> > criterio y los cubiertos van de la mano de la reserva. La mesa es por<br>> > el mero hecho de la ubicación y para saber que tienen un lugar<br>> > 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<br>> > 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<br>> > afecta a<br>> > > la SRS en general<br>> > <br>> > <br>> > Saco Tabla...<br>> > <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<br>> > es<br>> > > algo que hay que especificar y acotar, ya que además sirve para<br>> > saber<br>> > > durante cuanto tiempo una Reserva impide que se tome otra en la<br>> > misma<br>> > > mesa.<br>> > <br>> > <br>> > Son siempre dos turnos, pero dentro de un turno puede tener distintos<br>> > horarios de llegada... Lo agrego, se me pasó...<br>> > <br>> > > > 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<br>> > 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<br>> > 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<br>> > una<br>> > > Reserva y no una Mesa.<br>> > > Si en cambio esto implica que, además de las Reservas, se ven las<br>> > Mesas<br>> > > ocupadas por comensales que no tienen Reservas, tenés que<br>> > especificar el<br>> > > uso de la Mesa, que es independiente de las Reservas, si bien una<br>> > > Reserva puede convertirse en una Mesa Ocupada.<br>> > <br>> > <br>> > Leo por ahí yo me expresé mal y vos te enroscaste demasiado. Como vos<br>> > bien decís al principo, me refiero a una "reserva liberada". Ésto<br>> > pense que vaya determinado según el estado de la reserva. es decir,<br>> > que en el estado se determine si esa mesa se puede reasignar o no. se<br>> > entiende? por ahí yo no lo explique bien, pero olvidate de "ocupado",<br>> > son siempre mesas asignadas. que no se pueden reasignar a otra<br>> > reserva si ya hay una para ese turno y fecha. A partir de cuando se<br>> > libera el turno se podrían reasignar las mesas. <br>> > <br>> > > > 5.2. El Sistema debe permitir filtrar y ordenar los listados por<br>> > 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<br>> > las<br>> > > Mesas...<br>> > <br>> > <br>> > si no se va a dar de alta una nueva o modificar alguna no se puede<br>> > ver .... lo tendría que mostrar no.... jejejejej. ahora lo agrego. lo<br>> > que pasa que con el solo hecho de poner nueva reserva ya te muestra el<br>> > mapa... entonces lo ven por ahí. Lo hice un poco a las apuradas che!<br>> > ajjaja<br>> > <br>> > <br>> > > > 5.4 El sistema debe permitir asignar las mesas disponibles desde<br>> > 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<br>> > 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>> > <br>> > Si, es correcto lo que decís... lo cambio<br>> > <br>> > <br>> > > > 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<br>> > 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<br>> > 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<br>> > 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,<br>> > 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<br>> > nombre, turno, cubiertos, hora, que era una reserva. Luego surgió lo<br>> > de ver el "mapita del lugar" y poder asignarle mesas para que cuando<br>> > van llegando clientes eventuales sin reserva ver si los pueden<br>> > acomodar rápido en alguna mesa y ya lo cargan como una reserva en<br>> > estado ocupado. <br>> > <br>> > <br>> > 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>> > <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>> <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> </div></body>
</html>