> Referente al Req(12) -> ¿Debe recibir el gestor AMM una notificación de
> dirección de correo errónea?
No, no es necesario. Nuestro sistema (AMM) podrá proporcionar listas de direcciones mail para enviar información, y ahí se acaba su función. Otro sistema, no desarrollado por nosotros (mailman, por ejemplo), es el que se encargará de gestionar el envío y los mensajes de error en el mail.
> Referente al Req(16) -> ¿Es necesario que el sistema de pago externo (tipo
> PayPal) envíe una confirmación de pago de donaciones, o se suponen anónimas?
> ¿Hay que almacenarlas?
Las donaciones pueden ser anónimas o no. Supondremos que PayPal nos envia informes de quien ha donado dinero, y para qué causa (si la hay). Las donaciones, en principio, son un tipo de aportación y habrá que tratarlas como tales.
> Req(29) -> ¿Debemos contemplar como acontecimiento el acceso (tanto por
> parte del gestor AMM como del administrador) con login y password?
Partimos de una infraestructura software habitual: un sistema operativo más o menos seguro, y una base de datos relacional. Por tanto, no vamos a considerar lo acontecimentos relacionados con el login/password ni con los bloqueos de registro, pues NO vamos a desarrollarlos ni a programarlos ni nada. Simplemente, es algo con lo que ya contamos…
> Al dar de baja un SyS, ¿qué ocurre con las aportaciones? ¿Debemos indicar
> que se borran o suponer que lo hace la BD?
Es habitual, en los Sistemas de Información, que las bajas no impliquen borrado. Yo he sido empleado de la Universidad Carlos III hace unos 10 años pero sigo en su BD (como “inactivo”, eso sí). Es decir, un SyS puede darse de baja, y lo marcaremos como inactivo (o algo así), pero no implica que lo borremos de la BD. Sus datos siguen ahí, y pueden ser útiles para el futuro, o para ciertas consultas. Eso evitará, además, los borrados en cascada.
> Req(28 ) -> ¿Hay que contemplar también este requisito? (el hecho de que el
> administrador realiza mantenimiento)
No. Al igual que otros requisitos no funcionales (de calidad, usabilidad, seguridad, etc.), no es posible que generen acontecimientos.
Archivado bajo: General
No. Al igual que otros requisitos no funcionales (de calidad, usabilidad, seguridad, etc.), no es posible que generen acontecimientos.
–>eso significa que para la practica solo tenemos en cuenta los requisitos del apartado 3.1 (Req(01)->Req(18)) ?
Significa que los requisitos no funcionales no generan acontecimiento. Se tienen en cuenta todos los requisitos _en_principio_ pero cuando te acercas a ver qué se puede hacer con ellos, te encuentras con que muchos de ellos no generan acontecimiento. Eso es perfectamente normal.