Embed Size (px)
Citation preview
UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS”
TRABAJO FINAL ESPECIALIZACIÓN EN PROYECTOS INFORMÁTICOS
METODOLOGÍA PARA LA OPTIMIZACIÓN DE LOS PROCESOS DE RECOLECCIÓN DE INFORMACIÓN Y ANÁLISIS EN LA ETAPA DE
ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE
Autores Patricia Sarmiento Cuervo Diana Carolina Hernández
Director Alexandra Abuchar Porras
Bogotá 2017
2
Resumen
En la ingeniería de software, existe un continuo interés por garantizar que los sistemas
desarrollados cumplan las necesidades reales y esperadas de los clientes, sin embargo, esto no ha
sido posible ya que la etapa inicial, referente a la especificación de requerimientos, no es lo
suficientemente clara y precisa para todas las partes interesadas, siendo esta etapa de vital
importancia dentro del proceso de desarrollo de software.
Esta problemática se debe en gran parte a que no está definida correctamente la información del
alcance, el impacto, y demás elementos dentro de la especificación de los requerimientos. La
investigación se realiza con el fin de mejorar el proceso de recolección, análisis y medición del
alcance en la etapa de especificación de requerimientos de software, para así contribuir al
desarrollo de buenas prácticas en la ingeniería de Software y el fortalecimiento de la calidad de la
industria de sistemas.
Esta investigación está encaminada a identificar los componentes (actividades, ítems,
procedimientos, etc) ausentes y/o deficientes en las metodologías actuales, y que se consideran
importantes para un correcto y preciso levantamiento de información para la etapa de
especificación de requisitos. Así mismo, está orientada a optimizar las actividades y
procedimientos actuales que se mencionan en las metodologías ya existentes en el mercado.
Luego de determinar los componentes ausentes en las metodologías actuales, se busca diseñar
una metodología que permita la inclusión de nuevas prácticas en búsqueda del mejoramiento de
las actividades y procedimientos, que permitan a las organizaciones, mejorar/optimizar los
procesos actuales para el levantamiento de la información de las necesidades de sus clientes, y
posteriormente, un mejor diseño y definición de requerimientos que permita una mayor calidad
de productos y servicios, evitando re procesos en documentación y cambios en la definición del
alcance de los proyectos que ya han iniciado sus actividades, garantizando, una mayor
credibilidad y confianza frente al mercado de la ingeniería de software.
Dentro de la investigación, se manejará terminología tal como Metodología, Análisis,
Requerimiento, Diseño, Especificación, procedimiento, optimización, levantamiento, alcance,
impacto, términos que permitirán al lector desarrollar una idea clara y consistente del proceso de
especificación de requerimientos bajo una metodología de calidad y optimizada.
PALABRAS CLAVE: Metodología, Análisis, Requerimiento, Diseño, Especificación,
procedimiento, optimización, levantamiento, alcance, impacto.
3
Abstract
In software engineering, there is a continuous interest in ensuring that the developed systems
meet the actual and expected needs of the clients, however, this has not been possible because the
initial stage, referring to the specification of requirements, is not what sufficiently clear and
precise for all interested parties, being this stage of vital importance in the process of software
development.
This problem is due in large part to the fact that information on scope, impact, and other
components within the requirements is not correctly defined. The research is performed in order
to improve the process of collection, analysis and measurement of impact (scope) in the stage of
specification of software requirements, in order to contribute to the development of good
practices in Software Engineering and the strengthening of quality of the systems industry.
This research is aimed at identifying components (activities, items, procedures, etc.) that are
absent and / or deficient in current methodologies, and which are considered important for a
correct and accurate information gathering for the requirements specification stage. Likewise, it
is oriented to optimize the current activities and procedures that are mentioned in the
methodologies already existing in the market.
After determining the missing components in the current methodologies, it is sought to design a
methodology that allows the inclusion of new and better activities and procedures, which allow
organizations to improve / optimize current processes for the collection of information on the
needs of their clients, and later, a better design and definition of requirements that allows a
greater quality of products and services, avoiding reprocessing in documentation and changes in
the definition of the scope of projects that have already started their activities, guaranteeing
greater credibility and confidence in the software engineering market.
Within the research, terminology such as Methodology, Analysis, Requirement, Design,
Specification, procedure, optimization, survey, scope, impact, terms will be handled that will
allow the reader to develop a clear and consistent idea of the process of specification of
requirements under a quality and optimized methodology.
KEYWORDS: Methodology, Analysis, Requirement, Design, Specification, Procedure,
Optimization, Survey, Reach, Impact.
4
Agradecimientos
Primero quiero darle las gracias a Dios, quien es mi guía y mi luz ante las adversidades.Quiero darle un especial
agradecimiento a Patricia Sarmiento, mi compañera de especialización, quien durante mi accidente fue un gran
apoyo para poder culminar la universidad, ya no solo es mi compañera, sino una gran amiga a la que nunca olvidaré.
A mi mamá Fanny María Parra, que estuvo conmigo acompañándome y apoyándome en este percance. A los
profesores de la especialización por sus enseñanzas, tiempo, y acompañamiento, especialmente por su comprensión
por lo sucedido durante el segundo semestre.
Diana Carolina Hernández
A Dios por ser mi guía y fortaleza. A mis padres por sus consejos y su ejemplo de perseverancia y constancia. A mi
esposo por su apoyo incondicional, comprensión, amor, no dejarme desfallecer en el camino y ayudarme a culminar
mi especialización. A mi hija por ser la mayor motivación para seguir adelante y ser la razón de mi felicidad. A mi
amiga y compañera de tesis, por su compañía y apoyo constante en este nuevo logro.
Patricia Sarmiento Cuervo
5
Tabla de Contenido
Resumen ........................................................................................................................................................ 2
Abstract ......................................................................................................................................................... 3
1 CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN ................................................................ 9
1.1 IDENTIFICACIÓN DEL PROBLEMA ........................................................................................ 9
1.2 OBJETIVOS ................................................................................................................................ 10
1.2.1 OBJETIVO GENERAL ....................................................................................................... 10
1.2.2 OBJETIVOS ESPECÍFICOS ............................................................................................... 10
1.3 JUSTIFICACIÓN......................................................................................................................... 11
1.4 HIPÓTESIS DE INVESTIGACIÓN............................................................................................ 11
PARTE II CAPÍTULO II GENERALIDADES DEL PROYECTO ............................................................ 12
2.1 MARCO TEÓRICO ................................................................................................................. 12
2.2 MARCO CONCEPTUAL ........................................................................................................ 14
Definición general de Requerimiento ............................................................................................... 14
Clasificación de los requerimientos .................................................................................................. 15
Etapa de Especificación de Requerimientos (IR) ............................................................................ 15
Técnicas de levantamiento de requerimientos ................................................................................. 17
2.3 METODOLOGÍA DE LA INVESTIGACIÓN ............................................................................ 19
2.3.1 LEVANTAMIENTO DE INFORMACIÓN ........................................................................ 19
2.4 LIMITACIONES Y ALCANCE ....................................................................................................... 19
2.5 ORGANIZACIÓN DEL TRABAJO................................................................................................. 20
CAPÍTULO III CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN .................................................... 21
3.1 ANÁLISIS Y DIAGNÓSTICO DE SITUACIÓN ACTUAL ........................................................... 21
3.2 HISTORIA E IMPORTANCIA DE LOS REQUERIMIENTOS ...................................................... 22
3.3 REQUERIMIENTOS EN EL CICLO DE VIDA DE DESARROLLO DE SOFTWARE ................ 24
3.4 METODOLOGÍAS PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS ............................... 26
3.5 ANÁLISIS COMPARATIVO DE LAS METODOLOGÍAS ACTUALES EN LA ETAPA DE
ESPECIFICACIÓN DE REQUERIMIENTOS ....................................................................................... 35
CAPÍTULO IV DESARROLLO DE LA INVESTIGACIÓN ..................................................................... 36
4.1 FORMATOS DE APOYO AL PROCESO DE LEVANTAMIENTO DE INFORMACIÓN .............. 36
6
4.2 METODOLOGÍA PARA EL PROCESO DE LEVANTAMIENTO DE REQUERIMIENTOS. ..... 40
PARTE IV .................................................................................................................................................... 45
CAPITULO V CONCLUSIONES ........................................................................................................... 45
CAPITULO VI RECOMENDACIONES ................................................................................................ 46
BIBLIOGRAFÍA .......................................................................................................................................... 47
7
Tabla de Figuras
Figura 1. Problemas en el levantamiento de Requerimientos ……………………………….…….………..…14
Figura 2. Estrategias para el trabajo de los Requerimientos………………………………….…….…………17
Figura 3. Requerimientos dentro de los niveles de madurez de CMMI …………………………….…….…..22
Figura 4. etapa de definición de requerimientos en el Modelo de desarrollo de software en cascada…...25
Figura 5. etapa de definición de requerimientos en el Modelo de desarrollo de software evolutivo ..…...26
Figura 6. etapa de definición de requerimientos en el Modelo de desarrollo en espiral..………………….26
8
INTRODUCCIÓN
En la actualidad, en los proyectos de desarrollo de software siempre ha existido el interrogante
acerca de por qué los proyectos de software sufren constantes cambios en su alcance luego de
estar implementados, por esta razón, es tan importarte que el proceso de levantamiento de
requerimientos se realice de manera que garantice el éxito del software desarrollado e
implementado y cubra en su totalidad las necesidades para lo cual fue diseñado.
En nuestra experiencia hemos identificado que los mayores problemas en los proyectos de
software y la insatisfacción de los clientes, se dan por el mal levantamiento de requerimientos
que causa pérdidas a las compañías desarrolladoras y reprocesos en las demás etapas del
proyecto. Aunque actualmente se tienen varias metodologías existen problemas de comunicación,
documentación y falta de trabajo en equipo entre el cliente y los proveedores de software. Como
parte de esta problemática, es el desconocimiento entre proveedores y clientes sobre la
funcionalidad del negocio, los ítems que la componen (actividades, entradas, salidas, etc), lo que
conlleva a que, a la hora de especificar un requerimiento, no se tenga claridad sobre la necesidad
o conjunto de necesidades que debe cubrir el software a desarrollar, enfocándose en la
codificación del software sin entender claramente la necesidad de conocer el negocio.
Con el presente trabajo se espera que las Pymes desarrolladoras de software (Pequeñas y
medianas empresas) puedan ejecutar de forma clara y precisa, los procesos de recolección,
análisis y medición del alcance en la etapa de especificación de requerimientos de software a
través de una metodología integral y mejorada, esto con el fin de conseguir un mayor
entendimiento de las necesidades del cliente durante la primera etapa del proyecto, garantizando
así la calidad de un producto de software, disminuyendo tiempos y/o sobre costos por cambios en
el alcance luego de la implementación del software terminado.
9
PARTE I FUNDAMENTACIÓN DE LA INVESTIGACIÓN
1 CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN
1.1 IDENTIFICACIÓN DEL PROBLEMA
Actualmente en las Pymes desarrolladoras de software, se observa que existe una deficiencia en
el proceso de recolección de información sobre las necesidades del cliente, análisis y medición
del alcance en la etapa de especificación de requerimientos de software de los proyectos
implementados. Parte de este problema, es por la falta de entendimiento del proceso definido en
las metodologías existentes en la actualidad, además de la falta de comprensión del negocio y sus
correspondientes necesidades por parte de los proveedores para con sus clientes.
Analizando la causa de los fracasos de algunos proyectos de software en las empresas AS/NET y
SISTEMAS GYG tomadas como referencia de esta investigación, se encuentra que el 50% de
estos fracasos se deben a la gestión deficiente de los requerimientos, generando defectos de
software cuando este ya ha sido entregado al cliente, así como sobrecosto en el proyecto, debido
a los cambios que se deben realizar al producto entregado por no satisfacer la necesidad o
conjunto de necesidades que el cliente requiere cubrir con el software solicitado.
Las metodologías y estándares tales como: International Requirements Engineering Board -
IREB, Especificación de requisitos según IEEE 830-1998, Documentación de Requerimientos
Centrada en el Usuario – DORCU, han permitido a las organizaciones estructurar su proceso de
levantamiento de información para la especificación de requerimientos, sin embargo y de
acuerdo a la investigación realizada en las empresas de referencia, estas metodologías aunque son
aplicadas con base en la documentación que sugieren dichos estándares, no se observa que la
información plasmada en los documentos sean lo suficientemente claros y detallados que
permitan entender al proveedor cual es la necesidad puntual de sus clientes, generando en las
etapas posteriores, cambios y reprocesos en análisis y diseño del proyecto de software.
La posibilidad de integrar estos estándares en una metodología optimizada que permita,
establecer y definir claramente las necesidades de un cliente a través de la recolección y análisis
de la información necesaria y medición del alcance, y posteriormente plasmarlas en la
documentación que relacionan estas metodologías actuales, le garantiza a la organización
desarrolladora de software, establecer y documentar un requerimiento de manera clara y precisa,
que garantice que el producto final a entregarse, supla las necesidades reales del cliente, en el
tiempo y costo acordado inicialmente.
10
1.2 OBJETIVOS
Los objetivos a cumplir en este proyecto se presentan a continuación:
1.2.1 OBJETIVO GENERAL
Plantear una metodología para la optimización de los procesos de levantamiento de información,
análisis, medición del alcance de los proyectos en las pymes, que documente de forma clara y
precisa las necesidades del cliente durante la etapa de especificación de requerimientos de
proyectos de software.
1.2.2 OBJETIVOS ESPECÍFICOS
Analizar las falencias de las metodologías actuales de levantamiento de requerimientos
específicamente de International Requirements Engineering Board - IREB, Especificación
de requisitos según IEEE 830-1998, Documentación de Requerimientos Centrada en el
Usuario – DORCU.
Identificar un conjunto de procedimientos para la identificación clara y precisa de las
necesidades de los clientes.
Identificar las actividades y elementos que no están contempladas en las metodologías
existentes, y son necesarias para llevar a cabo un proceso de levantamiento de
requerimientos completo, estructurado y que proporcione la información necesaria y
suficiente para la documentación de las características de un software.
Integrar los documentos y formatos definidos en las metodologías International
Requirements Engineering Board - IREB, Especificación de requisitos según IEEE 830-
1998, Documentación de Requerimientos Centrada en el Usuario – DORCU, que
garantice la documentación amplia y completa de los requerimientos generados.
Diseñar una metodología integral que incluya un conjunto de procedimientos para la
identificación clara y precisa de un requerimiento, haciendo uso de los documentos y
formatos definidos en las metodologías actuales.
11
1.3 JUSTIFICACIÓN
El levantamiento de requisitos es una etapa inicial, critica y esencial en todo proyecto de
desarrollo de software, sin embargo en muchas ocasiones no se le da la importancia necesaria y
no se recolecta y documenta correctamente la información detallada de las necesidades del
cliente, así mismo no se define un alcance concreto para evitar insatisfacciones por parte del
cliente, ya que el software implementado no cubre todo lo requerido por el usuario o no se tiene
claridad acerca de lo que el sistema debe hacer para suplir las necesidades para lo cual fue
diseñado.
La insuficiencia de actividades en el proceso de levantamiento de requerimientos genera diversas
consecuencias para las organizaciones desarrolladoras, tales como horas extras de trabajo en las
compañías por controles de cambio e incrementos en actividades adicionales a las especificadas
inicialmente.
Es por esta razón, que una buena recolección de información, análisis, detalle y definición del
alcance durante la actividad de levantamiento en la etapa de requerimientos es crucial para el
éxito de los proyectos de desarrollo de software, evitando riesgos como sobrecostos, y reproceso
en actividades ya realizadas.
El tipo de justificación por el cual se desarrolla esta investigación, es de tipo práctica, ya que está
orientada a proponer una metodología que plantee procedimientos y estrategias para ayudar a las
pymes en la optimización de procesos y actividades de la etapa de especificación de
requerimientos de software.
1.4 HIPÓTESIS DE INVESTIGACIÓN
Cada una de las pymes utiliza diferentes metodologías para el levantamiento de requerimientos,
cada una de ellas tiene sus ventajas y desventajas, es por esta razón que se plantea la siguiente
hipótesis:
“Una metodología enfocada a optimizar las actividades principales en la etapa de especificación
de requerimientos, permite a las pymes la generación de software de alta calidad y garantiza una
mayor satisfacción del cliente”.
12
PARTE II CAPÍTULO II GENERALIDADES DEL PROYECTO
En la presente investigación, se abordará conceptos básicos donde interviene el proceso de
levantamiento de información y definición del alcance en la etapa de especificación de
requerimientos. A continuación, se describirá algunos de estos conceptos:
2.1 MARCO TEÓRICO
Actualmente las organizaciones están haciendo mucho más énfasis en los temas del proyecto en
los que el cliente es parte esencial, por proporcionar información valiosa para el desarrollo del
proyecto. Entre estos aspectos se encuentran el pleno entendimiento del problema a resolver y la
importancia de tener satisfecho con la solución al cliente, ya que esta es una forma de medir la
calidad de los productos del software, y por ende de la institución. La ingeniería de
requerimientos es uno de los procesos más importantes, pero a su vez más críticos dentro del
desarrollo de software, ya que es donde se define el diseño de la solución según las necesidades
del cliente. La Ingeniería de Requerimientos nace de la necesidad de administrar y revisar
requerimientos de los clientes en el momento de hacer la especificación del producto. Para lograr
un control más eficiente se generó una serie de pasos que podemos denominar. (Martinez
Guerrrero & Silva Delgado, 2010).
La especificación de requerimientos de software es entendida como el listado de funcionalidades
que el sistema debe realizar derivado del relevamiento de las necesidades de los usuarios. Estos
requerimientos funcionales expresan la totalidad de la funcionalidad que el sistema brindará. Por
otra parte, las condiciones de funcionamiento del ambiente operacional son expresadas por los
requerimientos no funcionales Este listado de requerimientos fue dejado de lado, no utilizado por
los seguidores de metodologías de tipo UP, que se apoyaron en la utilización de los casos de uso
como método no solo de modelar sino de describir requerimientos en las diferentes herramientas
de tipo Case que implementa UML. Un listado de requerimientos bien escrito debe no presentar
ambigüedad. Cuanto más detallado sea, mejor escrito estará. Un error común que se observa que
sucede en las empresas utilizadas como referencia para esta investigación, es la escritura o
especificación de los requerimientos expresando características del producto a construir más que
centrándose en los requerimientos. (Pantaleo, 2010).
Según Martínez Guerrero & Silva Delgado, generalmente los desarrolladores no implementan
todos los requerimientos por cuestiones de limitaciones de tiempo, dinero, recursos, etc. Por
tanto, se vuelve importante el tema de clasificar los requerimientos de mayor a menor prioridad
para el desarrollo del sistema, la cual está basada en tres etapas:
Selección de los criterios definidos para priorizar requerimientos
Importancia: Se debe decidir sobre la importancia de cada uno de los
requerimientos en el sistema
Impacto negativo: Se debe decidir sobre qué implicaciones negativas puede traer
la implementación del requerimiento dentro del sistema.
13
Costo: Esfuerzo que deben hacer los Stakeholders (ya sea económico, de recursos
físicos o humanos o nivel de complejidad) para llevar a cabo el requerimiento.
Riesgo: Es la probabilidad de fallo que pueda tener el requerimiento en su
aplicación.
Determinación de un ordenamiento de acuerdo a criterios específicos de uno
o más Stakeholders.
Composición de un orden final combinando el punto anterior con varios Stakeholders
Dentro del marco de trabajo de la especificación de requerimientos, Se tienen tres objetivos que
son claves para el desarrollo de los proyectos:
1. Lograr un acuerdo entre los desarrolladores y clientes
2. Proporcionar una base para el diseño de la especificación del producto
3. Proporcionar una base para la validación y verificación.
Al ser un proceso complejo, existen distintas aplicaciones del Levantamiento de Requerimientos,
por lo que puede ser ejecutado de diferentes maneras según el contexto. Por esa razón se pueden
considerar problemas en el transcurso de esta parte de la Ingeniería de Requerimientos, sean
técnicos o relacionados a la naturaleza humana. A continuación, se describen los componentes
mencionados:
Figura 1. Problemas en el levantamiento de Requerimientos.
TÉCNICOS HUMANOS
Alcance
Relacionadas al proceso
Relacionadas a la
computación
Múltiples puntos de vista
Fallas en la comunicación
Limitaciones de
conocimiento
Comportamiento ante la
situación
14
2.2 MARCO CONCEPTUAL
Definición general de Requerimiento
El término requerimiento, como concepto general, hace alusión a la necesidad o conjunto de
necesidades que tiene un cliente con relación a una situación en particular, y con base en esta
necesidad, se construye un software con características, restricciones y funciones acordes a la
necesidad planteada. A continuación, relacionaremos la definición del estándar IEEE utilizada
para esta investigación (IEEE Std. 610, 1990):
Una condición o necesidad de un usuario para resolver un problema o alcanzar un
objetivo.
Una condición o capacidad que debe estar presente en un sistema o componentes de
sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
Una representación documentada de una condición o capacidad detallada como las
descritas en los dos puntos anteriores.
De acuerdo a la anterior definición, se tiene entonces que un requerimiento desde el punto de
vista funcional, define lo que un sistema permite realizar al usuario, desde el punto de vista no
funcional, define las condiciones de cómo va a funcionar el sistema en el ambiente productivo.
Los requerimientos permiten definir un sistema a través del establecimiento del alcance, sus
características y prioridades.
Un buen trabajo con los requerimientos determina si el proyecto de software que se va a
desarrollar será de buena o mala calidad, ya que, si esto no se cumple, el costo del proyecto puede
verse afectado por reprocesamiento tanto de información como de actividades propias de la
implementación, así como generarse fallas que a largo plazo afectaran el funcionamiento correcto
del software.
La baja calidad en el desarrollo de software se debe en gran parte a las siguientes afirmaciones
(Pantaleo, 2010):
Falta de conocimiento del negocio por parte de proveedores, clientes y usuarios finales.
Falta de colaboración con los desarrolladores en el relevamiento y análisis de parte de los
Stakeholders.
Falta de planificación de las actividades de trabajo para documentar correctamente y de
manera precisa los requerimientos por parte de los desarrolladores.
Falta de conocimiento de la forma de construir modelos de requerimientos que faciliten su
posterior diseño por parte del equipo de desarrollo.
Falta de validación y verificación de los requerimientos por parte del equipo de calidad o
del mismo equipo de desarrollo, sin embargo, es mucho mejor que estas actividades sean
realizadas por un equipo ajeno al que las desarrolló.
15
Falta de comunicación del conocimiento que se tiene del negocio por parte del cliente y
de los usuarios.
Falta de comprensión del concepto clave acerca de que el desarrollo, debe ser siempre
conducido por los requerimientos, por parte de los desarrolladores.
En resumen, el no entendimiento de los requerimientos significa no conocer o reconocer alguno
de los aspectos mencionados en el listado anterior.
Clasificación de los requerimientos
Los requerimientos pueden clasificarse de acuerdo a sus características y condiciones de
operatividad, entre los cuales se tienen (Camacho Zambrano, 2005)
Requerimientos funcionales. Los requerimientos funcionales son enunciaciones de los
servicios que el sistema debe proveer, como el sistema debe reaccionar a entradas
particulares y como el sistema debe comportarse bajo situaciones particulares. En algunos
casos los requerimientos funcionales deben describir de manera explícita, lo que el
sistema no debe hacer, esto con el fin de determinar el alcance y los servicios que este
brindará.
Requerimientos no funcionales. Estos requerimientos son restricciones sobre los
servicios y funcionalidades ofrecidos por el sistema. Estos incluyen restricciones en el
tiempo que se debe demorar un proceso, restricciones sobre el proceso de desarrollo y
estándares. Los requerimientos no funcionales aplican usualmente a las condiciones o
restricciones con los cuales operará el software.
Requerimientos de dominio. Estos son requerimientos que provienen del dominio de
aplicación del sistema y reflejan características y restricciones de ese dominio. Estos
pueden ser funcionales o no funcionales.
Etapa de Especificación de Requerimientos (IR)
La especificación de requerimientos es la etapa inicial donde se plasman y describen las
necesidades de un usuario (cliente) en forma sistemática. Algunos autores mencionan la
ingeniería de requerimientos como soporte para la construcción de la documentación de esta
etapa.
Existen cuatro actividades generales para la ingeniería de requerimientos (IREB, 2010):
Elicitación: durante la captura de requerimientos, se utilizan diferentes técnicas para
obtener la información de los requisitos (necesidades) de las partes interesadas y otras con
el fin describir los requisitos detalladamente. Las prácticas de IR incluyen
entrevistas, cuestionarios, observación a la labor del usuario, talleres, lluvia de
ideas, casos de uso, juegos de rol y la creación de prototipos.
16
Con el objetivo de ampliar esta actividad, se hace énfasis en la estrategia que se puede
integrar para el desarrollo de los requerimientos, a continuación, se describe la estrategia:
Figura 2. Estrategias para el trabajo de los Requerimientos.
Documentación: durante la actividad de documentación, se describen los requisitos
adecuadamente. Se utilizan diferentes técnicas para documentar los requerimientos
usando lenguaje natural o modelos conceptuales.
Validación y negociación: para garantizar que se cumplen los criterios de calidad
predefinidos, los requisitos documentados deben ser validados y aceptados desde el
principio por los Stakeholders.
Gestión: la gestión de requerimientos es transversal a todas las demás actividades y
comprende las condiciones que son necesarias para estructurar los requerimientos, de
prepararlos para que pueden utilizarse por los diferentes roles involucrados en la gestión
de los mismos, para mantener la consistencia después de validarlos y para asegurar que
puedan ser diseñados y desarrollados correctamente.”
-Definir propósito y
participantes
-Definir forma de trabajo
-Preparar información
-Capacitar a los
participantes
-Preparar el lugar
-Comenzar la reunión
-Conducir reunión
-Cerrar la reunión
-Revisar
-Asignar tareas
-Publicar
documentación
-Planear próximos
pasos
-Medir Valor
agregado
-Ajustar el proceso
17
De acuerdo a lo anterior, la investigación estará centrada en la etapa de Licitación, ya que la
investigación busca mejorar las actividades principalmente de recolección de información
análisis y medición del alcance de un requerimiento dentro de la etapa de especificación de
requerimientos.
Técnicas de levantamiento de requerimientos
A continuación se describen algunas técnicas relevantes para el proceso de levantamiento de
información para la documentación de requerimientos (pmoinformatica, 2016):
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.
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.
18
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 de 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.
19
Las historias de usuario son una de las técnicas más difundidas para levantar
requerimientos de software en metodologías ágiles.
2.3 METODOLOGÍA DE LA INVESTIGACIÓN
Con base en la problemática y contexto mencionado en los capítulos anteriores, el trabajo de
grado se plantea como un tipo de investigación descriptiva y práctica, ya que busca describir una
metodología para optimizar los procesos y actividades iniciales de la etapa de especificación de
requerimientos para las pequeñas y medianas empresas desarrolladoras de software.
2.3.1 LEVANTAMIENTO DE INFORMACIÓN
Para el desarrollo de la investigación, se tendrá en cuenta técnicas de recolección de información
tales como la observación, con el que se busca identificar y extraer los elementos
(procedimientos, formatos, guías) de las metodologías actuales existentes para la ingeniería de
requerimientos, analizar las falencias de dichos elementos, elaboración de cuadros comparativos
entre metodologías para confrontar la información de cada una, realizar el diseño de plantillas
que integren la información de acuerdo a los cuadros comparativos realizados y finalmente
generar una metodología mejorada e integral que garantice que los procesos de recolección de
información, análisis y medición del alcance en la etapa de especificación de requerimientos de
software se realice de forma completa y precisa.
2.4 LIMITACIONES Y ALCANCE
Para entender la estructura teórica, alcance y limitaciones de este modelo, es importante denotar
que está orientado a integrar diferentes metodologías en la etapa de especificación de
requerimientos.
El presente trabajo de grado tiene como alcance la estructuración y diseño de una metodología
integrada de especificación de requerimientos la cual podrá ser utilizada en cualquier Pyme que
requiera una metodología, fácil, ágil, entendible y bien documentada. En esta metodología se
podrá apoyar la empresa para competir con un producto de mejor calidad, desarrollado en un
menor tiempo y dentro de los costos establecidos.
20
2.5 ORGANIZACIÓN DEL TRABAJO
El plan de trabajo tiene como finalidad realizar la descripción de las actividades generales y
especificas a realizar para desarrollo este trabajo de investigación, buscando tener una visión de
forma individual y grupal de las actividades necesarias para el desarrollo del presente trabajo.
A continuación, se describen las actividades a realizar:
PARTE I
CAPÍTULO I DEFINICIÓN DEL PROBLEMA
1.1 Identificación del problema
1.2 Objetivos
1.3 Justificación
1.4 Hipótesis de investigación
PARTE II
CAPÍTULO II GENERALIDADES DEL PROYECTO
2.1 Marco teórico
2.2 Marco Conceptual
2.3 Metodología de la investigación
2.4 Limitaciones y alcance
2.5 Organización del trabajo
CAPÍTULO III CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN
3.1 Análisis y diagnóstico de situación actual
3.2 Historia e importancia de los requerimientos
3.3 Requerimientos en el ciclo de vida de desarrollo de software
3.4 Metodologías para la especificación de requerimientos
3.5 Análisis comparativo de las metodologías actuales en la etapa de especificación de
requerimientos
CAPÍTULO IV DESARROLLO DE LA INVESTIGACIÓN
4.1 Formatos de apoyo al proceso de levantamiento de información.
4.2 Metodología para el proceso de levantamiento de requerimientos.
PARTE IV
CAPITULO IV CONCLUSIONES
CAPITULO V RECOMENDACIONES
BIBLIOGRAFÍA
21
CAPÍTULO III CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN
3.1 ANÁLISIS Y DIAGNÓSTICO DE SITUACIÓN ACTUAL
Una etapa fundamental en los proyectos de ingeniería de software es el levantamiento de
requerimientos, debido a que es el comienzo del proyecto y en la cual se puede identificar y
prevenir errores para el éxito del proyecto.
Las pequeñas y medianas compañías constituyen el 90% del sector empresarial (Genoveva,
2003), por esta razón, son nuestra base de investigación para analizar y establecer mejoras en el
levantamiento de requerimientos en estas compañías, las cuales tienen una gran cantidad de
necesidades que por medio de este estudio podemos satisfacer dichos factores que las afectan.
Existen muchas técnicas útiles que implementan las compañías tales como ASNET y SISTEMAS
GYG tomadas como referencia para esta investigación, para el levantamiento de requerimientos:
Entrevistas: Estas son realizadas con los usuarios o Stakeholders en las cuales se definen
las necesidades del cliente con preguntas abiertas para identificar información faltante y/o
preguntas cerradas para confirmar y validan la información.
Encuestas o cuestionarios: Son útiles para recopilar información de muchas personas, se
debe tener en cuenta el propósito y el enfoque de la encuesta.
Tormenta de ideas: En una sesión de trabajo estructurada y organizada se obtienen la
mayor cantidad de ideas posibles.
Historias de usuario: Son escritas por los usuarios en las cuales describen el
requerimiento y el beneficio de la funcionalidad que requieren.
Observación: Esta técnica es utilizada cuando se documenta la situación actual del
negocio.
Es también importante analizar la situación de las compañías con respecto a los niveles definidos
de CMM, esto con el fin de definir los elementos principales con los que debe contar una
empresa desarrolladora de software para clasificar en alguno de los niveles de CMM (Software
Engineering Institute).
Figura 3. Requerimientos dentro de los niveles de madurez de CMMI.
22
La calidad en los procesos de desarrollo de software es un elemento importante y estratégico
debido a la fuerte competencia que tienen estas compañías. Actualmente las compañías anhelan
tener certificación en CMMI debido a los beneficios que se tienen de mejora, a continuación, se
enuncian algunos de los beneficios (ComputerWorld):
Hacia el cliente:
Productos entregados en tiempo y presupuesto
Productos que cumplen requerimientos
Mayor control sobre presupuesto
Mejora en calidad
Consistencia en la organización
Mejora de la productividad
Hacia su organización:
Ventaja competitiva
Mejora en la relación con otros proveedores
Forma consistente de hacer el trabajo
3.2 HISTORIA E IMPORTANCIA DE LOS REQUERIMIENTOS
A lo largo del tiempo, la sociedad ha buscado los mecanismos suficientes para expresar las
necesidades, y conseguir cubrirlas para el alcance de sus metas y objetivos, ya sean a nivel
personal, profesional, emocional, etc. Esto no solo sucede de forma individual, sino a nivel de
grupo, siendo este último la base de lo que hoy se conformarían como empresas. La expresión de
estas necesidades ha hecho que aquellas personas o empresas que desean cubrirlas, formalicen
actividades asociadas a recolectar esta información como un proceso al que se le denominó
especificación de necesidades de los clientes.
Desde el aspecto del desarrollo de software y la informática en general, las actividades de
recolección de información de las necesidades de los clientes se incluían dentro del análisis de
sistemas. En esta fase se incluyeron métodos tales como análisis de sistemas y técnica de diseño
incorporado por los autores Ross y Schoman en 1977 así como el método de análisis y diseño
estructurados del autor Marco en 1978. El objetivo general de todos estos métodos consistió en
analizar los requisitos mediante un enfoque “divide y vencerás” que permitía ir dividendo las
necesidades de un sistema en piezas más pequeñas y después definir las funciones u objetivos que
cada parte del sistema debería realizar.
El énfasis de estos métodos estructurados para el análisis de requisitos fue redefinido en los años
80 por las técnicas JAD (Joint Applications Development, Desarrollo Conjunto de Aplicaciones,
que tuvieron como objetivo acelerar el proceso de modelado de las funcionalidades de los
sistemas involucrando a los usuarios en el diseño a través de reuniones, tormentas de ideas y
23
escenarios que permitirá al usuario describir la operación las funcionalidades y características del
sistema.
Otra área que contribuyó a la creación de la ingeniería de requisitos fue la ingeniería de software,
el objetivo de esta área fue el establecimiento del proceso de especificación de manera formal que
condujera a la entrega de productos de software de calidad y precisos con las necesidades de los
usuarios. Los ingenieros de software se encontraron con que, a pesar de contar con detalladas
especificaciones formales, algunos sistemas no eran aceptados o fallaban en circunstancias que
no habían sido contempladas ni detalladas.
La ingeniería de requisitos ha crecido a partir de estas áreas, la cual se ha centrado en investigar
técnicas y herramientas que complementen los métodos que aporte al proceso de la ingeniería
del software la base de documentación para los desarrollos de software que garanticen la real
satisfacción del cliente. Por esta razón, la especificación de requerimientos llamada también
ingeniería de requerimientos, ha pasado a ser de las actividades más importantes y relevantes en
el proceso de desarrollo de software, siendo esta la base y soporte a los demás procesos de la
ingeniera de software.
A continuación se detallan algunos aspectos que reflejan la importancia de la ingeniería de
requerimientos como actividad en el desarrollo de software:
Describe las capacidades que la aplicación debe proporcionar en términos comerciales y
funcionales para los clientes.
Cada actividad de la ingeniería de requerimientos consiste de una serie de pasos
organizados y bien definidos.
La ingeniería de requerimientos proporciona un conjunto de técnicas que apoyan al
control y las actividades de mantenimiento, tales como estimación de costos, tiempo y
recursos necesarios.
Disminuye los costos y retrasos de los proyecto ya que si se tienen correctamente
detallados las funcionalidades y características del software a construir, es menos
probable que se tenga que reinvertir tiempo y recursos en detallar o reformular las
características de las funcionalidades.
Aporta calidad a los productos de software ya que los desarrollos cuentan con una base de
documentación y conocimiento solida sobre el software que se requiere crear.
La especificación de requerimientos representa una comunicación clara y coherente entre
clientes y desarrolladores.
La ingeniería de requerimientos obliga al cliente a especificar sus requerimientos de
forma detallada, cuidadosa y clara, promueve la revisión y retroalimentación de cada
especificación, por lo que se le involucra durante todo el desarrollo del proyecto.
24
3.3 REQUERIMIENTOS EN EL CICLO DE VIDA DE DESARROLLO DE
SOFTWARE
El ciclo de vida del software, consta de varias etapas en los cuales se desarrolla la información
de un requerimiento y se transforma en un producto, a través de las actividades de análisis, diseño
y construcción de software. A continuación se ilustran los modelos actualmente utilizados de
Desarrollo de software:
Modelo en cascada
Este modelo es de los más antiguos definidos para la construcción de software también es
conocido como modelo secuencial-Lineal, y basa principalmente de 5 etapas, la primera etapa es
la etapa que tendremos en cuenta para el desarrollo de la presente investigación, como se ilustran
a continuación:
Figura 4. Ilustración de la etapa de definición de requerimientos en el
Modelo de desarrollo de software en cascada tomada y modificada (Ingeniería de Software, 7ª
Edición, 2005).
Modelo Evolutivo
Este modelo se basa en desarrollar una implementación inicial, y de acuerdo a la revisión y
comentarios de los usuarios finales, esta versión inicial tendrá refinamientos hasta llegar a la
versión final del producto.
(Pressman, 2010) Afirma que “el software, como todos los sistemas complejos, evoluciona en el
tiempo. Es frecuente que los requerimientos del negocio y del producto cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria rectilínea hacia el
producto final; los plazos apretados del mercado hacen que sea imposible la terminación de un
software perfecto, pero debe lanzarse una versión limitada a fin de aliviar la presión de la
competencia o del negocio; se comprende bien el conjunto de requerimientos o el producto
básico, pero los detalles del producto o extensiones del sistema aún están por definirse. En
estas situaciones y otras parecidas se necesita un modelo de proceso diseñado explícitamente
para adaptarse a un producto que evoluciona con el tiempo.”
25
En este modelo la etapa de especificación de requerimientos genera una versión inicial del
producto, como se muestra a continuación:
Figura 5. Ilustración de la etapa de especificación de requerimientos en el
Modelo de desarrollo de software evolutivo, tomada y modificada (Ingeniería de Software, 7ª
Edición, 2005).
Modelo en Espiral
Dentro de este tipo de modelo, se puede encontrar el modelo en espiral, donde se enlaza la
construcción de prototipos conservando los principios de las etapas definidas en el modelo en
cascada o secuencial-lineal, en este modelo también se incluye la especificación y validación de
requerimientos como se muestra a continuación:
Figura 6. Ilustración de la etapa de especificación de requerimientos en el
Modelo de desarrollo en espiral. Fuente: Adaptación de los autores a Bohem (Ingeniería de
Software, 7ª Edición, 2005).
26
3.4 METODOLOGÍAS PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS
El impacto de la ingeniería de requisitos (RE) en el desarrollo de sistemas exitosos y orientados
al cliente ya toma gran importancia en los desarrollos de software. Se ha convertido en una
práctica común proporcionar recursos para la ingeniería de requisitos. Además, hay una
comprensión cada vez mayor de que el papel del ingeniero de requisitos es esencialmente
autónomo y comprende una serie de actividades exigentes. Para el desarrollo de esta
investigación, se toman tres metodologías que tratan el tema de la especificación de
requerimientos. A continuación se detallan estas metodologías con el fin de identificar los
elementos claves para la especificación de requisitos, así como aquellos aspectos en los que no se
observa fortaleza.
Metodología International Requirements Engineering Board - IREB
Esta metodología se centra básicamente en las habilidades, actividades y técnicas que debe tener
en cuenta un ingeniero de requerimientos para el levantamiento y documentación de la
especificación de requerimientos. Esta metodología está diseñada para formar ingenieros de
requisitos con los elementos que debe tener en cuenta a la hora de realizar el levantamiento de
información y la especificación de la documentación.
El ingeniero de requisitos como rol de proyecto a menudo es el centro de atención. Por lo general,
es el rol que tiene contacto directo con las partes interesadas y tiene la capacidad y la
responsabilidad de familiarizarse, conocer y comprender el negocio y las necesidades de los
usuarios. Este rol la que identifica las necesidades subyacentes a las declaraciones de las partes
interesadas y las corrige de una manera que los arquitectos y desarrolladores, puedan
comprenderlos e implementarlos. El ingeniero de requisitos es, un traductor que entiende las
necesidades de los usuarios, que posee los conocimientos técnicos de TI para estar al tanto de los
problemas a los que se enfrentan los desarrolladores y para poder comunicarse con ellos. De
acuerdo a lo anterior, el ingeniero de requisitos tiene un papel central en el proyecto.
Dentro de las habilidades que debe tener un ingeniero de requisitos están:
Pensamiento analítico
Empatía
Habilidades de comunicación
Habilidades de resolución de conflictos
Habilidades de moderación
Confianza en sí mismo
Persuasión
Según la metodología IREB, las actividades básicas que debe tener en cuenta el ingeniero de
requisitos, son las siguientes:
Elicitación: durante la obtención de requisitos, se utilizan diferentes técnicas para obtener
los requisitos de las partes interesadas y otras fuentes para refinar los requisitos con
mayor detalle.
27
Documentación: durante la documentación, los requisitos obtenidos se describen con un
lenguaje adecuado y apropiado para todas las partes interesadas. Se utilizan diferentes
técnicas para documentar los requisitos mediante el uso de lenguaje natural o modelos
conceptuales como por ejemplo UML.
Validación y negociación: para garantizar que se cumplan los criterios de calidad
predefinidos, los requisitos documentados deben validarse con los usuarios y negociarse
desde el principio.
Gestión: la gestión de requisitos es ortogonal a todas las demás actividades y comprende
las medidas necesarias para estructurar los requisitos, para prepararlos de modo que
puedan ser utilizados por diferentes funciones, para mantener la coherencia después de los
cambios y para garantizar su implementación.
La etapa de Elicitación, es la etapa que interesa para esta investigación. Las demás etapas son
mencionadas con el fin de contextualizar al lector con una visión holística del proceso de
ingeniería de requerimientos.
Además de las actividades que debe llevar a cabo el ingeniero de requisitos, debe tener en cuenta
los tipos de requerimientos al momento de desarrollar la etapa de elicitación. Según la
metodología IREB los requerimientos se agrupan de acuerdo a los siguientes tipos:
Los requisitos funcionales definen la funcionalidad que ofrece el sistema a desarrollar.
Por lo general, estos requisitos se dividen en requisitos funcionales, requisitos de
comportamiento y requisitos de datos.
Los requisitos de calidad definen las cualidades deseadas del sistema a desarrollar y, a
menudo, influyen en la arquitectura del sistema más que los requisitos funcionales. Por lo
general, los requisitos de calidad se refieren al rendimiento, la disponibilidad, la
confiabilidad, la escalabilidad o la portabilidad de un sistema. Los requisitos de este tipo
son también llamados requisitos no funcionales.
Restricciones. Los requisitos de este tipo pueden restringir el sistema mismo (por
ejemplo, "El sistema se implementará mediante servicios web") o el proceso de desarrollo
("El sistema estará disponible en el mercado a más tardar en el segundo trimestre de
2012"). A diferencia de los requisitos funcionales y de calidad, las restricciones no se
implementan, se respetan porque limitan las características y cualidades del software
durante el proceso de desarrollo.
En el proceso de desarrollo, la ingeniería de requisitos cumple con la tarea de identificar todos
aquellos aspectos que tienen relación con el sistema. Al hacerlo, se pueden identificar aquellas
partes externas que influirán de gran manera en los requisitos del sistema. Para poder especificar
los requisitos para un sistema correcta y completamente, es necesario identificar las relaciones
entre el sistema los aspectos que lo afectan de la manera más precisa posible. La parte de la
realidad que es relevante para los requisitos de un sistema se denomina contexto del sistema. Los
siguientes posibles aspectos de la realidad influyen en el contexto de un sistema:
28
Personas (partes interesadas o grupos de partes interesadas)
Sistemas en funcionamiento (otros sistemas técnicos o hardware)
Procesos (procesos técnicos o físicos, procesos comerciales)
Eventos (técnicos o físicos)
Documentos (por ejemplo, leyes, estándares, documentación del sistema)
Elicitación de Requerimientos
Existen tres tipos diferentes de fuentes de requisitos:
Los grupos de interés: corresponde a las personas u organizaciones que (directa o
indirectamente) influyen en los requisitos de un sistema. Los ejemplos de partes
interesadas son usuarios del sistema, operadores del sistema, desarrolladores, arquitectos,
clientes y evaluadores.
Documentación: a menudo contienen información importante que puede proporcionar los
requisitos. Los ejemplos de documentos son documentos universales, como normas y
documentos legales, así como documentos específicos de características del negocio y
organización, como documentos de requisitos e informes de errores de sistemas
heredados.
Sistemas funcionales: pueden ser sistemas heredados o predecesores, así como sistemas
competidores. Al brindarles a las partes interesadas la oportunidad de probar el sistema,
pueden obtener una impresión del sistema actual y pueden solicitar extensiones o cambios
según sus impresiones.
Técnicas de elicitación de Requerimientos
Para el desarrollo de la elicitación de requerimientos, se cuenta con técnicas que apoyan el
proceso de captura y recolección de información. Dentro de las técnicas que resalta la
metodología IREB, se tienen las siguientes:
Entrevista: Durante una entrevista, el ingeniero de requisitos hace preguntas
predeterminadas a uno o más interesados y documenta las respuestas.
Cuestionario: Hacer uso de preguntas abiertas y / o cerradas (por ejemplo, preguntas de
opción múltiple) es otra forma de obtener los requisitos de las partes interesadas. Si hay
un gran número de participantes que deben ser encuestados, un cuestionario en línea es
una opción viable. Los cuestionarios pueden generar una gran cantidad de información en
un corto período de tiempo y a bajo costo.
Lluvia de ideas: las ideas se recopilan dentro de un marco de tiempo determinado,
generalmente en grupos de 5 a 10 personas. Las ideas son documentadas por un
moderador sin discutirlas, juzgarlas o comentarlas al principio. Esta técnica es
especialmente efectiva cuando un gran número de personas de diferentes grupos de
interés están involucradas. Entre las ventajas de esta técnica es que se puede recopilar una
29
gran cantidad de ideas en un corto período de tiempo y múltiples personas pueden ampliar
estas ideas en colaboración.
Técnica analógica: los problemas que enfrenta el proyecto se asignan a una situación
análoga que ocurre en la naturaleza, y se buscan las soluciones que proporciona la
naturaleza y luego se correlaciona con el proyecto.
Arqueología de sistemas: La arqueología del sistema es una técnica que extrae la
información necesaria para construir un nuevo sistema a partir de la documentación o
implementación (código) de un sistema heredado.
Reutilización: Los requisitos que se han compilado previamente y se han elevado a un
cierto estándar de calidad pueden reutilizarse. Para hacer eso, los requisitos se almacenan
en una base de datos, por ejemplo, y se mantienen disponibles en el nivel de detalle
requerido para su reutilización. Mediante la reutilización, los costos involucrados con los
procedimientos de obtención pueden reducirse significativamente.
Metodología de Especificación de requisitos según IEEE 830-1998
Ahora se estudia los conceptos claves para la especificación de requerimientos según la norma
IEEE 830. Esta metodología hace referencia a los elementos que debe comprender una
especificación de requerimientos de software. A diferencia de la anterior metodología, que se
centra en las actividades y habilidades del ingeniero de requisitos, la IEEE 830 se centra en el
detalle que debe llevar la documentación relacionada a la especificación de software.
A continuación se presenta una guía de lo que debe contener la especificación de requisitos de
software:
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones, siglas, y abreviaciones
1.4 Referencias
1.5 Apreciación global
2. Descripción global
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones
2.5 Atención y dependencias
2.6. Repartir proporcionalmente los requisitos
3. Los requisitos específicos
Apéndices
Índice
30
A continuación se hace una descripción del contenido de cada uno de los elementos que compone
la especificación de requerimientos de software según la metodología:
Capítulo Introducción
Propósito: tiene como finalidad especificar a qué público va dirigida la especificación de
requerimientos de software.
Alcance: tiene como finalidad identificar el producto de software que debe ser diseñado (por
ejemplo, Generador de Reportes, modulo de contabilidad, etc.). En esta sección se debe explicar
que hará y que no hará el software a desarrollar. Así mismo debe describir la aplicación de
software especificando los beneficios que brindará, así como los objetivos y metas del mismo.
Definiciones, siglas, y abreviaciones: en esta sección se debe proporcionar las definiciones de
todas las condiciones, siglas y abreviaciones que se requieren para interpretar la especificación
de software apropiadamente. Esta información puede detallarse por referencias de uno o más
apéndices dentro del mismo documento de especificaciones o por la referencia a otros
documentos.
Referencias: en esta sección se debe proporcionar una lista de las referencias de los documentos
utilizados para la especificación de requerimientos. Adicionalmente, se debe identificar cada
documento por el título, fecha y publicación de la organización. El objetivo es especificar de
donde se obtuvieron las referencias y fuentes de información para la especificación.
Apreciación global: esta sección describe lo que contiene el documento de especificación de
requerimientos de software adicional al capítulo de introducción.
Capítulo Descripción global
Perspectiva del producto: esta sección describe las características del software, describe cómo el
software opera dentro de las restricciones que incluye interfaces del sistema, interfaces con el
usuario, interfaces con el software, interfaces de comunicaciones, restricciones de memoria. En
términos de funcionamiento describe el modo de funcionamiento en la organización del usuario,
los periodos de tiempo de funcionamiento interactivo y periodos de funcionamiento inhabilitados
del software y datos que procesan las demás funciones.
Funciones del producto: Esta sección de la especificación de requerimientos de software debe
proporcionar una descripción general de las funciones mayores que el software realizará,
utilizando por ejemplo los métodos textuales o modelos gráficos para mostrar las funciones
diferentes y sus relaciones.
Características del usuario: esta sección debe describir las características generales de los
usuarios del producto que incluya nivel educativo, experiencia, y la formación técnica para la
manipulación del software.
31
Restricciones: Esta sección debe proporcionar una descripción general de las características
limitantes para el funcionamiento del software. Algunas de estas características son:
Políticas reguladoras
Limitaciones del Hardware
Interfaces a otras aplicaciones
Funcionamiento Paralelo
Funciones de la Auditoría
Funciones de Control
Requisitos de lenguaje
Requisitos de Fiabilidad
Credibilidad de la aplicación
Seguridad y consideraciones de seguridad
Atención y dependencias: Esta sección debe listar cada uno de los factores que afectan los
requisitos descritos en la especificación de requerimientos. Estos factores no son las restricciones
del diseño de software.
Repartir proporcionalmente los requisitos: Esta sección del documento de especificaciones de
software debe identificar y describir los requisitos que serán implementados y tenidos en cuenta
en las versiones futuras del sistema.
Capítulo Requisitos Específicos
Este capítulo debe contener todos los requisitos del software a un nivel de detalle suficiente para
permitirles a los ingenieros, diseñar un sistema cumpliendo los requisitos del software requerido
y a los certificadores, probar que el sistema satisface esos requisitos. A lo largo de este capítulo,
cada requisito descrito debe ser externamente perceptible por los usuarios, operadores u otros
sistemas externos. Estos requisitos deben incluir por lo menos una descripción de cada en el
sistema, cada salida del sistema y todas las funciones realizadas por el sistema durante su
procesamiento. Esta es la parte más grande y más importante de la especificación de
requerimientos.
Metodología Documentación de Requerimientos Centrada en el Usuario -
DORCU para la Ingeniería de Requerimientos
Siguiendo con la investigación, la siguiente metodología que se analiza es la DoRCU
(Documentación de Requerimientos Centrada en el Usuario), la cual consta de las siguientes
etapas:
Elicitación de requerimientos
Análisis de Requerimientos
Especificación de Requerimientos
Validación y Certificación de los Requerimientos
32
Elicitación de Requerimientos
Esta es la etapa en donde se indaga sobre las actividades que realiza el cliente/usuario, se busca
comprender sus necesidades y se detallan las restricciones que puedan afectar el desarrollo del
proyecto que cubra dichas necesidades. Como resultado de las acciones realizadas se tiene el
conjunto de los requerimientos de todas las partes involucradas.
Esta etapa está dividida en las siguientes sub etapas:
Formar el equipo multidisciplinario: La recolección de requerimientos es una actividad
que requiere el asesoramiento de profesionales especializados. Este asesoramiento puede
incluso requerir de las sesiones de elicitación por parte de especialistas en comunicación.
Buscar hechos: esta etapa busca indagar acerca del contexto del problema, de los
objetivos globales, límites e interfaces para el software que se desarrollará.
Recolectar y clasificar requerimientos: En esta etapa se describen los objetivos,
necesidades y requerimientos de clientes y usuarios. Estas necesidades y requerimientos
son verificadas comparándolas con los objetivos globales del software que fueron
recolectadas en la búsqueda de hechos. Es importante recolectar toda la información
posible. Es importante destacar los términos que son propios del lenguaje entre
desarrollador y usuarios. Una vez recolectados los requerimientos, se deben clasificar
estos requerimientos en funcionales y no funcionales.
Evaluar y racionalizar: esta etapa involucra la valoración del riesgo, con el fin de
determinar las condiciones técnicas, de costos y tiempo. Esta etapa también debe verificar
y confirmar que los requerimientos obtenidos de las etapas anteriores, son expresados con
claridad y precisión. Mediante esta verificación de requerimientos, se ponen en evidencia
las inconsistencias que pueden surgir entre los requerimientos extraídos.
Dar prioridad: esta etapa está dirigida a que los requerimientos deben tener prioridades
basándose en las necesidades del usuario. el costo y la dependencia. Esta prioridad debe
estar documentada en la especificación de requerimientos.
Integrar y validar: el objetivo de esta actividad es que los requerimientos que puedan ser
agrupados con el fin de obtener un conjunto de requerimientos.
Documentar la etapa: toda la información recopilada de las etapas anteriores, debe quedar
documentada de manera detallada y legible, donde se utilice un lenguaje común tanto para
los ingenieros del proyecto que desarrollaran el software como los usuarios y clientes.
Análisis de Requerimientos
En esta etapa se estudian los requerimientos extraídos en la etapa anterior, a los efectos de poder
detectar, entre otros, la presencia de áreas no especificadas, requisitos contradictorios y peticiones
33
que aparecen como vagas e irrelevantes. El resultado de haber llevado a cabo las tareas que
involucran estos términos puede, en más de una oportunidad, hacer que se deba regresar a la
primera etapa, a los efectos de eliminar todas las inconsistencias y falencias que se han detectado.
En esta etapa ya se realizan aproximaciones a un lenguaje técnico.
La etapa de análisis está dividida en las sub etapas:
Reducir ambigüedades en los requerimientos: en esta sub etapa se realizan las tareas que
permiten eliminar los términos que tienen más de una acepción, unificando el léxico
empleado entre ingenieros y usuarios, el objetivo de esta etapa es dejar una misma
definición de los requerimientos entre las partes interesadas.
Traducir a lenguaje técnico los requerimientos: posterior a la reducción de la ambigüedad
entre los requerimientos, se debe realizar la descripción y detalle de los requerimientos a
un nivel técnico que se acerque más al proceso de la ingeniería de software.
Plantear un modelo lógico: en esta etapa el objetivo es construir un modelo del problema
en términos de diagramas de flujo u otro tipo de representación que se considere
conveniente para el modelado del sistema que se desarrollará.
Documentar la etapa: Elaborar los documentos de especificación que se consideren
necesarios como soporte para las etapas desarrolladas. Estos documentos deben describir
como mínimo los requisitos, las características incluidas las restricciones y el flujo de
funcionamiento del sistema.
Especificación de requerimientos
Con base en la información elaborada en la etapa de análisis de requerimientos que involucra
funciones, datos, requerimientos no funcionales, objetivos, restricciones de diseño e
implementación o costos, esta etapa es un proceso de descripción y detalle del requerimiento. Si
se presentan dificultades para especificar un requerimiento, lo ideal es regresar a la etapa anterior
y revisar el análisis realizado.
Esta etapa está dividida en las siguientes etapas:
Determinar el tipo de requerimiento: De acuerdo a los diferentes tipos de requerimientos,
el objetivo de esta etapa es determinar a cuál de ellos pertenece cada requerimiento o
requisito especificado.
Elegir la herramienta de especificación acorde al tipo de requerimiento: Una vez definido
el tipo de requerimiento, seleccionar la herramienta de representación acorde a dicho tipo
y al tipo de especificación que se desea realizar.
Especificar de acuerdo a la herramienta seleccionada: Representar el requerimiento sobre
la base de la elección realizada en la etapa anterior.
34
Documentar la etapa: como se realizó en la etapa anterior, se deben documentar las sub
etapas que componen la especificación de requerimientos.
Validación y Certificación de los Requerimientos
Esta etapa final se basa en la integración y validación final de lo obtenido en cada una de las
etapas anteriores dando, como resultado final, el Documento de Especificación de
Requerimientos. Este documento está uno destinado al cliente/usuario a los efectos de la
certificación de los Requisitos y el otro técnico, orientado a nutrir las etapas que siguen para el
proceso de Ingeniería de Software referente al desarrollo e implementación del software.
Esta etapa tiene las siguientes sub etapas:
Seleccionar las fuentes de información a partir de las cuales validar el documento de
especificación.
Elegir o diseñar el modelo de documento acorde al grado de detalle requerido y al lector
final.
Elegir la herramienta de documentación que mejor se aplica al modelo seleccionado.
Documentar respetando los estándares vigentes a la fecha de realización del documento
de requerimientos.
Verificar que el documento de requerimientos del usuario esté contenido dentro del
documento técnico de software.
Certificar el documento de requerimientos a través de la conformidad del usuario.
Con estas sub etapas, se finaliza la revisión general sobre las tres metodologías utilizadas para el
desarrollo de esta investigación, es decir IREB, IEEE 830 y DoRCU. Teniendo en cuenta la
información recopilada de las metodologías anteriores, a continuación se realiza en el siguiente
capítulo un análisis comparativo entre las mismas con el fin de identificar falencias.
35
3.5 ANÁLISIS COMPARATIVO DE LAS METODOLOGÍAS ACTUALES EN LA
ETAPA DE ESPECIFICACIÓN DE REQUERIMIENTOS
A continuación se realiza una comparación entre las diferentes metodologías que son objeto de
análisis en la presente investigación:
Metodología
Elementos IREB IEEE 830 DoRCU
Definición
de Partes
interesadas
La metodología
menciona que las
partes interesadas
son una fuente de
requisitos, sin
embargo no
relaciona como debe
conformarse este
grupo de personas.
Esta metodología
incluye dentro del
capítulo Descripción
global, las
características que debe
tener el usuario, sin
embargo no describe
como debe conformarse
los usuarios.
Esta metodología incluye
una etapa de elicitación de
requerimientos, donde se
forma un equipo
multidisciplinario, sin
embargo se refiere al
equipo que desarrollara el
proyecto del lado del
proveedor y no de la
conformación del equipo
de trabajo.
Para concluir el análisis del elemento “definición de partes interesadas”, las metodologías no
especifican cómo debe conformarse el equipo de partes interesadas desde la perspectiva de
usuario/cliente.
Actividades de
Recolección
La metodología IREB
menciona las técnicas de
elicitación de
requerimientos para
realizar el levantamiento
de información, sin
embargo no clarifica
cuando es recomendable
utilizar cada una de estas
técnicas.
Esta metodología está
enfocada en la
documentación de la
especificación de
requerimientos, sin
embargo no menciona
técnicas ni
herramientas que
permitan realizar el
levantamiento de
información.
La metodología
DoRCU menciona
dentro de la etapa de
licitación de
requerimientos, la
recolección y
clasificación de los
mismos, sin embargo
no describe las
actividades que se
deben realizar para
dicha recolección y
clasificación.
Para concluir el análisis del elemento “Actividades de Recolección”, las metodologías aunque
mencionan dentro de sus etapas la recolección de información, no estructuran ni detallan los pasos
que se deben realizar para recolectar la información, teniendo en cuenta las técnicas de
levantamiento de requerimientos.
Actividades de
análisis
La metodología describe
técnicas de levantamiento
de requerimientos, sin
embargo no describe
técnicas o herramientas
útiles para el análisis de
La metodología IEEE
830 se centra en la
estructura que debe
llevar el documento
de especificación, sin
embargo no describe
Esta metodología
incluye dentro de la
etapa de elicitación
de requerimientos, las
actividades de
recolección,
36
información recopilada. una actividad de
análisis de la
información
recolectada.
clasificación y
evaluación de la
información
recopilada para la
formulación de los
requerimientos. Sería
pertinente describir
con más detalle estas
actividades.
Para concluir el análisis del elemento “Actividades de Análisis”, las metodologías no describen
con precisión, que actividades se deben llevar a cabo para analizar y estructurar la información
recolectada acerca de los requerimientos del usuario. La metodología más cercana es la de
DoRCU, sin embargo se considera relevante describir con detalle las actividades para el análisis.
Especificación de
Requerimientos
La metodología incorpora
una actividad de
documentación de los
requerimientos.
Esta metodología
IEEE 830 se centra en
la documentación de
la especificación de
requerimientos, por lo
tanto no se hace
necesario ampliar esta
metodología para esta
etapa.
La metodología
describe algunas
actividades a tener en
cuenta para la
documentación de la
especificación.
Para concluir el análisis del elemento “Especificación de Requerimientos”, las metodologías
describen las actividades suficientes para documentar y especificar los requerimientos recolectados
con el usuario. Para esta investigación, se toman los elementos de estas tres metodologías para
integrarlos en una sola actividad y así, complementarlas entre sí para describir un proceso de
especificación de requerimientos integral.
CAPÍTULO IV DESARROLLO DE LA INVESTIGACIÓN
4.1 FORMATOS DE APOYO AL PROCESO DE LEVANTAMIENTO DE
INFORMACIÓN
Las metodologías que son base de esta investigación no describen formatos ni plantillas que
ayuden a los ingenieros a recolectar la información requerida para el proyecto, por esta razón, en
este capítulo se plantean una serie de formatos que permitan recolectar información acerca de las
necesidades de los usuarios/clientes, con el fin de ser utilizadas en el capítulo de procedimientos
genéricos y específicos para el análisis y especificación de los requerimientos.
Las empresas tomadas como referencia para esta investigación, utilizan formatos diseñados por
ellas mismas, tomando como base la experiencia y algunos criterios expuestos por el
usuario/cliente, sin embargo no toman como guía las metodologías expuestas en esta
investigación. Teniendo en cuenta las metodologías expuestas, a continuación se presentan
algunos formatos útiles que apoyan el proceso de recolección de información:
APERTURA Y SOCIALIZACIÓN PARTES INTERESADAS:
La organización debe contar con un formato que permita recopilar la información de los roles y su relación con el proyecto a
desarrollar, de las partes interesadas del proyecto, ya sea del lado del cliente, del usuario o del proveedor, con el fin de identificar los
intereses de cada una de estas partes. Al tener identificado cada uno de los actores en el sistema, se garantiza que el software será
evaluado y aprobado por todos los actores requeridos.
38
DEFINICIÓN DE TÉCNICAS DE ELICITACIÓN:
La organización debe contar con un formato que permita asociar a cada necesidad planteada por el usuario y/o cliente, la técnica de
elicitación más pertinente para recopilar la información relacionada a dicha necesidad. Este formato no recopila la información de cada
necesidad, sino la técnica de elicitación que se utilizará para obtener toda la información correspondiente a cada solicitud del usuario.
39
MATRIZ DE RESPONSABILIDADES RASCI:
Luego de que se ha llevado a cabo la actividad de elicitación y definición de requerimientos, la organización debe contar con un
formato que permita asociar a cada requerimiento definido por el usuario y/o cliente, la responsabilidad adquirida para el desarrollo y
aprobación del requerimiento definido.
4.2 METODOLOGÍA PARA EL PROCESO DE LEVANTAMIENTO DE
REQUERIMIENTOS.
Luego de identificar algunos formatos que deberían ser incluidos durante el proceso de
recolección e identificación de necesidades, y finalmente la definición de requerimientos, se
procede a establecer los procedimientos que se deben tener en cuenta durante el proceso de
levantamiento de requerimientos. Según la investigación realizada a las empresas que son
referencia para la investigación de este trabajo de grado acerca del proceso de levantamiento de
requerimientos, se realiza el agrupamiento de actividades en 4 etapas para el proceso de
levantamiento y especificación de requerimientos:
1. Definición de partes interesadas
2. Proceso de Recolección de información
3. Proceso de Análisis de información
4. Proceso de especificación de requerimientos
A continuación se detallan cada una de estas etapas.
1. DEFINICIÓN DE PARTES INTERESADAS
En el capítulo 3.5, se concluyó del elemento “Definición de partes interesadas”, las metodologías
no especifican cómo debe conformarse el equipo de partes interesadas desde la perspectiva de
usuario/cliente y proveedor. Antes de iniciar las actividades de cualquier proyecto y luego de
recibir una solicitud de desarrollar un proyecto de software, adicional teniendo como guía las
metodologías mencionadas en esta investigación, se mencionan las siguientes actividades a
incluir dentro de la etapa de definición de partes interesadas:
1.1 Selección del Ingeniero de requerimientos. Esta actividad refiere a que la
organización que desarrollará el proyecto deberá realizar un proceso de selección en la
organización para determinar quien administrará el proceso de levantamiento de
información del proyecto, esta persona debe tener las siguientes cualidades: Pensamiento
analítico, Empatía, Habilidades de comunicación, Habilidades de resolución de conflictos,
Habilidades de moderación, Confianza en sí mismo y Persuasión. La organización
elaborará un proceso para seleccionar la persona que cumpla con el perfil y las
habilidades requeridas.
1.2 Realizar una reunión de socialización de las partes interesadas. La finalidad de
esta reunión es conocer cada una de las partes interesadas y su relación con el proyecto
que se requiere. En esta actividad se utilizara el formato de Definición de partes
interesadas descrito en el capítulo 4.1 Formatos de apoyo al proceso de levantamiento de
información – Apertura y socialización de partes interesadas. Esta actividad, permite
identificar si es necesario que otro integrante del cliente o del proveedor para desarrollar
el proyecto.
1.3 Definir un esquema u organigrama de roles que intervienen en el proyecto. Este
esquema hace alusión a un organigrama desde el más alto nivel hasta el más bajo, de los
41
roles que harán parte del proyecto tanto del lado del cliente (incluyendo el usuario final)
como del lado del proveedor que desarrollará el proyecto. Esto con el fin de identificar
por niveles, quienes y que roles se tendrán en cuenta para el proceso.
1.4 Generar un Acta de la reunión de socialización de las partes interesadas. Esta acta
deberá contener la información que trató la reunión realizada. En esta acta debe estar la
información como fecha, hora, lugar, asistentes, temas tratados y en general todo lo que
haya surgido durante la reunión. Esta acta deberá ser enviada a todas las partes para su
conocimiento y aprobación.
1.5 Anexar documentación elaborada al acta. Luego de ejecutar las actividades
anteriores, se debe anexar al acta, el formato diligenciado de Apertura y socialización de
partes interesadas y el organigrama del cliente y del proveedor. Esto hace parte de la
documentación del proyecto y sirve como referencia para involucrar a las partes en las
etapas posteriores.
Cabe aclarar, que las demás actividades que realice la organización que contribuya a establecer y
definir los actores y partes interesadas del proyecto, pueden ser integradas y/o apoyadas con las
actividades descritas en esta etapa.
2. PROCESO DE RECOLECCIÓN DE INFORMACIÓN
En el capítulo 3.5, se concluyó del elemento “Actividades de Recolección de información”, que
las metodologías aunque mencionan dentro de sus etapas la recolección de información, no
estructuran ni detallan los pasos que se deben realizar para recolectar la información, teniendo en
cuenta las técnicas de levantamiento de requerimientos. Teniendo como guía las metodologías
mencionadas en esta investigación, se mencionan las siguientes actividades a incluir dentro de la
etapa de Recolección de información que debe ejecutar el ingeniero de requerimientos:
2.1 Realizar una reunión de recolección de necesidades. Esta actividad la realiza el
ingeniero de requerimientos seleccionado y se realiza con el fin de convocar a las partes
interesadas para intercambiar las necesidades que se tienen respecto al proyecto
específicamente al software que se requiere desarrollar. Estas necesidades se describen de
manera general, esto con el fin de que el ingeniero pueda asociar a la necesidad, cuál será
la técnica más apropiada para recopilar la información suficiente sobre la necesidad
capturada. Para esta actividad, se utilizará el formato Definición de Técnicas de
Elicitación ilustrado en el capítulo 4.1.
2.2 Determinar las técnicas de elicitación de las necesidades. Una vez que se obtengan
las necesidades de los usuarios y del proyecto en general, se realiza la actividad de
selección de la técnica de elicitación más apropiada para recopilar la información
completa y al detalle de la necesidad. Las técnicas de elicitación que describe el formato
las selecciona el ingeniero de requerimientos, entre las cuales están:
Entrevista: Durante una entrevista, el ingeniero de requisitos hace preguntas
predeterminadas a uno o más interesados y documenta las respuestas.
42
Cuestionario: Hacer uso de preguntas abiertas y / o cerradas (por ejemplo, preguntas
de opción múltiple) es otra forma de obtener los requisitos de las partes interesadas. Si
hay un gran número de participantes que deben ser encuestados, un cuestionario en
línea es una opción viable. Los cuestionarios pueden generar una gran cantidad de
información en un corto período de tiempo y a bajo costo.
Lluvia de ideas: las ideas se recopilan dentro de un marco de tiempo determinado,
generalmente en grupos de 5 a 10 personas. Las ideas son documentadas por un
moderador sin discutirlas, juzgarlas o comentarlas al principio. Esta técnica es
especialmente efectiva cuando un gran número de personas de diferentes grupos de
interés están involucradas. Entre las ventajas de esta técnica es que se puede recopilar
una gran cantidad de ideas en un corto período de tiempo y múltiples personas pueden
ampliar estas ideas en colaboración.
Técnica analógica: los problemas que enfrenta el proyecto se asignan a una situación
análoga que ocurre en la naturaleza, y se buscan las soluciones que proporciona la
naturaleza y luego se correlaciona con el proyecto.
Arqueología de sistemas: La arqueología del sistema es una técnica que extrae la
información necesaria para construir un nuevo sistema a partir de la documentación o
implementación (código) de un sistema heredado.
Reutilización: Los requisitos que se han compilado previamente y se han elevado a un
cierto estándar de calidad pueden reutilizarse. Para hacer eso, los requisitos se
almacenan en una base de datos, por ejemplo, y se mantienen disponibles en el nivel
de detalle requerido para su reutilización. Mediante la reutilización, los costos
involucrados con los procedimientos de obtención pueden reducirse
significativamente.
2.3 Recolectar la información con las técnicas seleccionadas. Esta actividad hace
relación a la ejecución de las tareas de recolección para cada necesidad, teniendo en
cuenta la técnica de elicitación asociada a cada una de estas necesidades teniendo como
base el formato diligenciado Definición de Técnicas de Elicitación ilustrado en el capítulo
4.1.
2.4 Definición de Requerimientos. Esta actividad comprende la descripción y definición
de las necesidades ya expresadas como requerimientos. El objetivo de esta actividad es la
consolidación de la información recolectada de cada necesidad y describirlo como un
requerimiento formal. Estas descripciones formales son plasmadas en el formato matriz de
responsabilidades RASCI ilustrado en el capítulo 4.1.
Cabe aclarar, que las demás actividades que realice la organización que contribuya al proceso de
recolección de información del proyecto, pueden ser integradas y/o apoyadas con las actividades
descritas en esta etapa.
43
3. PROCESO DE ANÁLISIS
En el capítulo 3.5, se concluyó del elemento “Actividades de Análisis de información”, que las
metodologías no describen con precisión, que actividades se deben llevar a cabo para analizar y
estructurar la información recolectada acerca de los requerimientos del usuario. La metodología
más cercana es la de DoRCU, sin embargo se considera relevante describir con detalle las
actividades para el análisis. Teniendo como guía las metodologías mencionadas en esta
investigación, se mencionan las siguientes actividades a incluir dentro de la etapa de análisis de
información:
3.1 Reducir ambigüedades en los requerimientos. Esta actividad se realiza con el fin de
eliminar los términos que tienen más de una interpretación, unificando el léxico empleado
entre ingenieros y usuarios, el objetivo de esta etapa es dejar una misma definición de los
requerimientos entre las partes interesadas.
3.2 Traducir a lenguaje técnico los requerimientos. Se debe realizar la descripción y
detalle de los requerimientos a un nivel técnico que se acerque más al proceso de la
ingeniería de software.
3.3 Plantear un modelo lógico. El objetivo de esta actividad es construir un modelo del
problema en términos de diagramas de flujo u otro tipo de representación que se considere
conveniente para el modelado de cada requerimiento que se desarrollará.
4. ACTIVIDADES DE ESPECIFICACIÓN DE REQUERIMIENTOS
En el capítulo 3.5, se concluyó del elemento “Especificación de Requerimientos”, que las
metodologías describen las actividades suficientes para documentar y especificar los
requerimientos recolectados con el usuario. Para esta investigación, se toman los elementos de
estas tres metodologías para integrarlos en una sola actividad y así, complementarlas entre sí para
describir un proceso de especificación de requerimientos completo. Teniendo como guía las
metodologías mencionadas en esta investigación, se mencionan las siguientes actividades a
incluir dentro de la etapa de especificación de requerimientos:
4.1 Socializar la matriz de responsabilidades RASCI. Esta actividad comprende la
socialización con las partes interesadas de los requerimientos que fueron definidos, el formato
matriz de responsabilidades RASCI ilustrado en el capítulo 4.1, sirve como apoyo para
desarrollar la actividad.
4.2 Elegir la herramienta de especificación acorde al tipo de requerimiento. Una vez
definido el tipo de requerimiento, seleccionar la herramienta de representación acorde a dicho
tipo y al tipo de especificación que se desea realizar.
4.3 Especificar de acuerdo a la herramienta seleccionada. Representar el requerimiento
sobre la base de la elección realizada en la actividad anterior.
44
4.2 Describir un documento de requerimiento. Esta actividad consta de especificar a través
de un documento formal, las generalidades a tener en cuenta para el desarrollo del proyecto.
Estas generalidades pueden ser según las recomendaciones que hace la metodología de la
IEEE 830:
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones, siglas, y abreviaciones
1.4 Referencias
1.5 Apreciación global
2. Descripción global
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones
2.5 Atención y dependencias
2.6. Repartir proporcionalmente los requisitos
3. Los requisitos específicos (aquí se anexa la representación de los requerimientos)
Con las actividades descritas para las 4 etapas mencionadas anteriormente, se logra que el
proceso de levantamiento y especificación de requerimientos sea preciso y cuente con la
información necesaria para iniciar el proceso de desarrollo y validación con el cliente y/o usuario.
45
PARTE IV
CAPITULO V CONCLUSIONES
Luego de realizar esta investigación, en el cual se tomaron 3 estándares internacionales enfocadas
al proceso de especificación de requerimientos, con el fin de estudiarlos, analizarlos e
interpretarlos, y de los cuales se tomaron como referencia para estructurar la metodología
planteada en el capítulo IV, se concluye lo siguiente:
Los procesos de especificación de requerimientos involucran actividades que son omitidas
por las empresas que fueron tomadas como referentes para esta investigación, por
desconocimiento o falta de aplicación de metodologías que ayuden a realizar el proceso
correctamente.
Las empresas no estructuran su proceso de levantamiento y especificación de información
con guías y metodologías que existen para tal proceso, entre las cuales se tienen el
estándar IREB y la norma IEEE 830, por consiguiente es empírico este proceso en las
organizaciones.
Las empresas no invierten tiempo y recursos económicos en herramientas tecnológicas
que apoyen el proceso de especificación de requerimientos, ya que no consideran
relevante esta etapa durante la ejecución de los proyectos de desarrollo de software,
siendo esta la etapa inicial que recopila la información requerida para el desarrollo de los
proyectos.
Como falencia encontrada en las normas utilizadas para desarrollar esta investigación, no
involucran dentro de su metodología, la asignación de responsabilidades durante la etapa
de especificación de requerimientos, se considera importante que los roles que intervienen
tengan claridad de las actividades que deben realizar, esto contribuye a que se cumplan
las expectativas de los requerimientos.
Las metodologías aunque mencionan y detallan las actividades que se deben tener en
cuenta para hacer la especificación de requerimientos, no lo hace de forma ordenada y
secuencial, siendo este un inconveniente por el cual la etapa puede llegar a tener vacíos y
no desarrollarse adecuadamente.
46
CAPITULO VI RECOMENDACIONES
Luego de desarrollar esta investigación acerca de las metodologías y estándares para el proceso
de especificación de requerimientos, las recomendaciones que se hacen para las empresas, no
solo las referenciadas en este trabajo sino las demás empresas dedicadas al desarrollo de software
es:
Primero, involucrar una metodología de Especificación de requerimientos, puede ser las
mencionadas en la presente investigación, u otra que sea de conocimiento e interés para la
organización.
Segundo, tomar de la metodología seleccionada, los elementos que son claves para el
proceso de especificación de requerimientos, desde la etapa inicial de definición de partes
interesadas, hasta la documentación que se requiere para dicho proceso.
Tercero, podría tomarse la presente investigación como una guía para estructurar el
procedimiento para la etapa de requerimientos, esta investigación enumera unas etapas y
las actividades de cada etapa, lo que podría ser de utilidad para las empresas que deseen
definir su procedimiento para el levantamiento y especificación de requerimientos.
Cuarto, con base en las recomendaciones anteriores, las empresas deberían establecer un
procedimiento formal interno para llevar a cabo la etapa de especificación de
requerimientos para los proyectos de software.
47
BIBLIOGRAFÍA
Camacho Zambrano, A. N. (Junio de 2005). Herramientas para el analisis de requerimientos
dentro de la pequeña empresa desarrolladora de Software en Bogotá. Obtenido de
http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis189.pdf
ComputerWorld. (s.f.). Obtenido de ComputerWorld: http://www.computerworld.es/archive/la-
importancia-de-la-calidad-de-los-procesos-de-software
Genoveva, A. (2003). La realidad de la PYME Colombiana: Desafío para Colombia. Bogotá:
Fundes.
IEEE. (22 de Octubre de 2008). Especificación de Requisitos.
Martinez Guerrrero, J. M., & Silva Delgado, C. A. (28 de Noviembre de 2010). Universidad
Javeriana. Obtenido de
http://pegasus.javeriana.edu.co/~CIS1010IS06/descargas/Anexos/Marco%20Teorico/An
exo%202.%20Ingenier%C3%ADa%20de%20Requerimientos.pdf
Pantaleo, G. (2010). Calidad en el desarrollo de Software. Buenos Aires: Alfaomega.
pmoinformatica. (Agosto de 2016). Obtenido de
http://www.pmoinformatica.com/2016/08/tecnicas-levantamiento-requerimientos.html
Software Engineering Institute. (s.f.). Obtenido de Software Engineering Institute:
http://www.sei.cmu.edu/cmm
SOMMERVILLE, I. (2005). Ingenieria de Software. Madrid: Pearson Addison Wesley.
