El documento proporciona una guía sobre diferentes técnicas para la recolección de requisitos, incluyendo casos de uso del negocio, entrevistas, talleres y documentación arqueológica. Explica que los casos de uso del negocio son unidades funcionales que sirven como base para los requisitos funcionales y no funcionales. También describe diferentes técnicas para entender mejor las necesidades de los usuarios y partes interesadas, como hacer preguntas, construir modelos y usar mapas mentales durante las entrevistas.

1. INGENIERÍA DE REQUISITOS

2. Casos de uso del negocio
No importa qué tipo de trabajo, pero hay que entenderlo antes de decidir qué tipo de producto
ayudará a la empresa.
Al encontrar las partes más pequeñas de la obra, tiene una mejor oportunidad de encontrar actores
que son especialistas en esa parte de la obra y le puede dar una explicación más completa de la
misma.
Se busca piezas que cumplan con los siguientes criterios:
 Son particiones "naturales" cada uno hace una contribución obvia y lógica a la obra.
 Tienen conectividad mínimo para otras partes de la obra.
 Tienen un ámbito claramente definido.
 Tienen reglas para la definición de su ámbito de aplicación.
 Tienen límites que pueden ser observados y definidos.
 Pueden nombrarse con nombres reconocibles a los interesados.
 Su existencia puede ser determinada fácilmente.
 Tienen uno o más grupos de interés que son expertos para esa parte de la obra.

3. Guía formalidad
Proyectos Conejo: hacen uso de casos de uso del negocio a explorar su dominio del problema antes de
comenzar a formular una solución.
Proyectos de caballos: deben considerar dividir el área de trabajo utilizando casos de uso del
negocio, existe la posibilidad de utilizar BUC, entre los escenarios como documentación pase a lo largo
de los desarrolladores.
Proyectos elefante: tienen un gran número de partes interesadas, la comunicación clara es a la vez
importante y difícil.

4. Casos de Uso y su alcance
Ivar Jacobson describe a los casos de usos como una cantidad de trabajo por hacer.
La definición de un caso de uso no indica con precisión dónde o cómo un caso de uso comienza y
termina.
Sin la comprensión de la verdadera tarea del actor sin duda sucede si se excluye el actor del análisis que
estudiar se corre el riesgo de perder oportunidades para la automatización o la automatización
El Contexto de la Obra
La obra existe para proporcionar servicios para el mundo exterior. Para proporcionar estos servicios, el
trabajo debe recibir información y las señales del mundo exterior y envían mensajes a la misma.
El diagrama de contexto muestra el área de trabajo para estudiar y sus conexiones informativas con el
mundo exterior.
Los sistemas adyacentes son aquellas partes del mundo que tienen conexiones con el trabajo y que
tienen un efecto importante sobre el mismo.

5. Eventos de negocios disparadas por tiempo
Al instante en que señalizan a su intención de comprar un libro, es el evento de negocio.
Hay que tener en cuenta que los casos de uso del negocio son provocados por la llegada de un flujo de
información
Eventos de negocios disparadas por tiempo son iniciados por la llegada de un tiempo predeterminado (o
fecha).
Por qué Eventos de negocios y casos de uso son una buena idea
El resultado es que descubrimos las necesidades reales, y los descubrimos con mayor rapidez. Por no
mirar el interior, pero desde el exterior, tenemos una idea mucho más clara de la manera más funcional de
compartimentar el trabajo.
La razón primordial para el uso de casos de uso del negocio es promover la investigación de lo que está
sucediendo en el momento del evento de negocios.

6. Casos de Uso del Negocio
El caso de uso de negocio es siempre una colección de procesos identificables, datos que se recuperan y /
o se almacena, el uso de negocios caso es una unidad de funcionalidad. Esta unidad es la base para la
escritura de los requisitos funcionales y no funcionales.
Los eventos de negocios son conocidos por las partes interesadas, y que le puede mostrar cómo la
organización responde a ninguno de ellos.
Casos de Uso del Negocio y Casos de Uso del producto
Eventos del negocio ocurren en los sistemas adyacentes cuando deciden que quieren un poco de
información o servicio de la obra, o desean enviar alguna información a la obra.
Una vez que el evento de negocios ha pasado y el flujo de datos resultante ha alcanzado el trabajo, el
trabajo responde.
Una vez que entienda el trabajo correcto del caso de uso del negocio, determinar el alcance del producto
para ese caso de uso del negocio.
A veces, por razones técnicas, es posible optar por implementar un caso de uso comercial con una serie de
casos de uso del producto.

7. La Investigación del Trabajo
Guía de agilidad
Los requisitos se obtienen de personas, el analista de requisitos tiene que hablar con la gente, entender,
escuchar lo que dicen, escuchar lo que no dicen, y entender lo que necesitan. Los requisitos no son
soluciones. Hay que aprender el requisito antes de poder encontrar la solución.
Los proyectos de conejo: tienen que ser muy conscientes, es decir cuando se entiende la esencia de lo que
se dice, las soluciones serán mucho más apropiadas, y por lo general más elegantes.
Proyectos de caballo: hay más partes interesadas, y se hacer uso de entrevistas y talleres prácticos, estas
técnicas dan lugar a una mejor documentación.
Proyectos elefante: mayor número de interesados, tienen la necesidad de documentar sus hallazgos.

8. Responsabilidad
La pesca de arrastre es fundamental en el proceso de requerimientos que es provocado por el analista de
requisitos, el cual no trabaja solo: los usuarios y otras partes interesadas colaboran para reunir los
requisitos.
El Analista de Requerimientos
El tiene que entender lo que los usuarios y partes interesadas están diciendo sobre el trabajo, y luego
traducir ese conocimiento en requisitos de un producto, e inyectando algo nuevo en el trabajo, es decir
hará que el trabajo sea más fácil, mejor, más interesante y más agradable.
El analista de requisitos debe:
 Observar y aprender el trabajo que realizan los usuarios, se estudia su trabajo y les pregunta acerca
de lo que están haciendo y por qué lo está haciendo,
 Inventar mejores maneras de hacer el trabajo, el analista una vez que interpreta lo que el producto
debe hacer; junto con otras partes interesadas, producen un producto para mejorar el trabajo.
 Anote los resultados en la forma de unos requisitos de los modelos de especificación y análisis de
grupos de interés comprensible, el analista debe asegurarse de que él y las partes interesadas tienen
la misma comprensión del producto, y que los interesados estén de acuerdo que ese es el producto
que necesitan.

9. El papel de la Situación Actual
Esta actividad se realiza para entender un área de trabajo la cual no tiene documentación. Se puede usar
modelos para entender el trabajo, pero, paradójicamente, no se puede construir un modelo sin entender el
trabajo. Los modelos sirven como un lenguaje común entre el analista y sus grupos de interés.
Cuando modele el trabajo, no se debe tratar de especificar un nuevo producto, sino que simplemente se
establece el trabajo que realizan los usuarios en la actualidad.
Un beneficio que se genera mediante la construcción de modelos de sistemas actuales es que se entera de
dónde hacer preguntas a medida que se desarrolla el modelo, es decir señala aquellas áreas donde se
carece de entendimiento.
El modelo actual se utiliza para confirmar el alcance de trabajo, como el de asegurar que usted entiende la
situación antes de introducir cualquier mejora a la misma.
Aprendiz
El supuesto subyacente de aprendiz es que los usuarios están haciendo su trabajo, y el analista de requisitos
quien es el aprendiz, tiene que entender el trabajo, hay que tener presente que usted no está tratando de
volver a implementar el trabajo exactamente como es.

10. Si la explicación no es clara, el aprendiz hace preguntas: " ¿Por qué hiciste eso?” “¿Qué significa esto?”
“¿Con qué frecuencia ocurre esto?” “¿Qué pasa si este dato no está aquí?”, con este proceso el analista ve
a todos los casos y las acciones que el usuario adopte para cada uno.
Casos de Uso de Negocio y Talleres
Los talleres permiten trabajar con un menor número de actores especializados a la vez, es una actividad
humana, donde las partes interesadas describen o recrean el trabajo realizado, o lo que se desea hacer,
por el caso de uso del negocio. El analista debe registrar estas acciones y luego usarlas para obtener los
requisitos para el producto a desarrollar.
El taller es una actividad de transferencia de conocimientos del caso de uso del negocio de las partes
interesadas con el analista requisitos.

11. El uso de escenarios como un dispositivo de comunicación, el analista y los interesados trabajen juntos
para adquirir el conocimiento del caso de uso del negocio:
 El resultado deseado para el caso de uso del negocio.
 Los escenarios que describen el trabajo realizado por el caso de uso del negocio.
 Escenarios de excepción que describe las cosas que pueden ir mal y lo que funciona para corregirlos.
 Los escenarios alternativos que muestran variaciones permisibles para el trabajo.
 Las reglas de negocio aplicables al caso de uso del negocio.
 Características de los posibles usuarios de un producto construido para este caso de uso del negocio.
 Prototipos de baja fidelidad que se utilizan para ayudar a los interesados a visualizar el caso de uso del
negocio.

12. Resultado
Piense en los resultados, no las salidas.
El resultado es lo que la organización espera lograr cada vez que se produce el caso de uso del negocio.
Se debe pensar en este resultado en términos de resultados, no las salidas.
Escenarios
Los escenarios describen el trabajo que se realiza por el caso de uso del negocio. El escenario es un
documento de una de las partes interesadas descriptivo utilizado como centro de coordinación del taller.
Reglas de Negocio
Las reglas de negocio son las normas de gestión que trascienden y guían las decisiones de negocios del
día a día, cualquier producto que se desee construir debe ser conforme a las reglas de negocio.

13. Entrevistar a los Grupos de Interés
Las entrevistas son utilizadas por casi todos los proyectos para la obtención o recopilación de requisitos. Este
procedimiento puede funcionar muy bien para los interesados que son conscientes de las necesidades que
tienen, pero pocos interesados saben todas sus necesidades o puede pensar en todos ellos durante una
entrevista, debido a esta razón se debe utilizar otras técnicas de captura de requisitos.
Consejos para hacer sus entrevistas más efectivas:
- Establezca la entrevista en su contexto. Este paso es necesario para evitar que los entrevistados hablen
de algo irrelevante.
- Utilice casos de uso del negocio como un ancla para la entrevista.
- Hacer una pregunta, escuchar la respuesta y, a continuación, retroalimentar su comprensión.
- Retroalimentar su comprensión. Construir modelos, mientras que usted está entrevistando al usuario.
- Dibujar modelos y alentar al usuario a cambiar, por ejemplo, diagramas de flujo de datos, diagramas de
actividad, diagramas de secuencia, están disponibles para ayudarle a comunicar su comprensión de un
proceso.
- Utilizar la terminología y los artefactos de las partes interesadas, tanto conceptual como real.
- Mantener las muestras o copias de los artefactos. Los artefactos son las cosas que los actores utilizan en
su trabajo diario. Pueden ser cosas reales: documentos, computadoras, software, etc.
- Agradezca a los participantes por su tiempo.

14. Hacer las preguntas correctas
Una meta-modelo lingüística es una guía para ayudar a los entrevistadores a escuchar lo que los entrevistados
dicen y llegar a un entendimiento común inequívoca, esta meta-modelo se compone de una serie de patrones,
junto con las preguntas que se puede hacer para identificar posibles mal entendidos y aclarar el significado.
Algunos patrones útiles para escuchar y provocar preguntas siguen:
Comparación: Cuando usted oye la palabra “mejor”, pregunte, “¿En comparación con qué?”.
Juicio: ¿Quién dice que es mejor? ¿Qué es la autoridad?
Generalización: Cuando usted oye las palabras “no puedo” o “debe”, entonces pregunte: ¿Qué te lo impide?
¿Por qué debe usted hacerlo? ¿Qué pasaría si no lo hiciste?
Universal Cuantificadores: Si escuchas “nunca” o “siempre”, se dispara otra pregunta: ¿Esto no sucede
realmente nunca o sucede a veces? ¿Es realmente siempre o hay algunas excepciones?
La nominalización: En nominalización, un verbo que describe un proceso en curso se convierte en un
sustantivo, por ejemplo, “El procesamiento de las renovaciones a través de Internet es mejor” Pero, ¿qué
significa el altavoz para el “proceso”? ¿Qué actividades están implícitas por el uso de esa palabra en este
contexto?

15. Mapas Mentales
Utilizamos mapas mentales todo el tiempo, como para tomar notas durante las entrevistas, planificación de
proyectos o acciones, que resume los talleres. Los mapas mentales son una habilidad que beneficiará a
todos los requisitos de los analistas. Un mapa mental es una combinación de texto y dibujo y que intenta
representar la información de la manera que el cerebro entienda esta y la pueda asociar.
Los mapas mentales no siempre pueden ser construidos desde el centro hacia afuera. A veces uno tiene
ideas o escucha cosas cuando usted está tomando notas, que no tienen ninguna conexión con todo lo que
haya en su mapa.

16. Wikis, blogs, y foros de discusión
Estas técnicas se pueden aplicar a muchos tipos de proyectos, pero debido a que requieren la participación
de un número de grupos de interés, estas estrategias son más eficaces para los proyectos más grandes
como por ejemplo software para la venta.
La idea básica de un wiki es que puede hacer un post o editar o añadir a lo que ya se ha publicado, además,
cualquier persona puede añadir enlaces hipertextuales a otras fuentes útiles de información o realizar
cualquier otro tipo de cambio.
Otros invariablemente expresar su opinión, y en poco tiempo usted tiene una colección considerable de
información y opiniones que usted puede convertir fácilmente en necesidades de su producto.

17. Documento Arqueología
Documentos de Arqueología es una técnica de búsqueda a través de informes, formulario, documentos,
llamadas telefónicas regulares, manuales de usuario y archivos existentes para requisitos subyacentes.
Inspeccione los documentos que han recogido y para cada “cosa”, haga estas preguntas:
 ¿Cuál es el propósito de esto?
 ¿Quién lo usa y por qué?
 ¿Cuáles son los usos del sistema que hace de esta cosa?
 ¿Qué eventos de negocios utilizan o referencia esta cosa?
 ¿Puede esto tener un valor? Por ejemplo, ¿es un número, un código, o la cantidad?
 Si es así, a ¿qué colección de cosas pertenece?
 ¿El documento contiene un grupo de repetición de las cosas?
 Si es así, ¿cuál es la colección de cosas como se llama?
 ¿Puedes encontrar una relación entre las cosas?
 ¿Qué proceso hace que la conexión entre ellos?
 ¿Qué reglas se adjuntan a cada cosa? En otras palabras, ¿qué parte de la política empresarial cubre esto?
 ¿Qué procesos aseguran que estas reglas se obedecen?
 ¿Qué documentos se dan a los usuarios la mayor cantidad de problemas?

18. Elección de la mejor pesca de arrastre Técnica
Continuamos a ser cada vez más ambiciosos en términos de tamaño, complejidad, fragmentación, y el
nivel de participación humana en los productos que construimos. En forma similar, las técnicas de arrastre
de requisitos que utilizamos se siguen desarrollando para que siga el ritmo de nuestra ambición.
Técnicas de arrastre Fortalezas Conejo Caballo Elefante
Business events Partitions the work according to external
demands
*** *** ***
Current situation
modeling
Examines the legacy system for reusable
requirements
* ** ***
Apprenticing Spends time working with an expert * ** ***
Structures and
Identifies reusable requirements * ** **
patterns
Interviewing Can focus on detailed issues *** *** ***
Essence Finds the real problema *** *** ***
Business use case
Focuses the relevant stakeholders on the best
** *** ***
workshops
response to the business event
Creativity workshops Brings the team together to discover
innovative requirements
*** *** **
Brainstorming Facilitates creativity and invention *** *** ***
Personas Uses a composite virtual character to
represent the user/customer
* ** ***
Mind mapping An effective planning/note-taking technique *** *** ***
Wikis Uses online forums to allow all stakeholders
to contribute
** *** ***
Scenarios Shows the functionality of a use case *** *** ***
Low-Fidelity
Discovers undreamed-of requirements *** *** **
prototypes
high-fidelity
prototypes
Discovers usability requirements *** ** **
Document
archeology
Uses evidence from existing documents and
files
* ** ***
La Tabla indica la utilidad relativa de las técnicas en
función de sus ambiciones de agilidad, pero otros
factores pueden entrar en juego. La disponibilidad de
las partes interesadas a participar en el proceso de
requisitos es un factor importante en la determinación
de cómo se establezca sobre la recolección de
requisitos.