[Php-avanzado] Requerimiento funcionales 4

[Leonardo Tadei - Pegasus Tech Supply]

Hola Daniel,

El lun, 30-09-2013 a las 10:20 -0300, Daniel Billia escribió:
> http://www.ctr.unican.es/asignaturas/is1/is1-t03-trans.pdf
> 
> Buenos días Leo te mando unos de los link que estuve leyendo de la
> norma
> 
	Gracias por el enlace. Por suerte también dice que el acceso de los
usuarios no es una funcionalidad ;-)
	Tené en cuenta que estos slides son armados por un docente para dar una
clase, y no son la norma en sí, sino una buena interpretación de la
norma. En particular discrepo con la interpretación que se le da acá a
los "requerimientos de usuario", ya que los pone casi a la par de los
Requerimientos Funcionales, cuando en la norma claramente no lo son.
	Lo que no encuentro es la parte en la que te basaste para la última
separación que hiciste entre RF y RNF. La explicación dice:

--------------- Pag 15 -----------------------
Requisitos No Funcionales
Definen cualidades o atributos globales del sistema, o Establecen
restricciones sobre el producto desarrollado, el  proceso de desarrollo
o externas
No están generalmente relacionados con la funcionalidad del sistema 
No hay una distinción clara entre requisitos funcionales y no
funcionales
Expresar un requisito como funcional o no funcional depende del nivel de
detalle requerido en el documento de requisitos
----------------------------------------------

	No entiendo como el autor afirma que "no hay una distinción clara entre
requisitos funcionales y no funcionales" y a la vez dice que los RNF
"Definen cualidades o atributos globales del sistema, o Establecen
restricciones sobre el producto desarrollado, el  proceso de desarrollo
o externas" dejando de lado toda funcionalidad exhibida... por lo que no
parece depender del nivel de detalle del documento, sino de si es algo
que va a hacer el sistema, o si es una restricción de contexto para el
uso y la implementación.

	En cualquier caso, yo solo les pido los RF para este curso: todo lo
demás es bienvenido, pero no obligatorio.


> Te detallo los puntos que marcaste:
> 
> La RF2 es ciudad con su provincia es que me cree una confusión entre 
> Localidad y ciudad .

	Me imaginaba. Igual ahora en el RF2 perdiste la relación con la
Provincia, que siempre me pareció correcta: una Ciudad está en una
Provincia. Veo que en el diccionario sigue estando que la Ciudad tiene
una Provincia, por eso también me parece una omisión.
	No tiene sentido hablar en el RF2 del código postal, porque es un mero
atributo de la Ciudad, de la misma forma que no se habla en el artículo
ni del código ni del precio.

> Cada cliente tiene solo una provincia o una ciudad y una dirección si 
> tiene otra provincia o ciudad se crea una nueva cuenta.
> Pienso que si un cliente tiene una cuenta en una ciudad y 
> abre una cuenta en otra ciudad son dos comercios diferentes
> es como si fueran dos personas diferentes ¿?
> 
	Lo que me decís acerca de que si el cliente está en más de una ciudad
tiene que estar ingresado dos veces, es una cuestión de gustos. Por mi
no hay problema.
	Lo que sigo sin entender es el uso del "o" :-(
	Te doy un ejemplo a ver si me explico mejor. Si es provincia _o_
ciudad, significa que estaría correcto que me cargues de estas 3 formas:

Caso 1)
Nombre: Leonardo
Apellido: Tadei
Direcció: Rateriy 69
Teléfono: 4816600
Provincia: Buenos Aires
Localidad: --- ( ninguna) ---
...

Caso 2)
Nombre: Leonardo
Apellido: Tadei
Direcció: Rateriy 69
Teléfono: 4816600
Provincia: --- ( ninguna) ---
Localidad: Mar del Plata
...

Caso 3)
Nombre: Leonardo
Apellido: Tadei
Direcció: Rateriy 69
Teléfono: 4816600
Provincia: Buenos Aires
Localidad: Mar del Plata
...

	Los 3 estarían bien cargados? o en realidad siempre es como en el caso
3, en que tengo una Provincia _y_ una Localidad?

> El proceso de habilitación del cliente es solo cambiar el estado come
> esta acción es un proceso separado del ingreso de datos entraba como 
> un requerimiento funcional 

	Entiendo, es decir que va a haber una pantalla aparte para modificar el
atributo "habilitado" de los clientes.

> Si eso pensé de la imágenes y descripción es algo propio del articulo
> pero como en clientes que lleva cargado provincia y ciudad y se 
> gestionan aparte era el mismo caso.

	No es el mismo caso, porque por ejemplo una Provincia va a ser usada
por muchos Clientes, con lo cual se justifica su existencia por
separado, además de que la gestión de las Provincias es independiente de
la gestión del Cliente.
	En cambio cada imagen va a ser solo de un Artículo, al igual que cada
descripción. La imagen no tiene una existencia independiente del
Artículo que la usa.
> 
> Coloque el importar lista de articulo por lo que leí el apunte de esa 
> norma eso quedaría en el concepto de gestión de artículos ?.   
> 
	Está bien que la importación de listas de artículos sea una
funcionalidad aparte: lo que te decía es que sí es una Funcionalidad en
lugar de ser una No Funcionalidad como decía la versión anterior.

> El ultimo quedaría en el diccionario siendo que es un modo de
> controlar el sistema 
> 
	Me da lo mismo. Como el acceso es una No Funcionalidad, lo importante
es que no esté entre las funcionalidades.

> La tabla de imágenes o descripción no son únicas de ese articulo
> otros artículos pueden tener los mismos datos y seria repetitivos
> Es como el caso de Clientes con su provincia 

	No parece el mismo caso, porque si borrás un Cliente no deberías borrar
la Provincia asociada, aunque nadie más la use, en cambio si borrás un
Artículo tenés que borrar la imagen asociada con él, porque si no no
tenés otra forma de accederla.
	Podés tener muchos clientes que se apelliden Perez, pero esto no es una
repetición!
> 
	Otras cuestiones:
a) pedido y consulta son la misma cosa? Si son distintas tienen que
tener RF por separado.
b) al pedido/consulta en el RF le falte algo como "de un Artículo por un
Cliente".
c) el pedido/consulta dice que solo puede ser de un Artículo: no puedo
consultar por más de uno?
d) en Consulta y en Registro hay un "estado", si este estado no es un
texto para escribir a mano, debés especificarlo por separado.


	Me queda pendiente la respuesta el tema de las Localidades y Provincias
de los Clientes.
	Con eso te puedo validar la SRS.

	Gracias por el esfuerzo en emprolijar esto! 
	Vamos que falta poco!

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