[Php-avanzado] Especificación de Requerimientos R5
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Vie Oct 26 12:00:34 ART 2012
Hola Jorge,
El jue, 25-10-2012 a las 01:11 -0300, Jorge Di Iorio escribió:
> Le hice todas las modificaciones que charlamos en clase...
>
> Jorge Di Iorio
>
>
>
>
>
>
>
>
> documento de
> texto sencillo
> adjunto
> (Requerimientos
> JD.txt)
>
> Especificacin de Requerimientos
>
> Sistema de Gestin de Reservas y Alquileres de Complejos Deportivos
>
> REQUERIMIENTOS FUNCIONALES
>
> 1. El sistema debe gestionar clientes.
> 2. El sistema debe gestionar complejos.
> 3. El Sistema debe gestionar deportes.
> 4. El sistema debe gestionar Canchas con su
> Complejo[4] y Deportes[6].
Para ser consistente, el diccionario de Cancha debería decir
"deporteS".
> 5. El sistema debe gestionar tarifas con su
> Complejo[4].
> 6. El Sistema debe gestionar cotas no laborales de
> Canchas[5].
> 7. El Sistema debe gestionar cotas no laborales
> de Complejos[2].
> 8. El sistema debe gestionar Reservas con su
> Cancha[7], Cliente[3], Tarifa[5] y mostrar su estado.
Te olvidaste de especificar antes de esto el mostrar los Estados de
Reservas !!!
El "estado" te va a quedar entonces con un [] con la referencia al RF.
Las Reservas se pueden borrar??? Porque acá dice que sí...
> 8.1. El sistema debe mostrar las Reservas
> dadas filtrando por fechas, complejo, cancha y deporte.
> 8.2. El Sistema debe impedir la Reserva de
> una cancha de un complejo si la misma pertenece a un complejo que se
> encuentra en una cota de Tiempo de inactividad.
> 8.3. El Sistema debe impedir la Reserva de
> una cancha si la misma se encuentra en una cota de Tiempo de
> inactividad.
> 8.4. El Sistema debe impedir realizar
> reservas si el Cliente se encuentra inactivo.
> 9. El sistema debe gestionar Reservas Fijas con
> su Cliente[1], Cancha[4] y Tarifa[5](opcional) y mostrar su estado..
Idem RF8
> 9.1. El sistema debe realizar una reserva
> fija un determinado da de la semana y dejarla hecha en el calendario
> hasta una fecha de vencimiento.
> 9.2. El sistema debe mostrar en el
> calendario todas las Reservas fijas.
> 9.3. El sistema debe advertir cuando una
> reserva fija est llegando a su fin.
Con un cartel? manda un mail? te lama por teléfono?
Cuál es la naturaleza de la "advertencia"?
Cómo se determina "llegando a su fin"?
Esto es muy ambiguo!!!
> 9.4. El sistema debe dar de baja una
> reserva fija para un da determinado y realizar una reserva "comn" para
> otro cliente.
> 9.5. El Sistema no debe realizar reservas
> fijas si el Cliente se encuentra inactivo.
> 10. El sistema debe advertir cuando una reserva
> fija se cancele repetidas veces(la cantidad de cancelaciones admitida
> estar en los parametros del sistema).
> 11. El sistema debe gestionar Alquileres con su
> Cliente[1], Cancha, Reserva[9](Opcional) y mostrar su estado..
> 11.1. El Sistema no debe realizar Alquileres
> si el Cliente se encuentra inactivo.
> 12. El sistema debe mostrar el listado de Reservas
> de los clientes.
> 12.1. El sistema debe mostrar un listado de
> reservas con su cliente[1] filtrando por Estado y Fecha.
Estado va a tener su [] atrás...
> 12.2. El sistema debe mostrar un listado de
> reservas fijas por estado por si se le debe llamar la atencion al
> cliente.
No tiene sentido poner acá para qué se emite el listado, ya que según
decís la decisión la tomará una persona. Este RF se acaba en la palabra
"estado []".
> 13. El sistema debe mostrar el listado de
> Alquileres de los clientes.
> 13.1. El sistema debe mostrar los alquileres
> que realizo un cliente.
> 13.2. El sistema debe mostrar un listado de
> los alquileres con su cliente[1] filtrando por Fecha.
>
> Diccionario:
> Cliente: Cdigo, Nombre, dni, domicilio,
> telfono fijo, telfono celular, email, observacin, activo (s/n).
> Complejo: Cdigo, Nombre, Domicilio,
> Observacin.
> Deporte: Cdigo, Nombre.
> Cancha: Cdigo, Nombre, Deporte, Complejo,
> Observacin.
> Tarifa: Cdigo, Nombre, Complejo, valor,
> Observacin.
> Cotas no Laborales de Canchas: Detalle, Fecha
> y Hora de Inicio, Fecha y Hora de Fin, Cancha.
> Cotas no Laborales de Complejos: Detalle,
> Fecha de Inicio, Hora de Inicio, Fecha de Fin, Hora de Fin, Complejo.
> Estado de Reserva: Nombre[Reservado,
> Confirmado, Cancelado Cliente, Cancelado Complejo, Caido], Color.
> Reserva: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Hora Inicio, Hora Fin, Estado de Reserva.
> Estado de Reserva Fija: Nombre[Cancelado
> Cliente, Cancelado Complejo, Caido, Reasignado], Color.
> Reserva Fija: Cliente, Cancha, Tarifa,
> Descuento, Recargo, Observacin, Fecha Inicio, Fecha Fin, Hora Inicio,
> Hora Fin, Dia de la Semana,Estado de Reserva Fija.
> Estado de Alquiler: Nombre[Pendiente de Pago,
> Pago, Bonificado], Color.
> Alquiler: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Hora Inicio, Hora Fin, Tarifa, Pago(s/n),
> Con Reserva(s/n), Estado de Alquiler.
> Parametros del Sistema: Nombre, Valor. (ej:
> nombre:"cantidad de cancelaciones admitida", Valor:5)
Seguro que no... toda entrada en el diccionario existe porque hace
referencia a un RF, pero no hay un RF de "Parametros del Sistema", lo
cual está bien, porque estos parámetros que nombrás son claramente un
tema de diseño y no de especificación.
Reveé los RF que hablan de parámetros, no nombres el parámetro y
especificá cuál es la condición o el nombre de la condición que
determina esto.
>
> REQUERIMIENTOS NO FUNCIONALES
>
> 1. El sistema debe ser web.
> 2. El sistema debe solicitar loguin para su
> utilizacin.
> 3. El sistema debe gestionar usuarios.
>
> Diccionario:
> Usuario: Cdigo, Nombre, Contrasea,
> Agrega Registros, Modifica Registros, Elimina Registros, Modifica
> Usuarios.
... y creo que la próxima versión debería ser la última.
Seguimos!
--
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-avanzado