 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.
 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
 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.
 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.
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.
 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.
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

Infografía

  • 1.
     INTRODUCCIÓN Hoy díala 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: Suimplementació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 YCUESTIONARIOS: 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 deRequisitos 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 quela 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