INGENIERÍA EN DESARROLLO Y GESTIÓN DE SOFTWARE

MATERIA: METODOLOGÍAS PARA EL DESARROLLO DE

PROYECTOS

NOMBRE:

BUCIO FLORES SANDRA ARELI

FRÍAS CABALLERO LAURA PATRICIA
JIMÉNEZ SAN JUAN LIZBETH
NAVARRO MIGUEL DANA GABRIEL
ROJAS AGUILAS IVÁN ALEJANDRO
VICTORIA MARTÍNEZ DEYANIRA

PROFESORA: MARÍA LUISA MORALES MONROY

GRUPO:7IDS2

Fecha de entrega: 15 de noviembre de 2021

ÍNDICE
INTRODUCCIÓN.................................................................................................................3

Obtención y análisis de requerimientos............................................................................5

TÉCNICAS DE DEFINICIÓN DE REQUERIMIENTOS.......................................................7

Entrevistas............................................................................................................................7

Lluvia de ideas (Brainstorming)...........................................................................................8

Prototipos...........................................................................................................................10

Caso de uso.......................................................................................................................11

Taller de requerimientos....................................................................................................12

CONCLUSIÓN...................................................................................................................15

REFERENCIAS..................................................................................................................16
INTRODUCCIÓN

Las técnicas de definición de requerimientos facilitan el proceso de transformación de los

requerimientos de los clientes, ya sean hablados o escritos, en especificaciones precisas,
no ambiguas consistentes y completas. También se encargan de establecer y mantener
los cambios de requerimientos entre clientes y el equipo. Es muy importante tomarlas en
cuenta, ya que nos permite mantener una estructura en las necesidades del proyecto,
disminuir costos y retrasos, mejorar la calidad del producto, mejorar la comunicación en
un equipo de trabajo y sobre todo evitar rechazos de usuarios finales.

La obtención de requerimientos no solo es un proceso técnico, sino también un proceso

social que envuelve a diferentes personas, lo que conlleva dificultades añadidas a su
realización. Existe un gran número de técnicas para obtener requerimientos. A
continuación se describen las más utilizadas. Hay que aclarar que ninguna de estas
técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener
requerimientos completos.

P á g i n a 3 | 17
¿QUÉ ES UN REQUERIMIENTO?

Un requerimiento es una característica del sistema o una descripción de algo que el

sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema. Al iniciar
un proyecto, ¿cuál es la primera actividad? Tenemos que comunicarnos, saber
lo que el usuario quiere, cómo lo quiere, cuándo y porqué. Al hablar de necesidades, en
términos más técnicos, estamos hablando de requerimientos
.
La comunicación es la base para la obtención de los requerimientos, pero es también la
principal fuente de error:
 Falta de procedimientos y guías formales.
 Falta de participación del usuario.
 Mala interpretación de las necesidades.
 Falta de comunicación.

Para poder obtener buenos requerimientos, primero debemos definir que son, que los
caracteriza y como pueden clasificarse. Hay muchas definiciones de Requerimiento, se
considera una de las más completas la siguiente: “Una capacidad necesitada por un
usuario para resolver un problema o llevar a cabo un objetivo”

Características:
 Necesario
 Completo
 Correcto
 Factible
 Modificable
 Priorizado
 Verificable
 Claro

A partir de una descripción resumida del sistema se elabora un informe que recomienda
la conveniencia o no de realizar el proceso de desarrollo. Responde a las siguientes

P á g i n a 4 | 17
preguntas:
I. ¿El sistema contribuye a los objetivos generales de la organización?
II. ¿El sistema se puede implementar con la tecnología actual?
III. ¿El sistema se puede implementar con las restricciones de costo y tiempo?
IV. ¿El sistema puede integrarse a otros que existen en la organización?

Una vez que se ha recopilado toda la información necesaria para contestar las preguntas
anteriores se debería hablar con las fuentes de información para responder nuevas
preguntas y luego se redacta el informe, donde debería hacerse una recomendación
sobre si debe continuar o no el desarrollo.

Importante: Si los requerimientos no se identifican bien entonces el costo de modificar

ese requerimiento durante las fases posteriores del desarrollo de software es muy alto.

Ejemplo: Si modificar un requerimiento durante la fase de requerimientos cuesta

$100.000, durante las fases siguientes el costo de modificar ese requerimiento puede ser
de $2.000.000 o incluso hasta $100.000.000 dependiendo del momento en el que se
tenga que modificar el requerimiento.

Obtención y análisis de requerimientos

Tipos de requerimientos:

 Requerimientos funcionales:

 Describen una interacción entre el sistema y su ambiente. Cómo debe comportarse

el sistema ante determinado estímulo.

 Describen lo que el sistema debe hacer, o incluso cómo NO debe comportarse.

 Describen con detalle la funcionalidad del mismo.

 Son independientes de la implementación de la solución.

 Se pueden expresar de distintas formas

P á g i n a 5 | 17
 Requerimientos de usuario: Son declaraciones, en lenguaje natural y en
diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.

 Requerimientos de sistema: Estos requerimientos establecen con detalle las

funciones, servicios y restricciones operativas del sistema. El documento de
requerimientos del sistema deberá ser preciso, y definir exactamente lo que se va.

 Requerimientos no funcionales

 Describen una restricción sobre el sistema que limita nuestras elecciones en la

construcción de una solución al problema.

 Requerimientos del producto: Especifican el comportamiento del producto

(usabilidad, eficiencia, rendimiento, espacio, fiabilidad, portabilidad).

 Requerimientos organizacionales: Se derivan de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador (entrega,
implementación, estándares).

 Requerimientos externos: Interoperabilidad, legales, privacidad, seguridad, éticos.

 Otras Clasificaciones:

 Requerimientos del dominio:

 Reflejan las características y restricciones del dominio de la aplicación del sistema.

 Pueden ser funcionales o no funcionales y pueden restringir a los anteriores.

 Como se especializan en el dominio son complicados de interpretar.

 Requerimientos por Prioridad:

 Que deben ser absolutamente satisfechos

 Que son deseables, pero no indispensables

 Que son posibles, pero que podrían eliminarse

 Requerimientos del Usuario:

P á g i n a 6 | 17
  Son declaraciones en lenguaje natural y en diagramas de los servicios que se
espera que el sistema provea y de las restricciones bajo las cuales debe operar.

 Pueden surgir problemas por falta de claridad, confusión de requerimientos,

conjunción de requerimientos.

 Requerimientos del Sistema:

 Establecen con detalle los servicios y restricciones del sistema.

TÉCNICAS DE DEFINICIÓN DE REQUERIMIENTOS

Como sabemos, un área de conocimiento de gran importancia en el desarrollo de

software es la ingeniería de requerimientos. Esta comprende las actividades de obtención
(captura, descubrimiento y adquisición), análisis (y negociación), especificación, y
validación de requisitos. Además, establece una actividad de gestión de requerimientos
para manejar los cambios, mantenimiento y rastreabilidad de los requerimientos.

A continuación se muestran distintas técnicas utilizadas para obtener estos

requerimientos a la hora de empezar a desarrollar un proyecto:

Entrevistas

La entrevista se puede definir como un “intento sistemático de recoger información de otra

persona” a través de una comunicación interpersonal que se lleva a cabo por medio de
una conversación estructurada.
De igual manera es de gran utilidad para obtener información cualitativa como opiniones,
o descripciones subjetivas de actividades, ya que es una técnica muy utilizada, y requiere
una mayor preparación y experiencia por parte del analista.
Debe quedar claro que no basta con hacer preguntas para obtener toda la información
necesaria. Es muy importante la forma en que se plantea la conversación y la relación
que se establece en la entrevista.

P á g i n a 7 | 17
Estos son algunos de los aspectos más importantes a tener en cuenta al realizar
entrevistas:

 Preparación. Es necesario documentarse e investigar la situación de la

organización analizando los documentos disponibles, de tal forma que la entrevista
se enfoque en aquellos aspectos que están solamente en la mente del entrevistado
y que no son accesibles por otros medios como la observación o el análisis de
documentos.
 Entrevistar al personal adecuado. La mayoría de los analistas adoptan un
enfoque top-down, comenzando a entrevistar a directivos para que brinden un
panorama general de hacia dónde deberían ir las cosas, y terminando por hablar
con los empleados que aportan detalles importantes de la operación.
 Duración. Una entrevista debería durar a lo sumo un par de horas.
 Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados
puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

Lluvia de ideas (Brainstorming).

Esta técnica se puede utilizar para identificar un primer conjunto de requisitos en aquellos
casos donde no están muy claras las necesidades que hay que cubrir, o cuando se está
creando un sistema que habilitará un servicio nuevo para la organización.

Para poder desarrollarla de manera efectiva, los directores de proyecto deberían crear un
ambiente que facilite el trabajo en equipo, y motivarlo continuamente proporcionando
desafíos y oportunidades, por lo que es necesario tener en cuenta ciertos aspectos:

 Evitar las críticas negativas

 Definir bien los objetivos

 Promover la colaboración: 

 Desarrollo de confianza entre los miembros del equipo.

P á g i n a 8 | 17
  Gestión de los conflictos de manera constructiva.

 Fomento de la resolución colaborativa de problemas, y en la toma de decisiones de

modo colaborativo. 

La lluvia de ideas resulta muy útil para todo tipo de organizaciones. Esta práctica resulta
positiva para incentivar la propuesta de ideas no solo en el momento que estén
atravesando un problema, sino para estar mejor preparados antes las posibles crisis del
futuro.
Ejemplos:

 Técnica de 5 Whys:

Se trata de preguntar cinco veces seguidas el porqué de algo para finalmente entender el
problema. Pongamos el ejemplo de un logo. El problema es que el logo no transmite su
esencia de la marca.

 Ranking forzado
Esta técnica es fantástica cuando hay que elegir entre varias ideas complejas. Por
ejemplo, si el objetivo de este brainstorming es generar ideas para una campaña creativa
de una bebida nueva que va a lanzar Coca-Cola, con esta técnica, el mecanismo es el
siguiente:

 Primero, hay que reducir el número de ideas a 10 (si es a 5 mejor).

 Escribirlas en una tabla, en filas.

 En las columnas poner los criterios que ayudarán a elegir la mejor idea, según el
objetivo.

 Cada participante pone una valoración en cada criterio (si hay 10 ideas, la mínima
puntuación será un 10).

 Al final se suman las puntuaciones y se elige la que tenga la mayor valoración.

P á g i n a 9 | 17
Prototipos.

Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas

(que no son totalmente operativos) de la aplicación pedida. Esta técnica es
particularmente útil cuando:
 El área de la aplicación no está bien definida (posiblemente por ser algo muy
novedoso).
 El costo del rechazo de la aplicación por los usuarios es muy alto.
 Es necesario evaluar previamente el impacto del sistema en los usuarios y en la
organización.

Los prototipos de sistema permiten a los usuarios experimentar para ver cómo éste ayuda
a su trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos.
Además de permitir a los usuarios mejorar las especificaciones de requerimientos, el
desarrollo de un prototipo tiene otras ventajas:

I. Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
II. Durante el desarrollo del prototipo, el personal del desarrollo de software puede
darse cuenta de que los requerimientos son inconsistentes y/o están incompletos.
III. Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra
la factibilidad y usabilidad de la aplicación a administrar.
IV. El prototipo se utiliza como base para escribir la especificación para la producción.

En general, el uso de esta técnica es un medio que permite solventar objeciones del
usuario del tipo: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea”. Por lo
general, la construcción de prototipos incrementa los costos en las etapas iniciales de un
proyecto, pero esto se recupera en etapas posteriores gracias al mejor entendimiento de
los requerimientos por parte de los desarrolladores. En algunos casos también se utiliza
como un medio para formalizar la aceptación previa del cliente de los requisitos del
proyecto.

P á g i n a 10 | 17
 Caso de uso.

Un caso de uso es una secuencia de acciones realizadas por el sistema, que producen un
resultado observable y valioso para un usuario en particular, es decir, representa el
comportamiento del sistema con el fin de dar respuestas a los usuarios.
Estos diagramas presentan varios tipos de elementos:

 Actores. Un actor es algo o alguien que se encuentra fuera del sistema y que
interactúa con él. En general, los actores serán los usuarios del sistema y los
sistemas externos al que se esté́ desarrollando.
 Casos de uso. Un caso de uso representa el comportamiento que ofrece el sistema
de información desde el punto de vista del usuario. Típicamente será́ un conjunto
de transacciones ejecutadas entre el sistema y los actores
 Relación. Dependiendo del tipo de relación, la representación en los diagramas
será́ distinta. Así́ pues, las relaciones entre un actor y un caso de uso se
representan mediante una línea continua entre ellos. Las relaciones entre casos de
uso se representan con una flecha discontinua con el nombre del tipo de relación
como etiqueta.

Ventajas

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la

intención que tiene el actor (su usuario) al hacer uso del sistema.

Como técnica de extracción de requerimiento permite que el analista se centre en las

necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la
gente especializada en informática dirija la funcionalidad del nuevo sistema basándose
solamente en criterios tecnológicos.

A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las

tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor
aportan al negocio. Esto facilita luego la priorización del requerimiento.
P á g i n a 11 | 17
Ejemplo:

Taller de requerimientos

Un taller de requerimientos es la manera estructurada de recolectar requerimientos y se

utiliza para dimensionar el alcance, definir, identificar, priorizar y obtener consenso en los
requerimientos que se van a considerar en un proyecto determinado.
Por lo tanto, es muy importante que cuando se lleve a cabo uno de estos talleres, se
aproveche al máximo esa oportunidad única de tener a todos los involucrados en un
proyecto en un solo lugar y ser altamente eficiente y productivo. La metodología es la
siguiente:
Nombre: Taller Estructurado de Requerimientos
Descripción: Reunión especial dedicada a examinar y discutir un grupo de
Requerimientos

P á g i n a 12 | 17
Elementos: Paquete de Requerimientos, Alcance, Comprensión, Confirmación y
Aprobación de Requerimientos
Roles:
Autor.- El analista de negocio responsable de recolectar los requerimientos. Objetivo:
contestar preguntas, escuchar comentarios y sugerencias, realizar cambios a los
requerimientos
Experto(s).- Persona o personas especializadas en la Solución. Objetivo: realizar
preguntas, escuchar comentarios y sugerencias, analizar información, determinar
viabilidad
Moderador.- Facilitador Neutral. Objetivo: facilitar la sesión, mantener el foco en los
requerimientos, imponer la participación, reglas del juego y disciplina, vigilar el
cumplimiento de la agenda, facilitar el proceso de toma de decisiones y consenso
Escribano: Persona que registra los resultados de la sesión. Objetivo: Documentar todos
los comentarios, sugerencias y asuntos surgidos en la sesión
Participantes: Cualquier otra persona involucrada en el proyecto. Objetivo: Leer la
documentación, Presentar y Discutir Comentarios, Realizar Preguntas, Sugerir Cambios a
Requerimientos
Autorizador: Persona con facultades para aprobar cambios a los requerimientos.
Objetivo: Aprobar los Requerimientos durante o al final de la sesión.
Reglas del taller
Definir cuáles son las condiciones de la reunión, por ejemplo: no influencia de puestos
jerárquicos, participación activa, la duración de las discusiones, que se hace si un tema
no se resuelve en el tiempo límite, uso de un “parking lot”etc.
Entregables
Qué resultados debe de generar la reunión: requerimientos confirmados y aprobados,
minuta de la reunión, relación de preguntas, supuestos, comentarios, temas pendientes,
sugerencias y pendientes del “Parking Lot”, etc.

Los resultados de los talleres de requisitos se documentan en uno o varios artefactos de

Requisitos de interesados. A menos que disponga de una buena herramienta de soporte,
suele ser interesante permitir que los interesados entren esta información. Si ha elegido

P á g i n a 13 | 17
discutir el sistema en términos de actores y guiones de uso, es posible que también tenga
que definir un modelo de guión de uso.

Antes del taller

El moderador necesita "vender" el taller a los interesados que deben asistir, y establecer
el grupo que participará en el taller. Los asistentes deben disponer de material
preparatorio para revisarlo antes de llegar. El moderador es responsable del entorno
logístico del taller, como enviar las invitaciones, encontrar la sala apropiada con el
equipamiento necesario para la sesión, y distribuir el orden del día del taller.

Realización de la sesión:
El moderador dirige la sesión, que incluye:

 Dar a todos la oportunidad de hablar.

 Mantener la sesión activa.

 Para los objetivos de gestión de requisitos, la recopilación de una entrada del

Producto de trabajo: Atributos de requisitos apropiados

 Registrar los descubrimientos.

 Resumir la sesión y trabajar en las conclusiones.

Consolidar los resultados:

Después del taller de requisitos, el moderador (junto con los Rol: Analista de sistemas)
deberán dedicar un tiempo a sintetizar los descubrimientos y condensar la información en
un formato presentable.
Ejemplo:

P á g i n a 14 | 17
CONCLUSIÓN

Es muy importante mencionar que el poder formular una especificación de requerimientos

completa y consistente, es un paso muy importante para evitar cometer errores en la
definición de los requerimientos, ya que los mismos pueden resultar muy caros de corregir
una vez desarrollado el sistema. De ahí, la vital importancia que tiene la definición de
requerimientos en generar una adecuada especificación que contemple claramente y sin
ambigüedades los requerimientos del sistema a desarrollar, con el fin primordial de evitar
que los proyectos fracasen debido a una mala elaboración de la definición de
requerimientos.

La importancia de la existencia de esta serie de estándares radica en la posibilidad que

tienen las empresas nacionales de contar con una serie de documentos que puedan
servir como una guía para orientar mejor sus procesos de desarrollo (incluyendo la parte
importante que corresponde a la técnica elegida por la empresa). Hay que notar el aporte
que ha venido a proporcionar la utilización de técnicas como la especificación, la lluvia de
ideas y el desarrollo de prototipos, que ayudan a definir requerimientos de una manera
concisa

P á g i n a 15 | 17
REFERENCIAS

A. GABRIELA. ¿QUÉ ES UN TALLER DE REQUERIMIENTOS? CONSULTADO EL 11 DE

NOVIEMBRE DE 2021 DE: HTTP://GABRIELALMEIDA.COM.MX/259/COMO-LLEVAR- A-

CABO-UN-TALLER-DE-REQUERIMIENTOS-PRIMERA-PARTE/

CILLERO, M. (2016, 9 OCTUBRE). CASOS DE USO. MANUEL.CILLERO.ES.

RECUPERADO 11 DE NOVIEMBRE DE 2021, DE

HTTPS://MANUEL.CILLERO.ES/DOC/METODOLOGIA/METRICA-3/TECNICAS/CASOS-DE-

USO/

OBTENCIÓN DE REQUERIMIENTOS. TÉCNICAS Y ESTRATEGIA. (2021). SG BUZZ.

HTTPS://SG.COM.MX/REVISTA/17/OBTENCION-REQUERIMIENTOS-TECNICAS-Y-

ESTRATEGIA

ÁVILA, C. (2021). DEFINICIÓN DE REQUERIMIENTO |

OVA2_INGENIERIADESOFTWARE. KONRADLORENZ.EDU.CO.
HTTPS://REPOSITORIO.KONRADLORENZ.EDU.CO/MICROSITIOS/001-1527/DEFINICIN_

DE_REQUERIMIENTO.HTML

‌
ALBA, T. (2020, JULY 21). QUÉ ES Y CÓMO GENERAR IDEAS CON LA TÉCNICA

BRAINSTORMING [+EJEMPLOS]. ESFERA CREATIVA; ESFERA CREATIVA.

HTTPS://ESFERACREATIVA.COM/TECNICA-BRAINSTORMING/

P á g i n a 15 | 17