Hacemos uso de cookies propias y de terceros para proporcionar una mejor experiencia de usuario. Al seguir navegando entendemos que acepta nuestra Política de Cookies.
En las Metodologías de Desarrollo de Calidad se utilizan siempre técnicas para la toma de requerimientos, donde la participación del usuario es esencial.
Dentro de los procesos de negocio de las compañias, quien mejor conoce la practica habitual en el desempeño del trabajo, es el usuario, por lo tanto ¿Quien mejor que el usuario para trasladar lo que se espera de una aplicación?
Cuando un proyecto parte con información ambigua o inexacta, y se añaden otros factores como una mala administración del proyecto, o descontrol en los cambios experimentados durante la vida del proyecto. Todo esto afecta directamente a la duración del mismo y por lo tanto puede tener un efecto negativo en el coste. Dando como resultado la insatisfacción del cliente, la ampliación en la duración del proyecto o el fracaso inminente.
Para conseguir llevar a exito un proyecto de software se debe evaluar con toda la certeza posible el alcance del trabajo a realizar, para ello hay que contemplar algunos aspectos:
• Riesgos en los que se puede incurrir
• Recursos necesarios para el buen funcionamiento de las aplicaciones
• Las tareas de implantación a llevar a cabo
• Medir correctamente el esfuerzo, lo que nos llevará a poder definir los costes
• Extablecer el plan a seguir.
Definiciones de Requerimiento o Requisitos de Software (Según explica Wikipedia):
La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.
¿Que características deben cumplir las Especificaciones de Requisitos de Software?
Las características de una buena ERS estan definidas en el estándar IEEE 830-1998. Una buena ERS debe ser:
• Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
• Consistente. Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
• Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.
• Correcta. El software debe cumplir con los requisitos de la especificación.
• Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
• Priorizable. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
• Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
• Verificable. Debe existir un método finito sin costo para poder probarlo.