[Php-avanzado] SRS Sistema de Reservas RestoBar

[Leonardo Tadei - Pegasus Tech Supply]

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.

> 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

>    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.

> 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.

> 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.

> 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...

> 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 .

> 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. 

	Este es el mismo de arriba, pero en negativo. Sacá uno de los dos.

> 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...


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