INGENIERÍA DE REQUERIMIENTOS El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de soft softwa ware re es llam llamad adoo Inge Ingeni nier ería ía de Requ Requer erim imie ient ntos os.. La meta meta de la inge ingeni nier ería ía de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. Ingenie Ingeniería ría de Requeri Requerimie miento ntoss es la I!"I#L I!"I#LI$% I$% para desarrol desarrollar lar una especif especificac icación ión completa, consistente y no am&igua, la cual servir' como &ase para acuerdos comunes entre todas las partes involucradas y en dónde se descri&en las ()$"I*$E! que realizar' el sistema. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. •
Los requerimientos funcionales definen las funciones que el sistema ser' capaz de realizar. escri&en las transformaciones que el sistema realiza so&re las entradas
•
para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento +en tiempo y espacio, interfaces de usuario, fia&ilidad +ro&ustez del sistema, disponi&ilidad de equipo, mantenimiento, seguridad, porta&ilidad, est'ndares, etc.
CARACTERÍSTICAS DE LOS REQUERIMIENTOS Las características de un requerimiento son sus propiedades principales. )n conjunto de requerimientos en estado de madurez, de&en presentar una serie de características tanto individualmente como en grupo. % continuación se presentan las m's importantes. •
•
•
Necesario )n requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y adem's su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso )n requerimiento es conciso si es f'cil de leer y entender. !u redacción de&e ser simple y clara para aquellos que vayan a consultarlo en un futuro. Com!leto )n requerimiento est' completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
•
•
•
Consistente )n requerimiento es consistente si no es contradictorio con otro requerimiento. No am"i#uo )n requerimiento no es am&iguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no de&e causar confusiones al lector. $erifica"le )n requerimiento es verifica&le cuando puede ser cuantificado de manera que permita -acer uso de los siguientes mtodos de verificación/ inspección, an'lisis, demostración o prue&as.
IM%ORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS Los principales &eneficios que se o&tienen de la Ingeniería de Requerimientos son/ •
•
•
•
•
•
#ermite gestionar las necesidades del proyecto en forma estructurada/ "ada actividad de la IR consiste de una serie de pasos organizados y &ien definidos. 0ejora la capacidad de predecir cronogramas de proyectos, así como sus resultados/ La IR proporciona un punto de partida para controles su&secuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. isminuye los costos y retrasos del proyecto/ 0uc-os estudios -an demostrado que reparar errores por un mal desarrollo no descu&ierto a tiempo, es sumamente caro1 especialmente aquellas decisiones tomadas durante la RE. 0ejora la calidad del software/ La calidad en el software tiene que ver con cumplir un conjunto de requerimientos +funcionalidad, facilidad de uso, confia&ilidad, desempe2o, etc.. 0ejora la comunicación entre equipos/ La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. !i este consenso no ocurre, el proyecto no ser' e3itoso. Evita rec-azos de usuarios finales/ La ingeniería de requerimientos o&liga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del pro&lema, por lo que se le involucra durante todo el desarrollo del proyecto.
%ROCESO DE AN&LISIS DE REQUERIMIENTOS El proceso del esta&lecimiento de requerimientos de un sistema de software, como ya mencionamos, es el primer paso esencial en entregar lo que el cliente desea. % pesar de esto, la insuficiencia de tiempo y esfuerzo son a menudo encontrado en esta actividad y e3isten pocos mtodos sistem'ticos para soportarlo. Entre los mtodos conocidos se puede citar a los siguientes/ #ara #ressman, en el proceso de an'lisis de requerimientos del software se puede identificar cinco tareas o etapas fundamentales/
'( Reconocimiento )el !ro"lema !e de&en de estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del conte3to del sistema. El analista de&e esta&lecer un canal adecuado de comunicación con el equipo de tra&ajo involucrado en el proyecto. En esta etapa la función primordial del analista en todo momento es reconocer los elementos del pro&lema tal y como los perci&e el usuario.
*( E+aluaci,n - s.ntesis En esta etapa el analista de&e centrarse en el flujo y estructura de la información, definir las funciones del software, determinar los factores que afectan el desarrollo de nuestro sistema, esta&lecer las características de la interfaz del sistema y descu&rir las restricciones del dise2o. 4odas las tareas anteriores conducen f'cilmente a la determinación del pro&lema de forma sintetizada.
/( Mo)eli0aci,n urante la evaluación y síntesis de la solución, se crean modelos del sistema que servir'n al analista para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo servir' de pilar para el dise2o del software y como &ase para la creación de una especificación del software.
1( Es!ecificaci,n Las tareas asociadas con la especificación intenta proporcionar una representación del software. Esto m's adelante permitir' llegar a determinar si se -a llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales.
2( Re+isi,n )na vez que se -an descrito la información &'sica, se especifican los criterios de validación que -an de servir para demostrar que se -a llegado a un &uen entendimiento de la forma de implementar con 3ito el software. La documentación del an'lisis de requerimientos y manuales, permitir'n una revisión por parte del cliente, la cual posi&lemente traer' consigo modificaciones en las funciones del sistema por lo que de&er'n revisarse el plan de desarrollo y las estimaciones previstas inicialmente.
M3TODO CORE El mtodo "ontrolled Requirements E3pression +"*RE 5$orris6 es un conjunto de notaciones te3tuales y gr'ficas, con guías especificadas para la captura y validación de requerimientos del sistema, en las etapas iniciales del dise2o del sistema. "*RE -a sido,
por tradición, pensado como puramente una tcnica de captura y an'lisis de requerimientos +R"%, aunque soporta algunos aspectos de dise2o tales como estructuras de datos. "*RE est' &asada en el principio de primero definir el pro&lema a ser analizado +definición del pro&lema, y luego dividirlo en unidades o puntos de vista a considerar. El mtodo "*RE consiste en siete etapas. "ada una produce salidas que alimentan a la etapa su&secuente como entrada o que forman parte de la especificación de requerimientos final. "*RE pretende e3aminar el sistema y su am&iente en un n7mero de niveles, con detalles m's finos progresivamente en cada nivel. Las siete etapas se presentan a continuación/
'( Definici,n )el !ro"lema( El propósito de la definición del pro&lema es identificar los límites del mismo. "ontiene detalles de los o&jetivos de la empresa de los usuarios del sistema, la &ase para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y quin va a ser el responsa&le de la revisión y aceptación de los resultados finales.
*( Estructuraci,n )el !unto )e +ista( El propósito de esta etapa es descomponer el am&iente del sistema en los elementos para que el sistema propuesto pueda ser analizado desde los puntos de vista de todas las entidades que se comunican con l, la m's importante de las cuales son los usuarios. urante esta etapa, todas las entidades que son fuentes potenciales de información de&en ser identificadas.
/( Colecci,n ta"ular( Esta etapa es cuando la información so&re los flujos de datos entre los puntos de vista y el procesamiento de stos son reunidos. Esto ayuda a esta&lecer la totalidad y consistencia.
1( Estructuraci,n )e )atos( En la etapa previa, los elementos de información que pasan entre los puntos de vista son referidos por sus nom&res generales. En esta etapa, se da una vista m's cercana al contenido, a la estructura y a la derivación de datos, al producir diagramas de estructura de datos.
2( Mo)elaci,n in)i+i)ual )e !untos )e +ista( Esta etapa puede dividirse en dos partes. Lo 7nico concerniente a la primera es convertir las 4"(8! en una notación diferente para producir los diagramas individuales del modelo de punto de vista. La segunda parte se refiere a agregar alguna información nueva perteneciente a flujos de datos internos, control de acciones y tiempo de acciones.
4( Mo)elaci,n com"ina)a )e !unto )e +ista( Esta etapa facilita el an'lisis de una secuencia de eventos de m's de un punto de vista. "ada diagrama de modelo com&inado de punto de vista producido durante esta etapa es una representación del procesamiento de información que ocurre entre puntos de vista.
5( An6lisis )e restricciones( En esta etapa, se consideran restricciones adicionales tales como desempe2o y seguridad. 9stas pueden afectar los diagramas de puntos de vista ya producidos. Las restricciones se documentan en una especificación de restricción del sistema.
)$I:ER!I% $%"I*$%L E #I)R%
(%")L4% E I$;E$IERI% I$)!4RI%L
E!")EL% #R*(E!I*$%L E I$;E$IERI% I$(*R0%4I"%
4<4)L*/
I$;E$IERI% E RE=)ERI0IE$4*! %L)0$*/ "arrasco 4alledo, Eric> (a&i'n
*"E$4E/ Ing. Lizana #uellas
#I)R%, ?@AB
