[Php-avanzado] Auto-clas Re:

[Leonardo Tadei - Pegasus Tech Supply]

Hola Carlos,

	Está muy buena.
	Habrás notado si estás leyendo las idas y vueltas de otras SRS, que
hacerla sirve para descubrir  acotar al detalle funcionalidades que a
veces pensamos vagamente, pero que todavía no están completamente
definidas.
	De hecho, confeccionar una SRS sirve tanto para comprender lo que hay
que hacer como para indicárselo a otros.
	Vamos a pulirla.
	Primero: los requerimientos funcionales empiezan con "El sistema debe",
y no con otra fórmula parecida, como el futuro que usás en algunos
casos. Siempre, siempre "El sistema debe..."
	A esta altura debe parecerles un capricho mio, pero por un lado la
definición de SRS que estamos usando es de la IEEE, y por otro es de
veras efectivo para cuando pensamos las cosas decir lo que el sistema
debe hacer, y no otras cosas de alrededor.

	El resto va intercalado:

El lun, 06-07-2009 a las 20:14 +0200, Carlos Brandes escribió:
> Leonardo aca te mando mi version 1.0 de Auto-Clas

	Es la versión 1.0 de la SRS o del sistema?

> Auto-clas  v1.0
> 
> Auto-clas es un sitio dedicado a la publicación de avisos clasificados
> gratuitos de automotores en internet.
> 
> Para poder publicar un aviso es preciso ser un usuario registrado,
> dicho registro se realizara por medio de un breve formulario por única
> vez.
> 
> Los datos personales de los avisos serán enviados a los interesados.

	Qué son los "datos personales de los avisos"???
	Sin una definición en el glosario de "aviso" esto no queda nada
claro...

> El sistema será acotado al rubro automotores,  pero debe permitir en
> un futuro ser modificado para admitir otros rubros como por ejemplo el
> inmobiliario,  teniendo siempre la misma operatoria de envió de los
> datos a los interesados y el registro para poder publicar.
> 
> Se intentara seducir a los interesados para que se registren con la
> promesa de recibir por mail los rubros que el coloque como “de
> interés”  en la inscripción,

	No hay un requerimiento para gestionar los rubros que son nombrados
acá.

>  pero no será obligatorio para recibir los datos  de los avisos.

	Esto significa que un usuario puede darse de alta y no querer recibir
datos de ningún rubro?
	Si significa esto, es bastante difícil darse cuenta por la forma en que
lo expresaste...

> Requerimientos:
> 
> 1.      El sistema debe gestionar avisos.

	Al Glosario con los datos que constarán en los avisos!

> 2.      El sistema debe gestionar usuarios e interesados.

	Los usuarios no son un requerimiento funcional... y si marcar el
interés es opcional, sin dudas que los interesados y los usuarios no
pueden estar en el mismo requerimiento.

> 3.      El sistema previo al intento de publicación de un aviso,
> verificara la situación de registro de los usuarios, si el mismo esta
> registrado permitirá la publicación, caso contrario el sistema
> indicara que debe registrarse y mostrara el formulario diseñado para
> tal fin, en dicho registro se solicitara el segmento de interés del
> usuario(4x4, sedan 4 puertas etc.).

	Esto está expresado muy bien... pero no es un requerimiento funcional.
	Esto es un "caso de uso".
	Los casos de uso son muy esclarecedores para ilustrar como es el
circuito de uso de ciertos requerimientos. Creá una sección "Casos de
uso" y pasalo ahí.


> 4.      El sistema llevara un registro estadístico de las operaciones
> realizadas y de los usuarios que las realizaron.

	Esto es ambiguo:  tenés que expresar la naturaleza de la estadística, y
si son varias, habrá un requerimiento por cada una.

> 5.      El sistema deberá colocar una fecha de caducidad de los
> avisos, el mismo debe estar sujeto a la cantidad de avisos publicados,
> es decir si la cantidad de avisos publicados esta por debajo de un
> mínimo el aviso durara 30 días, si dicha cantidad supera ese mínimo el
> aviso durara 20 días, vencido dicho plazo se le informara por medio de
> un email al usuario si quiere renovar su aviso. Si el usuario no
> accede a renovar su aviso el mismo será dado de baja. 

	Bueno, como te decía más arriba, nada de futuros.
	Qué te parece redactar esto de nuevo pero apuntando a la función? Por
ejemplo "El sistema debe caducar los avisos"... "El sistema debe enviar
un aviso de que un aviso caduca dentro de 3 días"... y así cubriendo las
3 o 4 funcionalidades que están acá adentro medio pegoteadas.
	Que varios requerimientos se usen a la vez en un caso de uso, no
significa que son un solo requerimiento.

> 6.      Tres días antes de que se cumpla la fecha de caducidad del
> aviso el sistema enviara un correo indicando al usuario que debe
> actualizar su aviso.

	El sistema debe!

> 7.      El sistema enviara en forma automática los datos de los avisos
> al interesados, previo intento de su registro, si el usuario no accede
> al mismo, de todos modos recibirá dichos datos.

	El sistema debe!!

> 8.      El sistema enviara en forma automática a los
> usuarios/interesados registrados los avisos que contengan los
> segmentos que colocaron en la registración.

	El sistema debe!!!

> Requerimientos no Funcionales:
> 
> 1.      El sistema debe permitir subir avisos con hasta 3 imágenes del
> automóvil a publicar.

	Esto es más bien la definición de los datos que tiene un aviso, y por
tanto irá en el glosario, y no como un requerimiento no funcional.

> 2.      El sistema debe limitar al máximo la libertad del usuario para
> cargar los datos del vehículo a publicar para evitar errores en la
> publicación.

	Este sí es no funcional.

> Glosario:
> 
> Usuario: Individuo que desea publicar un aviso clasificado.

	Nones... hablando de software, el "usuario" es la entidad que hace
login.
	Tenés que buscar una mejor palabra, porque en los requerimientos estás
mezclando a este usuario con la entidad a la que referencian los
avisos... por esto no te observé en todos los requerimientos en los que
aparece la palabra "usuarios".
	Abajo pongo un ejemplo absurdo para ilustrar esto.

> Interesado: Individuo que intenta obtener los datos de algún aviso
> clasificado.

	Mmm.... pero más arriba decís que el interés se selecciona por grupo.
Es por grupo o por aviso???


Ejemplo absurdo:

Un sistema de una biblioteca en que los socios pueden reservar por la
web, y pasar a retirar los libros:

Caso de uso:

"El usuario hace una reserva de un libro que esté disponible. Luego el
usuario revisa las reservas del día y las prepara para ser retiradas.
Entonces, el usuario pasa a retirar el libro; cuando llega, ingresa su
código de usuario y el usuario revisa en pantalla si tiene deuda: si no
tiene imprime un comprobante de entrega y se lo da al usuario para que
lo firme; si tiene deuda, el usuario va hasta la caja en donde el
usuario registra el pago y entrega un comprobante de pago..."

	La cuestión es que un sistema tiene muuuuchos usuarios, incluso algunos
de ellos jamás lo verán ni usarán.
	Nosotros restringimos la palabra "usuario" para indicar a quién hace
login.
	El el caso de uso anterior, hay por lo menos "bibliotecarios", "socios"
y "cajeros", que el sistema deberá gestionar o no, pero si hace falta
gestionarlos es algo que emana de los requerimientos como justificación.

	En tu sistema, Carlos, qué es el "usuario"???


	Seguimos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key