Levantamiento de requerimientos funcionales y no funcionales
Requerimientos no funcionales
Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que estos corresponden a los requisitos funcionales.
Requisitos del producto.
Especifican el comportamiento del producto, como los requisitos de rendimiento sobre la velocidad de ejecución del sistema y la cantidad de memoria necesaria, los requisitos de fiabilidad que establecen la tasa de fallos para que el sistema sea aceptable, los requisitos de portabilidad y los requisitos de usabilidad.
Requisitos organizativos
Se derivan de las políticas y procedimientos existentes en la organización cliente y en la organización del desarrollador: estándares en los procesos a utilizar; requisitos de implementación tales como lenguajes de programación o el método de diseño a utilizar; y requisitos de entrega que especifican cuándo se entregará el producto y su documentación.
Necesidades externas
Se derivan de factores externos al sistema y a su proceso de desarrollo. Incluyen los requisitos de interoperabilidad que definen la forma en que el sistema interactúa con los demás sistemas de la organización; los requisitos legales que deben seguirse para garantizar que el sistema funciona dentro de la ley
Mal ejemplo de RNF: El sistema debe ser seguro.
¿Qué tan seguro es “seguro”?
¿En qué situaciones?
¿Existe una norma a cumplir?
¿En qué secciones?
¿Qué debe ocurrir si el sistema no puede funcionar tan rápido como se requiere?
Requerimientos funcionales
Los requerimientos funcionales de un sistema, son aquellos que describen cualquier actividad que este deba realizar, en otras palabras, el comportamiento o función particular de un sistema o software cuando se cumplen ciertas condiciones.
Descripciones de los datos a ser ingresados en el sistema.
Descripciones de las operaciones a ser realizadas por cada pantalla.
Descripción de los flujos de trabajo realizados por el sistema.
Descripción de los reportes del sistema y otras salidas.
Definición de quien puede ingresar datos en el sistema.
Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean aplicables.
Historia de Usuario:
Como usuario, quiero que la aplicación sea fácil de usar, de modo que no tenga que pasar mucho tiempo aprendiendo a usarla.
¿Qué significa ser “fácil de usar”?
¿Fácil para quién?
¿Cómo se mide?
¿Cómo lo rastreas?
¿Cómo se prueba? ¿Contra qué criterios?
Historia de usuario:
Como usuario, quiero que se muestre un tutorial al iniciar sesión por primera vez, para que pueda ver para qué se utiliza cada opción de la pantalla de inicio
Ya sabes lo que hay que comprobar, que explica cada opción en la pantalla de inicio.
Usted sabe cuando necesita ser mostrado, en el primer inicio de sesión del usuario (puede explicar más adelante si el tutorial puede ser omitido, mostrado en otros momentos, accedido desde alguna sección dentro del menú, etc.)