Está en la página 1de 3

REQUERIMIENTOS NO FUNCIONALES

1. El diseo debe contemplar el uso ptimo de recursos tales como conexiones a


la base de datos.
2. Contemplar en el diseo la clara particin entre datos, recursos y aplicaciones
para optimizar la escalabilidad del sistema.
3. Debe contemplar requerimientos de crecimiento para usuarios tanto internos
como externos.
4. Debe contemplar requerimientos de confiabilidad y consistencia de los
componentes de negocio ante recuperaciones. En caso de fallas de algn
componente, no debe haber prdida de informacin.
5. Debe contemplar requerimientos de consistencia transaccional. Ante la falla del
aplicativo, se debe contar con mecanismos que contemplen la interrupcin de
transacciones para que estas finalicen de manera correcta.
6. El acceso al Sistema debe estar restringido por el uso de claves asignadas a
cada uno de los usuarios. Slo podrn ingresar al Sistema las personas que
estn registradas, estos usuarios sern clasificados en varios tipos de usuarios
(o roles) con acceso a las opciones de trabajo definidas para cada rol.
7. El control de acceso implementado debe permitir asignar los perfiles para cada
uno de los roles identificados.
8. Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar
accesos o modificaciones indebidos (no autorizados) a la informacin y proveer
los servicios requeridos por los usuarios legtimos del sistema.
9. Se debe crear una aplicacin que no presente una interfaz complicada y que el
aprendizaje del uso de la aplicacin sea totalmente intuitivo y no necesite de
mayores explicaciones, esto garantizara la satisfaccin del cliente.
10. Se debe de restringir que el usuario solo realice las opciones permitidas. Debe
ser capaz de recuperarse fcilmente de cualquier error que pudiera sucederle.
11. El sistema debe estar en capacidad de permitir en el futuro su fcil mantenimiento con
respecto a los posibles errores que se puedan presentar durante la operacin del
sistema.

12. El sistema debe validar automticamente la informacin contenida en los


formularios de ingreso. En el proceso de validacin de la informacin, se deben
tener en cuenta aspectos tales como obligatoriedad de campos, longitud de
caracteres permitida por campo, manejo de tipos de datos, etc.
13. La solucin debe ser 100% basado en web y toda administracin debe
realizarse desde un navegador.

14. Permitir su navegacin a travs de los exploradores ms comunes como Mozilla


Firefox, Internet Explorer, Google Chrome, Opera.
15. El sistema debe operar de manera independiente del navegador que se utilice.
16. Autoajustable a cualquier tamao y resolucin de pantalla del usuario, utilizar
imgenes optimizadas y componentes de diseo que permitan mostrar la
informacin de manera dinmica, gil y esttica.
17. Orientada a servicios. (SOA).
18. Orientada a objetos.
19. Deber funcionar en 4 gestores de base de datos los cuales son Microsoft SQL
Server, MySQL, PostgreSQL y Oracle.
20. Que permita y utilice reutilizacin de cdigo.
21. La solucin debe ofrecer adecuados niveles de servicio donde la disponibilidad
y recuperacin de fallos sea garantizada.
22. Se debe estructurar el cdigo de una manera consistente y predecible.
23. Garantizar que el diseo de las consultas no afecte el desempeo de la base de
datos, ni considerablemente el trfico de la red.
24. Ofrecer interfaz Web para usuarios.
25. Permitir la publicacin de informacin independiente de la plataforma.
26. Permitir el manejo de versiones.
27. La solucin debe ofrecer las interfaces para intercambiar informacin e
integrarse con otros sistemas.
28. Debe definirse un estndar de interfaz tomando en cuenta los colores de la
institucin y los colores de la empresa que desarrolla la aplicacin, ya que con
estas dos combinaciones se tiene la probabilidad de que el usurario este
cmodamente trabajando con la aplicacin.
29. La Utilizacin de los Recursos. Debe utilizarse procedimientos almacenados
bsicos, que no tengan ms de una sentencia, esto para el acceso a la base de
datos. Los filtros de bsquedas o lgica del negocio para los datos debe
implementarse en la capa de negocio.

30. La Facilidad de Diagnostico. Debe realizarse la Prueba con la ayuda de los


casos de uso de prueba. De esta forma garantizar el buen funcionamiento de la
aplicacin.
31. El sistema debe ser construido e implantado de tal manera que un cambio en
los parmetros de negocio no obligue a la generacin de una nueva versin del
modulo.
32. Debe ser una aplicacin altamente transaccional y que permita su uso las 24
horas del da 7 das de la semana. Debe garantizar que el sistema ser de fcil
acceso y de operaciones no complicadas.
33. El sistema siempre debe pedir confirmacin al usuario antes de guardar los
cambios en el sistema.
34. El tiempo promedio de las transacciones en el sistema no debe exceder los 6
segundos.
INTERFACES
35. Las pantallas principales deben contener el logotipo de la empresa.
36. Utilizar para la creacin de los Formularios Web hojas de estilos CSS.
37. Los reportes mostrarn el logo y nombre de la empresa.

También podría gustarte