SEP SEIT DGIT
CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOL~GICO
cenidet
PROPUESTA METODOL~GICA PARA LA CAPTURA DE REQUISITOS
T E S I S Que para obtener el Grado de
Maestro en Ciencias de la Computación
presenta MARTÍN GERARDO MARTÍNEZ RANGEL
Director de tesis: DR. JAVIER ORTÍZ HERNÁNDEZ
Cuernavaca, Morelos Noviembre de 2001
Centro Nacional de Investigación y Desarrollo Tecnológico
FORMA C3 REVISION DE TESIS
Cuernavaca, Morelos a 6 de noviembre de 2001
Dr. Raúl Pinto Elías Presidente de la Academia de Ciencias Computacionales Presente
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: PROPUESTA METODOLOGICA PARA LA CAPTURA DE REQUISITOS, realizada por el C. Mart in Gerard0 Martínez Rangel, y habiendo cumplido con todas las correcciones que le fueron indicadas, acoidamus no tener objeción para que se le conceda la autorización de impresión de la tesis.
Sin otro particular, quedamos de usted.
Atentamente
c.c.p. Dr. Ro'dolfo A. Pazoc Rangel/Jefe del Departamento de Ciencias Computacionales
hlERlOR h l E R h A D O P A L M RA S/N C O f R h A V A C A M O R M É X CO A P A R l A D O P O S l A L 5-164 C P o2050 C C L R h A V A C A TELS. (73112 2314.12 7613.18 7741. FAX (731 12 2434 cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
FORMA C4 AUTORIZACION DE IMPRESIÓN DE TESIS
Cuernavaca, Morelos a 9 de Noviembre de 2001
C. Martin Gerard0 Martinez Rangel Candidato al grado de Maestro en Ciencias de la Computación Presente
De’spués de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: PROPUESTA METODOLOGICA PARA LA CAPTURA DE REQUISITOS, ‘me es grato comunicarle, que conforme a los iineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.
Atentamente
- Dr. Roddo A. Pazos Rangel
Jefe del Depto. de Ciencias Computacionales
INTERIOR INTERNADO PALMIRA S I N , CUERNAVACA. MOR MEXICO APARTADO POSTAL 5-164 CP 62050, CUERNAVACA. TELS. [73)12 2314.12 7613 ,I8 7741, FAX (73) 12 2434 cenidet
AGRADECIMIENTOS
Primeramente al creador por darme la oportunidad de reencontrarlo en momentos felices de mi vida.
,
A mi madre, por el ejemplo de coraje y determinación por salir adelante mediante
el trabajo en los momentos mas críticos de nuestras vidas, y sobre todo por
respetar siempre nuestras decisiones.
A Tere, mi esposa, por apoyarme siempre y por estar conmigo en todo momento,
y sobre todo por recordarme siempre a Io largo de nuestro matrimonio el
compromiso que tenía con el CENIDET y conmigo mismo de graduarme pronto.
A mis dos preciosas y pequeñitas hijas: Diana Sofía y Alexa Mariana. A ti Diana Sofía por ser el primer motorcito que impulso mi vida profesional y por manifestar
a tu corta edad ese gusto por el estudio y la ciencia. Y a ti Alexa Mariana por venir a confirmar mi sentido de ser en esta vida.
A la Secretaría de Educación Pública y al Centro Nacional de Investigación y
Desarrollo Tecnológico por la beca SEP recibida a traves de la Dirección General de
Institutos Tecnológicos para terminar mis estudios de maestría.
A Javier Ortiz Hernandez. Director de este trabajo de tesis, quien siempre me
motivó y apoyo en todo para seguir adelante con este trabajo de tesis y por la amistad con la que me distingue.
A mis revisores de tesis, Máximo López Sánchez y René Santaolaya Salgado, quienes se dieron a la tarea de leer todas las versiones de este trabajo de tesis y cuyas valiosas observaciones permitieron el. desarrollo y escritura del mismo. No puedo dejar de mencionar en especial a Olivia Fragoso por el apoyo que me brindó para terminar este trabajo de tesis. A los tres gracias por brindarme su amistad.
AI Instituto Tecnológico de Zacatepec, el cual me formó primeramente como Técnico y posteriormente como Ingeniero durante ocho años. Tiempo que
recuerdo con mucha gratitud.
A todos mis compañeros y compañeras, y amigos y amigas que me distinguen con
su amistad y a quienes no menciono para no omitir a ninguno (del CENIDET, del
iTZ, de la UAEM, del IIE, de Telmex, de la Unisol, etc), a todos ustedes gracias.
A los que se encuentran lejos (Manuel Adams, Carlos Astorga y Hugo Estrada y
esposa) también gracias por su amistad y consejos.
A Gerard0 Reyes y esposa por animarme a seguir adelante, a mis suegros por el
apoyo recibido, a mis hermanos y cuñados, a mis compadres Fortunato Solares y esposa por la amistad de siempre, a mis queridos alumnos por darme la
oportunidad de confirmar día a día mis conocimientos ante ustedes.
Este trabajos de tesis fue apoyado por los siguientes proyectos:
1. Proyecto: "Ingeniería de Requerimientos de software: IRIS", proyecto CONACrr clave 28953a
2. Proyecto: "Ingeniería de Requerimientos de software: IRIS", proyecto
COSNET clave 761.99-P.
3. Proyecto apoyado por C O N A M con la clave 32042-A
4. Proyecto apoyado por Cosnet con la clave 759.99P
CONTENIDO
Capítulo 1 Introducción 1.1 Antecedentes .................................................................................................... 1.2 Description del problema ................................................................................... 1.3 Propuesta de solucion ....................................................................................... 1.4 Objetivos ........................................................................................................... 1.6 Beneficios ......................................................................................................... 1.7 Alcances y limitaciones :
2.1 Introduccion .................................................................................................... 2.2 Trabajos relacionados ................................... : ...................................................
2.2.2 Herramienta para la captura de requisitos de los usuarios .............................. 2.2.3 Un método de trabajo para auxiliar la definición de requisitos ........................
2.3 Conclusiones ....................................................................................................
.. ..
. . 1.5 Metodología de solucion .................................................................................... . . . ............................ .........................................................
Capítulo 2 Estado del arte ..
2.2.1 Teoría de la actividad:"ün marco de trabajo para la captura de requisitos .......
Capítulo 3 Marco teórico Capítulo 4 Propuesta metodológica
4.1 Modelo de proceso para la captura de requisitos ........... ; ..................................... 4.2 Componentes de la metodología propuesta ........................................................
4.2.1 Búsqueda de hechos ............................................................................... 4.2.2 Obtencion de requisitos ............................... ; ........................................... 4.2.3 Evaluación y'razonamiento de requisitos ................................................... 4.2.4 Asignacion de prioridades .................... ................................................... 4.2.5 Integracion y validacion ........................................................................... 4.2.6 Representación del conocimiento adquirido .................................................
.. .. . . ..
Capítulo 5 Aplicación de la metodología en un escenario real 5.1 Antecedentes .................................................................................................. 5.2 Búsqueda de hechos ....................................................................................... .. 5.2.1 Analisis operacional .................................................................................
5.2.2 Analisis del problema ............................................................................... 5.2.3 Analisis organizacional ...................................................................... ; ...... 5.2.4 Identificación de la partes afectadas ......................................................... 5.2.5 Resultados obtenidos de la búsqueda de hechos ........................................
. .
. .
. . 5.3 Obtencion de Requisitos .................................................................................. 5.4 Evaluación y Razonamiento de requisitos ......................................................... 5.5 Asignacion de prioridades ................................................................................ 5.6 Integracion y validacion .................................................................................. 5.7 Representación del conocimiento ..................................................................... 6.1 Evaluacion de la metodología ............................................................................. 6.2. Resultados obtenidos ...................................................................................... 7.1 Conclusiones .................................................................................................. ,7.2 Trabajos futuros ..............................................................................................
Referencias Bibliográficas ...............................................................................................
.. . . ..
Capítulo 6 Pruebas y resultados
Capítulo 7 Conclusiones y trabajos futuros
..
Pág . 1 2 3 4 4 5 6 6 7 8 9 9 11 12 13 15 26 27 32 33 35 37 38 39 40 43 44 44 44 46 50 53 53 55 58 65 66 67 70 71 75 77 78 79 80
Lista de figuras
2-1 Proceso de venta ....................................................................................... I 11 I . 3-1 Ingeniería de requisitos como un proceso iterativo ................................... 24
4-1 Modelo de la propuesta rnetodológici para la captura de requisitos ........ 29 4-2 Descripcion de un escenario ............... ! ...................................................... 42
5-2 5 1
. .,
5-1 Análisis organizacional a nivel Gobiemo Federal-IES ............................. 50 Análisis organizacional a nivel IES .... 1 ......................................................
I
Lista de tablas I I I . .
4-1 5-1 Escenario para la actividad de pago de solicitud ....................................... 6-1 requisitos ............................................................ I ....................................................
Tareas que comprende el modelo de proceso para la captura de requisitos
Evaluación de las técnicas de acuerdo
31 69
74 su utilidad en el proceso de captura de
. .
I
Cenidet Cap. 1. Introducción
cdbz'tulo 1 Introducción
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.1
Cenidet Cap. 1. Introducción
1.1 Antecedentes
Para el éxito en el desarrollo de sistemas de información es esencial tener
una comprensión completa de los deseos y necesidades de los usuarios que deben
satisfacerse. La definición de requisitos es una evaluación cuidadosa de las
necesidades que un sistema debe cubrir, se trata generalmente de un documento
que debe decir porqué un sistema es necesario dadas las condiciones actuales y
anticipadas [Greenspan94]. El reconocimiento de la naturaleza crítica de los
requisitos estableció la ingeniería de requisitos como un sub-campo de la Ingeniería de Software.
La ingenien2 de requ/sitosestá determinada principalmente por: la dificultad
para caracterizar la organización y su medio ambiente inmediato, la dificultad para
modelar las restricciones de la organización que inhiben o controlan su función; la
diversidad de recursos tecnológicos y humanos disponibles para un determinado
contexto; y la flexibilidad, robustez, mantenibilidad y calidad requeridas. El campo
de la ingeniería de requisitos emerge como una sub-área de la ingeniería de
software, ayudando a que la fase de requisitos en el desarrollo de sistemas de
software sea más sistemática y disciplinada [Yu95al.
La ingenien2 de requ/sitos de sohare tiene por objetivo analizar y
documentar los requerimientos de software. Esto involucra crear particiones de los requerimientos del sistema en subsistemas y tareas para permitir mapearlos al
software. En este proceso también se realiza la transformación de requerimientos del sistema en descripciones de requerimientos de software. A traves del análisis, diseño y prototificación se van a conocer qué datos deben ser automatizados o no [Thayeer97], en este sentido el proceso de captura de requisitos dentro de la ingeniería de requisitos presenta una opción que permite satisfacer las demandas de información que se tienen de un sistema en construcción.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.2
Cap. 1. Introducción Cenidet
La ingeniería de requisitos comprende actividades de captura de requisitos,
análisis, especificación y validación. Hoy en día, la mayoría de los métodos, técnicas y herramientas para trabajar con requisitos están enfocadas
especialmente a la parte de especificación, por ejemplo la representación de requisitos, dando por sentado que la captura de requisitos se da de manera natural
y que éstos se encuentran a la mano listos para utilizarse.
La fase de captura de requisitos debe interesarse en las relaciones entre los sistemas y sus ambientes en lugar de colocar los requisitos solamente en términos
de los sistemas de software [Yu95a]. Lo que implica transformar una necesidad
operacional producto del proceso de captura de requisitos en una descripción del sistema (análisis) y en esta descripción se deben de incluir datos acerca del desempeño de este sistema. Esto es logrado en fases posteriores a la captura de
requisitos mediante el uso de un proceso iterativo de análisis, diseño y prototificación [Thayeer97].
El proceso de captura de requisitos se ha convertido así en eje central para
las otras áreas que intervienen en la construcción de un sistema de información, y es el núcleo de los intereses básicos de representación y razonamiento acerca del conocimiento acumulado durante la fase de captura de requisitos [Greenspan94].
1.2 Descripción del Problema.
Existe un termino en inglés, “requirements elicitation”, que hasta ahora se a visto traducido generalmente como recolección de requisitos, captura de requisitos u obtención de requisitos. Últimamente se empieza a utilizar en el medio científico y profesional Iberoamericano la expresión “elicitación de requisitos” [Goguen97, Galvao99, Laguna99, Duran981. Que hace referencia a un proceso de entrevistas,
reuniones o charlas, en las que un experto de una empresa informática intenta ayudar al cliente a aclarar sus ideas y obtener un catálogo de funciones que deben de ejecutar los programas que la empresa informática le va a desarrollar.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.3
Cap. 1. Introducción Cenidet
Los desarrolladores que apoyan el término "elicitación" indican que el significado del verbo "elicit" en inglés es demasiado rico en matices como para limitarlo a "recolectar", "capturar" u "obtener". Sin embargo hasta ahora no se conoce otro significado dentro de la literatura de la ingeniería de requisitos, por Io que a partir de este momento el término "requirement elicitation" se utilizara como
"captura de requisitos", el cual, como ya se mencionó anteriormente hace
referencia al 'broceso de entrevistas, reuniones o charlas en las que un experto de
una empresa informática intenta ayudar al cliente a aclarar sus ideas y obtener un catálogo de funciones que deben de ejecutar los programas que la empresa informática le va a desarrollar". Lo anterior permite describir claramente el
problema que se trata en esta tesis, en cuanto a que los requisitos que se consiguen muchas veces son incompletos, mal entendido y ambiguos.
1.3 Propuesta de solución
Como solución al problema de la captura de requisitos se propone una metodología que haga uso de las herramientas existentes para llevar a cabo
entrevistas, reuniones o charlas, con el objeto de buscar información y recopilar
hechos, así como representar el conocimiento adquirido. Esta metodología está
basada en un modelo de proceso de captura de requisitos de software que se presenta como parte de la misma solución en este trabajo de tesis. Las
herramientas que se integraran en la metodología serán aquellas donde exista referencia de su utilidad y eficacia, incorporando las ventajas que cada una de
ellas tienen y que son Útiles para la recuperación de información, las cuales puedan ser derivadas de acuerdo a los atributos que debe contener el sistema a
desarrollarse.
1.4. Objetivos
A continuación se mencionan los objetivos que se pretenden lograr con este trabajo de tesis:
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.4
*',b
Cap. 1. Introducción Cenidet
1) Proponer una mefodo/ogia para /a aptura de requisitos en la que se pueda apoyar el responsable de la captura de requisitos para esclarecer los deseos y necesidades que tienen los usuarios respecto a un sistema de información durante el proceso de captura de requisitos.
2) Sentar las bases para que se puedan realizar a futuro otros trabajos de investigación que permitan sistematizar la captura de los requisitos dentro
de la ingeniería de requisitos.
1;s Método de solución
La metodologia de solución que se propone a utilizar para el logro de este
trabajo de tesis esta compuesta por varias estrategias las cuales se describen a continuación.
ESTRATEGIAS
1) Describir el estado del arte en el área de la ingeniería de requisitos, en
particular describir los trabajos principales relacionados con el proceso de captura de requisitos.
2) Desarrollar un modelo de proceso para la captura de requisitos como parte
de la metodología que se propone, ubicando las herramientas que son Útiles en la búsqueda de hechos, recuperación de información y representación del conocimiento adquirido a lo largo del proceso según sea el caso.
3) Describir los criterios que se puedan utilizar para evaluar la metodología
para la captura de requisitos propuesta en este trabajo de tesis. 4) Presentar un caso de estudio donde se aplique la metodología para la
captura de requisitos.
5) Documentar los resultados obtenidos del caso de estudio.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.5.
cap. 1. Introducción Cenidet
1.6 Beneficios
El desarrollo de un modelo de proceso y una metodología para la captura de
requisitos, permitirá a los responsables de la especificación de requisitos de
software, clarificar los deseos y necesidades de los clientes respecto al sistema de información a construir, contribuyendo con esto a que los requisitos encontrados
sean completos y mejor entendidos por todos los actores que participan en la construcción de un sistema de información.
Adicionalmente este proyecto permitirá continuar con una línea de
investigación en modelado de procesos de negocio, dentro del campo de la ingeniería de requisitos. Donde una problemática particular es la búsqueda de
información y de hechos como parte de la tarea de captura de requisitos.
1.7 Alcance y Limitaciones
La propuesto metodológica que se propone está enfocada exclusivamente al
área de problemas que concierne a la búsqueda de hechos, obtención de información, su integración y representación del conocimiento adquirido, en un
orden tal que permitan encontrar soluciones a los problemas encontrados en el
proceso de captura de requisitos como una extensión del trabajo que se presenta en [Mittermeir90 y Christel921.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.6
, . . , ~; .. . . , . ,.,.,, . ,_..~i. ~ .
Cap. 2. Estado del Arte Cenidet
Cupz'tulo 2 Estudo del Arte
En este capitulo, se presenta el contexto en el que se encuentra la tarea de
captura de requisitos para el desarrollo de sistemas de información dentro de la
ingeniería de requisitos.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.7
. . . . . , . - . . . .
Cap. 2. Estado del Arte Cenidet
2.1 Introducción
Una pregunta fundamental dentro de la ingeniería de requisitos es, cómo
encontrar lo que el usuario realmente necesita. Existen investigaciones donde se
concluye que muchos proyectos fracasan debido a los problemas encontrados
durante el proceso de captura de requisitos de software [GAO 1992, Duran98, Galvao991.
U
Los problemas para la definición precisa de la funcionalidad que un sistema
de información debe tener, se acentúan por el complejo esquema de comunicación
en el que interactúan el usuario y el analista de sistemas o el ingeniero de requisitos durante el proceso de captura de requisitos.
El usuario brinda una concepción de la funcionalidad, aunque podría no estar completamente seguro de ello. El analista por su parte deberá especificar correctamente la funcionalidad a partir de esta primera concepción mediante
aproximaciones sucesivas. Este ambiente de interacción usuario-analista motiva la
búsqueda de estrategias robustas para garantizar que los requisitos del usuario
serán descubiertos con precisión y que además serán expresados en una forma
correcta y sin ambigüedad, además de que sean verificables, trazables y
modificables.
Actualmente existe un creciente reconocimiento de que la tarea de captura de requisitos no es un reto matemático o tecnológico (como Io fue en sus
orígenes), si no que forma parte de un proceso social complejo[Goguen97]. Además de que por lo regular no se trata sino de una aproximación a traves del papel central del analista, quien realiza la recolección de requisitos. Lo anterior ha
provocado que distintos grupos de investigación en el área de la ingeniería de requisitos propongan algunas soluciones o marcos de trabajo que permitan capturar los requisitos. La mayoría de los esfuerzos de investigación señalan el aspecto social, factor central donde se generan las actividades de un proceso y
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.8
Cap. 2. Estado del Arte Cenidet
donde ha de funcionar un sistema de información tal como Io describen Galvao
Martins y Mascia Deltrini [Galvao99] de la Universidad Metodista de Piracicaba, Brasil. Otro trabajo importante dentro de la Ingeniería de requisitos, en donde se concluye que la captura de requisitos esta cada vez más centrada en la parte social que en la parte tecnológica, es el que se describe en [De BortoliZOOO] y que
permite apoyar la definición de requisitos en el proceso de captura de requisitos.
Por otro lado en [Laguna99], se propone un marco para la normalización de la captura de requisitos y su inmediata expresión en forma de activos que sirvan como base para el análisis de los mismos, con el objeto de proveer algún grado de formalización durante este proceso.
2.2. Trabajos relacionados
Dentro de la literatura de la ingeniería de software; mas específicamente dentro de la ingeniería de requisitos se encontraron trabajos relacionados con este tema de tesis. Se describirán aquellos que por su relevancia en cuanto a la captura de requisitos aportan conocimiento al problema a resolver.
2.2.1. Teoría de la actividad: "Un Marco de Trabajo para la Captura de
requisitos"
Entre los trabajos relacionados con este tema de tesis y que sirven como antecedente para el estudio del estado del arte del proceso de captura de requisitos se encuentra Activity Theory: a Framework to Software
Requirements Elicitation, de Galvao Martins y Mascia Deltrini [Galvao 19991 de la Universidad Metodista de Piracicaba, Brazil. Estos autores señalan que la teoría de la actividad fue desarrollada en la sicología y enfocada hacia las practicas
humanas dentro de procesos tanto a nivel individual como a nivel social. Esta teoría se basa en que cualquier acción humana debe ser entendida dentro de un mínimo contexto social establecido por una actividad. De esta forma en [Galvao99] se propone un enfoque para la captura de requisitos dentro de un marco de
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.9
Cenidet Cap. 2. Estado del Arte
trabajo en donde existen preceptos de la teoría de la actividad, y que constituyen
un conjunto de principios constituidos en un sistema conceptual general.
Los principios básicos de la teoría de la actividad son los siguientes:
1) Principio de actividades entre concesiones.
2) Principio de orientación a objetos.
3) Principio de estructura jerárquica de las actividades
4) Principios de internalización y externalización.
5) Principios de mediación.
6) Principios de desarrollo.
Estos principios no son ideas aisladas, ya que cada uno de ellos está
perfectamente conectado. La naturaleza de la teoría de la actividad esta
manifestada en ese conjunto de principios. De acuerdo a la teoría de la actividad,
una actividad es una forma en la cual un sujeto actúa sobre un objeto, y así mismo
una actividad es descompuesta en acciones, en donde cada acción es
descompuesta a su vez en operaciones. Queda de manifiesto que una actividad es
orientada por una motivación, mientras que una acción es orientada hacia el logro de una o mas metas, así como las operaciones son orientadas por las condiciones.
Esto se puede visualizar en el siguiente ejemplo: en donde se descompone una actividad denominada proceso de venta, tal y como se describe en la fig. 2-1.
Esta forma de representar el conocimiento permite lograr que el analista
responsable de capturar los requisitos de software tenga una idea clara de lo que el sistema ha de realizar. Este enfoque es Útil en tanto no se tenga toda la
información que brota de las fuentes de información dentro de los procesos mismos del negocio. Información que a su vez pueda ser agrupada y
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Mattínez Rangel Pag.10
Cenidet Cap. 2. Estado del Arte
caracterizada, para posteriormente aplicar el método que en este trabajo se
propone, lo cual es por demás interesante.
I Actividad
Proceso de venta
Acciones
Emitir la cuenta de la venta
imitir el pago de la venta
Fig. 2-1.Proceso de venta
Operaciones I ~
Llenar los campos del
pago de la venta.
Calcular la tasa de
Imprimir la cuenta de
la venta. I
Dividir la venta en
varios pagos de
acuerdo a las fechas de
vencimiento.
Imprimir los recibos de
pago.
2.2.2. Herramienta para la captura de requisitos de los usuarios
Otro trabajo relacionado con este tema de tesis se describe en [Laguna99], donde se propone un marco de trabajo para la normalización de la captura de requisitos y su inmediata expresión en forma de activos que sirvan como base para
el análisis de los mismos. Esta funcionalidad es expresada inicialmente en términos de casos de uso del negocio y de casos de uso, que luego son traducidos al formato de alguna plantilla en particular. Por ejemplo la plantilla Volere que se describe en [Volere2000], o la que propone Duran Toro en [DurangS].
- - Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.11
Cenidet Cap. 2. Estado del Arte
La herramienta Propuesta [Laguna991 "A User Requirements Elicitation Tool'' está basada en el uso de flujos de trabajo y redes de Petri para la captura Y normalización de los requisitos funcionales. ' Esta herramienta soporta la
construcción de un sistema de información. Un flujo de trabajo es un modelo de la
logística de los procesos del negocio. Un proceso de flujo de trabajo es realmente
un diagrama que especifica el flujo de tareas que se deben ejecutar en un orden
determinado y bajo condiciones determinadas. Las redes de Petri se han utilizado para expresar la semántica de los flujos de trabajo, donde cada uno de ellos al ser
expresado con una red de Petri se ha denominado un Workflow Net [Van97]. Una
red de Petri permite manipular eventos que son activados bajo condiciones
explícitas. Estas redes han sido ampliamente utilizadas en el modelado de sistemas
cuyo comportamiento es guiado por un patrón de reglas complejas. El marcado de
la red de Petri podría representar la interacción que muestra la secuencia de
estados y no la evolución específica de los casos de uso en conjunto.
2.2.3. Un método de trabajo para auxiliar la definición de requisitos
La captura de requisitos está cada vez mas centrada en la parte social que
en la parte tecnológica, un trabajo importante que viene a sustentar Io antes dicho
es el método de trabajo presentado en [De BortoliZOOO]. El método está
compuesto de tres etapas principales: elicitacion, modelado y validación. La
elicitación o captura de requisitos no es mas que la adquisición de conocimiento
sobre el sistema de información sujeto a estudio. Dicho conocimiento adquirido es
traducido y representado de manera gráfica en la etapa del modelado para que posteriormente sea validado en la Última etapa.
Durante el proceso de captura se utilizan diversas técnicas tales como entrevistas, observaciones y un abordamiento basado en etnográfia, análisis de
protocolos, etc. El método propuesto por De Bortoli y Alencar Price de la Universidad Federal de Rio Grande, Brasil, tiene por objetivo realizar una tarea anterior a la definición de requisitos de software que es precisamente la tarea de
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.12
Cenidet Cap. 2. Estado del Arte
captura de requisitos. En esta tarea se busca la adquisición de conocimiento de las
situaciones y 10s hechos que componen a los sistemas de información dentro de
una organización.
según quienes Proponen el método [De Bortoli2000], el principio básico que deben tener 10s desarrolladores,de software es un conocimiento total sobre el ambiente en el cual ha de funcionar el sistema, y que les permita proponer una
solución automatizada o computarizada. De acuerdo al método propuesto, la
primera actividad dentro del proceso de captura de requisitos consiste en
identificar las fuentes de información utilizando entrevistas estructuradas y
obteniendo como resultado de esta etapa un texto. En la segunda actividad dentro
de la tarea de captura de requisitos se tiene que colectar la información mediante
las observaciones, lectura de documentos, abordamiento etnográfico y entrevistas.
El resultado de estas dos actividades es la representación textual del conocimiento
adquirido, elemento principal y de mucha utilidad para la tarea de modelado que
se realizará utilizando diagrarnas de flujo de trabajo, y cuyo resultado será la
representación gráfica del conocimiento adquirido durante la etapa de captura de
requisitos. Por Último, se presenta la tarea de validación en tres fases: validación individual que consiste en una comprobación informal, la validación general
mediante la técnica de reunión estructurada, y validación del léxico ampliado del
lenguaje utilizado mediante una comprobación informal.
2.2.4. Conclusiones
AI parecer las relaciones sistémicas vistas desde el punto de vista de las actividades, contribuyen a una captura de requisitos más cuidadosa, una vez que la persona responsable de la captura de requisitos o ingeniero de requisitos tenga en cuenta los elementos que son necesarios para la comprensión de un problema. Tales elementos son: el problema mismo a resolver, herramientas de la mediación o herramientas que permitan llegar a acuerdos, objetos y relaciones, comunidades de participantes, reglas del trabajo y división del trabajo. Los trabajos presentados
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martínez Rangel Pag.13
Cenidet Cap. 2. Estado del Arte
con antelación permiten identificar a cada uno de esos elementos, Cada uno de ellos aborda la problemática del proceso de captura de requisitos tratando de
aportan conocimientos que permitan de algún modo resolver los problema encontrados en la definición de requisitos. Se percibe que la mayoría de las
propuestas están mas orientadas a la representación y especificación de requisitos que a la captura de los mismos, dando por sentado que estos se encuentran a la mano y listos para utilizarse. Es precisamente en este Último aspecto donde este
trabajo de tesis encuentra su fortaleza, ya que la captura de requisitos es vista
como un proceso evidentemente social donde se recupera información mediante
herramientas ya probadas que permiten trabajar en grupos. Mediante el marco de trabajo o metodología que se propone "Metodología para la Captura de
Requisitos", se puede caracterizar la información colectada a partir de los procesos donde han de funcionar los sistemas de información, poniéndola a disposición del ingeniero de requisitos, responsable de la especificación del sistema a desarrollar.
Esta información se puede registrar en alguna de las plantillas propuestas como lo es la plantilla de Volere [VolereZOOO] o la que Propone Amador Duran Toro de la Universidad de Sevilla[Duran98]. La finalidad de la plantilla es dar formato a la información colectada. Se trata de un trabajo posterior a la captura de requisitos, garantizando que los requisitos del usuario serán descubiertos con precisión y que
además sean expresados en una forma correcta y sin ambigüedad.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.14
Cap. 3. Marco Teórico Cenidet
En este capítulo, se presenta el contexto que involucra la resolución del problema planteado en esta tesis.
Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.15
La ingeniería de software es una ramificación de la ingeniería de sistemas
que refiere al desarrollo de los sistemas intensivos de software, lógicos, grandes y
complejos. La ingeniería de software se enfoca hacia las metas del mundo real y a los servicios que proporcionan los sistemas que se desarrollan, así como a la especificación exacta de la estructura y del comportamiento del propio sistema. La puesta en practica de estas especificaciones, también se refiere a los procesos, a
los métodos y a las herramientas para el desarrollo de los sistemas intensivos del
software de una manera lógica, económica y oportuna.
El proceso de desarrollo de software consiste en una serie de pasos bien definidos, que seguidos adecuadamente, conducen a un software mantenible y bien diseñado. Aún así, muchas organizaciones olvidan las fases de captura de requisitos, análisis y diseño a favor de comenzar inmediatamente la implementación de código. Es ma5 positivo pensar en el desarrollo de software, no
como un proceso lineal, sino como un ciclo iterativo. Aunque el paso de una fase a otra se realiza en un sentido, también pueden existir vueltas atrás en determinados momentos, especialmente cuando aparecen requisitos de usuario ocultos en las primeras fases.
La Ingeniería de Requisitos es una area dentro de la Ingeniería de Software, la
cual procura sistematizar el proceso de la definición de requisitos. Este proceso es considerado actualmente como una tarea crítica dentro del ciclo de desarrollo de
software. La sistematización de este proceso es necesaria porque la complejidad de los sistemas actuales exigen que se preste mayor atención al correcto entendimiento del problema antes de comprometer una solución. Para que la definición de requisitos sea lo mas eficaz posible, es necesario que los Ingenieros de Software entiendan el
ambiente en el cual el software funcionará y escoger el modelo o modelos que mejor representen tal ambiente. La etapa de captura de requisitos es considerada como la actividad más importante, decisiva y al mismo tiempo crítica para el desarrollo de software.
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.16
Cenidet Cap. 3. Marco Teórico
Los problemas de captura de requisitos pueden ser agrupados en tres grandes categorías según [McDermid89].
PROBLEMAS DE ALCANCE. En el cual, los requisitos pueden ser encontrados con muy poca o mucha información, y tienen que ver con:
> Los límites del sistema mal entendidos.
9 información de diseño innecesaria proporcionada.
Las técnicas de captura de requisitos, necesariamente deben ser
suficientemente amplias para establecer los límites para el sistema en desarrollo, más aún, deben enfocarse sobre las actividades para la creación de requisitos,
más que a las actividades de diseño, evitando puntos contextuales que puedan conducir a requisitos que sean incompletos, no verificables, innecesarios e inútiles.
El enfoque muy amplio sobre las actividades de diseño impropiamente enfatizadas por los desarrolladores, por encima de las necesidades de los usuarios puede resultar en requisitos muy pobres.
La captura de requisitos debe comenzar con un análisis organizacional y de contexto para determinar los Iímites,del sistema a construir, así como también para determinar los objetivos del sistema dentro del medio ambiente en el cual ha de
desenvolverse. Las metodologías para la captura de requisitos deben aplicarse de
manera correcta sobre a lo que a estas conciernen en cuanto a la búsqueda,
recolección y representación del conocimiento adquirido para que los requisitos capturados se ajusten a las metas de los usuarios y así mismo estas metas se vean reflejadas en el sistema a desarrollar.
PROBLEMAS DE ENTENDIMIENTO o COMPRENSION. Esto se da dentro del contexto de entendimiento entre los participantes, que se ve caracterizado por los distintos lenguajes utilizados durante el proceso de captura de requisitos, los problemas que tienen que ver con esto son:
~~
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.17
Cap. 3. Marco Teórico Cenidet
9 Los usuarios tienen un incompleto entendimiento o comprensión de sus necesidades.
9 Los usuarios tienen una pobre comprensión de las capacidades y limitaciones acerca de las computadoras.
k Los analistas’tienen un pobre entendimiento del dominio del problema.
9 Los usuarios y los analistas hablan diferentes lenguajes.
9 Es fácil de omitir información.
9 Conflictos de puntos de vista entre los diferentes participantes (usuarios).
k Los requisitos son frecuentemente vagos, casi imposibles de comprobar.
Existen tres aspectos importantes que se tienen que considerar en cuanto a los problemas de entendimiento y comprensión, que son:
Las comunidades involucradas en la captura de requisitos poseen una
variedad de antecedentes y niveles de experiencia, de tal forma que
el conocimiento que tenga un grupo puede ser extraño para otro grupo. Esto representa una dificultad para el analista de requisitos en el momento de interpretar e integrar la información obtenida de
estos diversos grupos.
El lenguaje usado para expresar los requisitos de estas comunidades
de usuarios, puede ser demasiado formal o informal para encontrar las necesidades de cada uno de estos grupos; una vez mas debido a la diversidad de estas comunidades.
Se obtiene una gran cantidad de información durante la captura de
requisitos, lo cual parece normal, pero se requiere que ésta sea estructurada de alguna forma, la comprensión de esta estructura
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.18
Cenidet Cap. 3. Marco Teórico
depende de las características de la organización y de las comunidades participantes dentro del proceso de captura de
requisitos.
Los problemas de comprensión necesariamente resultan de la involucración
de todos los grupos de gentes que participan en la captura de requisitos; ya que estos son producidos e interpretados por la gente con diferentes niveles de experiencias y educación o formación , la forma en que los requisitos son
expresados y el tamaño de los sistemas descritos por los requisitos también afectan la comprensión. Si los participantes en la captura de requisitos no comprenden adecuadamente la salida de los procesos, los requisitos que resulten pueden ser , ambiguos, inconsistentes e incompletos, lo que se traduce en
requisitos incorrectos, no enfocados de una manera adecuada hacia las necesidades de las comunidades de donde se capturaron los requisitos.
PROBLEMAS DE VOLATILIDAD. Se refiere a los cambios naturales en los
requisitos, el principal problema refiere que:
> Los requisitos evolucionan de manera natural a través del tiempo.
El cambio de requisitos durante el tiempo que toma el desarrollar un sistema de información se da de manera natural debido a que las necesidades
de los usuarios pueden madurar a causa de que el conocimiento obtenido sobre el sistema a desarrollar va en aumento, pero también es común que los
requisitos puedan cambiar a un nuevo conjunto de necesidades debido a imprevistos organizacionales o por presiones del medio ambiente. Si tales cambios no son direccionados de manera correcta, el conjunto de requisitos
puede llegar a ser incompleto e inconsistente con la nueva situación, y potencialmente inservibles porque la información capturada ha llegado a ser obsoleta. Una de las causas que generan el problema de la volatilidad de los requisitos es que las necesidades de los usuarios evolucionan con el tiempo [Sage90], Otra causa es que los requisitos son producto de la contribución de
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.19
Cenidet Cap. 3. Marco Teórico
muchos individuos, y estos individuos frecuentemente tienen conflictos entre sus necesidades y metas. Por ejemplo, es usual que haya más de un usuario tenga duda acerca de Io que se quiere, ya que frecuentemente los usuarios
tienen diferentes puntos de vista e intereses contradictorios. [Dubois 881.
La complejidad de la organización, es otra causa de la volatilidad de 10s requisitos, las metas de la organización, políticas, estructuras y roles de trabajo de los usuarios finales pueden cambiar durante el curso del desarrollo de un sistema, especialmente si el número de usuarios afectados por el desarrollo de los sistemas incrementa.
Los procesos de la ingeniería de requisitos para la captura, especificación y validación no deben ejecutarse solamente una vez durante el desarrollo de un
sistema, sino que deberán ejecutarse de una manera iterativa para que los requisitos reflejen el nuevo conocimiento ganado durante la especificación,
validación y subsecuentes actividades-Un proceso interactivo durante la captura de los requisitos puede direccionar de manera adecuada los problemas de volatilidad que se presentan [Dubson 921. Una metodología de requisitos debe ser iterativa
para que las soluciones que se planteen puedan ser retrabajadas a la luz del conocimiento aumentado [Macavlay 90.1
La captura de requisitos debe comenzar con un análisis organizacional y de contexto (modelado del negocio) para determinar los límites del sistema a construir, así como también para determinar los objetivos del sistema dentro del medio ambiente en el cual ha de desenvolverse. Un análisis organizacional y
contextual permite que estas metas sean capturadas y sirvan para verificar que los requisitos sean desde luego, Útiles y correctos,
Existen al menos tres grandes contextos que afectan a los requisitos y a los procesos de la ingeniería de requisitos para un sistema propuesto:
Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martínez Rangel Pag.20
Cenidet Cap. 3. Marco Teórico
Contexto Organizacional, se caracteriza porque:
o El interés primario de los clientes no es un sistema basado en computadoras sino, más bien en algunos efectos positivos totales,
que resulten de la introducción de computadoras en su medio ambiente (Dubois 88).
O La captura de requisitos comienza sin una apreciación del contexto
organizacional, lo que provoca que un gran número de restricciones sean asumidas debido a prejuicios , políticas de administración, ignorancia técnica, prácticas añejas ya establecidas, resistencia del personal, etc. (Mittermeir 90).
Contexto del medio ambiente. Los factores del medio ambiente se ven
reflejados cuando:
o Restricciones de Hardware y Software son impuestas sobre el sistema
final.
o El sistema final que se ha de desarrollar, típicamente podrá ser un
componente mas de algún sistema grande y con una organización ya
existente o requerida en el lugar donde ha de funcionar el sistema,
o La madurez del dominio del sistema a desarrollar está en su mejor
nivel.
a Existe una certeza de las interfaces que el sistema a desarrollar deberá tener con el objeto de poder interactuar con él o los sistemas existentes o sistemas más grandes.
Contexto del proyecto. El contexto del proyecto también afecta a los
requisitos y a los procesos de ingeniería de requisitos, los factores que influyen dentro del contexto del proyecto son:
Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.21
Cenidet Cap. 3. Marco Teórico
O Los atributos de las diferentes comunidades de gentes involucradas
en el desarrollo de un nuevo sistema, tales como usuarios finales,
patrocinadores, desarrolladores y analistas de requisitos.
O Las restricciones impuestas por la gente involucrada en el proceso de captura, por ejemplo: restricciones administrativas relacionadas con
el costo del tiempo y calidad deseada en el sistema en desarrollo.
La comprensión de la organización, el medio ambiente y el contexto del
proyecto proveen un buen punto de comienzo en la captura de requisitos, y quien o quienes realicen la captura de requisitos no se deben comprometer en otra dirección que no sea la captura, por ejemplo en actividades de diseño. Cuando se tiene una primer versión de la especificación de requisitos, no se deben lanzar las campanas al vuelo, ya que ésta debe ser permanentemente refinada, hasta que la
especificación tenga lugar a partir de los requisitos capturados, aunque en
realidad, las actividades de diseño de alto nivel y las actividades de especificación de requisitos son terminadas de manera simultánea, ya que no se pueden separar los cómo de los qués [Lavi 881.
Se puede considerar como una meta muy loable, el querer separar las actividades de la captura de requisitos de aquellas que tienen que ver con las de
análisis y diseño, pero eso representa una gran dificultad para llevarlo a la práctica, y no es fácil que se pueda lograr esta separación, pero desde luego que
se puede y es muy saludable hacerlo, mas si se hace al comienzo de todo el proceso de construcción del sistema, ya que permite que los requisitos capturados cubran las necesidades de todas las comunidades de usuarios, independientemente del "status" con que éste cuente dentro de la organización.
Durante la captura de requisitos se debe tener especial cuidado, ya que puede ser que los requisitos iniciales puedan ser pobremente especificados, innecesarios e incompletos, o que por Io contrario, que estos sean sobre
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.22
Cenidet Cap. 3. Marco Teórico
especificados, muy completos pero sobrecargados con inútiles restricciones de
diseño.
El análisis de requisitos es un proceso social y las técnicas y métodos que no reconocen este factor, irremediablemente, la gran mayoría fracasan, y tienen
menor oportunidad para obtener toda la información necesaria[Leite97].
Los procesos de la ingeniería de requisitos para la captura, especificación y
validación no deben ejecutarse solamente una vez durante el desarrollo de un sistema, sino que deberán ejecutarse de una manera iterativa para que los requisitos reflejen el nuevo conocimiento ganado durante la especificación,
validación y subsecuentes actividades
La noción tradicional del ciclo de vida del desarrollo de software refiere a que la captura de requisitos debe completarse antes de la etapa de diseño. Ahora la captura de requisitos y la etapa de diseño es vista de manera simbiótica (no se
puede separar). El conjunto inicial de necesidades comienza fuera del proceso de diseño que es gradualmente refinado de una manera sistemática y coherente con los requisitos establecidos.
Debido al problema de comprensión y alcance discutido anteriormente, las necesidades de los usuarios pueden no ser expresados de manera clara en los requisitos, ya que los desarrolladores y el analista de requisitos pueden adoptar
algunas posiciones basadas sobre esas ambigüedades.
Dentro de un proceso interactivo, esas posiciones equivocadas pueden ser detectadas y corregidas rápidamente, por ejemplo, un proceso iteractivo permite que los usuarios reciban retroalimentación mucho más pronto acerca de las interpretaciones por parte del grupo responsable de la captura de los requisitos, Io que permite que los problemas se corrijan tan pronto son encontrados. Muchos acercamientos tradicionales de desarrollo no permiten que ciertas comunidades de participantes, tales como los usuarios reciban retroalimentación de otras
Propuesta Metodología para la Captura de Requisitos Ing. Marth G. Martinez Rangel Pag.23
interpretaciones de otros grupos de participantes, hasta que el sistema esté completo y liberado. Un proceso iterativo de ingeniería de requisitos es ilustrado en la Fig. 3-1.
/ Metas
(entendimiento del contexto) (entendimiento interno)
\ Especificación
Fig. 3-1. Ingeniería de requisitos como un proceso iterativo.
Se ha observado en la norma del IEEE del glosario de la terminología de la ingeniería de software, un incremento de la naturaleza iterativa del desarrollo de requisitos. En el glosario de 1983 “El análisis de requisitos es definido como el
proceso de estudiar las necesidades de los usuarios para llegar a una definición de requisitos del sistema [IEEE83].
Pero esto ha evolucionado en el tiempo, ya que en el glosario de 1990 se ha dado una segunda definición y ha sido añadida al análisis de requisitos: “Es el
proceso de estudiar y refinar sistemas, hardware o requisitos de software”
Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.24
Cap. 3. Marco Teórico Cenidet
[IEEEgO]. Esto implica un examen en retrospectiva de los requisitos en pasos de
refinamiento, por ejemplo: un proceso interactivo de ingeniería de requisitos.
Los requisitos no son totalmente conocidos al comienzo del desarrollo de un
sistema, ya que mediante el conocimiento adquirido a Io largo del proceso de captura de requisitos deben evolucionar más allá de la fase de análisis y diseño de
un proyecto. Las comunidades involucradas en la captura de requisitos, incluyendo
usuarios, desarrolladores y clientes, todos ellos pueden aprender y crecer durante
el desarrollo del sistema y durante su mantenimiento. Este incremento de conocimiento obtenido por las comunidades responsables de la captura de
requisitos con respecto al sistema, puede ser utilizado para mejorar el sistema mas que obligar a que los requisitos permanezcan estáticos.
Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.25
Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos
Capítdo 4 Prqnesta Metodologica para la
En este capítulo, se presenta la propuesta metodológca para la captura de requisitos, tema central de este trabajo de tesis.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Range1 Pag.26
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
4.1 Modelo del proceso para la captura de requisitos.
El contexto de captura de requisitos dentro del proceso de desarrollo de
sistemas trata de encontrar hechos, obtener información y su integración en un
orden tal que se pueda obtener el conjunto de requisitos que describan un número
de soluciones posibles mediante la representación del conocimiento adquirido.
En este capítulo se describe el modelo en el que se basa la metodología
propuesta para la captura de requisitos y que deberá considerar el analista de
requisitos como una herramienta de apoyo. Los requisitos capturados provienen de
varias comunidades de usuarios, siendo el propio analista el responsable de
comunicar estos requisitos a la comunidad de desarrolladores, adicionalmente a
estas tareas, el analista de requisitos debe asegurarse de que las necesidades de otras comunidades afectadas se vean reflejadas en los requisitos obtenidos y que
una comprensión adecuada o apropiada de estos requisitos sea comunicada a todas las partes involucradas.
El modelo de la metodología propuesta, visto como un proceso, reconoce la importancia de la comunicación entre los diferentes grupos de usuarios, de
acuerdo con el paradigma que subyace en el método IBIS' (Issue Based Information Systems) [Bageman 881.
Aunque reconocer la importancia de la comunicación no es suficiente, las experiencias y motivaciones de los participantes se verán reflejadas en el modelo
para la captura de requisitos mediante la ejecución de actividades que permitiran aprovechar esta diversidad. Un conjunto de estas actividades estará orientado a
El método IBIS, está basado en el principio de que el proceso de diseño para problemas complejos está fundamentado en la conversación entre los participantes (por ejemplo, diseñadores, clientes, e implantadores del sistema) sobre sus respectivas experiencias y puntos de vista para resolver aspectos de diseño que son importantes para que el sistema en desarrollo tenga el éxito deseado.
I
Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martínez Rangel Pag.27
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
los usuarios, mientras que el otro conjunto de actividades estará orientado a los desarrolladores en estrecha comunicación.
Todas las actividades a ejecutarse pueden agruparse en tareas asociadas
para encontrar hechos, obtener requisitos, hacer evaluaciones, razonar sobre los requisitos encontrados, asignar prioridades sobre los requisitos encontrados, lograr
una integración de todo el trabajo desarrollado y su respectiva validación y por Último representar el conocimiento adquirido.
El modelo que sigue la metodología propuesta (fig. 4-1) es muy similar al modelo
de captura de requisitos propuesto por Mittermeir [Mittermeir90] y al propuesto
por Michael G. Christel y Kyo C. Kang [Christel92] pero con dos grandes variantes:
Primero, la asignación de prioridades ocurre después del razonamiento de los requisitos respecto al propuesto por Mittermeir, al igual que en el de Michael G.
Christel y Kyo C. Kang, y segundo, en el modelo que se propone se integr la fase
de representación del conocimiento adquirido y que no se encuentra ni en el
modelo propuesto por Mittermeir ni en el propuesto por Christel y Kyo C. Kang.
Estas variantes obedecen a dos razonamientos lógicos: primero, porque no es
posible asignar prioridades a los requisitos encontrados si antes éstos no son
razonados y evaluados; y segundo, en los modelos propuestos en [Mittermeir90,
Christel921 no se presenta una fase que permita representar el conocimiento
adquirido a Io largo del proceso de captura de requisitos.
Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martinez Rangel Pag.28
Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos
- requisitos
A
Búsqueda de hechos
Asignación de prioridades
~
I
-
Integración y validación
~~ -
A v
1 del Representación -
conocimiento adquirido
Fig. 4-1. Modelo de la metodología propuesta para la captura de requisitos
Este proceso es primeramente ejecutado durante la fase de exploración dentro del
contexto del problema, con la finalidad de encontrar hechos. Se continúa
posteriormente con las actividades de obtención y clasificación de los requisitos encontrados, el razonamiento y evaluación de los mismos, la asignación de prioridades, la integración y validación de los requisitos, y por Último, se termina con la fase de representación y captura del conocimiento adquirido en el dominio del problema. Hasta aquí termina la fase de captura de requisitos y el primer nivel en la especificación de requisitos es logrado. Durante las subsiguientes fases que componen el desarrollo de un sistema de información, las especificaciones son
Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martínez Rangel Pag.29
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
validadas y los requisitos inciertos aclarados, identificando requisitos no conocidos y refinando los existentes como sea necesario.
Siempre en base a mecanismos de comunicación (tormenta de ideas, JAD, etc.) empleados durante la captura de requisitos, las tareas a realizar dentro de este
proceso son citadas de manera iterativa, comenzando de nuevo con la reunión de requisitos para detallar y mejorar el documento de requisitos. Recordando que típicamente todos los requisitos en un sistema no son conocidos inmediatamente,
Io cual implica que la fase de integración y validación inicie con requisitos
incompletos, y por Io tanto, puede ser necesario regresar algunos pasos para la captura de requisitos a través de la fase de búsqueda de hechos en un proceso
eminentemente iterativo, tal como se propone en el modelo para la captura de
requisitos.
Las tareas que comprenden el modelo del proceso son listadas en la tabla 4-1. Allí sobresale la búsqueda de hechos, la cual comienza con un análisis operacional
donde se detalla el proceso operativo que dio origen a la necesidad de construir un
sistema de información. Se identifican los objetivos que se persiguen dentro del
proceso que se describe. Se continua dentro de la misma fase con el análisis del
problema que consiste en identificar los factores que deben considerarse para cumplir con los objetivos de la organización, identificando las comunidades
participantes que influyen de manera directa en los resultados. Con los resultados
obtenidos en las dos actividades anteriores, ya se está en condiciones de desarrollar un análisis del contexto organizacional identificando los ambientes principales que permitan visualizar de manera descriptiva el contexto general donde se gesta el problema a resolver, mediante la construcción de un sistema de información.
La fase de búsqueda de hechos termina con la identificación de todas las partes afectadas por el sistema en construcción, incluyendo a las personas estratégicas dentro de la organización que pueden tomar decisiones, y a los usuarios finales.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Mattínez Rangel Pag.30
Cap. 4. Propuesta metodológica para la captura de requisitos
Las tareas para encontrar hechos son importantes [Berlín 891 “Estudiar las necesidades de los usuarios es el primer paso para llegar ‘a una solución, conjuntamente, con el entendimiento de la tecnología disponible y de las
herramientas existentes. Sin un entendimiento ‘de la tecnología es casi imposible
llegar a una solución, y sin un entendimiento de las necesidades uno puede
resolver el problema de manera equivocada”.
A continuación se presentan las actividades agrupadas en tareas.
Cenidet . .
. .
hechos
requisitos
razonamiento
prioridades
validación
Representaciór
conocimiento 1 adquirido Tabla 4.1. T,
J Realizar un análisis operacional J Realizar un análisis del problema J Realizar un análisis del contexto organizacional J Identificación de todas las partes afectadas por el sistema en
construcción, incluyendo a las personas estratégicas dentro de la organización que pueden, tomar decisiones, y a . los usuarios finales.
J Identificar los requisitos orientados a las necesidades de los usuarios.
J Agrupar los requisitos expresados de acuerdo .al acto o actores que los expresan.
J Evaluar la consistencia de cada uno de los requisitos expresados respecto a lo expresado en la búsqueda de hechos.
J Evaluar si los requisitos expresados no se contraponen. J Realizar un razonamiento del porque algunas cosas son
‘expresadas como requisitos. J Determinar la importancia relativa de cada uno de los requisitos
expresados. J Determinación de la importancia relativa entre los requisitos de un
actor respecto a los requisitos expresados por los otros actores con el objeto de asignar prioridades.
J Integrar todos los elementos que se utilizaron durante la búsqueda de hechos y que dieron.origen a los requisitos.
J Validar que todos los requisitos establecidos correspondan a las metas originalmente estructuradas durante la búsqueda de hechos.
J Creación de escenarios que permitan representar y capturar el conocimiento adquirido de los episodios mas relevantes que se dan a lo largo del proceso de captura de requisitos.
as que comprende el modelo de proceso para la captura de requisitos.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.31
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
La comunicación entre las actividades que se desarrollan dentro del proceso para la captura de los requisitos es cíclica, y mejora mediante el conocimiento adquirido a traves del tiempo. El mejoramiento de la comunicación es deseable. La representación de los requisitos apoya al entendimiento y permite que los cambios inevitables y su representación sean introducidos tempranamente para permitir el
mantenimiento y los cambios deseables.
4.2 Componentes de la metodología propuesta
Los componentes para la captura de requisitos que aquí se propone son los siguientes:
Búsqueda de hechos. Normalmente el sistema a ser desarrollado es parte de un
sistema ya existente y mas grande, donde mucha gente puede ser afectada por el
desarrollo. El enfoque socio-técnico para encontrar hechos expuestos, es similar a la metodología ORDIT' donde el sistema es visto como "un todo donde es posible
poner el ambiente operacional con el usuario como una parte integral del sistema",
de acuerdo a Io expuesto en [Dobson92]. Un análisis organizacional directo
permite poner de manifiesto cómo es el conocimiento acerca del sistema destino
en construcción, y cómo puede ser afectado por este conocimiento. Las
consideraciones arquitecturales, así como las restricciones de un proyecto tales como el costo, ayudan a definir el sistema que está siendo construido. Tales
consideraciones dentro de la tarea de búsqueda de hechos se presentan como sigue:
1. Un examen de la organización, en el cual el sistema a desarrollarse deberá funcionar.
* La metodología ORDIT (Definición de Requisitos Organizacionales para Tecnología de Información), reconoce explícitamente que el usuario tiende a trabajar de una manera colaboradora y cooperativa , de manera que se logren todos los objetivos, ya que el lema de la metodología ORDIT es: "producir sistemas de información, los cuales no sólo relacionen las necesidades organizacionales y funcionales de los usuarios finales, sino también de aquellos grupos de usuarios finales y sus requisitos de uso y aceptabilidad asociados. [Dobson 911.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martínez.Rangel Pag.32
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
2. Establecimiento de altos niveles de emisores o papeles que deberá jugar el sistema en desarrollo.
3. Determinación de algunas restricciones sobre la arquitectura.
4. Determinación de la existencia de sistemas similares.
Obtención de requisitos. Captura la información a traves del uso de vistas
multidisciplinarias, tales vistas expresan que es Io que se ha de construir.
Evaluación y razonamiento. Exponen las consistencias en los requisitos
obtenidos. Determinan porqué algunas cosas han sido expresadas como requisitos.
Asignación de prioridades. Determina la importancia relativa de los requisitos, por ejemplo: Pregunta cuándo los requisitos deben ser tratados en relación con
otros.
Integración y validación. Reúne la información colectada desde los primeros
pasos durante la captura y valida que estos requisitos correspondan a las metas
originalmente estructuradas durante la búsqueda de hechos.
Representación del conocimiento adquirido. Mediante la creación de
escenarios se representa y captura el conocimiento adquirido de los episodios mas
relevantes que se dan a lo largo del proceso de captura de requisitos de acuerdo a
la percepción que los clientes y usuarios tienen del dominio del problema.
4.2.1 Búsqueda de hechos.
Refiriéndonos a la tabla 4-l., el primer paso en la captura de requisitos incluye la determinación de que es el problema, de cómo debe este ser tratado y
cómo las comunidades de participantes deben ser involucradas tanto para la toma de decisiones como para la formulación del problema y su posible solución.
La salida para esta actividad incluye:
Propuesta Metodológica para la Captura de Requisitos' Ing. Mattín G. Martinez Rangel Pag.33
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
J Un análisis operacional
J Un análisis del problema
J Un análisis del contexto organizacional
J Identificación de todas las partes afectadas por el sistema en construcción,
incluyendo a las personas estratégicas dentro de la organización que
pueden tomar decisiones, y a los usuarios finales.
Una vez que se ha entendido el dominio del problema, mucha de esta información puede ya existir de alguna forma y estar fácilmente disponible. En
otros casos la definición del contexto del problema puede hacer más difícil la
actividad de captura de requisitos y quizá puede necesitar de pasos múltiples que
conciernen a la actividad de validación antes de que el contexto del problema se
tenga correctamente. El problema del alcance de las actividades involucradas en
estas tareas, son vagas y abiertas a la interpretación por parte del analista de
sistemas.
Es mejor tener todas las partes participantes afectadas en esta area
incluyendo usuarios, desarrolladores y clientes. Esto resulta en una integración
entre camaradas que representan a las diversas comunidades participantes en el análisis de contexto del proceso para la formulación del problema; lo cual puede
impactar positivamente sobre la volatilidad de los requisitos. Si todas las partes están involucradas en el acuerdo del alcance, se tiene una mejor oportunidad de
corregir directamente el problema, y pueden tratarse mejor los cambios en los requisitos, evitando que éstos ocurran durante el proceso de desarrollo.
Un enfoque efectivo para lograr la comunicación entre las diversas disciplinas para la búsqueda de hechos, es el uso de una técnica de proceso de grupo, tales como el JAD (desarrollo de aplicaciones en conjunto) que se describe en [Zahniser90]. Todas las partes afectadas pueden ser representadas en grupos
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.34
Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos
que puedan ejecutar de manera anticipada las tareas de búsqueda de hechos. Ésto promociona titularidad compartida, formulación rápida y pronta del problema,
alínea las perspectivas, y logra un entendimiento entre los participantes en el
proceso de captura de requisitos acerca del problema a ser resuelto y del alcance
de los subsecuentes requisitos que deban ser capturados.
Dentro de una técnica estructurada de reunión como 10 es el ]AD, otras técnicas pueden ser usadas para promover la comunicación entre los individuos,
desde muchas disciplinas potenciales. SSM (Metodología para desarrollo de
sistemas de software) proporciona un modelo de .obtención de información
[Checkland901 que puede ser utilizado para identificar los objetivos esenciales de la situación del problema. El método IBIS [Bageman881 puede ser usado para
registrar los diferentes puntos de vista de los. participantes, las posiciones
asociadas, y los argumentos en los que se apoyan estas discusiones entre los
grupos. Esta información puede ser utilizada para soportar las actividades de
generación de consenso, las cuales son parte del proceso JAD. Tal registro es de un valor incalculable durante la búsqueda de hechos y puede ser interactivo
durante todo el proceso de captura de requisitos. En fases posteriores de la
búsqueda de hechos, puede no ser necesaria la estructuración de grupos mediante técnicas tales como el JAD para redefinir los requisitos, pero es posible que sea
necesario utilizar nuevamente estas técnicas en fases que se dan a través de la captura, principalmente cuando una nueva comunidad de usuarios es reconocida y
puede verse afectada por el desarrollo del sistema propuesto.
4.2.2 Obtención de requisitos.
Dependiendo del curso que tome el sistema que comienza a desarrollarse y de
los grupos que pueden ser afectados, la obtención de los requisitos es una combinación entre ambos enfoques: composicional y descomposicional. En la formulación anticipada de un problema, es importante el obtener tanta información como sea posible tanto de los usuarios como de los desarrolladores y clientes.
~
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Marthez Rangel Pag.35
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
Alguna o mucha información puede provenir del grupo de técnicas empleadas para
el desarrollo de búsqueda de hechos, tales como el JAD. Otro tipo de información
puede ser obtenida a traves del uso de las intervenciones directas de los usuarios
finales y otras partes afectadas. Cuestionarios, observaciones y simulaciones del
medio ambiente son otras técnicas que pueden ser utilizadas para obtener información de diferentes individuos o grupos [Andriole 901. La salida de esta
actividad incluye:
Objetivos orientados a los clientes y usuarios
Requisitos orientados a las necesidades de los clientes y usuarios.
Estas necesidades y requisitos son verificadas contra todos los objetivos del
sistema propuesto durante la búsqueda de hechos.
Cuando existen muchos clientes y usuarios que contribuyen con requisitos
para ser analizados mediante técnicas tales como intervenciones, un gran número
de conjuntos de necesidades y requisitos o puntos de vistas pueden ser
colectados. Es muy difícil para el analista identificar y resolver inconsistencias entre estos diferentes puntos de vista, si éstos no tienen una estructura adicional para la
información. Una forma de proveer esta estructura y de organizar la información
que proviene de muchos individuos, es a traves del uso del método CORE
(expresión de requisitos controlados) descrito en [Stephens85], el cual permite la extracción de requisitos con estas características. Eventualmente, esas múltiples vistas son compuestas en requisitos para el sistema propuesto o en desarrollo.
Estas vistas son mejor entendidas si son estructuradas en piezas
manejables. Esto es especialmente cierto, dado que el proceso de captura es incremental y se enfrenta con cambios inevitables en los requisitos. Si nosotros tenemos vistas monolíticas de un sistema completo, esto puede hacer muy difícil de comprender vistas muy grandes y también dificulta el encontrar las porciones
de que vistas pueden ser afectadas por un cambio incremental en los requisitos. ~~~ ~
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.36
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
Esto debe ser un proceso descomposicional asociado con la obtención de requisitos, donde las vistas puedan descomponerse en componentes significativos.
Idealmente, es aplicable el uso de modelos de dominio y tecnológicos, como
la descomposición. Por ejemplo: el enfoque de modelos de dominio [Davis90]. Este enfoque permite una mejor comunicación de la parte de captura de la información expresada mediante las vistas. CORE enfatiza el uso de diagramas de flujo de
datos para la descomposición de tales vistas, la representación usada para la
descomposición es muy dependiente del dominio de la aplicación, por ejemplo: la
representación del flujo de datos de CORE puede fallar al momento de adecuar la
captura de formalismo, el cual puede ser necesario en requisitos para sistemas
embebidos [Finkelstein 861.
4.2.3 Evaluación y razonamiento
La evaluación de riesgo debe orientarse hacia Io técnico, hacia el costo y lo que concierne a la planeación. En adición, el razonamiento detrás de la
información obtenida en estados previos debe ser examinada para determinar cuando los verdaderos requisitos están ocultos en este razonamiento, y que deben
expresarse explícitamente. El razonamiento y la evaluación de riesgos son las dos
principales salidas de esta actividad. -
IBIS es una buena técnica para capturar el razonamiento en los puntos
donde se ubican los argumentos en el marco de trabajo de las técnicas de desarrollo en grupo (JAD) y las intervenciones. Los modelos estructurados del dominio y la tecnología son extremadamente Útiles. Por ejemplo, con las características del modelo de dominio; es posible seleccionar ciertas alternativas,
describiendo las decisiones que se tomaron y el razonamiento asociado con la
selección de estas alternativas.
Una vez que el razonamiento ha sido capturado y examinado, las inconsistencias pueden ser idealmente encontradas y tomar las mejores decisiones
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.37
Cap. 4. Propuesta metodológica para la captura de requisitos
que permitan resolver estas inconsistencias y que permitan tratar las necesidades reflejadas en el razonamiento.
Cenidet
En deducción, este razonamiento es extremadamente útil durante el proceso de captura de requisitos así como la documentación sobre las decisiones
particulares que se hicieron, en caso de incrementarse los cambios sobre los requisitos capturados, estos cambios deben ser verificados para ver si los nuevos
requisitos corresponden con el razonamiento que se tiene del resto de los requisitos.
4.2.4 Asignación de prioridades
El desarrollo incremental tanto del sistema como el de los requisitos, se acentúan en este modelo de proceso para la captura de requisitos. Si los requisitos
son priorizados, las necesidades mas altas necesitan ser tratadas primeramente y los cambios subsecuentes en los requisitos ya definidos re-examinados, antes de
que las necesidades de baja prioridad (con sus cambios respectivos) sean
implantados, esto puede resultar en un ahorro, tanto en costo como en tiempo cuando se procesan los cambios mencionados en los requisitos durante el desarrollo del sistema.
Los requisitos deben ser priorizados en base al costo, a su relación con otros
requisitos, y a las necesidades de los usuarios. Los modelos de arquitectura pueden ayudar en la determinación sobre cómo el sistema puede ser
incrementalmente desarrollado. El Despliegue de la Función de la Calidad (QFD- Quality Function Deployment) es una técnica ideal para determinar las
características críticas de un sistema y promover las necesidades de los usuarios, esta técnica se describe en [Schubert89].
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Marthez Rangel Pag.38
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
4.2.5 Integración y validación
Un avance importante de las técnicas de desarrollo en grupo, tal como es el
JAD, es que promueve la titularidad compartida del desarrollo de los requisitos con una mejor definición del alcance, así como también reduce la oportunidad para
cambios futuros en los requisitos. Estas técnicas acentúan la integración de las múltiples puntos de vista entre los participantes de la construcción de un sistema de información. Lo anterior tanto como sea posible a través de involucrar todas las partes afectadas por el desarrollo del sistema para que la propiedad compartida no
se pierda. Si la integración es llevada a cabo por una sola comunidad durante el
proceso de la captura de requisitos, tales como la búsqueda de hechos, obtención de requisitos y otros estados anteriores, enfocar la integración de esta manera
puede ser vista como una interpretación de los desarrolladores de los requisitos, y
esto puede ser criticado por no incorporar otras interpretaciones importantes de
otras comunidades.
Existen un gran número de maneras para tratar el problema de la integración. Una forma es la de repetir las técnicas de desarrollo en grupo, luego del proceso de captura de requisitos. Lo anterior para que la titularidad compartida
tenga lugar nuevamente. Cuando los gerentes de niveles altos se involucran
frecuentemente en tales grupos de desarrollo, puede ser imposible obtener el
compromiso de todos los participantes durante la búsqueda de hechos cuando esta
contribución es crítica, así como también al final del proceso de captura de
requisitos. El involucrar personal de alto nivel, tanto al comienzo como al final del desarrollo conceptual puede rechazarse a favor de involucrar gentes de otros niveles al comienzo del desarrollo conceptual.
Las tareas de integración deberán ser ejecutadas, y llevadas a cabo por el
analista de sistemas y los resultados obtenidos del proceso de captura de requisitos deberá comunicarlos a las otras partes involucradas en dicho proceso a través de varias estrategias, como la creación de escenarios. Esta comunicación
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.39
Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos
puede ser vista como el resultado del concepto de exploración y la captura de requisitos, comenzando con las primeras actividades de demostración y validación. Esta validación de requisitos asegura a todas las partes afectadas que sus intereses se encuentran a buen resguardo. e
En los casos donde el analista de requisitos es el responsable de la
integración de la información .que contengan todos los atributos deseables, vistos en el marco de este trabajo de tesis, es posible utilizar algunas técnicas como los
modelo de dominio que proveen de mapas acerca de cómo organizar la información en un documento de requisitos, y cómo debe presentarse dicha
información a todas las partes involucradas en la captura de requisitos.
Cuando el concepto de diversos' puntos de vista es usado, estas vistas pueden ser integradas a través de la técnica del diagrama de concepto descrito en
[Delugach91]. Este es un buen enfoque automático para la integración de puntos
de vista, pero no soporta fácilmente el desarrollo incremental de requisitos. La
técnica QFD puede asimismo, ser usada para la integración y validación mediante
la relación de los puntos de vista .de los usuarios y de los desarrolladores de un sistema. La integración de los puntos de vista de los usuarios y de los desarrolladores puede revelar las deficiencias existentes en las fases iniciales de la metodología de captura de requisitos para que sean revisadas.
4.2.6. Representación del conocimiento adquirido
La tarea principal del análisis de requisitos es generar especificaciones que describan el comportamiento del sistema en forma no ambigua, consistente y
completa. Para que esta tarea sea llevada a cabo en forma adecuada, es necesario
determinar correctamente el contexto, es decir, dónde se efectuarán las tareas de ingeniería, con que recursos se cuenta, y cuales son los límites y los objetivos del producto que se está por desarrollar. Este contexto se denomina Universo de Discurso (UD) y evoluciona a lo largo del proceso de desarrollo y mantenimiento
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.40
Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet
del soffware. Cuanto mejor se especifique ese UD, mayores serán las posibilidades de obtener un sistema bien definido.
El UD contiene todas las fuentes de información que se van a utilizar. Por medio de la captura de requisitos se intenta descubrir la información necesaria
para conocer el sistema en estudio. En [Leite97, Leonardi971 se propone entre otras cosas, el uso de escenarios como técnicas para representar esa información. Es importante destacar que durante la fase de captura de requisitos puede ser
necesario re-delinear el UD.
Los escenarios son un medio natural para representar y capturar
conocimiento del dominio durante la captura de requisitos y documentación de
requisitos [Zorman95]. Un escenario constituye una descripción de los aspectos
relevantes en cuanto al comportamiento y al ambiente de un sistema, mediante
episodios concretos y específicos, usando generalmente lenguaje natural. Los
escenarios se pueden usar para describir el comportamiento externo del sistema
permitiendo la participación e interacción del usuario durante todo el proceso de
análisis de requisitos. Además, los escenarios pueden ayudar en la validación de la
especificación de requisitos [Hsia94].
Para definir escenarios se requiere un conocimiento detallado que sólo los
expertos del dominio pueden proveer y validar. Los escenarios están más cerca
que otros modelos abstractos de la percepción que los clientes y usuarios tienen
del dominio del problema, ya que se escriben usando el lenguaje específico de ese dominio. Esto facilita la asimilación de descripciones complejas y abstractas que de otra forma se podrían entender mal [Potts95] y permite establecer una buena comunicación con los expertos no técnicos del dominio.
La construcción de escenarios es un proceso que consiste en entender, analizar y describir el comportamiento de un sistema en términos de las diferentes
formas en las que se espera usarlo. El producto final de esta etapa es un
Propuesta Metodológica para la Captura de Requisitos. Ing. Martin G. Marthez Range¡ Pag.41
Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos
Contexto
documento que contiene un conjunto de escenarios correctos, completos,
consistentes y validados. Este documento forma parte de la especificación de requisitos del sistema y se usa como guía para el diseño y las pruebas.
Nombre del escenario
Meta a ser alcanzada en el macrosistema
Ubicación geográfica y estado inicial del escenario
Un escenario se puede describir utilizando el esquema propuesto en [Leite97] que se muestra en la Figura 4-2.
11 Excepcidn 11 CitLaciÓn qJe provoca un comportamiento oiferente del escenario I
Recursos
Actores
Episodios
Medios necesarios para la realización del escenario
Personas u organizaciones
Serie de sentencias que muestran el comportamiento del escenario
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Marthez Rangel Pag.42
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
CapítuZo 5 Aplicación de da prquesta metodológica en un escenario real
En este capítulo, se presenta un caso de estudio en un escenario real donde se aplica la propuesta metodológica.
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Marthez Rangel Pag.43
Cenidet Cap. 5. Aplicación de la metodología en un escenario real
5.1. Antecedentes
El modelo de la metodología para la captura de requisitos que se propone
en este trabajo de tesis se aplicó en la construcción de un sistema de información en su fase de captura de requisitos. El sistema apoyara el proceso para administrar los recursos otorgados por el gobierno federal a través del Fondo para Modernizar
la Educación Superior, FOMES, a las instituciones de educación superior públicas del país.
Siguiendo el modelo de proceso de la metodología propuesta se encontró lo
siguiente :
5.2. Búsqueda de hechos
En esta parte del modelo de proceso para la captura de requisitos, las tareas a realizar consistieron en identificar a los actores principales, realizar un
análisis operacional, un análisis del problema, un análisis del contexto
organizacional, así como la identificación de todas las partes afectadas por el sistema en construcción, identificando a las personas que son estratégicas dentro de la organización y que pueden tomar decisiones, así como a los usuarios finales. Lo encontrado se describe a continuación:
5.2.1. Análisis operacional
El FOMES es un programa estratégico creado por el Gobierno Federal a través de la Secretaría de Educación Pública (SEP) para otorgar recursos
extraordinarios, no regularizables, con el propósito de mejorar, modernizar y
complementar la infraestructura de apoyo al trabajo académico de los cuerpos académicos y sus alumnos e impulsar el desarrollo institucional de las Instituciones de Educación Superior (IES).
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martfnez Rangel Pag.44
Cap. 5. Aplicación de la metodologia en un escenario real Cenidet
Los recursos obtenidos, a partir de proyectos institucionales tiene como
objetivo general la realización del Programa de Fortalecimiento Integral en el ámbito que les corresponda y como objetivo específico alguno de los siguientes entre otros:
a) El mejoramiento integral del proceso enseñanza-aprendizaje;
b) La actualización de planes y programas de estudio, y la flexibilización
-curricular;
c) La implantación de programas institucionales de tutoría individualizada O
de seguimiento de egresados siguiendo la metodología de la Asociación
Nacional de Universidades e Instituciones de 'Educación Superior (ANUIES),' así como de .retención, orientación educativa, y conclusión de
estudios, entre otros, que propicien una mejor atención y seguimiento
de los alumnos por parte de las IEC;
d) La consolidación de sistemas de información que apoyen los procesos de
planeación, autoevaluación, acreditación de programas y certificación de
los procesos de gestión y administración institucionales;
e) La adecuación de la normativa para el mejor funcionamiento de la institución;
f) La ampliación y modernización de la infraestructura académica de
laboratorios, aulas, talleres, plantas piloto, centros de lenguas extranjeras y bibliotecas, entre otros, para que los cuerpos académicos de las Instituciones de Educación Superior y sus alumnos cuenten con
condiciones apropiadas para su trabajo académico;
g) Fortalecimiento de proyectos de investigación en desarrollo, que hayan generado resultados y en los que participen estudiantes, como un medio para mejorar la calidad de la educación que reciben;
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.45
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
h) Dotación de equipo de cómputo para actividades académicas en áreas comunes, siempre y cuando atiendan necesidades de equipamiento para docencia y generación o aplicación innovativa del :conocimiento, de los
cuerpos académicos y sus estudiantes;
i) Equipamiento de laboratorios compartidos por cuerpos académicos de una o varias IEC.
5.2.2. análisis del problema
La administración de los recursos federales asignados a los proyectos
FOMES es un proceso complejo debido a que existen muchos factores que deben
tomarse en cuenta para cumplir con los compromisos establecidos mediante
convenio entre una institución de educación superior y la secretaría de educación
pública. Los proyectos del FOMES tienen una duración de un año fiscal. En casos
plenamente justificados podrán continuar más allá de este límite, recibiendo financiamiento para periodos subsecuentes previa solicitud y evaluación de la etapa anterior y en función de la disponibilidad de fondos.
Mediante la construcción de un sistema de información se apoyará al proceso que se sigue para la administración de los fondos aportados por el
gobierno federal, a traves de:
1. Un Fideicomiso con una institución de crédito autorizada para la inversión y
administración con los recursos aportados por la CEP para dar cumplimiento a los objetivos y las metas del FOMEC.
2. La designación de un comité técnico del Fideicomiso formado por tres
personas de la institución, el cual será responsable de:
a) Vigilar el efectivo cumplimiento de todos y cada uno de los fines del
Fideicomiso;
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.46
Cap. S. Aplicación de la metodología en un escenario real Cenidet
b) Autorizar la asignación de recursos necesarios para llevar a cabo los fines del Fideicomiso, de acuerdo con los programas e instrucciones
que el mismo establezca;
c) Autorizar la celebración de actos y contratos de los cuales se deriven
derechos y obligaciones para el patrimonio del Fideicomiso;
d) Solicitar a la Dirección General de Educación Superior (DGEC) su
autorización por escrito para emplear los productos financieros
generados en el Fideicomiso, los cuales sólo podrán ser aplicados al
cumplimiento de metas de proyectos FOMEC apoyados originalmente
en forma parcial, o de aquellos que fueron dictaminados
favorablemente pero que no fueron apoyados por insuficiencia presupuestal;
e) Instruir a la Fiduciaria respecto a las políticas de inversión del
patrimonio del fideicomiso; y
f) Cualesquiera otras obligaciones derivadas de la ley.
3. Una coordinación que administre el proceso FOMEC, siendo esta uno de los usuarios principales del sistema de información del cual se capturaran los
requisitos para su construcción, esta coordinación será responsable de:
a) Validar que la solicitud de pago cumpla con todos los requisitos
establecidos para su tramitación.
b) Enviar al comité técnico del Fideicomiso FOMEC mediante un acta la
relación de solicitudes que cumplen con los requisitos establecidos
para su aprobación.
c) Enviar al tesorero de la institución la relación de pagos para su
contabilización y emisión de los cheques correspondientes.
Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martínez Rangel Pag.47
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
d) Instruir mediante oficio a la institución de crédito autorizada para la inversión y administración para que traspase fondos de la cuenta del Fideicomiso a la cuenta corriente para que se paguen los cheques liberados por la tesorería de la institución de educación superior.
e) Registrar los gastos que genera cada responsable de proyecto con el
objeto de poder informar al comité técnico del Fideicomiso FOMES de
la evolución que tiene cada proyecto y se tomen las acciones que
correspondan en cada caso.
9 Informar de los resultados obtenidos cada cierto periodo de tiempo al responsable de dar seguimiento al desarrollo de los proyectos para
que se realicen los siguientes procesos:
I) De seguimiento académico y financiero de cada uno de los
proyectos.
11) Evalúe los resultados obtenidos.
El seguimiento académico y financiero Io realiza la DGES en dos etapas. La primera, a mitad del año de ejecución y la Última, al finalizar el año, cuando se
concluyen los proyectos, cuyo resultado final se reporta junto con el soporte
documental y los productos alcanzados. Estas etapas se cumplen mediante las acciones siguientes:
1. La institución de educación superior establecerá la apertura del Fideicomiso del año en vigor, conforme al convenio de colaboración, dando evidencia del mismo y remitiendo a la DGES los estados de
cuenta mensuales.
2. AI término del primer semestre de ejecución de proyectos, la
institución de educación superior presentará en la DGES a traves del responsable de dar Seguimiento al desarrollo de los proyectos el
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.48
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
informe del seguimiento intermedio, con los avances académico y financiero de los proyectos, anexando los documentos probatorios del ejercicio presupuestal.
3. La 'DGES realizará el análisis del informe de seguimiento intermedio
para conocer el grado de avance y la consistencia de los datos en
función del convenio signado. En caso de detectarse retrasos notorios o irregularidades en el uso de 105 recursos, la DGES solicitara información complementaria a la Institución de educación superior.
4. AI término del segundo semestre de ejecución de proyectos, la
institución de educación superior presentará en la DGES el informe
de seguimiento final con la conclusión de los avances académicos y financieros de los proyectos, así como los documentos
comprobatorios del ejercicio presupuestal.
5. Cuando se hayan cumplido las metas académicas según el convenio
con la institución de educación superior, y comprobado el uso
adecuado de los recursos, la DGES remitirá a institución de educación
superior el. oficio de liberación.
6. En caso que una institución no entregue a las DGES la información
que le solicita, y/o no se cumplan las metas académicas según el
convenio, y/o no se utilicen los recursos otorgados para el desarrollo de los proyectos aprobados, la DGES podrá cancelar la participación de la institución de educación superior en el Programa.
La evaluación de los resultados académicos la llevará a cabo la DGES y se realizara una vez por año. Para ello la DGEC solicitara a la institución de educación superior una autoevaluación de los resultados de los proyectos FOMES apoyados y
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.49
Cenidet Cap. 5. Aplicación de la metodología en un escenario real
su impacto académico. La DGES empleará dicha evaluación para retroalimentar los criterios de asignación y las políticas de operación del FOMES.
5.2.3. Análisis organizacional
A partir del análisis operacional y del análisis del problema se extrae el análisis organizacional el cual se presenta a continuación en dos fases, una considerando el contexto donde participa el Gobierno Federal y la institución y que se presenta en la figura 5-1, y la otra fase considerando un contexto local donde
participan todos los actores (personas, dependencias) de la institución de
educación superior en donde se implantará el sistema, lo anterior se presenta en la figura 5-2.
Universidad Estatal Gobierno Federal
Evalúa proyectos y otorga recursos 4
financieros
Evalúa resultados y Administra recursos toma acciones financieros y corresuondientes presenta resultados
Fig. 5-1. Análisis organizacional a nivel Gobierno Federal-Institución de educación
superior Estatal.
Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martínez Rangel Pag.50
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
5.2.4. Identificación de las partes afectadas
A partir de las tareas de análisis operacional, análisis del problema y análisis organizacional es posible identificar a cada uno de las partes afectadas por la implantación de un sistema de información. Se presenta a continuación la lista de las partes afectadas (se incluyen aquellas que aunque no inciden directamente en el proceso de administración de los recursos FOMES, si tienen que ver con los procesos administrativos dentro de la institución, como es el caso del almacén.
a) Comité técnico de FOMES.
b) Coordinación FOMES
c) Institución de crédito
d) Responsable de dar seguimiento al desarrollo de los proyectos
e) Responsables de proyecto
9 Proveedores
g) Tesorería
h) Departamento de Almacén
i) Departamento de compras
j) Departamento de contabilidad.
5.2.5 Resultados obtenidos en la búsqueda de hechos
Establecimiento del contexto del problema: El problema que se tiene es la administración de los recursos extraordinarios que reciben las instituciones de educación superior de parte del gobierno federal y que tienen que ser erogados
Propuesta Metodoiogtca Para La Capbra De Requisitos Ing. Martin G. Martinez Rangel Pag.53
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
bajo ciertos lineamientos que permitan lograr las metas establecidas en cada proyecto.
Total de los objetivos a cumplir: a continuación se señalaran aquellos objetivos que deben cumplirse con la implantación de un nuevo sistema de información que apoye a la coordinación FOMES en la administración de los recursos.
a) Llevar un control del gasto que hace cada responsable de proyecto, de
acuerdo al monto establecido para cada uno de ellos.
b) Verificar que los recursus erogados cumplan con las metas que persigue
cada proyecto, y que los bienes adquiridos sean aquellos que fueron especificados en la propuesta del proyecto que fue evaluado por la SEP.
c) Que la coordinación FOMES informe con oportunidad y veracidad al responsable de dar seguimiento al desarrollo de los proyectos de los avances que tiene en materia financiera por proyecto, metas y bienes
adquiridos.
d) Que la coordinación FOMES informe a la SEP de los resultados obtenidos en términos del gasto mediante la emisión de estados de cuenta.
e) Que la coordinación FOMEC sepa en todo momento ia lista de proveedores
que se tienen, cheques emitidos por la tesorería, bienes adquiridos,
traspasos realizados de la cuenta del fideicomiso a la cuenta corriente para
pago de cheques, metas cumplidas por proyecto en termino del gasto rea I izado.
f) Que la coordinación FOMES sepa en todo momento el estado actual que guarda cada documento(so1icitudes atendidas, solicitudes rechazas, cheque emitidos, cheques cobrados, cheques cancelados, solicitudes de compras atendidas, solicitudes de compras rechazadas, etc).
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.54
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
5.3. Obtención de requisitos
A partir de la búsqueda de hechos a Io largo de todo el proceso FOMES, es
posible identificar los requisitos orientados a las necesidades de los usuarios.
En esta parte es importante señalar que los requisitos que se obtuvieron
obedecen a las necesidades que tienen los tres actores principales dentro del proceso FOMES, estos actores son el comité técnico, el responsable de dar seguimiento al desarrollo de los proyectos y el responsable de la coordinación
FOMES. A continuación se mencionan los requisitos mas importantes que cada uno de ellos propuso que el sistema debe cubrir.
Comité Técnico:
2) Que el sistema permita identificar en todo momento los movimientos
que tiene el fideicomiso y que los montos erogados correspondan con
los objetivos que se deben cumplir en cada uno de los proyectos.
3) Que de acuerdo a las necesidades de pago que se tengan, permita
identificar mediante el sistema si es factible el autorizar el
movimiento de fondos de la cuenta del fideicomiso a la cuenta
corriente para cubrir los pagos autorizados.
4) Que de acuerdo a los objetivos que se deban cubrir en cada uno de
los proyectos, permita identificar en qué proyectos se requiere
autorizar la celebración de actos y contratos de los cuales se deriven derechos y obligaciones para el patrimonio del Fideicomiso.
5) Obtener información de cada uno de los proyectos que por insuficiencia presupuesta1 no han podido cubrir sus obletivos en su totalidad. Lo anterior con el objeto de pedir autorización a la SEP para emplear los productos financieros generados en el Fideicomiso
para apoyar a estos proyectos.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.55
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
6) Que el sistema permita obtener información respecto a io5 recursos comprometidos con el objeto de poder instruir a la Fiduciaria respecto a las políticas de inversión del patrimonio del fideicomiso.
Coordinación FOMES:
1) Que el sistema permita mantener los datos de un proyecto, así como de los responsables de cada uno de ellos.
2) Que el sistema permita mantener los datos específicos de cada
proyecto como son sus objetivos, estrategias y metas, así como los conceptos o bienes que podrá adquirir para cumplir cada una de sus metas.
3) En cuanto al manejo de conceptos, es importante que el sistema permita identificar cuáles son susceptibles de ser modificados.
4) Que para el registro de solicitudes de pago permita capturar por
separado aquellas que generan compromisos de aquellas que no
generan compromisos, así como de las solicitudes que generan
retención de impuestos.
5) Que el sistema permita registrar pedidos y en todo momento se
conozca el estado que guarda cada uno de ellos (pedido atendido por
compras, pedido atendido por el proveedor, pedido con bien
adquirido, pedido cancelado etc.).
6) Permitir agrupar solicitudes de pago en actas que deberán ser
analizadas por el comité técnico y en su defecto autorizar o rechazar
aquellos pagos que a juicio del comité deban rechazarse.
7) Registrar cheques y conocer en todo momento cuales ya fueron
cobrados por los proveedores, cuáles cheques fueron cancelados,
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.56
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
qué cheques son para pagos de solicitudes que generan retención de impuestos, etc.
8) Que el sistema permita realizar comprobaciones de pagos hechos con anticipación mediante la presentación de facturas con todos los datos
asociados a ellas.
9) Que el sistema permita en todo momento registrar modificaciones en
todos los rubros ya mencionados.
10) Que el sistema permita realizar transferencias de fondos de la cuenta del fideicomiso a la cuenta corriente para pago de solicitudes.
Rresponsable de dar seguimiento al desarrollo de los proyectos
1) Que el sistema permita identificar los avances que tiene cada uno
de los proyectos en cuanto a su financiamiento.
2) Que el sistema permita generar un informe financiero detallado por
cada proyecto y que dicha información se transfiera al sistema SIFOMEC que es proporcionado por la SEP el cual se utiliza como
instrumento para reportar resultados.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.57
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
5.4. Evaluación y razonamiento de los requisitos.
En esta parte se evalúo la consistencia de cada uno de los requisitos
expuestos por las partes o actores principales del proceso FOMES y se razonó del porque algunas cosas son expresadas como requisitos, los resultados de estas
tareas se muestran a continuación.
Requisito
No.
1
Descripción
Que el sistema
permita identificar en
todo momento los movimientos que
tiene el fideicomiso y
que los montos erogados
correspondan con los
objetivos que se
deben cumplir en
cada uno de los
proyectos.
Que de acuerdo a las necesidades de pago
que se tengan, permita identificar mediante el sistema si
es factible autorizar
Parte o actor
que lo
expresa
:omité Técnico
:omite Técnico
Evaluación y
Razonamiento
Este requisito está en
correspondencia con el convenio que tiene la institución con la SEP en
cuanto a que se le debe
enterar a la segunda los
movimientos financieros que
se realizan y si tales
movimientos tienen que ver
con los objetivos planteados
en cada uno de los proyectos
Este requisito esta en correspondencia en cuanto
que se debe minimizar el traspaso de recursos que se tienen en el fideicomiso a la cuenta corriente, ya que la
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.58
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
el movimiento de
fondos de la cuenta del fideicomiso a la cuenta corriente para
cubrir los pagos
autorizados.
Que de acuerdo a los
objetivos que se
deban cubrir en cada
uno de los proyectos, permitir identificar en
que proyectos se requiere autorizar la
celebración de actos y
contratos de los cuales se deriven
derechos y
obligaciones para el patrimonio del Fideicomiso.
Obtener información
de cada uno de los
proyectos que por insuficiencia
presupuesta1 no han podio cubrir sus objetivos en su totalidad. Lo anterior
:omite Técnico
:omite Técnico
primera es la que más
intereses genera.
Este requisito esta expresado
de manera adecuada en
cuanto que con ello es
posible reservar en la cuenta
corriente un monto
comprometido, mismo que no generaría intereses. El
sistema deberá por
consiguiente permitir
identificar el número de
pagos que contempla un
compromiso.
Este requisito es expresado
en correspondencia con la posibilidad de que la Institución pueda utilizar los
recursos que provienen de intereses generados en el fideicomiso. Lo anterior tiene sentido en cuanto que
Propuesta Metodológica Para La Captura De Requisitos Ing. Marth G. Martínez Rangel Pag.59
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
con el objeto de pedir autorización a la SEP
para emplear los productos financieros generados en el
Fideicomiso para
apoyar a estos
proyectos.
Que el sistema
permita obtener
información respecto
a los recursos
comprometidos con el
objeto de poder
instruir a la Fiduciaria respecto a las políticas de inversión
del patrimonio del
fideicomiso.
Que el'sistema permita mantener los datos de un proyecto,
así como de los responsables de cada
:omité Técnico
:oordinaciÓn 'OMES
algunos proyectos fueron apoyados en algunas de sus
metas con muy pocos recursos, entonces el sistema deberá permitir identificar
qué proyectos tienen una
eficiencia en el gasto del
100°/~ y que tengan metas sir cumplir por falta de recursos
financieros
Este requisito tiene relación al
requisito número tres, con la
premisa de que este se esta expresando en que aparte de
tener compromisos derivados
de contratos o convenios con
algunos proveedores es necesario instruir al banco
para que reserve los recursos
que se utilizarán a corto
plazo.
~
Este requisito es expresado desde el punto de vista operativo, y tiene que ver con
el mantenimiento de la
información expresada en las
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.60
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
uno de ellos.
Que el sistema
permita mantener los datos específicos de
cada proyecto como
son sus objetivos,
estrategias y metas,
así como los
conceptos o bienes
que podrá adquirir
para cumplir cada una
de sus metas
En cuanto al manejo
de conceptos, es
importante que el
sistema permita
identificar cuales son
susceptibles de ser
modificados.
:oordinación
'OMES
:oordinaciÓn
:OMES
propuestas de los proyectos de los montos con que fueror
apoyados en cada una de sus metas.
~ ~~
Este requisito está expresado
en correlación con el requisitc
número siete, pero
considerando que en esta parte el cisterna deberá permitir identificar los rubros
o bienes que podrá adquirir
un responsable de proyecto
en cada una de sus metas.
Este requisito es expresado
en cuanto a que no todos 10s conceptos pueden ser
susceptibles de ser modificados, en el caso de
conceptos muy generales es
posible modificarlos y de acuerdo al criterio de costo adquirir otros conceptos que tengan relación con el
modificado (es decir un concepto puede modificarse
siempre y cuando el concepto
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.61
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
10
11
12
Para el registro de solicitudes de pago,
permitir capturar por
separado aquellas que
generan compromisos
de aquellas que no
generan
compromisos, así
como de las
solicitudes que
generan retención de
impuestos.
Que el sistema
permita registrar
pedidos y en todo momento se conozca
el estado que guarda
cada uno de ellos
(pedido atendido por
compras, pedido atendido por el proveedor, pedido con bien adquirido, pedido cancelado etc.).
Permitir agrupar
Loordinación 'OMES
:oordinaciÓn
:OMES
:oordinaciÓn
sea del mismo genero
(acervo-acervo)
Este requisito es expresado :on el objeto de poder :umplir el requisito número
seis expresado por el comité
:étnico.
fste requisito es expresado
:om0 una necesidad a todo el
xoceso, ya que es necesario dentificar en todo momento
!I estado que guarda un ledido en cuanto a que
iermite saber el total de los
'ecurso que deben :ransferirse de la cuenta del
Ideicomiso a la cuenta
:orriente para cubrir los :ompromisos.
Iste requisito es expresado
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.62
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
L3
14
solicitudes de pago en
actas que deberán ser analizadas por el
comité técnico y en su defecto autorizar o rechazar aquellos
pagos que a juicio del
comité deban
rechazarse.
Registrar cheques y
conocer en todo
momento cuáles ya
fueron cobrados por los proveedores,
cuáles cheques fueron
cancelados, que
cheques son para
pagos de solicitudes
que generan retención de
impuestos, etc.
Que el sistema permita realizar
comprobaciones de pagoshechoscon anticipación mediante
'OMES
:oordinación
'OMES
,
:oordinaciÓn
'OMES
como parte del convenio que
'a institución de educación
juperior tiene con la sep en ruanto a que debe existir un :omité que verifique que 10s 3astos que se realizan 3ermiten cumplir las metas
?stablecidas en cada uno de os proyectos.
3 t e requisito es expresado
:on el objeto de validar los
;aldos de cada proyecto para dentificar los avances que se
:¡enen en cuanto a Io inanciero.
3 t e requisito es expresado
?n el sentido de que es iosible que en algunos casos ;e liberen pagos anticipados :on el compromiso de que en
Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.63
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
.5
la presentación de
facturas con todos los datos asociados a ellas.
Que el sistema
permita en todo
momento registrar
modificaciones en
todos los rubros ya
mencionados.
6
Coordinación
FOMES
Coordinación
FOMES
Que el sistema
permita realizar
transferencias de
fondos de la cuenta
del fideicomiso a la
cuenta corriente para
pago de solicitudes.
un determinado momento deberá ser comprobado el gasto mediante factura
Este requisito es expresado como parte de las necesidades de un sistema de
información y no visto como
parte de cumplir alguna
necesidad especifica de algún
actor o parte participante.
Este requisito es expresado
como una necesidad que
tiene tanto el comité técnico
como la coordinación FOMES
en cuanto a el control que debe existir en el fideicomiso.
7
L
Que el s/stema
permita identificar los avances que tiene
cada uno de los
proyectos en cuanto a
su financiamiento.
Responsable
de dar seguimiento al
desarrollo de
los proyectos
Este requisito es expresado como parte del convenio que
existe entre la institución de
educación superior y la SEP
en cuanto a que ésta última deberá evaluar los resultados en base al gasto erogado en cada proyecto.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.64
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
18 Que el sistema Responsable Este requisito es expresado
permita generar un de dar para cumplir una necesidad informe financiero seguimiento al como parte de un convenio
detallado por cada desarrollo de existente entre la propia
proyecto y que dicha los proyectos . institución de educación
información se
transfiera al sistema
SIFOMES, mismo que
es proporcionado por
la SEP, y el cual se
utiliza como
instrumento para
reportar resultados.
superior y la SEP.
5.5. Asignación de prioridades
En esta parte se determinó la importancia relativa de cada uno de los requisitos de un actor respecto a los requisitos que son expuestos por los otros
actores. Se concluyó que en orden de importancia los requisitos expresados por la coordinación FOMES tienen mayor prioridad sobre los requisitos expresados por el
comité técnico y por el responsable de dar seguimiento al desarrollo de los
proyectos, en el orden que se menciona, y que los requisitos expresado por el comité técnico tienen mayor prioridad sobre los requisitos expresados por el responsable de dar seguimiento al desarrollo de los proyectos. Lo anterior aunque
en el orden de jerarquía en cuanto a la toma de decisiones se encuentra el comité técnico en primer lugar, seguido por el responsable de dar seguimiento al
desarrollo de los proyectos.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.65
Cenidet Cap. 5. Aplicación de la metodología en un escenario real
5.6. Integración y validación.
En esta parte se reunió la información colectada desde los primeros pasos que componen el proceso de captura de requisitos como parte de la metodología
que se está aplicando al proceso FOMEC y validando que los requisitos obtenidos
corresponden a las metas originalmente estructuradas durante la búsqueda de
hechos.
La información colectada se basó en entrevistas con cada uno de los actores
,los cuales describieron de manera detallada cada una de las funciones que les
toca realizar dentro del proceso FOMEC, así como documentación que hace
referencia al convenio que realiza la propia institución de educación superior con la
SEP. En dicho convenio la institución de educación superior se compromete
textualmente a abrir un fideicomiso con una institución de crédito, y así mismo se
compromete a informar en todo momento mediante estados de cuenta, el estado
que guarda' el financiamiento, además de comprometerse a utilizar los recursos
únicamente para 10s. fines para 10s que le fueron proporcionados a la institución Y
que ya fueron mencionados al inicio de este documento. Otro documento
importante fue el diario oficial de la federacion, en donde el gobierno federal.
convoca a través de la SEP a todas las institución de educación superiores públicas
a participar en la presentación de proyectos, con el objeto de obtener recursos
extraordinarios, bajo ciertas bases establecidas por la subsecretaria de Educación
Superior e Investigación Científica (CECIC).
En cuanto a la validación de los requisitos, se identificó que cada uno de los
requisitos propuestos corresponden efectivamente a cubrir los objetivos que la propia institución de educación superior se compromete a cumplir mediante
convenio con el gobierno federal, como Io es un control sobre el fideicomiso, un
control de los recursos aportados por el gobierno federal y con un compromiso fundamental en cuanto a que los recursos sean gastados exclusivamente para
Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.66
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
TiTULO
3BJETiVO
ZONTEXTO
cumplir las metas propuestas en cada uno de los proyectos que se presentaron
para evaluación y que fueron apoyados con recursos financieros.
Pago de solicitud
Pago de solicitud al proveedor de bienes adquiridos
Mediante solicitud de compra el proveedor ha entregado un bien al responsable del proyecto, el cual debe hacer los trámites correspondientes para que sea
liberado el pago que cubra el bien adquirido.
5.7. Representación del conocimiento.
4CTORES
Esta parte del modelo del proceso que se sigue en la metodología
propuesta, tiene que ver con la creación de escenarios que permitan representar y
capturar el conocimiento del dominio durante la captura de requisitos. Como ya se
mencionó, un escenario constituye una descripción de los aspectos relevantes de
comportamiento y del ambiente de un sistema, mediante episodios concretos y
específicos usando generalmente lenguaje natural. A continuación se presenta en la tabla 5-1 un ejemplo de escenario 'que permite capturar el COnOCimientO
adquirido como parte del modelo de la metodología para la captura de requisitos
que se propone en este trabajo de tesis.
Coordinador de FOMES,
Proveedor,
Responsable de proyecto,
El uso de escenarios se aplicó al proceso que se sigue para administrar los
recursos otorgados por el gobierno federal a través del Fondo para Modernizar la Educación Superior en lo que corresponde al pago de solicitudes. En la tabla 5-1 se
presenta el escenario respectivo.
Propuesta Metodológica Para La Captura De Requisitos Ing. Mar th G. Martinez Rangel Pag.67
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
.ECURCOC
PISODIOC
Tesorero,
Zomité técnico,
Departamento de compra,
lepartamento de almacén,
[nstitución de crédito.
lisponibilidad del bien adquirido,
'ormato de solicitud de compra,
'ormato de solicitud de pago firmado por el responsable del proyecto, proveedor
I avalado por el comité técnico.
1.
2.
3.
4.
5.
6.
El responsable del proyecto solicita al coordinador de FOMES solicitud
de compra del bien requerido.
El coordinador de FOMES solicita al departamento de compras que
cotice y a su vez seleccione al proveedor que ofrezca mayores
beneficios.
El proveedor entrega el bien adquirido con factura que ampara el costo
al responsable del proyecto.
El responsable del proyecto solicita mediante solicitud de pago y
factura correspondiente la liberación de fondos que cubran el bien
adquirido.
El coordinador de FOMEC realiza los trámites para que la tesorería
genere el cheque por el monto que ampara la factura.
El coordinador de FOMEC mediante oficio instruye a la institución de
crédito la liberación de fondos para el pago de cheques.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.68
Cap. 5. Aplicación de la metodología en un escenario real Cenidet
EXCEPCION
7. El proveedor recoge cheque en la tesorería y se presenta ante la institución de crédito para el cobro correspondiente mediante la
presentación de cheque.
a) Si el proveedor no entrega el bien adquirido en el plazo establecido, se podrá prescindir de sus servicios.
b) Si la tesorería no libera el pago en el plazo establecido, el proveedor recibirá un monto extra por concepto de moratoria.
c) Si el proveedor no recoge cheque en la tesorería en un plazo
determinado, se cancelará su cheque y deberá iniciarse nuevamente todo
el proceso para pago.
Tabla 5-1. Escenario para la actividad de pago de solicitud.
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.69
Cap. 6. Evaluación y Resultados de la Metodología Cenidet
Capítulo 6 E valuacióay resultados de la propuesta metodo lógica
En este capítulo, se presenta la evaluación de la propuesta metodológrca y los resultados obtenidos de su aplicación en el caso de estudio.
Propuesta Metodológica para la Captura.de Requisitos Ing. Martin G. Martinez Rangel Pag.70
Cap. 6. Evaluación y Resultados de la Metodología Cenidet
6.1 Criterios de evaluación
Es necesario llevar a cabo una evaluación cuando se propone una nueva metodología para la captura de requisitos. El objetivo es determinar los beneficios
que aporta sobre la practica actual. Los estudios o referencias que se tienen en
cuanto a la evaluación de otras metodologías similares indican que las formas o métodos existentes para tal fin están plagados de dificultades, ya que no existe
una forma de controlar su uso o aplicación por parte de los desarrolladores
experimentados y novatos, además de que no existe una forma de medir los
niveles de creatividad que éstos tengan. Por Io que se sabe, no existen desarrollos
comerciales que permitan comparar las metodologías existentes entre una y otra y
la Única forma de saber si una es buena o mala es aplicándola a un caso real que
permita identificar si los resultados obtenidos corresponden a lo que indica la
metodología o no.
En cuanto a las herramientas o técnicas utilizadas por la metodología
propuesta, mas adelante se hace una evaluación de cada una de ellas, se identifica
en qué aspectos son de utilidad, y su relativa madurez en cuanto a su aplicación para obtener información, expresión de requisitos y validación de los mismos.
En general, la evaluación de la metodología puede resultar buena en tanto
el analista experimentado, como el analista novato responsables de la captura de
requisitos, tengan conocimiento de la metodología que se propone. En [Fowler901
se indica que en el análisis final de una metodología para la captura de requisitos, ésta tiene valor si el producto final es considerado como bueno
Como se describe en [Winokur90], es esencial proveer de un entrenamiento
completo para la metodologia a evaluar y para todas las herramientas de soporte antes de que ésta sea aplicada a un sistema real para su evaluación, de Io
contrario, sin un entrenamiento propio de la metodología y las herramientas de soporte, el método puede emplearse mal y la evaluación puede estropearse.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel' Pag.71
Cap. 6. Evaluación y Resultados de la Metodología Cenidet
Dado que esta Propuesta surge de dos metodologías desarrolladas para la captura de requisitos [Mittermeir90, Christel921, y que en su momento fueron
validadas por los autores, resulta necesario comentar que el modelo para la
captura de requisitos que aquí se presenta es muy similar a las metodologías antes
mencionadas. Con la salvedad de que en este modelo que se propone se integra la
fase de representación del conocimiento adquirido y se aclaran con mayor
precisión los beneficios que trae consigo el utilizar herramientas y técnicas, cuya
efectividad ya ha sido probada en otros casos de estudio en cuanto a que permiten
recuperar, organizar y representar la información adquirida
En este sentido es importante señalar que los criterios de evaluación de la metodología que se propone en este trabajo de tesis fueron tomados con base al
logro de las tareas que se deben realizar en cada uno de los pasos que contempla
la metodología y al beneficio que trae el uso de las herramientas mencionadas.
A continuación se presentan los puntos a evaluar en cada una de las
técnicas o herramientas y que son de gran utilidad en el proceso de captura de
requisitos, y utilizadas por la metodología.
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Marthez Rangel Pag.72
Cap. 6. Evaluación y Resultados de la Metodología Cenidet
I.
11.
111.
IV.
V.
VI.
VII.
VI11
IX.
La técnica es Útil en aspectos organizacionales o de análisis del contexto.
La técnica es Útil para evitar el diseño prematuro.
La técnica es Útil cuando existen varios colaboradores.
La técnica es Útil cuando existen varias disciplinas en la colaboración.
La técnica es Útil cuando el tamaño del problema es grande.
La técnica es útil cuando existen expresiones múltiples de requisitos.
La técnica es Útil cuando existe una gran volatilidad.
Cuando la técnica tiene ya una madurez reconocida.
Cuando la técnica se prescribe (resulta indispensable) de manera definida.
En la tabla 6-1 se presenta la evaluación de las técnicas que son de utilidad
en los aspectos de recuperación de información, expresión de requisitos y
validación de los mismos. En cada uno de esos aspectos es posible trabajar con
mas de una herramienta. Respecto a la columna VIII, donde se indica la relativa madurez de estas técnicas, es importante señalar que algunas de ellas son muy
maduras, ya que han sido probadas y usadas en la captura de requisitos por una década o mas. Otras son propuestas muy recientes que en el esfuerzo por
investigar se han presentado, pero no han sido muy usadas en el area de la
captura de requisitos.
Si una técnica no esta clasificada en la columna de madurez (VIII) eso no
significa que no produzca buenos resultados, si no mas bien que no existe registro alguno que muestre su aplicabilidad en la captura de requisitos, pero se sugiere su
uso en este proceso.
Para calificar a cada una de las técnicas que se proponen, se utiliza la marca y, esta calificación pueden ser: dos marcas(qy) que significa que ya es reconocida
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.73
Cenidet Cap. 6. Evaluación y Resultados de la Metodología
CORE
Vistas múltiples de Delugach
SSM
su utilidad y que posee la calidad deseada, una marca (v) significa que es útil en
el aspecto donde se señala, pero que no es tan fuerte como otras técnicas y que posee la calidad deseada pero con un alcance limitado, sin marca o nada significa que la técnica no puede enfocarse a un aspecto dado, o que provee un pequeño
soporte.
w Y w w ww ww
y~ ww ww ww
iv w w
Aspectos I1 I11 I V V V I VI1 VI11 I X
QFD
Concepto de Prototificación
I I I I I I I . . . . .
REUNIÓN I DE INFORMACIÓN " ' '
- r - i i - i i - T -
w w w ww
w w w
I I I I I I I . , , J , . . . .
. . . . , . . ,: 7
I
4 EXPRESION DE REQUISTTOS . ,
I--- r,'-I17-- 77
Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel ' Pag.74
Cap. 6. Evaluación y Resultados de la Metodología Cenidet
En cuanto a la evaluación de la metodología aquí propuesta, se considera
Útil en cuanto a que los resultados obtenidos al aplicarla en el entorno real fueron buenos. Se concluyó que la metodología es Útil tanto para el analista novato como
para el analista experimentado. El único requisito que se indicó para poder
aplicarla es que quien la utilice debe tener un pleno conocimiento de la
metodología, identificar los pasos que debe seguir, tomar en cuenta las tareas a
realizar en cada uno de ellos, saber utilizar las herramientas y técnicas sugeridas, y
principalmente saber identificar los resultados que debe obtener en cada fase de la
metodología.
6.2 Resultados obtenidos
El modelo de la metodología para la captura de requisitos que se propone
en este trabajo de tesis se aplicó a la fase de captura de requisitos del proceso
para administrar los recursos otorgados por el gobierno federal a través del Fondo
para Modernizar la Educación Superior, FOMEC, a una institución de educación
superior, con el objetivo de construir un sistema de información.
Dado que la metodología propuesta consta de un modelo que indica
claramente los pasos a seguir para la captura de requisitos, así como las tareas a realizar en cada paso y los resultados que deben obtenerse producto de la
ejecución de esas tareas, resultó de mucha utilidad saber que esta metodología puede utilizarse para resolver el problema de búsqueda, recolección y organización de información dentro de las organizaciones con el objeto de capturar los
requisitos que deben cumplirse al construir un sistema de información.
Todas las actividades que se ejecutaron se agruparon en tareas asociadas
para encontrar hechos, obtener requisitos, evaluar y razonar los requisitos encontrados, asignar prioridades. Los resultado que se lograron se pueden resumir de la siguiente manera:
Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.75
Cenidet Cap. 6. Evaluación y Resultados de la Metodología
a) Se logró tener una visión clara en un periodo muy corto acerca del contexto
del problema.
b) Se identificaron a los actores que intervienen en el proceso de captura de
requisitos.
c) Se identificaron sus deseos y necesidades, mismos que resultan en los
requisitos para la construcción del sistema requerido.
d) Se representó el conocimiento adquirido en cuanto a la actividad de pago
de solicitudes mediante la construcción de un escenario.
Propuesta Metodológica para la Captura de Requisitos Ing. Mattín G. Martinez Rangel Pag.76
Cap. VIL Conclusiones y trabajos futuros Cenidet
CaDziuZo 7 Conclusiones y trabajos futztros
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.77
Cap. VII. Conclusiones y trabajos futuros Cenidet
7.1 Conclusiones.
La capfura de requisitos ha recibido poca atención de la comunidad de la
ingeniería de software en el pasado, quizá por que es un area donde se tiene
que llegar a acuerdos de una manera informal, en vez de buscar etiquetas que
tengan que ver con requisitos, usualmente se negocia con la especificación y esta es la razón principal del porqué las definiciones del análisis de requisitos y la
especificación de requisitos de los sistemas de información, la mayoría de las
veces resultan en desacuerdo con Io que realmente se espera que haga el
sistema en desarrollo. De esa observación se ha aprendido que el análisis de
requisitos, en particular la captura de requisitos, es una tarea difícil, que es
cuidadosamente evadida por la mayoría de los responsables de la especificación
de sistemas de información y que no la enfrentan por no tener a la mano los
elementos suficientes que les permitan capturar el conocimiento necesario que
los lleve a los requisitos.
Se reconoce que el trabajo desarrollado aquí es difícil de encajar dentro de
las ciencias, ya que el rigor científico marca que todo trabajo que se desarrolle
dentro de cualquier disciplina de la ingeniería de software, en especial dentro de
la ingeniería de requisitos, este debe tener una buena dosis de formalismo, que
permita sistematizar el proceso de que se trate, en este caso el proceso de
captura de requisitos.
Es evidente que este trabajo no es el eslabón perdido dentro de la
ingeniería de requisitos, pero si representa un esfuerzo por responder de una
manera mas clara a los problemas que se tienen en la captura de requisitos y
apoyar con ello el trabajo que debe realizar el analista de sistemas dentro de una realidad que existe y que esta dentro de las organizaciones que esperan que las
Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.78
Cenidet Cap. VII. Conclusiones y trabajos futuros
soluciones que se proponga este de acuerdo con los deseos y necesidades de los
usuarios.
7.2 Trabajos futuros.
Uno de los trabajos que se proponen como continuación de esta tesis, es la
sistematización de la captura de requisitos, con el objeto de poder entregar los
resultados a la persona responsable de hacer el análisis del sistema en
construcción. La solución que se proponga debe apoyar al analista de requisitos
identificar que deseos y necesidades de un usuario o grupo de usuarios se
contraponen con los deseos y necesidades de otro usuario o grupo de usuario de
manera sistemática.
Propuesta Metodológica Para La Captura De Requisitos Ing. Marth G. Martínez Rangel Pag.79
Referencias bibliográficas Cenidet
[Congress 901
[Christel92]
[ DoD 911
[IEEE 831
[IEEE 901
[SEI 911
[Adriole 901
REFERENCIAS BIBLIOGRAFICAS
US. Congressinal Subcommittee on Investigations and Oversight.
Bugs in the Program: Problems in Federal Government Computer software Development and Regulation. Technical Report 4/90
Staff Study, U.S. 101 St Congress, Washington, DC, April 1990.
Software Engineering Institute Requirements Engineering Project.
Issues I n Requirements Elicitation. Technical Report CMU/SEI-92- TR-12, Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, P.
US. Department of Defense. Software technology Plan: Volume I1
Plan of Action (Technical Report Draft 5, 8/15/91), U.S. Department of Defense, August 1991.
Institute of Electrical and Electronics Engineers. IEEE Standard
Glossary of Software Engineering Terminology. ANSI/IEEE
Standard 729-1983, Institute of Electrical and Electronics Engineers, New York, 1983.
Institute of Electrical and Electronics Engineers. IEEE Standard Glossary of Software Engineering Terminology. IEEE Standard
610.12-1990 (revision and redesignation of IEEE Std. 729-1983),
Institute of Electrical and Electronics Engineers, New York, 1983.
Software Engineering Institute Requirements Engineering Project. Requirements Engineering and Analysis Workshop Proceedings Technical Report CMU/SEI-91-TR-91-30, Software Engineering Institute, Pittsburgh, PA, December 1991.
Andriole, Stephen I. Command and Control Information Systems Engineering: Progress and Prospects. Advances in Computers
Metodología Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.80
Cenidet Referencias bibliográficas
[Begeman 881
[Berlin 891
[Cameron 861
[Cameron 891
[Checkland 901
[Conklin 88 ]
[Conklin 911
[Cordes 891
[Duran981
[Davis 901
31:l-98, 1990.
Begeman, Michael L., and Conklin, Jeff. The Right TOO! for the Job. BYTE 13(10):255-266, October 1988.
Berlin, Lucy M. User-Centered Application Definition: A
Methodology and Case Study. Hewlett-Packard Journal 40(5):90-
97, October 1989.
Cameron, John R. An Overview of JSD. IEEE Transactions on
Software Engineering SE-12(2):222-240, February 1986.
Cameron, John R. Prototyping Core Functionality Using JSD. I n
IEE Colloquium on “Requirements Capture and Specification for
Critical Systems” (Digest No. 138), 2/1-2/2. Institution of Electrical
Engineers, November 1989.
Checkland, Peter & Scholes, Jim. Soft Systems Methodology in
Action. New York:John Wiley & Sons, 1990.
Conklin, Jeff, and Begeman, Michael L. g1BIS:A Hypertext Tool
for Exploratory Policy Discussion. ACM Transactions on Office Information Systems 6(4):303-331, October 1988.
Conklin, Jeff, and Yakemovic, K.C. Burgess. A Process-Oriented
Approach to Design Rationale. Human-Computer Interaction
6(3/4):357-391, 1991.
Cordes, D.W., and Carver, D.L. Evaluation Method for User Requirements Documents. Information and Software Technology.
Duran, A. et ai., “Una propuesta metodológica para la recolección
de requisitos de un sistema software”, 111 Jornadas de Trabajo MENHIR, 1998.
Davis, Alan M. Software Requirements: Analysis and Specification. Prentice Hall: Englewood Cliffs, NJ, 1990.
Metodología Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.81
Referencias bibliográficas Cenidet
[De Bortol~2000]. Lis Angela de Bortoli, Ana María de Alencar Price "Un Método de
[Delugach 911
[Dobson 911
[Dobson 921
[Dubois 881
[Finkelstein 861
[Fowler 901
Trabajo Para Auxiliar la Definción de Requisitos". Memorias. Jornadas Iberoamericanas de Ingeniería de Requisitos y
Ambientes de Software. Cancún, México, abril del 2000.
Delugach, Harry S. A Multiple Viewed Approach to Software
Requirements. Ph.D. thesis, University of Virginia, 1991.
Dobson, J.E., Martin, M.J., Olphert, C.W., and Powrie, S.E. Determining Requirements for CSCW: the ORDIT Approach. IFIP
Conference on Collaborative Work, Social Communications and
Information Systems (COSCIS91):333-35. Elsevier Science
Publishers B.V. (North-Holland), 1991.
Dobson, J.E., Blyth, A.J.C., Chudge, J., and Strens, M.R. The
ORDIT Approach to Requirements Identification. Proceedings of
the Sixteenth Annual International Computer Software &
Applications Conference. IEEE Computer Society, September
1992.
Dubois, E., Hagelstein, J., and Rifaut, A. formal Requirements
Engineering with ERAE. Philips Journal of Research 43(3/4):393-
414, 1998.
Finkelstein, Anthony, and Potts, Colin. Structured Common Sense:
The Elicitation and Formalization of System Requirements. Software Engineering 86. London: Peter Peregrinus, Chapter 16, 1986.
Fowler, C.I.H., Kirby, M.A.R., and Macaulay, L.A. Historical Analysis:A Method for Evaluating Requirements Capture Methodologies. Interacting with Computers 2(2):190-204, August
1990.
Metodología Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.82
Referencias bibliográficas Cenidet
[Greenspan941
[Goguen97]
[ GA0921.
CGalvao991
[Goodrich 901
[Hsia94]
[Holbrook 901
[Jokela 901
[Jordan 901
S. Greenspan, 3. Mylopoulos, and A. Borgida. "On Formal Requirements Modelling Languages: RML Revisited." Proc. idh ht. Cant: Sohare €ng. Pp. 135-148, Sorrento, Italy, May 1994.
Goguen, J. A. and C. Linde, 'Techniques for Requirements
Elicitation", Software Requirements Engineering, 2"d. Ed., IEEE CS
Press, 1997, pp 110-122.
US General Accounting Office, Mission CFitical Systems: Defense
Attempting to Address Major Sohare Challenges, GAOIIMTEC-
93-13, December 1992.
Galvao Martins L.E, Mascia Deltrini B. "Activity Theory: a
Framework to Software Requirements Elicitation" I1 Jornadas
Iberoamericanas de Ingeniería de Requisitos. Buenos Aires,
Argentina, Septiembre de 1999.
Goodrich, Victoria, and Olfman, Lorne. An Experimental Evaluation
of Task and Methodology Variables for Requirements Definition Phase Success. In Bruce O. Shriver (editor), Proceedings of the Twenty-Third Annual Hawaii International Conference on System
Sciences, 201-209. IEEE Computer Society, January 1990.
Hsia Pei et. al, Formal Approach to Scenario Analysis, IEEE
Software, March 1994.
Holbrook, Capt. Hilliard 111. A Scenario-Based Methodology for
Conducting Requirements Elicitation. ACM SIGSOFT Software Engineering Notes 15(1):95-104, January 1990.
Jokela, Timo, and Lindbergh, Kal. Statecharts Based Requirements Analysis: Deriving User Oriented Models. Microprocessing and Microprogramming 30( 1-5):289-296, August 1990.
Jordan, Pamela W., Seller, Karl S., Tucker, Richard W., and Vogel,
Metodología Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.83
Cenidet Referencias bibliográficas
[Kang 901
[Kean 911
[Leite97]
[Laguna991
[Macaulay 901
[McDermid 891
[Mittermeir 901
David. software Storming: Combining. Rapid Prototyping and .
Knowledge Engineering. IEEE Computer, 39-48, May 1989.
Kang, KYo c., Cohen, Sholom G., Hess, James A., Novak, William E., and Peterson, A. Spencer. Feature-Oriented Domain Analysis
(FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21,
‘ADA235785, Software Engineering Institute, Pittsburgh, PA,
November 1990.
Kean. Elizabeth C. An Informal Approach to Developing an
Environment for Requirements Capture and Refinement. In Proceedings of the Requirements Engineering and Analysis
Workshop Held 3/91.
Leite J.C.S.P., Rossi G.,et al, Enhancing a Requirements Baselíne
with Scenarios, Proceedings of RE 97’: International Symposium
on Requeriments Engineering, IEEE, January 1997.
Laguna, M.A., Marqués, J.M., García, F;J., “A user requirements
elicitation tool”. I V Jornadas de Trabajo. MENHIR, Sedano, 1999.
Macaulay, Linda, Fowler, Chris, Kirby, Mark, and Hutt, Andrew. USTM: A New Approach to Requirements Specification. Interacting
with Computers 2(1):92-118, April 1990.
McDermid, J.A. Requirements Analysis: Problems and the STARTS Approach. I n IEE Colloquium on “Requirements Capture and Specification for Critica¡ Systems” .(Digest No. 138), 4/1-4/4.
Institution of Electrical Engineers, November 1989,
Mittermeir, Roland T., Roussopolus, Nicholas, Yeh, Raymnd T.,
and Ng, Peter A. An Integrated Approach to Requirements Analysis. Modern Software Engineering: Fundations and Current Perspectives. New York: Van Nostrand Reinhold, 119-164, Chapter
. .
Metodología Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.84
Cenidet Referencias bibliográficas
Metodología Para La Captura De Requisitos Ing. Martin G. Marthez Rangel Pag.85
[Potts 911
[Porn951
[Ramesh 911
[Rzepka 891
[Sage 901
[Schouwen 901
[Schubett 891
5, 1990.
porn, Colin., Seven (Plus or Minus Two) Challenges for Requirements Analysis Research. I n Proceedings of the Requirements Engineering and Analysis Workshop Held 3/91
(CMU/SEI-9-1-TR-30). Software Engineering Institute. December
1991.
Potts C., Using Schematic Scenarios to Understand User Needs,
DIS95.
Ramesh, B. & Dhar, V. Representation and Maintenance of
Process Knowledge for Large Scale systems Development. I n
Proceedings of the Sixth Anual Knowledge-Based Software
Engineering Conference, 288-299. Rome Laboratory, Griffis AFB,
NY, September 1991.
Rzepka, William E. A Requirements Engineering Tested: Concept,
Status, and First Results. I n Bruce D. Shriver (editor), Proceedints
of the Twenty-Second Annual Hawaii International Conference on
System Sciences, 339-347. IEEE Computer Society, 1989.
Sage, Andrew P., and Palmer, James D. Software Systems Engineering. New York: John Wiley &Sons, 1990.
Van Schowen, A. John. The A-7 Requirements Model: Re-
Examination Real Time Systems and an Application to Monitoring
Systems. Technical Report 90-276, Queen’s University, May 1990.
Schubert, M.A. Quality Function Deployment: “A Comprehensive Tool for Planning and Development. I n Proceedings of the IEEE
1989 National Aerospace and Electronics Conference NAECON 1989 (Cat. No. 89CH2759-9), 1498-1503. IEEE Dayton Section
Aerospace and Electronic Systems Society, IEEE, New York, May
Referencias bibliográficas Cenidet
[Silva851
[Stair 911
[STEP 911
[Stephens 851
[Thayeer97]
[Va n9 71
[Volere20001
[Winokur 901
1989.
Silva, M., "Las redes de Petri en la automática y la informática",
Madrid, 1985.
Stair, Ralph M. Jr., and LaMothe, Richard S. The Use of Systems
Planning Methodologies. Journal of Computer Information
Systems 318(2):34-37, Winter, 1990-1991.
Software Test & Evaluation Panel (STEP), Requirements Definition
Implementation Team. Operational Requirements for Automated Capabilities, Draft Pamphlet (Draft PAM), April 23, 1991.
Stephens, M., and Whitehead, K. The Analyst-A Workstation for
Analysis and Design. I n Proceedings of the Eight IEEE
International Conference on Software Engineering. IEEE Computer
Society Press, 1985.
Thayeer H. Richard [y] Dorfman Morlin, Software Requirements
Engineering. (segunda edición, IIE, computer Society Press, Los
Alamitos California, 1997).
Van der Aalst, W.M.P., "The application of Petri Nets to Workflow
Managment", Eindhoven University of Technology, Netherland, 1997. URL: wwwis.win.tue.nl/-wsinwa/jcsc/jcsc.html
"Requirements Specification Template". Edition 6.1 James & Suzanne Robertson Principals of the Atlantic Systems Guild.
London, Aachen & New York,2000
Winokur, M., Lavi, J.Z., Lavi, I., and Oz, R. Requirements Analysis and Specification of Embedded Systems Using ESCAM-A Case Study. I n Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering (Cat. No.
90CH2867-0), 80-89. IEEE Computer Society Press, May 1990.
Metodología Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.86
Referencias bibliográficas Cenidet
[Yakernovic901 Yakemovic, K.C. Burgess, and Conklin, E. Jeffrey. Report on a Development Project Use of an Issue-Based Information System.
I n CSCW '90 Proceedings. ACM, October 1990.
[Yu95a] Yu, E. S. K, "Modelling Strategic Relationships for Process ReEngineering", Ph.D. Thesis. Department of Computer Science,
University of Toronto, 1995
Zahniser, Richard A. How to Speed Development with Group Sessions. IEEE Software, 109-110, May 1990.
Zorman L., The Content and Compositkm of Scenarios, OOPSLA Workshop, Requirements Engineering: Use cases and more, 1995.
Zucconi, Lin. Techniques and Experiences Capturing Requirements
for Several Real-Time Applications. ACM SIGSOFT Software
Engineering Notes 14(6):51-55, October 1989.
[Zahniser 901
[Zorman95]
[Zucconi 891
[Fomes 20011 http://sesic.sep.gob.mx/fomes/index. htm
Metodología Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.87
Top Related