INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

INSTITUTO TECNOLÓGICO SUPERIOR CORDILLERA

Alumno: Josué Vargas

TÉCNICAS DE LEVANTAMIENTO DE REQUERIMIENTOS

Una etapa fundamental en proyectos de ingeniería de software, es la identificación y documentación

de los requerimientos del futuro sistema al comienzo del proyecto, pues en numerosas ocasiones se
ha demostrado que es cuando pueden prevenirse errores que puedan significar el fracaso del
proyecto.

En la Ingeniería de requisitos, el levantamiento de requerimientos se refiere a la identificación y

documentación de los requerimientos de un sistema, a partir de los usuarios, clientes o interesados
(Stakeholders). A la práctica también se le conoce como Recopilación de requerimientos.

ANÁLISIS DE DOCUMENTACIÓN

Consiste en obtener la información sobre los requerimientos funcionales y requerimientos no

funcionales de software a partir de documentos que ya están elaborados.
Es útil cuando los expertos en la materia no están disponibles para ser entrevistados o ya no forman
parte de la organización.
Utiliza la documentación que sea relevante al requerimiento que se está levantando.
Ejemplos de documentación: Planes de negocio, actas de constitución de proyecto, reglas de
negocio, contratos, definiciones de alcance, memorándums, correos electrónicos, documentos de
entrenamiento, entre otros.

OBSERVACIÓN

Consiste en estudiar el entorno de trabajo de los usuarios, clientes e interesados de

proyecto (Stakeholders).
Es una técnica útil cuando se está documentando la situación actual de procesos de negocio.
Puede ser de dos tipos, pasiva o activa.
En observación pasiva, el observador no hace preguntas, limitándose solo a tomar notas y a no
interferir en el desempeño normal de las operaciones.
En observación activa, el observador puede conversar con el usuario.

ENTREVISTAS

Se realizan con los usuarios o interesados clave.

Direccionan al usuario hacia aspectos específicos del requerimiento a levantar.
Son útiles para obtener y documentar información detallada sobre los requerimientos y sus niveles
de granularidad.
Pueden ser entrevistas formales o informales.
 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

Una clave es mantenerse enfocado en los objetivos de la entrevista.

Las preguntas abiertas son útiles para identificar información faltante.
Las preguntas cerradas son útiles para confirmar y validar información.
El éxito de las entrevistas depende del grado de conocimiento del entrevistador y entrevistado,
disposición del entrevistado de suministrar información, buena documentación de la discusión y en
definitiva de una buena relación entre las partes.

ENCUESTAS O CUESTIONARIOS

Es una técnica útil para recopilar eficientemente los requerimientos de muchas personas.
La clave para el éxito es que tengan un propósito y audiencia claramente definida, establecer fechas
topes para llenar la encuesta, con preguntas claras y concisas.
Deben enfocarse en los objetivos de negocio que se necesitan identificar.
Pueden apoyarse con entrevistas de seguimiento con usuarios individuales.
Pueden contener tanto preguntas cerradas como preguntas abiertas.

MESAS DE TRABAJO (WORKSHOPS)

Es una técnica efectiva para obtener información rápidamente de varias personas.

Es recomendable tener una agenda predefinida y preseleccionar a los participantes,
siguiendo buenas prácticas para reuniones efectivas.
Se puede utilizar un facilitador neutral y un transcriptor (que no sea el mismo facilitador).
Se puede utilizar un material común sobre el cual enfocar la atención y conversar, por ejemplo una
presentación con un desglose del proceso que se está estudiando o un flujograma.
Se pueden combinar con otras técnicas como pueden ser las entrevistas y cuestionarios.

TORMENTA DE IDEAS

Es una sesión de trabajo estructurada orientada para obtener la mayor cantidad de ideas posibles.
Es recomendable limitarlas en el tiempo, utilizar ayudas visuales y designar un facilitador.
Las reglas son importantes, por ejemplo los criterios para evaluar ideas y asignarles un puntaje, no
permitir las críticas a las ideas y limitar el tiempo de discusión.
En una primera fase, se deben identificar la mayor cantidad de ideas, para luego evaluarlas. Todas
las ideas deben ser consideradas y deben limitarse que una idea se le ahogue o critique antes de
tener tiempo de desarrollarla.

HISTORIA DEL USUARIO

Las historias de usuario, son una aproximación simple al levantamiento de requerimientos de

software, en la cual la conversación pasa a ser más importante que la formalización de
requerimientos escritos.
Es recomendable que sean escritas por el mismo cliente o interesado (con apoyo del facilitador si es
necesario), con énfasis en las funcionalidades que el sistema deberá realizar.
Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la funcionalidad y el
resultado esperado de la aplicación en una frase corta.
 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

Las historias de usuario son una de las técnicas más difundidas para levantar requerimientos de
software en metodologías ágiles.

PROTOTIPOS

Los prototipos y los modelos son mecanismos excelentes para presentar ideas a los usuarios porque
ellos pueden ver inmediatamente algunos aspectos claves del sistema. Mostrar los Prototipos puede
provocar que el usuario brinde un mayor número de requerimientos o cambie de idea acerca de los
requerimientos existentes depurándolos.

Los prototipos también pueden ilustrar como la solución podría funcionar o dar a los usuarios
un vistazo de lo que podrían hacer con el sistema. Muchos más requerimientos salen a la vista
cuando el usuario puede comprobar los que están proponiendo.

AHP (PROCESO DE ANÁLISIS JERÁRQUICO)

Fue desarrollado a finales de los 60 por Thomas Saaty, quien a partir de sus investigaciones en el
campo militar y su experiencia docente formuló una herramienta sencilla para ayudar a las personas
responsables de la toma de decisiones.

Su simplicidad y su poder han sido evidenciados en las cientos de aplicaciones en las cuales se han
obtenido importantes resultados y en la actualidad, es la base de muchos paquetes de software
diseñados para los procesos de tomas de decisiones complejas. Además, ha sido adoptado por
numerosas compañías para el soporte de los procesos de toma de decisiones complejas e
importantes.

El AHP es una metodología para estructurar, medir y sintetizar. Ha sido aplicado ampliamente en la
solución de una gran variedad de problemas. Es un método matemático creado para evaluar
alternativas cuando se tienen en consideración varios criterios y está basado en el principio que la
experiencia y el conocimiento de los actores son tan importantes como los datos utilizados en el
proceso.

IDENTIFICACIÓN DE REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la
manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos
funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la

especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones
de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no
es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios
al sistema, retrasando la entrega de éste e incrementando el costo.
 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y

ser consistente. La compleción significa que todos los servicios solicitados por el usuario están
definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de

consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del
sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas
inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas
emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes
revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de
requerimientos.

IDENTIFICACIÓN DE REQUERIMIENTOS NO FUNCIONALES

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega
el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo
y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como
la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la
interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en
el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros
sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las
políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos
de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad
que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la

organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de programación o el método de diseño a
utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su
documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de

desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema
interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse
para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son
impuestos al sistema para asegurar que será aceptado por el usuario.

En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es

posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de
mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva los
requerimientos no funcionales cuantitativos es muy alto.

En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de

requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de forma
separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los
requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e
 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance
apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que
claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace
colocándolos en una sección aparte o diferenciándolos, de alguna forma, de los otros requerimientos
del sistema.

Aspectos a considerar:

Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:

• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?

PROYECTO PROPIO

De acuerdo a mi proyecto de diseñar un sistema que genere campos magnéticos de imán que
ralenticen el giro de las llantas de los vehículos en lugares considerados de alto riesgo, el método a
utilizarse es una mesa de trabajo para que los participantes formen un equipo multidisciplinaria en el
cual se puedan proponer diferentes alternativas y la forma en cómo debería estar estructurado el
sistema de prevención, que medidas, que ramas de la ingeniería se necesita aplicar, que riesgos,
que controles diseñar.

En cuanto a los identificación de requerimientos es importante la identificación de requerimientos

funcionales ya que es necesario que cada punto sea explícitamente y entendido por el sistema
multidisciplinario que analizara como deberá estar integrado y calculado cada parte integrante del
sistema de prevención de accidentes, es decir nada puede quedar sujeto a restricciones que causen
un funcionamiento efectivo del sistema.