Obtencion de requisitos

¿Cómo obtener los
Requisitos?
A Conde, P Pasaca, L Negron,
A Quizphe, W Maldonado
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Junio, 2020
Loja, Ecuador

3
1. Definición de Requisitos de Software
2. Técnicas de Recolección de Requerimientos(Elicitación)
○ Entrevista
○ Brainstorming/Tormenta de ideas
○ Escenarios/ Caso de Uso
○ Prototipos
○ JAD (Join Application Development)
3. Problemas con la Elicitación
4. Mejora de Procesos
Agenda

4
DEFINICIÓN
Los requisitos de software son la propiedad que
debe exhibir el software, en el cual se expresa las
necesidades y limitaciones definidas en un
proyecto de software que contribuyen a la solución
de algunos problemas del mundo real.
Requisitos de Software

5
Los ingenieros de software deben trabajar junto a los clientes y usuarios finales del
sistema para determinar el dominio de la aplicación, los servicios que proveerá el
mismo, el rendimiento requerido del sistema, las restricciones de hardware entre
otros.
Fuentes de Requisitos
• Partes interesadas (Stakeholders)
• Documentos
• Sistema en funcionamiento
Requisitos de Software

6
¿Cuál es el mejor? La mejor manera de responder eso es ... depende . ¿En que?
Depende sobre su situación, su entorno, su experiencia, la experiencia de sus
partes interesadas, su compromiso de gestión y su cronograma para capturar
todos los requisitos.
Es probable que cambie con el tiempo, diferentes proyectos, organizaciones
diferentes y las necesidades de todos. El resultado probablemente sea que no
puede recolectar todos los requisitos, con solo unas pocas técnicas, de ahí la
combinación de las mismas.
Técnicas de Recolección de
Requerimientos (Elicitación)

7
Las entrevistas son la técnica de elicitación más utilizada.
- Se plantean una serie de preguntas para obtener las
correspondientes respuestas en el contexto de un
determinado dominio de problemas.
- Suelen realizarlas, los ingenieros de requisitos, al
personal de la organización del cliente, con el objeto
de abordar asuntos relacionados con los procesos de
negocio o con características del software a
desarrollar.
En las entrevistas se pueden identificar tres fases:
1. Preparación
2. Realización
3. Análisis.
Entrevista

8
1. PREPARACIÓN
Estudiar el dominio del problema
El ingeniero de requisitos debe:
● Conocer las categorías y conceptos de la comunidad de clientes y
usuarios.
● Recurrir a técnicas de estudio de bibliografía sobre el
tema,documentación de proyectos similares realizados anteriormente.
● La inmersión dentro de la organización donde se va desarrollar dicho
sistema.
Entrevista

9
1. PREPARACIÓN
Seleccionar a las personas a las que se va a entrevistar:
Se debe minimizar el número de entrevistas.
● Se comienza por los directivos: ofrecen una visión global.
● Se continúa con los futuros usuarios: aportan información más detallada.
● Y con el personal técnico: aporta detalles del entorno operacional.
Determinar el objetivo y contenido de las entrevistas:
Para minimizar el tiempo de la entrevista es fundamental fijar el objetivo que
se pretende alcanzar y determinar previamente su contenido.
Entrevista

10
1. PREPARACIÓN
Planificar las entrevistas
● Se debe fijar la fecha, hora, lugar y duración de acuerdo a la agenda del
entrevistado.
● Se deben buscar sitios agradables donde no se produzcan interrupciones
y que resulten naturales a los entrevistados.
Entrevista

11
2. REALIZACIÓN
Apertura
El entrevistador debe presentarse e informar al entrevistado sobre la razón de
la entrevista, qué se espera conseguir, cómo se utilizará la información, la
mecánica de las preguntas, etc.
Desarrollo
● Durante la entrevista se puede aplicar distintas técnicas como las
denominadas de libre contexto, estas preguntas no se pueden responder con
un “sí” o “no, con lo cual permite una mayor comunicación y evitan la
sensación de estar interrogando.
● Se deben evitar tecnicismos que no conozca el entrevistado y palabras o
frases que puedan dificultar la comunicación, es fundamental mostrar interés
en todo momento.
Entrevista

12
2. REALIZACIÓN
Terminación
Al terminar la entrevista se debe :
● Recapitular para confirmar que no ha habido confusiones en la
información recogida
● Agradecer al entrevistado su colaboración y citarle para una nueva
entrevista si fuera necesario
● Dejar abierta la posibilidad de volver a contactar al entrevistado, para
aclarar dudas que surjan al estudiar la información o al contrastar con
otros entrevistados.
Entrevista

14
Es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en
un ambiente libre de críticas o juicios
Las sesiones de brainstorming suelen estar formadas por un número de cuatro a
diez participantes.
El brainstorming puede ayudar a generar una gran variedad de vistas del
problema y a formularlo de diferentes formas.
Se pueden identificar cuatro fases:
1. Preparación
2. Generación
3. Consolidación
4. Documentación
Braindstorming/ Tormenta de ideas

15
1. PREPARACIÓN
● Selección de los participantes y jefe de la sesión.
● Citarlos y preparar la sala donde se llevará a cabo la sesión.
Los participantes en una sesión son normalmente clientes, usuarios, ingenieros
de requisitos, desarrolladores y, si es necesario, algún experto en temas
relevantes para el proyecto.

16
2. GENERACIÓN
● El jefe abre la sesión exponiendo un enunciado general del problema a
tratar, que hace de semilla para que se vayan generando ideas.
● Los participantes aportan libremente nuevas ideas sobre el problema
semilla.
● El proceso continúa hasta que el jefe decide parar, bien porque no se están
generando suficientes ideas, en cuyo caso la reunión se pospone, bien
porque el número de ideas sea suficiente para pasar a la siguiente fase.
Durante esta fase se deben observar las siguientes reglas:
- Se prohíbe la crítica de ideas.
- Se debe generar un gran número de ideas.
- Se debe alentar a los participantes a combinar o completar las ideas de otros
participantes.

17
3. CONSOLIDACIÓN
Se deben organizar y evaluar las ideas generadas durante la fase anterior.
Revisar ideas: se revisan las ideas generadas para clasificarlas. Es habitual
identificar ideas similares, en cuyo caso se unifican en un solo enunciado.
Descartar ideas: aquellas ideas que los participantes consideren
excesivamente avanzadas se descartan.
Priorizar ideas: se priorizan las ideas restantes, identificando las
absolutamente esenciales, las que estarían bien pero que no son esenciales y
las que podrían ser apropiadas para una próxima versión del sistema a
desarrollar.
4. DOCUMENTACIÓN
El jefe produce la documentación oportuna conteniendo las ideas priorizadas y
comentarios generados durante la consolidación.

19
Un caso de uso es la descripción de una secuencia de
interacciones entre el sistema y uno o más actores en la
que se considera al sistema como una caja negra y en la
que la que los actores obtienen resultados observables.
Los casos de uso presentan ciertas ventajas sobre la
descripción meramente textual de los requisitos
funcionales.
Además, pueden servir de base a las pruebas del sistema
y a la documentación para los usuarios
Escenario/ Caso de Uso

20
En esta metodología se propone la utilización de los casos de uso como técnica tanto
de elicitación como de especificación de los requisitos funcionales del sistema.
Nombre: Identifica al escenario
Objetivo:Establece la finalidad del escenario,a ser la alcanzada en el contexto del
problema. El escenario describe el logro del objetivo.
Contexto: Describe las acciones previas necesarias para iniciar el escenario, las
precondiciones, la ubicación física y temporal.
Recursos:Identifican los objetos pasivos con los cuales los actores trabajan.
Actores:Detalla las entidades que se involucran activamente en el escenario.

21
Set de episodios:Cada episodio representa una acción realizada por un actor,
donde participan otros actores y se utilizan recursos. Los episodios se ejecutan
secuencialmente.
Casos alternativos:Menciona los casos de excepción,que pueden corresponder a
otros escenarios.
Relaciones entre casos de uso
includes: se dice que un caso de uso A incluye el caso de uso B, cuando B es una
parte del caso de uso A. Además, siempre que ocurre A ocurre también B, por lo
que se dice que B es un caso de uso abstracto.

22
extends: un caso de uso A extiende a otro caso de uso B, cuando A es una
subsecuencia de interacciones de B que ocurre en una determinada circunstancia.
Por otro lado, el caso de uso A puede ser un caso de uso abstracto o concreto, en
cuyo caso puede ocurrir sin necesidad de que ocurra el caso de uso B.

24
La creación de prototipos es un método para reunir
requisitos. En este caso, puede reunir requisitos
preliminares para una versión inicial de la solución.
Se le muestra esto a los usuarios y partes interesadas,
y ellos pueden darle retroalimentación, idealmente
generando más requisitos.
- Esto puede ser útil para garantizar que está
capturando los elementos de datos que los
usuarios necesitan y cómo debe agruparlos.
- Es posible que deba repetir varias veces para
obtener la información correcta.
Prototipos

25
- Esta técnica tiene la ventaja de ayudar a las personas que quizás no sepan
exactamente lo que necesitan.
- Los prototipos no necesitan hacerse en una computadora se pueden dibujar en
papel como un boceto, una diapositiva o diapositivas de PowerPoint, incluso una
animación o un guión gráfico.
- La razón por la que esta técnica puede funcionar es que las personas tienen
dificultades para describir lo que quieren en una página o pantalla en blanco.
- Los prototipos se pueden construir en torno a casos de uso o escenarios si los
tiene alternativamente, si no, la creación de prototipos de varias capturas de
pantalla puede ayudar a derivar casos de uso y escenarios-
Prototipos

27
La técnica denominada JAD (Desarrollo Conjunto
de Aplicaciones), es una alternativa a las
entrevistas individuales en estas reuniones se
ayuda a los clientes y usuarios a formular
problemas y explorar posibles soluciones,
involucrándose y haciéndolos sentirse partícipes
del desarrollo.
JAD (Join Application Development)

28
Esta técnica se base en cuatro principios
- Dinámica de grupo
- Uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias,
multimedia, herramientas CASE, etc.)
- Mantener un proceso organizado y racional
- Tener una filosofía de documentación por lo que durante las reuniones se trabaja
directamente sobre los documentos a generar.
En comparación con las entrevistas individuales, presenta las siguientes ventajas:
● Ahorra tiempo al evitar que las opiniones de los clientes se contrastan por
separado.
● Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la
documentación generada, no sólo los ingenieros de requisitos.
● Implica más a los clientes y usuarios en el desarrollo.

29
PARTICIPANTES DEL JAD
- Jefe del JAD: es el responsable de todo el proceso y asume el control durante las
reuniones. Debe entender y promover la dinámica de grupo, iniciar y centrar
discusiones, reconocer cuándo la reunión se está desviando del tema.
- Analista: es el responsable de la producción de los documentos que se deben
generar durante las sesiones JAD. Debe tener la habilidad de organizar bien las
ideas y expresarlas claramente por escrito.
- Patrocinador ejecutivo: es el que tiene la decisión final de que se lleve a cabo el
desarrollo. Debe proporcionar a los demás participantes información sobre la
necesidad del nuevo sistema y los beneficios que se espera obtener de él.
- Representantes de los usuarios: durante el JAD/Plan, suelen ser directivos con
una visión global del sistema. Durante el JAD/Design, suelen incorporarse
futuros usuarios finales.

30
- Representantes de sistemas de información: son personas expertos en sistemas
de información que deben ayudar a los usuarios a comprender qué es o no
factible con la tecnología actual y el esfuerzo que implica.
- Especialistas: son personas que pueden proporcionar información tanto del
punto de vista de los usuarios porque conocen muy bien el funcionamientode la
organización, como desde el punto de vista de los desarrolladores porque
conocen perfectamente ciertos aspectos técnicos de la instalación hardware de la
organización.
Fases del JAD
1. Adaptación
2. Celebración de Sesiones
3. Conclusión

31
1. ADAPTACIÓN
- Es responsabilidad del jefe del JAD, ayudado por uno o dos analistas, adaptar la
técnica del JAD para cada proyecto.
- Debe comenzar por definir el proyecto a alto nivel, para lo cual pueden ser
necesarias entrevistas previas con algunos clientes y usuarios.
- Es necesario recabar información sobre la organización para familiarizarse con
el dominio del problema
Una vez obtenida una primera idea de los objetivos del proyecto
- Es necesario seleccionar a los participantes, citarles para las reuniones y
proporcionarles una lista con los temas que se van a tratar en las reuniones para
que las puedan preparar.
- El jefe del JAD debe decidir la duración y el número de sesiones a celebrar,
definir el formato de la documentación.

32
2. CELEBRACIÓN DE SESIONES
Durante las sesiones, los participantes exponen sus ideas y se discuten, analizan
y refinan hasta alcanzar un acuerdo.
Los pasos a seguir:
- Presentación: se presenta y se da la bienvenida a todos los participantes por
parte del patrocinador ejecutivo y del jefe del JAD. El jefe del JAD explica
la mecánica de las sesiones y la planificación prevista.
- Definir objetivos y requisitos: el jefe del JAD promueve la discusión para
elicitar los objetivos o requisitos de alto nivel mediante preguntas como:
"¿Por qué se construye el sistema?", "¿Qué beneficios se esperan?", . . . A
medida que se van elicitando requisitos, el analista los escribe para que
permanezcan visibles durante la discusión.

33
2. CELEBRACIÓN DE SESIONES
- Delimitar el ámbito del sistema: una vez obtenido un número importante
de requisitos, es necesario organizarlos y llegar a un acuerdo sobre el
ámbito del nuevo sistema.
- Documentar temas abiertos: aquellas cuestiones que hayan surgido
durante la sesión que no se han podido resolver, deben documentarse para
las siguientes sesiones y ser asignadas a una persona responsable de su
solución para una fecha determinada
- Concluir la sesión: el jefe del JAD concluye la sesión revisando con los
demás participantes la información elicitada y las decisiones tomadas.

34
3. CONCLUSIÓN
Una vez terminadas las sesiones es necesario transformar las transparencias, notas y
demás documentación generada en documentos formales.
Se distinguen tres pasos:
- Completar la documentación: los analistas recopilan la documentación
generada durante las sesiones en documentos conformes a las normas o
estándares vigentes en la organización.
- Revisar la documentación: la documentación generada se envía a todos los
participantes para que la comenten. Si los comentarios son lo suficientemente
importantes, se convoca otra reunión para discutirlos.
- Validar la documentación: el jefe del JAD envía el documento al patrocinador
ejecutivo para su aprobación. Una vez aprobado el documento se envían copias
definitivas a cada uno de los participantes.

36
Según AJ McDermid nos da diez problemas específicos, clasificadas en tres
categorías:
1. Problemas de alcance
2. Problemas de comprensión
3. Problemas de volatilidad
Problemas con la Elicitación

37
Tienen que ver con la definición de los límites del sistema de manera
suficientemente amplia, pero aún así debería garantizar que se trata de requisitos
y no de diseño.
1. El límite del sistema está mal definido.
Se debe conocer el límite del sistema, tienen que ser definidos al comienzo del
proyecto, y los principales interesados deben ponerse de acuerdo sobre los
límites de dónde comienza y termina el sistema.
2. Se puede proporcionar información de diseño innecesaria.
Se debe escribir sus requisitos independientemente de la aplicación. Ya que hay
algunas situaciones en las que las restricciones arquitectónicas modificarán ese
edicto u orden. El único reto será decidir cuando algo es una implementación o
es una restricción.
Problemas de alcance

38
Tienen que ver con las malas comunicaciones entre los usuarios y el ER (Ingeniero
de Requisitos).
3. Los usuarios tienen una comprensión incompleta de sus necesidades.
Llega a ocurrir porque los usuarios sólo ven una parte del sistema, la que
utilizan. Puedes compensarlo hablando con un conjunto diverso de usuarios para
asegurarte de que obtienes una perspectiva más amplia.
4. Los usuarios tienen poca comprensión de las capacidades informáticas
y limitaciones.
No es necesario que que los usuarios conozcan las capacidades y limitaciones de
las computadoras. Ese es el trabajo de los diseñadores y desarrolladores.
Cuando los usuarios no están familiarizados con las nuevas tecnologías, se
pueden ofrecer requisitos que aborden más capacidades debido a su análisis de
la brecha, con los requisitos examinados por los usuarios.
Problemas de comprensión

39
5. Los analistas tienen poco conocimiento del dominio del problema.
Cuando eres transferido a un nuevo programa del que no sabes nada, aparte de lo
que has oído hablar de él. Por supuesto, no serás un experto en el dominio del
proyecto. A veces toma meses, antes de que te conviertas en un experto para
entender mucho de lo que la gente dice. Haz muchas preguntas.
6. El usuario y el analista hablan diferentes idiomas.
La mayoría de los usuarios no son programadores informáticos. No fueron
contratados por ese conjunto de habilidades. Por lo tanto, tienes que ser
consciente de los prejuicios que algunas personas tienen. Ciertos ingenieros y
desarrolladores de computadoras piensan que todos los usuarios deben ser muy
hábiles en computadoras, cuando no lo son.

40
7. Es fácil omitir información "obvia".
Esta es la trampa que las personas suponen una cierta cantidad de información
que todos conocen. Esa es una ventaja de comenzar sin ser un experto en el
dominio completo, ya que notará que falta información y hará preguntas cuando
esté confundido.
8. Diferentes usuarios tienen diferentes puntos de vista.
Muchas veces, esto se debe a diferentes responsabilidades, y debe capturar
múltiples puntos de vista. En algunos casos, se obtiene información incorrecta.
Esto es un poco más problemático ya que aquí se debe averiguar qué fuente es
incorrecta y eliminarla.
9. Los requisitos son a menudo vagos e inestables
Se debe estar atento cuando se elabore los requisitos, y después de un descanso
en el tiempo,hay que revisar todo lo que se ha escrito y hacer una comprobación
de todos los buenos atributos contra los requisitos.

41
Los problemas de la volatilidad tienen que ver con el cambio. El crecimiento de un
requisito es de 1 a 4 por ciento al mes. Si sabes que esto va a suceder (y sucederá),
puedes prepararte para ello.
10. Los requisitos evolucionan con el tiempo
Tener un proceso de gestión de cambios ayuda porque brinda un proceso para
examinar esos posibles cambios y cómo podrían afectar lo que ya tiene.
Además, se debe estudiar sobre el enfoque ágil para la definición de requisitos,
ya que nos ayudará a mitigar el problema del crecimiento al captar requisitos
cercanos al momento en que se producirá el desarrollo, de manera que el
crecimiento se tome en consideración en ese momento.
Problemas de Volatilidad

42
Muchas veces no se entrará en un proyecto desde el principio, por tal motivo algunas
veces los procesos no están bien definidos e incluso no se entenderán bien.
- Existen muchas formas de mejorar los procesos, sin embargo la mejor opción es la
de experimentar y conseguir experiencia, aunque por desgracia no siempre es una
opción válida.
- Por lo tanto, se debe investigar los procesos ya usados y aumentarlos en eficiencia,
sólo en casos excepcionales se deberá descartar los procesos ya existentes para
hacer unos nuevos desde cero.
También necesitará ver quién en la gerencia patrocinará sus mejoras. Sin un apoyo
estratégico, no podrá tener éxito, no importa cuán buenas sean las propuestas.
- Hay que tener en cuenta que este personaje puede no ser una sola persona y
tampoco una persona de alto rango.
Mejora de Procesos

43
- Podría ser el líder del equipo, el jefe de programas, o incluso el público objetivo.
Al encontrar a esa persona o personas se debe establecer una estrecha relación
con ellos.
Hay que recordar que no siempre se tendrá éxito, por tal motivo se debe tener un
cierto grado de control emocional para sobrellevar estos acontecimientos.
A veces, las ideas para la mejora del proceso pueden provenir de los mismos
interesados por tal motivo hay que estar atentos a los requerimientos del público
objetivo.
Mejora de Procesos

44
Cŕeditos
• George Koelch, Requirements writing for system engineer
• Pierre Bourque, Richard E. (Dick) Fairley, Guide to the Software
Engineer Body of Knowledge
• Fabio Cardona & Jose Castaño, Técnicas utilizadas para la toma de y
elicitación de requerimientos en ingenieria de Software

Obtencion de requisitos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Obtencion de requisitos

Similar a Obtencion de requisitos (20)

Obtencion de requisitos