[Php-avanzado] Requerimientos

Mar Sep 24 09:30:09 ART 2013

Hola Pehuén,

	es una excelente 1er versión de SRS.

	Te hago unas observaciones y unas preguntas intercaladas con tu texto:

	En general, estoy de acuerdo en definir palabras como "gestionar" o
"registrar", pero esta definición pasala a una introducción del
documento, ya que puesta en el diccionario de los Requerimientos
Funcionales pareciera que es algo que tiene que ver con lo que el
software va a hacer, en vez de ser una definición de la propia
especificación.
	Habitualmente la palabra "registrar" se usa para AL, como por ejemplo
para ingresos o egresos de libros que no deben ser alterados; en este
sistema habría que usarlo para los votos, que no deben ser cambiados. Si
como decís al final esto va a seguir por ese lado, va a hacer falta
pensar en otro término para el AL, o cambiar ahora "registrar" por una
palabra que denote mejor AML
	A su vez, en estas aclaraciones, el término "base de datos" no va, ya
que un principio de una buena SRS es especificar qué se va a hacer, pero
nunca cómo se va a hacer: podrías almacenar los datos de muchas otras
maneras, pero esto será una decisión de diseño y no parte de la
especificación (salvo un Requerimiento No Funcional que lo imponga, en
cuyo caso esto pasa a esa sección de la SRS)

El lun, 23-09-2013 a las 19:17 -0700, Fernando Pehuén Borsani escribió:
> Partiendo del supuesto de que el software va dirigido a una librería,
> estos son los requerimeintos tentativos:
> 
> 
> 01) El sistema debe gestionar empleados.
> 02) El sistema debe gestionar administradores.

	No veo que los Empleados no los Administradores tengan ningún sentido
funcional en este sistema.
	Al ser solamente una restricción de acceso, no se expresan como parte
de la funcionalidad. Si querés mantenerlos, pasalos a una sección de
Requerimientos No Funcionales y después vemos como expresar quién accede
a qué.

> 03) El sistema debe registrar editoriales.

	Qué es el "número de identificación" que aparece en el diccionario de
Editorial?
	Si es algo propio del dominio del problema, está correcto. Si estás
pensando en que será en el futuro un ID de una tabla de base de datos,
es incorrecto expresarlo acá, porque surgirá de una decisión de diseño y
no como parte del problema.

> 04) El sistema debe registrar autores.

	Idem RF3

> 05) El sistema debe gestionar libros.

	Está expresado de forma incompleta. Fijate que según el diccionario el
Libro tiene una Editorial y un Autor. A nivel funcional debés expresar
esta relación así:
	"El sistema debe gestionar Libros con su Autor[4] y su Editorial[3]" o
"El sistema debe gestionar Libros con sus Autores[4] y su Editorial[3]"
para el caso de que en este sistema se pueda indicar que un Libro tiene
más de un Autor.

> 06) El sistema debe registrar visitantes.
> 07) El sistema debe moderar visitantes[6].

	Si registrar es AML y moderar es BM, sumados son ABML que es gestionar,
ergo, esto no son 2 RF sino uno solo que se gestiona ;-)
	Tal vez lo estés expresando de esta forma porque estás pensando en dos
interfaces distintas para esta tarea: una de AML y otra de BM. Si es
así, acá poné solo "gestionar" y aclará esto en un apéndice de
interfaces del sistema haciendo un boceto de estas dos.

	Además, según el diccionario, falta expresar la existencia de los sexos
y de los rangos de edades. Supongo que serán cosas que solo se
"muestren" y que no vale la pena hacer un ABM de esto.
	Si hace falta expresar luego la relación funcional como en el RF5

> 08) El sistema debe ofrecer votar los libros[5].

	La palabra "ofrecer" genera confusión, porque todo lo acá expresado va
a ser "ofrecido" por el sistema. Funciona igual de mal que "permitir".
	Tal vez podrías expresarlo como "El sistema de registrar votos a los
libros[5].
	En el diccionario de "voto" (dice "votar" pero es ese) te faltan los
atributos que tiene. Ponés ahí cómo debe funcional, pero justamente eso
va acá arriba, porque es el funcionamiento, aunque sin hablar de colores
o formas.

> 09) El sistema debe mostrar la suma de los votos de los libros[5].

	Este RF hay que integrarlo con el de arriba. Parece la misma cuestión
de "pantalla" del RF7.

	Los demás RF tienen más o menos las mismas observaciones que los
anteriores.

> 10) El sistema debe registrar comentarios.
> 11) El sistema debe moderar comentarios[10].
> 12) El sistema debe mostrar los comentarios[10] ya moderados[11].
> 13) El sistema debe ofrecer votar los comentarios[10].
> 14) El sistema debe mostrar la suma de los votos de los
> comentarios[10]
> 15) El sistema debe registrar la popularidad del libro[5].
> 16) El sistema debe mostrar la popularidad del libro[5].
> 17) El sistema debe reportar al administrador[2] el ranking de
> popularidad[16].
> 18) El sistema debe buscar editoriales[3].
> 19) El sistema debe buscar autores[4].
> 20) El sistema debe buscar libros[5].

	En los "buscar" expresá los términos de búsqueda posibles.

> 21) El sistema debe mostrar los resultados de las búsquedas
> [18-19-20].

	Definí "buscar" para que incluya el L y sacá el RF 21.

> 
> Diccionario:
> 
> Gestionar: ABML (alta, baja, modificación, listar en pantalla) en la
> base de datos.
> Registrar: AML (alta, modificación, listar en pantalla) en la base de
> datos.
> Base de datos: colección de datos que se cargan desde el sitio web
> generado por este software y que se almacenan en el servidor.
> Servidor: proveedor del servicio de almacenamiento del sitio web.
> Empleado: persona bajo sueldo que realiza funciones administrativas
> para el comprador de este software. Nombre, dni, edad, sexo, puesto.
> Administrador: empleado que tiene permiso para actualizar la
> información de la página.
> Editorial: nombre, número de identificación.
> Autor: nombre, número de identificación.
> Libro: isbn, editorial, autor, título.
> Visitante: persona externa a la empresa que lee el contenido web
> generado por este software. Nombre, email, rango de edad, sexo.
> Comentarios: opinión que el visitante deja escrita sobre un libro
> específico.
> Moderar: BM (baja, modificación).
> Votar: seleccionar entre estas dos opciones: valoración positiva,
> valoración negativa, representadas por una flecha verde que apunta
> hacia arriba y una flecha roja que apunta hacia abajo.
> Popularidad: cantidad de personas que leen la información de un libro.
> Reportar: enviar un registro ordenado decrecientemente con la lista de
> los libros y la cantidad de visitas que recibió cada uno.
> Buscar: a partir de una palabra ingresada por el usuario comprobar
> coincidencias en la base de datos.
> 
> 
> Pensaba en agregar algunas funciones de stock, y quizás algo más sobre
> los empleados para cubrir el área de recursos humanos, pero primero
> quiero corregir los problemas de esta primer parte.

	Estoy de acuerdo. Lo que planteás es un subsistema razonable, y más
vale pulirlo ahora y luego seguir.

> Por ejemplo: el jueves se mencionó que los permisos no son
> funcionalidades, así que el segundo requisito no sería correcto.

	y el primero tampoco, tal como se menciona más arriba... y les decimos
"requerimientos"

>  Por otro lado si el dueño puede darle control administartivo a otros
> empleados, entonces tiene que haber una función que se lo permita
> hacer (sino tendría que llamar por teléfono cada vez que cambie de
> administrador).

	Esto es correcto, pero recordá que quién accede a qué no es parte del
problema, y por tanto no es una funcionalidad, es una no-funcionalidad.
	No es que no exista, es que no va acá esta descripción.
	Si querés ampliar la SRS para que tenga una sección de RNF, con gusto
te ayudo.

	Cuando tengas la versión 2, 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