1. Tipos de requerimientos
1.1. Ambiente físico: - ¿Dónde esta el equipo que el sistema necesita para funcionar? - ¿Existe una localización o varias? - ¿Hay restricciones ambientales como temperatura, humedad o interferencia magnética?
1.2. Interfaces: - ¿La entrada proviene de uno o más sistemas? - ¿La salida va a uno o más sistemas? - ¿Existe una manera preestablecida en que deben formatearse los datos?
1.3. Usuarios y factores humanos - ¿Quien usará el sistema? - ¿Habrá varios tipos de usuario? - ¿Cuál es el nivel de habilidad de cada tipo de usuario? - ¿Qué clase de entrenamiento requerirá cada tipo de usuario? - ¿Cuán fácil le será al usuario comprender y utilizar el sistema? - ¿Cuán difícil le resultará al usuario hacer uso indebido del sistema?
1.4. Funcionalidad - ¿Qué hará el sistema? - ¿Cuándo lo hará? - ¿Existen varios modos de operación? - ¿Cómo y cuando puede cambiarse o mejorarse un sistema? - ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?
1.5. Documentación - ¿Cuánta documentación se requiere? - ¿Debe estar en línea, en papel o en ambos? - ¿A que audiencia está orientado cada tipo de información?
1.6. Datos - ¿Cuál será el formato de los datos, tanto para la entrada como para la salida? - ¿Cuán a menudo serán recibidos o enviados? - ¿Cuán exactos deben ser? - ¿Con qué grado de precisión deben hacerse los cálculos? - ¿Cuántos datos fluyen a través del sistema? - ¿Debe retenerse algún dato por algún período de tiempo?
2. ANÁLISIS DE REQUERIMIENTOS
2.1. ase para la definición del proceso de administración de requerimientos es el área de procesos Requirements Development (RD) del modelo CMMI Development versión 1.3 (Capability Maturity Model Integration), que reúne un conjunto de prácticas que orientan y garantizan el correcto análisis de los requerimientos de un sistema, en un proyecto de desarrollo de software.
2.2. El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo: 1. Reconocimiento del problema 2. Evaluación y síntesis 3. Modelado 4. Especificación 5. Revisión
2.3. METODO CORE
2.3.1. EL MÉTODO CORE es considerado el primer método que incluye puntos de vista o perspectivas como entidades de primera clase
2.3.2. CORE se ha utilizado en muchos de los proyectos del Ministerio de Defensa del Reino Unido y de la industria aéreo espacial de Europa aunque se a tenido poco impacto fuera de dichos dominios.
3. CARACTERÍSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO DE SOFTWAR
3.1. Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos. -Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. -Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s. -La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. -Este es el enfoque más realista actualmente.
3.2. VENTAJAS DEL MODELO ESPIRAL
3.2.1. No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad. En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos. Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo
3.3. DESVENTAJAS DEL MODELO ESPIRAL
3.3.1. Existe complicación cuando se evalúa los riesgos. Se requiere la participación continua por parte del cliente. Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.
4. SEGUN ZAVE
4.1. Trata sobre la rama de la ingeniería del software la cual trata con el establecimiento de los objetivos, funciones y las restricciones de los sistemas software. Asimismo, también se ocupa de la relación entre los factores.
5. SEGUN BOEHN
5.1. La ingeniería de Requerimientos es la es una de las disciplinas para el desarrollo de una especificación completa, consistente y no ambigua, la cua nos servirá como una de las base para acuerdos comunes entre todas las partes involucradas.
6. SEGÚN LOUCOPOULOS
6.1. Es el trabajo sistemático del desarrollo de los requisitos, a través de un proceso iterativo y cooperativo de análisis de un problema, la cual será documentando los resultados en una variedad de formatos.
7. SEGÚN LEITE
7.1. Es es unos de los proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar.
7.2. Los requerimientos son desarrollados conjuntamente por el cliente, usuario y diseñadores del sistema de software. El resultado final constituye la documentación de los requerimientos.
8. ELICITACIÓN DE REQUERIMIENTOS
8.1. El producto del proceso de elicitación es todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema. La elicitación requiere orientar las técnicas para interactuar con las fuentes en las que potencialmente se encuentran los elementos para la formulación de los requerimientos.
8.2. TÉCNICAS DE ELICITACIÓN DE REQUERIMIENTOS
8.2.1. TÉCNICAS TRADICIONALES.
8.2.1.1. Cuestionarios, Surveys, Entrevistas de comienzo y final abierto, estructuradas y Análisis de documentos formularios, organigramas, modelos, estándares, manuales, normas, etc
8.2.2. TÉCNICAS DE ELICITACIÓN GRUPALES.
8.2.2.1. Brainstorming, Focus groups y RAD/JAD
8.2.3. Prototipos.
8.2.3.1. Solo o combinado con otras técnicas
8.2.4. Técnicas orientadas por modelos.
8.2.4.1. Métodos basados en objetivos y métodos basados en escenarios
8.2.5. Técnicas cognitivas.
8.2.5.1. Laddering, Card Sorting y Repertory Grids
8.2.6. Técnicas contextuales.
8.2.6.1. Métodos etnográficos (observación del participante), Etnometodología y Análisis de conversación (estudio de conversación e interacción)