1. Desarrollo de prototipos
1.1. Varciones reducidas de la aplicación
1.2. Se utiliza cuando
1.2.1. El área de aplicación no está bien definida
1.2.2. El costo del rechazo por los usuarios es muy alto
1.2.3. Es necesario evaluar el impacto del sistema en los usuarios
1.3. Permiten a los usuarios experimentar cómo este ayuda a su trabajo
1.4. Fomentan el desarrollo de ideas
1.5. Permite a los usuarios mejorar las especificaciones de requerimientos
1.6. Posee las siguientes ventajas
1.6.1. Se identifican las discrepancias entre desarrolladores y usuarios
1.6.2. El personal puede darse cuenta de fallos en los requerimientos
1.6.3. Se dispone de un sistema que muestra la factibilidad y usabilidad de la aplicación
1.6.4. El prototipo se utiliza como base para escribir la especificación para la producción
1.7. Se usa como medio para formalizar la aceptación previa del cliente de los requisitos del proyecto
2. Observación
2.1. Permite obtener información sobre la forma en que se efectúan las actividades
2.2. Permite observar la forma en que se llevan a cabo los procesos
2.3. Verifica que realmente se sigan los pasos especificados
3. Estudio de documentación
3.1. Los manuales y reportes pueden proporcionar información
3.1.1. Organizaciones
3.1.2. Operaciones
3.2. Difícilmente se refleja la manera en la que realmente se desarrollan las actividades
3.3. Introduce al analista al dominio de operaciones y vocabulario utilizado
4. Cuestionarios
4.1. Permite reunir información proveniente de un grupo grande de personas
4.2. Emplea formatos estandarizados para las preguntas puede proporcionar datos más confiables que otras técnicas
4.3. Asegura el anonimato de los encuestados
4.4. Se debe seleccionar a los encuestados
4.4.1. Asegurar que el conocimiento y experiencia de éstos califiquen para dar respuestas a las preguntas
5. Escenarios
5.1. Documentanel comportamiento del sistema cuando se le presentan eventos específicos
5.2. Incluyen una descripción del flujo de datos y las acciones del sistema
5.3. Son una técnica que se basa en escenarios para la obtención de requerimientos
5.4. Analiza y describe modelos de sistemas orientados a objetos
5.5. Identifica a los actores involucrados en una interacción y nombra al tipo de ésta
6. Requerimientos no funcionales
6.1. Se pueden registrar en un documento de requerimientos de software
6.2. Suelen expresarse de una manera general y sin hacer referencia a algún modulo
6.3. Requerimientos no funcionales
6.3.1. Comprobabilidad
6.3.2. Disponibilidad
6.3.3. Extensibilidad
6.3.4. Escalabilidad
6.3.5. Mantenibilidad
6.3.6. Seguridad
6.3.7. Usabilidad
7. Lluvia de ideas
7.1. Brinda un espacio de tiempo limitado
7.2. Facilita la obtención de ideas originales
7.2.1. No toma en cuenta la eficacia de las mismas
7.3. Se utiliza cuando se necesita
7.3.1. Producir una gran cantidad de ideas
7.3.2. Captar posibilidades de mejora
7.3.3. Integrar a los miembros de un equipo de trabajo
7.4. Hacer una lluvia de ideas nos otorga esta herramienta
7.4.1. Obtención de una amplia gama de ideas
7.4.2. Estímulo de la creatividad
7.4.3. Eliminación de bloqueos
7.4.4. La obtención de diversas soluciones
7.5. Pasos para hacer una lluvia de ideas
7.5.1. Hallar un espacio de tiempo para reunirse
7.5.2. Crear un ambiente relajado para facilitar el flujo de las ideas
7.5.3. Presentar el tema central y estipular tiempo límite
7.5.4. Exponer las propuestas
7.5.5. Tomar nota de las propuestas
7.5.6. Elegir las mejores ideas
7.5.7. Hacer una lista con las ideas aprobadas
7.5.8. Crear procedimiento para ejecutar la idea más factible
7.6. Existen reglas para llevar a cabo una lluvia de ideas
7.6.1. Evitar hacer críticas destructivas
7.6.2. Expresar todas las ideas
7.6.3. Apuntar siempre a la cantidad, entre más ideas mejor
7.6.4. Apoyar las propuestas y buscar formas para mejorarlas
8. Entrevista
8.1. Ayuda a obtener información que permite diseñar una interfaz y los diversos procesos asociados
8.1.1. Permite conocer
8.1.1.1. Usuario
8.1.1.2. Lo que quiere o necesita el usuario
8.1.1.3. Los matices que nos aporta de la realidad que investigamos
8.2. Hay interacción directa con los usuarios mediante una conversación
8.3. Al desarrollar una entrevista debemos tener la necesidad de responder preguntas
8.4. Para realizar una entrevista debemos
8.4.1. Poner en evidencia los desajustes de criterios iniciales
8.4.2. No creer que conocemos todos los detalles a profundidad
8.4.3. Realizar preguntas que no podemos responder por nuestra cuenta
8.4.3.1. ¿Quién es el cliente? ¿A qué se desica?
8.4.3.2. ¿Cuál es el proyecto? ¿Cuales son sus objetivos?
8.4.3.3. ¿Quién está implicado en el proyecto? ¿Cuál es su papel en el proyecto?
8.4.3.4. ¿A quién está dirigido? ¿A quién beneficia?
8.4.3.5. ¡En qué entorno se desarrolla el proyecto?
8.4.4. Evaluar la posibilidad de plantear cuestiones respecto de todas y cada una de las tareas de usuario
8.4.5. Contar con una segunda versión de la entrevista
8.4.5.1. No proporcionará más y mejores resultados
8.4.6. Debe ser una conversación
8.5. Tiene como objetivo conocer todos los detalles evidentes u ocultos de los procesos involucrados en las tareas de usuario
9. Requerimientos funcionales
9.1. Describen cualquier actividad que este deba realizar, en otras palabras, el comportamiento o función particular de un sistema o software cuando se cumplen ciertas condiciones
9.1.1. Descripciones de los datos a ser ingresados en el sistema
9.1.2. Descripciones de las operaciones a ser realizadas por cada pantalla.
9.1.3. Descripción de los flujos de trabajo realizados por el sistema.
9.1.4. Descripción de los reportes del sistema y otras salidas
9.1.5. Definición de quien puede ingresar datos en el sistema
9.1.6. Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean aplicables.