[Php-avanzado] Marquez - SRS

Leonardo Tadei - Pegasus Tech Supply leonardot en pegasusnet.com.ar
Mie Nov 30 18:23:16 ART 2011


Hola Sergio!

El mié, 30-11-2011 a las 12:57 -0300, Sergio Marquez escribió:
> Leo, te envío mi Especificación de requisitos en base a el de otros
> compañeros, sé que falta el Diccionario pero quería corregirlo
> primero. Saludos!

	Está muy bien planteado.
	Te hago unos comentarios intercalados:

	Primero, en la bibliografía de requerimientos se habla de
requerimientos, no de requisitos.
	Es una discusión larga y académica, pero en castellano es mejor
"requerimiento" (de requirenment) que "requisito", porque un requisito
es una precondición (ej: es requisito tener aprobado PHP Inicial para
cursar PHP Avanzado), y en cambio un requerimiento es algo con lo que
tenés que cumplir a futuro (Ej: se requiere para aprobar el curso
aprobar una evaluación y un trabajo final).

	Si querés usar "requisito" en vez de requerimiento, necesito que lo
justifiques adecuadamente.

> ********************************************************************************
> 
> 
> Requisitos Empresariales:
> El sistema que se pretende hacer es un abm de gestion de items,
> clientes y proveedores para permitir documentar compras de items a
> proveedores y ventas de items a clientes.

	Bueno, creo que a nivel empresarial, basta con "documentar las compras
a proveedores y las ventas a los clientes".
	Hablar de ABM no suele ser lo que la empresa necesita, si bien queda
claro que será necesario para poder hacer lo que sí necesita.

> Metodología:
> No se que poner en ésta parte. Casos de uso?

	Ignorá esta sección: el que la usó lo sacó de algun lado pero no vale
la pena detenernos acá. Nos estamos basando en la norma IEEE830 para
hacer esto.
	Además la metodología a usar debería depender del sistema, así que hay
que conocer el problema (SRS) para poder elegir una.
	Implementarlo en PHP para la web almacenando en MySQL es un
Requerimiento No Funcional.

> Requisitos no funcionales:
> - El sistema debe gestionar usuarios de tipo:
> - empleado: puede agregar, eliminar o modificar items, clientes o
> proveedores.
> - administrador: es el superusuario del sitio, puede realizar todas
> las tareas del mismo.

	Esto está muy bueno expresarlo, pero no se especifica así.
	Se especifica diciendo a que RF (o a que parte, por ejemplo solo
edición) tienen acceso los empleados y los administradores.
	Por esto es importante numerar los RF.

> -El sistema debe presentar informes estadísticos de compras y ventas
> del mes.

	Dos cosas: emitir un informe es una funcionalidad, así que va con los
RF; tenés que especificar el informe, ya que "cálculos estadísticos"
sobre las compras y las ventas se pueden hacer centenas!
	Se especifica un RF por cada informe a emitir.

> -El sistema debe presentar informes sobre últimos movimientos.

	Idem. Además "últimos movimientos" es ambiguo.
	Cuantos son los últimos? los de ayer? los del mes actual? los últimos
100?

> -El sistema debe presentar informes sobre documentos pendientes de
> pago.

	Los "documentos" no aparecen especificados!


> Requisitos funcionales:

	Una regla básica de la elaboración de SRS es que los RF estén
ranqueados. Esto significa que no se debe mencionar nada en un RF que no
esté especificado previamente.
	Además lo expresado no debe ser ambiguo.

	Convenimos (para escribir menos) usar la palabra "gestión" para indicar
ABM y presentación por pantalla. 

	Revisá esto porque por ejemplo tenés la gestión de items, y luego el
alta, con lo que generás una ambigüedad porque si gestión es ABM, el
alta por separado es una repetición que confunde y te hace preguntar si
no se puede modificar o borrar items.

	No hables de compra o venta en el mismo RF: redactá uno para la compra
y otro para la venta. Puede que sea parecido de escribir e incluso de
implementar luego, pero sin duda son cosas independientes y no se
justifica que estén juntas (y además viola otros principios de la SRS).

	Respecto al ranqueo, fijate que el RF del cliente menciona las facturas
de venta, pero estas no están especificadas.

	Al hablar de "saldos" y "cuentas" me das la idea de una Cuenta
Corriente. Si existe, especificala.

	Bueno, hagamos otra iteración, y andale agregando el diccionario,
porque sirve para descubrir omisiones y asunciones en la SRS funcional.

	Saludos!

> - El sistema debe gestionar items.
>        -El sistema debe dar de alta nuevos items.
>        -El sistema debe modificar stock de items luego de la compra o
> venta realizada.
> - El sistema debe gestionar clientes.
>        -El sistema debe dar de alta nuevos clientes.
>        -El sistema debe registrar la deuda del cliente si no se han
> pagado sus facturas de venta.
> - El sistema debe gestionar proveedores.
>        -El sistema debe dar de alta nuevos proveedores.
>        -El sistema debe registrar saldo deudor/acreedor de la empresa
> con cada proveedor.
> - El sistema debe asentar facturas de compra.
>       - El sistema debe asentar cliente que realiza la compra.
>       - El sistema debe asentar el tipo de factura de la compra.
>       - El sistema debe asentar la fecha de la compra.
>       - El sistema debe asentar los items incluidos en la compra con
> sus respectivos importes unitarios y cantidades.
>       - El sistema debe asentar el importe de IVA de la compra.
>       - El sistema debe asentar el importe de IIBB de la compra.
>       - El sistema debe asentar el importe total de la compra.
>       - El sistema debe asentar el valor a modificar sobre la cuenta
> afectada por la compra.
>       - El sistema debe permitir marcar la factura como paga o no
> paga.
> - El sistema debe asentar facturas de venta.
>       - El sistema debe asentar el tipo de factura de la venta según
> tipo de responsable.
>       - El sistema debe asentar la fecha de la venta.
>       - El sistema debe asentar cliente que realiza la venta.
>       - El sistema debe asentar los items incluidos en la venta con
> sus respectivos importes unitarios y cantidades.
>       - El sistema debe asentar el importe de IVA de la venta.
>       - El sistema debe asentar el importe de IIBB de la venta.
>       - El sistema debe asentar el importe total de la venta.
>       - El sistema debe permitir marcar la factura como paga o no
> paga.
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado

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



Más información sobre la lista de distribución Php-avanzado