1. ROL DE REQUERIMIENTOS
1.1. El rol clave es mostrar a los desarrolladores y usuarios que se necesita de un sistema.
2. ¿COMO SE IDENTIFICAN LOS REQUERIMIENTOS?
2.1. Primer encuentro de interlocución con usuarios y clientes
2.2. Desarrollar varias técnicas de recolección de información como:
2.2.1. Entrevistas
2.2.2. Brainstorming
2.2.3. Prototipeo
2.2.4. Cuestionarios
2.3. Redactar todos los requerimientos cuando se logran a detalle en el archivo de "Especificación de Requerimientos"
3. ESPECIFICACIÓN DE REQUERIMIENTOS
3.1. Define y documenta de forma completa el comportamiento externo del sistema que se va a construir. Caracterizado por
3.1.1. Definidos Sin Ambiguedad
3.1.2. Son Completos
3.1.3. Especifica el origen
3.1.4. Evita detalles del Diseño
3.1.5. Están numerados
4. ADMINISTRACIÓN DE REQUERIMIENTOS
4.1. Es un proceso que tiene por objetivo comprender y controlar los requerimientos.
4.1.1. VENTAJAS
4.1.1.1. Mejor Control de Proyectos Complejos
4.1.1.2. Mejor calidad en el software y satisfacción del cliente
4.1.1.3. Reducción de costos y retrasos del proyecto
4.1.1.4. Facilita la conformidad de estandares
4.1.2. DESVENTAJAS
4.1.2.1. No son siempre obvios y tienen muchas fuentes
4.1.2.2. No son siempre fáciles de expresar en palabras.
4.1.2.3. Cambian
4.1.2.4. Tipos diferentes a distintos niveles de detalle
5. QUE ES UN REQUERIMIENTO DE SOFTWARE?
5.1. Capacidad de Software necesaria por el usuario para resolver un problema.
6. Requerimientos de Sistemas
6.1. Muestra todo lo que el sistema debe hacer y las restricciones sobre la funcionalidad
7. Requerimientos de Usuario
7.1. Conjunto completo de resultados a ser detenidos utilizando el sistema
8. COSTO DE ERRORES EN LOS REQUERIMIENTOS
8.1. Una efectiva administración de requerimientos conduce a uno ahorro en costos del proyecto
8.1.1. TRES RAZONES
8.1.1.1. Costos de reparar errores en los requerimientos superan en mas de 10 veces a otros errores.
8.1.1.2. Errores de requerimientos comprenden encima del 40% de todos los errores de un proyecto de software.
8.1.1.3. Pequeños reducciones en el número de errores de requerimientos rinden grandes dividendos al evitar requerimientos rinden grandes dividendos al evitar costos de re costos de re-trabajo y días de retraso
9. REQUERIMIENTOS DE DOMINIO
9.1. Se derivan del dominio del sistema más que de las necesidades específicas de los usuarios.
9.2. Son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación.
9.3. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
10. REQUERIMIENTOS FUNCIONALES
10.1. Describen la funcionalidad o los servicios que se espera proveerá el sistema.
10.2. Dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software
11. REQUERIMIENTOS NO FUNCIONALES
11.1. Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
11.1.1. METRICAS PARA ESPECIFICAR ESTOS REQUERIMIENTOS
11.1.1.1. Rapidez
11.1.1.2. Tamaño
11.1.1.3. Facilidad de Uso
11.1.1.4. Fiabilidad
11.1.1.5. Robustez
11.1.1.6. Portabilidad
12. CADENA DE RESPONSABILIDADES
12.1. Cadena Funcional que se establece para la atención del requerimiento
12.1.1. ACTOR NEGOCIO
12.1.1.1. Alguien fuera del negocio que interactua con el
12.2. Involucra las interacciones producto de los requerimientos de un actor externo al negocio (cliente o proveedor) con las responsabilidades de un trabajador de negocio. Actor
12.2.1. TRABAJADOR NEGOCIO
12.2.1.1. Interactua con otros roles de trabajadores de negocio y manipula entidades