[Php-objetos] Jorge Re: Tesis - Requerimientos

[Leonardo Tadei - Pegasus Tech Supply]

Hola Jorge!

El vie, 27-02-2009 a las 23:14 +0000, castorin en mdp.edu.ar escribió:
> >> El sistema debe:
> >>
> >> - Gestionar usuarios de la biblioteca
> >
> > 	Perfecto. En el diccionario más abajo está el Usuario. Lo paso acá
> > arriba para comentar el diccionario en el contexto de este
> > requerimiento:
> > -----
> >> Usuario
> >>
> >> Persona que puede registrar transacciones en el sistema.
> >
> > 	"Transacción" es vocabulario de bases de datos... toda cosa que pase,
> > pensada así, será una transacción!!!
> > 	La idea es determinar cual es el problema a resolver, el sistema a
> > construir, en términos del dominio del problema.
> >
> 
> No se si hay un termino que englobe préstamos, devoluciones, etc... en una
> sola palabra, si fuera necesario podriamos usar "movimiento"?

	Es que justamente acá no hay que englobar nada.
	La SRS es el documento que le darás a una empresa de desarrollo para
que te cotice, o a tu equipo de trabajo para que lo diseñe y escriba.
	Debe tener un nivel de detalles tal que describa por completo qué hay
que hacer! 

	En el extremo, cuando esto se hace bien y completo, pasa que los que
escriben solo conocen al diseñador (y a veces ni siquiera) y el
diseñador no conoce al cliente.
	Si no está en la especificación, es que no hay que hacer eso!

> >> Categorías posibles docente, alumno, graduado, empleado (según la
> >> categoría
> >> se establece las cantidades máximas de ítems a prestar y días de
> >> préstamo)
> > -----
> >
> > 	Si enumerás ejemplos de categorías... pero no hay un requerimiento que
> > diga que el sistema debe manejar categorías...
> >
> > 	En mi caso "usuario" me resultó algo confuso, porque pensé que eran
> > usuarios del sistema, como operadores. En el diccionario me hubiera
> > servido más ver qué era el usuario.
> >
> 
> Deformación profesional. Para mi el que viene a la biblioteca a buscar un
> libro es "usuario", pero en este contexto podria ser socio o lector...

	Está perfecto el uso que le diste a usuario.
	Justamente quería aclararte que para mí, que del dominio de las
bibliotecas conozco solo lo de afuera, gracias al diccionario pude
desambiguar quién era ese actor.

	La idea es usar los nombres que tengan las cosas en el propio dominio
del problema. Si las empezamos a cambiar, luego el cliente/experto no
podrá validar el requerimiento.

> >> - Emitir listados de control
> >
> > 	De control de qué?
> 
> Bueno, aunque no sea el lugar en el diccionario decia:
> 
> "Listados de control
> Usualmente se requieren: préstamos diarios, morosos a la fecha,
> sancionados e inhabilitados a la fecha."

	Sí, lo vi en el diccionario, la pregunta era para destacar que en el
lugar de la funcionalidad, se nombra "control" y no se dice de qué.

> > 	No pretendo que la SRS sea perfecta ni mucho menos, sino que obtengan
> > un buen listado de lo que debe hacer, para después poder modelar algo
> > razonable.
> >
> 
> A Dios rogando...
> 
> >
> > 	Seguimos!

	Como diseñadores (porque este curso es de diseño de software) es
importantísimo poderse comunicar tanto con los expertos y documentar qué
dicen, como con los desarrolladores para decirles qué hacer.

	Más allá de que esto es leve y por ser su primera experiencia costará
hasta el extremo de la frustración, es fundamental hacerse un "mapa
mental" del problema y documentarlo, como paso previo al diseño.

	Nos vemos!

PD: para los que quieran ver y buscar ejemplos de SRSs:
http://www.google.com/search?hl=en&safe=off&client=iceweasel-a&rls=org.debian%3Aes-AR%3Aunofficial&q=srs+ieee+830&btnG=Search

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