1. requisitos funcionales y no fucionales

1. ¿Qué describe un requisito?

“Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo”

que es un requisito?:

Los requisitos de un proyecto de software son las funciones, características y restricciones que debe cumplir el producto final. En otras palabras, los requisitos definen qué debe hacer el software, cómo debe verse y las condiciones que deben cumplirse para que se considere exitoso.

Recopilación de requisitos es fundamental para poder crear un producto que satisfaga las necesidades del consumidor o clienta. Es importante tener en cuenta que los requisitos pueden cambiar a lo largo del curso de un proyecto, por lo que es importante contar con un mecanismo para rastrear y administrar estos cambios.

//visuresolutions.com//

//www.northware.mx//

2.¿Qué es un requisito funcional y un requisito no funcional?

Requisito funcional:

Se puede pensar en un requisito funcional como una característica del producto que el usuario detecta.

Es una declaración de cómo debe comportarse un sistema. Define lo que el sistema debe hacer para satisfacer las necesidades o expectativas del usuario.

Los requisitos funcionales se pueden considerar como características que el usuario detecta, puede ser una característica obvia, como un gran botón Agregar al carrito. Pero también puede ser una característica menos obvia, como calcular correctamente el impuesto sobre las ventas para la compra en línea del usuario.

Requisito no funcional:

Los requisitos no funcionales (NFR) son las restricciones impuestas a un sistema que definen sus atributos de calidad. Por lo general, se denotan con adjetivos como seguridad, rendimiento y escalabilidad. Los requisitos no funcionales son importantes porque ayudan a garantizar que el sistema satisfaga las necesidades del usuario.

categorias de requisitos no funcionales

Los requisitos no funcionales se pueden dividir en dos categorías:

1.atributos de calidad: Estas son las características del sistema que determinan su calidad general. Los ejemplos de atributos de calidad incluyen seguridad, rendimiento y facilidad de uso.

2.restricciones: Estas son las limitaciones impuestas al sistema. Los ejemplos de restricciones incluyen el tiempo, los recursos y el entorno.

DIFERENCIAS:

El requisito funcional se basa en caracteristicas de un sistema que se implementan y le dan una funcion al software, y el requisito no funcional le imprimen unas retricciones al sistema, para que el mismo funcione de manera optima y segura.

funcional: propiedades

no funcional: restriccion y optimizacion

//visuresolutions.com//

3.¿Qué factores se deben tener en cuenta, en el momento de obtener requisitos?

Para conseguir un proyecto de software exitoso debes comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.
Para poder obtener buenos requerimientos, primero debemos definir que son, que los caracteriza y como pueden clasificarse. Hay muchas definiciones de Requerimiento, considero una de las más completas la siguiente:

*entender meta

*riesgos

*recursos

*tareas para alcanzar meta

*costos 

*y plan a seguir

//www.northware.mx//

4.¿Cómo deben ser los requisitos?

los requisitos tienen que ser:

• Necesario. Si se tiene alguna duda acerca de la necesidad del requerimiento, se pueden preguntar “¿Qué sería lo peor de no incluirlo?” Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario.
• Completo. Un requerimiento esta completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
• Consistente. Un requerimiento es consistente si no es contradictorio con otro requerimiento
• Correcto. acuerdo entre dos partes. Contiene una sola idea.
• Factible. El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el requerimiento es no factible hay que revisar la visión del sistema y replantear el requerimiento
• Modificable. Que se pueda realizar alguna modificación sobre el requerimiento y esta sea sencilla, consistente y completa
• Priorizado. Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo Esencial/Critico, Deseado, Opcional Verificable
• Verificable. Si un requerimiento no se puede comprobar, entonces ¿Cómo se sabe si se cumplió con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o demostración. Cuando se escriba un requerimiento, se deberá de determinar los criterios de aceptación.
• Rastreable. la especificación se debe organizar de tal forma que cada función del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente. Facilita las pruebas y la validación del diseño
• Claro. Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro

//www.northware.mx//

5. ¿Qué deben indicar los requisitos?

Que debe hacer el software, como debe verse, y las conciciones que deben cumplirse para que se considere exitoso. 

//visuresolutions.com//

6. ¿Cómo se obtienen los requisitos?

observacion:

Por medio de esta técnica el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. Este método permite observar la forma en que se llevan a cabo los procesos y, por otro, verificar que realmente se sigan todos los pasos especificados. Como sabemos, en muchos casos los procesos son una cosa en papel y otra muy diferente en la práctica. Los observadores experimentados saben qué buscar y cómo evaluar la relevancia de lo que observan.

//sg.com.mx/

7. ¿Qué problemas pueden presentarse al obtener requisitos?

Los principales errores o problemas a la hora de hacer requisitos son los siguientes:

1. Insuficiente preparación. Desde errores en la oferta y en el contrato hasta defectos en la preparación operativa del proyecto. Éste es uno de los puntos que no deben confundirse en la metodología agile. No se trata de improvisar, sino de tener a mano y preparadas todas las palancas que debemos accionar para ir reconduciendo los proyectos conforme vayan surgiendo cambios en el mismo. No hay que tomar medidas correctoras, sino aplicar en cada momento las medidas que previamente estaban analizadas como posibles actuaciones a llevar a cabo.
2. Falta de competencias del equipo de gestión. De ahí, la importancia del curso PMP y de una buena formación de los directores de Proyecto. Es la punta de lanza de una organización que debe liderar la gestión de una manera eficiente, contando con el máximo conocimiento y las más modernas herramientas de management. En este punto, es importante destacar que las llamadas “habilidades blandas”, como la comunicación o la empatía, son siempre piezas clave en el papel de un director.
3. Falta de conocimiento del mercado. Ciertamente los proyectos van a sufrir graves cambios y no es posible afrontarlos correctamente sin un buen conocimiento del mercado, saber a quién recurrir, ver alternativas o dar con la solución a determinados problemas. Tener un extenso panel de colaboradores con los que contar en los momentos más complicados es esencial para superar las dificultades.
4. Ineficiente gestión de los stakeholders. Gestión que empieza en la fase previa del proyecto, donde es muy importante la realización de un “mapeo” que nos muestre cuáles van a ser los stakeholders relevantes en el proyecto y adecuar la estrategia de gestión y negociación con cada uno de ellos. Además, es necesario hacerlo en función de las fortalezas de cada uno y los avances en las capacidades de negociación a lo largo del ciclo de vida del proyecto.
5. Condicionantes externos difícilmente gestionables. Pandemia, crisis económica, aumento de la competencia o ERE en la empresa. A veces, simplemente, los proyectos no se pueden llevar a cabo de manera satisfactoria y, en ese caso, el objetivo del director/a de Proyectos debe ser minimizar la pérdida y buscar acuerdos futuros, ya que seguro que estas acciones tendrán fuertes afecciones en cliente y proveedores.