[Php-avanzado] Especificación de Requerimientos R4

Mar Oct 23 10:59:04 ART 2012

Hola Jorge!

El mar, 23-10-2012 a las 00:14 -0300, Jorge Di Iorio escribió:
> Leo, que quiere decir "copy & paste"? No lo he escuchado nunca!

	Lo que no habías escuchado nunca era "Find & Replace" ;-)

	Esta versión de tu SRS va a ser una de las últimas.
	Más que correcciones, te planteo preguntas que me surgen para entender
bien el problema.

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

	En el diccionario de Cancha aparecen la cantidad de jugadores. Esta
cantidad tiene algún funcionamiento o es solo descriptiva? No es el
deporte el que tiene cantidad de jugadores?

	También en el diccionario figura "activa", con lo que supongo que será
sí/no. Es más prolijo y mejor especificado tener especificado "Estado"
para mostrar (no para gestionar) y decir que la cancha tiene Estado...
esto es porque yo asumo sí/no, pero no están especificados los valores
que puede tomar el "activo" que especificaste.
	Otra forma de rellenar esta omisión es poner en el diccionario ",
activa (s/n)." con lo que además del atributo mencionás los estados
posibles a tomar.

>                 5.      El sistema debe gestionar tarifas con su
> Complejo[4].
>                 6.  El Sistema debe gestionar cotas de tiempo no
> laborales de Canchas[5].

	En el diccionario el nombre de esto es parecido, pero no es el mismo.
Decidite a usar un nombre y usalo siempre.

	Tiene sentido ponerle un código a esto?

	Por las dudas, hacé que en el diccionario de las cotas no laborales en
vez de "fecha" sea "fecha y hora", así por ejemplo podrías tener en
mantenimiento una cancha solo de mañana.

>                 7.      El Sistema debe gestionar cotas de no
> laborales de Complejos[2].        
>                 8.      El sistema debe gestionar Reservas con su
> Cancha[7], Cliente[3], Tarifa[5] y estado[Reservado, Reservado Fijo,
> Confirmado, Cerrado, Pagado, Cancelado Cliente, Cancelado Complejo].

	Dejá la enumeración de los estados de Reserva solo en el  diccionario.

	Vas a permitir borrar Reservas? Acá decís que sí, pero pareciera por el
enfoque que le estás dando que no se borran, sino que en tal caso
cambian de estado... idem para las fijas y los alquileres.

	Qué significa el estado "cerrado"?
	Qué sentido tiene que una Reserva esté "pagada" habiendo por otro lado
Alquileres?
	Para qué está el estado "Reservado Fijo" acá, si las Reservas Fijas
están especificadas aparte?

>                         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 no debe permitir realizar
> reservas si el Cliente se encuentra inactivo.

	Mantené la sintaxis y poné esto como "El sistema debe impedir
reservar... "

>                 9.      El sistema debe gestionar Reservas Fijas con
> su Cliente[1], Cancha[4] y Tarifa[5](opcional).
>                         9.1.    El sistema debe permitir al usuario
> 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 al usuario
> cuando una reserva fija est llegando a su fin.
>                         9.4.    El sistema debe advertir al usuario
> cuando una reserva fija se cancele repetidas veces(la cantidad de
> cancelaciones admitida estar parametrizada en el sistema).

	Esta advertencia pasala a un RF aparte, y en el diccionario de la
advertencia, especificá esta parametrización.

>                         9.5.    El sistema debe permitir al usuario
> dar de baja una reserva fija para un da determinado y pisarla con una
> reserva comn.

	Sacá la palabra "permitir", de este y de todos los RF en que aparezcan.
El "usuario" también está fuera de lugar: todo lo que estás poniendo es
lo que puede hacer "el usuario".
	Te animás a especificar esto hablar de "pisar" la reserva?
	A mi me parece que acá hay algo que sobra y algo que falta...

	Bueno, los comentarios y preguntas se aplican también a los alquileres
y reservas fijas, así que paro acá.

	Miralo y si querés en clase mañana seguimos, o mandame una nueva
versión luego,

	Saludos!

>                         9.6.    El Sistema no debe permitir realizar
> reservas fijas si el Cliente se encuentra inactivo.
>                 10. El sistema debe gestionar Alquileres con su
> Cliente[1], Cancha y Reserva[9](Opcional).
>                         10.1.   El Sistema no debe permitir realizar
> Alquileres si el Cliente se encuentra inactivo.
>                 11.     El sistema debe mostrar el listado de Reservas
> de los clientes.
>                         11.1.   El sistema debe mostrar un listado de
> reservas con su cliente[1] filtrando por Estado y Fecha.
>                         11.2.   El sistema debe mostrar un listado de
> reservas fijas por estado por si se le debe llamar la atencion al
> cliente. 
>                 12.     El sistema debe mostrar el listado de
> Alquileres de los clientes.
>                         11.1.   El sistema debe mostrar los alquileres
> que realizo un cliente.
>                         11.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.
>                         Complejo: Cdigo, Nombre, Domicilio,
> Observacin.
>                         Deporte: Cdigo, Nombre.
>                         Cancha: Cdigo, Nombre, Deporte, Cantidad de
> Jugadores, Piso, Complejo, Observacin, Activa.
>                         Tarifa: Cdigo, Nombre, Complejo, valor,
> Observacin.
>                         Cotas no Laborales de Canchas: Cdigo, Nombre,
> Fecha de Inicio, Fecha de Fin, Cancha.
>                         Cotas no Laborales de Complejos: Cdigo,
> Nombre, Fecha de Inicio, Fecha de Fin, Complejo.
>                         Reserva: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Hora Inicio, Hora Fin, Estado[Reservado,
> Reservado Fijo, Confirmado, Cerrado, Pagado, Cancelado Cliente,
> Cancelado Complejo].
>                         Reserva Fija: Cliente, Cancha, Tarifa,
> Descuento, Recargo, Observacin, Fecha Inicio, Fecha Fin, Hora Inicio,
> Hora Fin, Dia de la Semana,Estado[Reservado, Reservado Fijo,
> Confirmado, Cerrado, Pagado, Cancelado Cliente, Cancelado Complejo].
>                         Alquiler: Cliente, Cancha, Tarifa, Descuento,
> Recargo, Observacin, Fecha, Hora Inicio, Hora Fin, Tarifa, Pago. 
>                 
>                 
>         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. 
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key