1.  INTRODUCCIÓN
Hoy día la economía global depende más de sistemas automatizados que en
épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una
nueva década de procesos y estándares de calidad. A pesar de los avances
de la tecnología, aún existen procesos de producciones informales, parciales y,
en algunos casos, no confiables.
Sin embargo, a pesar de
los avances de la tecnología, aún
existen procesos de producciones
informales, parciales y, en
algunos casos, no confiables, lo q
ue trae como consecuencia una
alta incidencia de fallos en los
proyectos de software.
Como solución a estas
fallas, la ingeniería de
requerimientos cumple un papel primordial en el proceso
de producción de software, ya que enfoca un área fundamental; la definición de lo
que se desea producir.
Los requerimientos son
declaraciones que identifican
atributos, capacidades,
características y/o cualidades que
necesita cumplir un sistema (o un
sistema de software) para que tenga
valor y utilidad para el usuario.
Un requerimiento debe cumplir ciertos criterios y características:
 ÚNICO: El requerimiento debe poder ser interpretado
inequívocamente de una sola manera.

2.  VERIFICABLE: Su implementación debe poder ser comprobada. El test debe dar
como resultado CORRECTO o
INCORRECTO.
 CLARO: Los requerimientos no deben
contener terminología innecesaria.
Deben ser establecidos de forma clara y
simple.
 VIABLE (REALISTA Y POSIBLE): El
requerimiento debe ser factible según las
restricciones actuales de tiempo, dinero
y recursos disponibles.
 NECESARIO: Un requerimiento no es necesario si ninguno de los interesados
necesita el requerimiento o bien si la retirada de dicho requerimiento no tiene
ningún efecto.
La Ingeniería de Requerimientos cumple
un papel primordial en el proceso de producción
de software, ya que enfoca un área fundamental:
la definición de lo que se desea producir.
Su principal tarea consiste en la
generación de especificaciones
correctas que describan con claridad,
sin ambigüedades, en forma
consistente y compacta,
el comportamiento del sistema; de esta
manera, se pretende minimizar los
problemas relacionados al desarrollo de
sistemas.
“La captura de requisitos es la actividad
mediante la que el equipo de desarrollo de un
sistema de software extrae, de cualquier fuente
de información disponible, las necesidades que
debe cubrir dicho sistema” (Díez, 2001).
“Se ocupa de construir un producto de
software de alta calidad bajo restricciones de
tiempo y presupuesto”. ( Sebastian Uchitel,
2011) - http://www-2.dc.uba.ar

3.  ENTREVISTAS Y CUESTIONARIOS: Las entrevistas son un
método común. Por lo general no se entrevista a toda la gente que se relacionará
con el sistema, sino a una selección de personas
que represente a todos los sectores críticos de la
organización.
 TALLERES: Los requisitos
tienen a menudo implicaciones cruzadas
desconocidas para las personas implicadas
individuales y que a menudo no se descubren en
las entrevistas o quedan incompletamente
definidas durante la misma.
 FORMA DE CONTRATO: En lugar de una entrevista, se
pueden llenar formularios o contratos indicando los requisitos. En
sistemas muy complejos éstos pueden tener centenares de páginas.
 PROTOTIPOS:
Un prototipo es una pequeña
muestra, de funcionalidad
limitada, de cómo sería el
producto final una vez
terminado. Ayudan a conocer la
opinión de los usuarios y
rectificar algunos aspectos
antes de llegar al producto
terminado.
 CASOS DE USO: Un caso de uso es una técnica para
documentar posibles requisitos, graficando la relación del sistema con los
usuarios u otros sistemas.
 PLANIFICACIÓN / EXTRACCIÓN: en
esta etapa, se recogen los requisitos en
bruto, sin pulir. Estos requisitos que se
toman de primeras, acabarán
dividiéndose en muchos requisitos en
las siguientes fases.

4.  ANÁLISIS /
NEGOCIACIÓN: consiste en
estudiar la información obtenida en
la fase anterior y separarlo en
distintos casos para facilitar su
comprensión.
 ESPECIFICACIÓN: Una
vez separados los requisitos
principales, los cuales se
denominan requisitos de alto nivel, pasamos a detallar cada una de las
funcionalidades que queremos que realice nuestro software.
 VALIDACIÓN: Finalmente se chequea que los requisitos cumplan
todas las necesidades que el cliente necesita.
Una especificación de requisitos del software es una descripción completa del
comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que
describen todas las interacciones que se prevén que los usuarios tendrán con el software.
Los requisitos del software se dividen
en tres:
 FUNCIONALES: son los que
el usuario necesita que efectúe el software.
Normalmente se identifican como los
requisitos que responden a la pregunta ¿qué
hace? e.g. El sistema debe emitir un
comprobante al asentar la entrega de
mercadería.
 NO FUNCIONALES: son los
"recursos" para que trabaje el sistema de
información (redes, tecnología). Ej: el soporte de almacenamiento a usar
debe ser MySQL . Normalmente se identifican como los requisitos que
responden a la pregunta ¿cómo lo hace? e.g. rápido, fácil etc.
 EMPRESARIALES U ORGANIZACIONALES: son el marco contextual en el
cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar
costos de expedición.

5. La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
 La educción (a veces llamada
"elicitación", debido a una mala
traducción de "elicitation") de los
requisitos de usuario.
 El análisis y negociación de
requisitos para derivar requisitos
adicionales.
 La documentación de los requisitos
como especificación.
 La validación de los requisitos
documentados contra las
necesidades de usuario.
 Así como los procesos que apoyan estas
actividades.
 Los requerimientos no son obvios y vienen de muchas fuentes.
 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Existen muchos tipos de requerimientos y diferentes niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
 Nunca son iguales. Algunos son más
difíciles, más riesgosos, más importantes o más
estables que otros.
 Los requerimientos están
relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.

ada requerimiento tiene propiedades únicas y
abarcan áreas funcionales específicas.
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
 Son difíciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.

6.  ENTREVISTAS CERRADAS: las preguntas ya están previstas, tienen un orden y una
forma de ser planteadas que no pueden ser modificadas por el entrevistador. Es en
realidad un cuestionario.
 ENTREVISTAS ABIERTAS: en las cuales no se preparan preguntas concretas, y, por
el contrario, se discute con el entrevistado las expectativas que este tiene del
sistema.
 CASOS DE USO Y/O ESCENARIOS: Los casos de uso describen interacciones entre
los usuarios y el sistema, enfatizando en lo que el usuario necesita del sistema. Los
escenarios son ejemplos de sesiones de interacción entre el sistema y el usuario,
donde un solo tipo de interacción entre los dos participantes es simulada y descrita.
 OBSERVACIÓN Y ANÁLISIS SOCIAL: La observación permite a los investigadores
observar lo que los usuarios hacen actualmente en un determinado contexto.
 LLUVIA DE IDEAS: Son sesiones donde todos los participantes brindan sus ideas
para obtener una solución a una problemática.
 PROTOTIPOS: Es programa de computador que implementa algunos de los
requerimientos de un sistema.
 MODELOS: Esquema teórico, generalmente en forma matemática, de un sistema o
de una realidad compleja, como la evolución económica de un país, que se elabora
para facilitar su comprensión y el estudio de su comportamiento.
 ADMINISTRACIÓN DE REQUERIMIENTOS: Es un proceso que tiene por objetivo
comprender y controlar los requerimientos. Como todo proceso de administración,
inicia con la planeación a la par de la identificación inicial de requerimientos.
 CONCLUSIÓN
A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que
se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben
ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la
evaluación de especificaciones alternativas, la formalización de la SRS, entre otras.
Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para
diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema
son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR;
encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece
diferentes soluciones ante un problema.

7. Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a
clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el
proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino
también, del nivel de experiencia que tengan los involucrados.
Entregar software de calidad, a tiempo y dentro del presupuesto, hará que nuestros clientes
confíen y asegurará el crecimiento y madurez de la relación de negocio.
 REFERENCIAS ELECTRÓNICAS
 http://www.monografias.com/trabajos6/resof/resof.shtml
 http://www-2.dc.uba.ar/materias/isoft1/teoricas_2009_1/01-Introduccion_IR_BN.pdf
 http://blogs.salleurl.edu/project-management/gestion-de-requerimientos-ii-
caracteristicas-de-los-requerimientos/
 http://www.academia.edu/14042189/Ensayo_Importancia_Ingenieria_de_Requisitos
 http://katade.com/2016/03/08/la-ingenieria-de-requisitos/
 https://lcrl.files.wordpress.com/2011/07/captura-de-requisitos.docx
 https://es.slideshare.net/jevv_14/ingenieria-de-requisitos-48308372
 https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos
 http://requerimientos.galeon.com/
 http://tecnologicofch.blogspot.com/2013/03/22-tecnicas-de-la-ingenieria-de.html