requerimientos funcionales ejemplos pdf

Hay muchos tipos de requerimientos funcionales, pero en general, se pueden agrupar en cuatro categorías principales:

• Requerimientos de datos: Estos requerimientos se centran en la información que necesita el sistema para realizar su función. Por ejemplo, un sistema de inventario necesitará datos sobre los productos, como el nombre, la descripción, el precio, etc. Los requerimientos de datos también pueden incluir la estructura de la base de datos, los formatos de los datos, las restricciones de los datos, etc.
• Requerimientos de funcionalidad: Estos requerimientos se centran en las funciones y características que debe tener el sistema. Por ejemplo, un sistema de inventario necesitará la capacidad de agregar nuevos productos, eliminar productos existentes, actualizar datos de productos, buscar productos, etc. Los requerimientos de funcionalidad también pueden incluir la interfaz de usuario, las características de seguridad, las características de rendimiento, etc.
• Requerimientos de no-funcionalidad: Estos requerimientos se centran en las características del sistema que no son estrictamente funcionales. Por ejemplo, un sistema de inventario necesitará características de seguridad para proteger los datos, características de rendimiento para asegurar que el sistema pueda manejar el volumen de datos, características de fiabilidad para asegurar que el sistema no se caiga, etc.
• Requerimientos de restricciones: Estos requerimientos se centran en las limitaciones del sistema. Por ejemplo, un sistema de inventario necesitará limitaciones de seguridad para evitar que los usuarios no autorizados accedan a los datos, limitaciones de rendimiento para asegurar que el sistema no se sobrecargue, limitaciones de fiabilidad para asegurar que el sistema no se caiga, etc.

Los requerimientos funcionales deben cumplir con ciertos criterios para ser considerados válidos. En general, se espera que los requerimientos cumplan con los siguientes criterios:

• Los requerimientos deben ser verificables y medibles. Esto significa que deben ser posibles de comprobar y medir. Por ejemplo, un requerimiento de que el sistema sea “fácil de usar” no es verificable o medible, pero un requerimiento de que el sistema tenga un “tiempo de respuesta de no más de 2 segundos” es verificable y medible.
• Los requerimientos deben ser completos. Esto significa que deben ser lo suficientemente específicos como para ser implementados por un desarrollador. Por ejemplo, un requerimiento de que el sistema tenga una “interfaz de usuario amigable” no es lo suficientemente específico, pero un requerimiento de que el sistema tenga una “interfaz de usuario basada en la Web con una barra de navegación en la parte superior” es lo suficientemente específico.
• Los requerimientos deben ser consistentes. Esto significa que no deben contradicirse entre sí. Por ejemplo, un requerimiento de que el sistema tenga una “interfaz de usuario basada en la Web con una barra de navegación en la parte superior” y otro requerimiento de que el sistema tenga una “interfaz de usuario basada en la Web sin barra de navegación” son inconsistentes.
• Los requerimientos deben ser válidos. Esto significa que deben ser factibles de implementar y que deben estar alineados con los objetivos del proyecto. Por ejemplo, un requerimiento de que el sistema sea “implementado en Java” es válido si el proyecto requiere que el sistema sea desarrollado en Java. Sin embargo, un requerimiento de que el sistema sea “implementado en Java” no es válido si el proyecto requiere que el sistema sea desarrollado en C++.

Los requerimientos funcionales también deben ser tratados como un documento vivo que puede ser modificado y actualizado a medida que cambien las necesidades del proyecto. Por ejemplo, si se descubre que un requerimiento no es válido, o si se descubre que un requerimiento es inconsistente con otro requerimiento, entonces el requerimiento debe ser modificado o eliminado.