INSTITUTO TECNOLGICO SUPERIOR DE TEPOSCOLULA.

A S I G N A T U R A:
PLANIFICACIN Y MODELADO.

TRABAJO: RESUMEN DE INGENIERA DE REQUERIMIENTOS

PROFESOR: LIC. MARCO ANTONIO RUIZ VICENTE.

ALUMNA: GABRIELA MONTESINOS AVENDAO.

SEMESTRE: VII ING. EN SISTEMAS COMPUTACIONALES.

AGOSTO 2012

INTRODUCCIN
Por qu importan los requerimientos? La tarea ms importante que el ingeniero de software hace para el cliente es la extraccin iterativa y el refinamiento de los requerimientos del producto. Los requerimientos se deben descubrir antes de empezar a construir un producto, y puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. Si no se tienen los requerimientos correctos, no se puede disear o construir el producto correcto y, por lo tanto, el producto no permitir a los usuarios finales realizar su trabajo. Los requerimientos se pueden dividir en requerimientos funcionales los cuales definen qu hace el sistema (describen todas las entradas y salidas), es decir, las funciones del sistema, y los no-funcionales que definen los atributos que le indican al sistema cmo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cmo, cundo y cunto del qu. Qu es la Ingeniera de Requerimientos (IR)? La IR se define como un "conjunto de actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto determinado, en las cuales, utilizando tcnicas y herramientas, se

analiza un problema y se concluye con la especificacin de una solucin (a veces ms de una). El uso del trmino "ingeniera" implica que se deben utilizar tcnicas sistemticas y repetibles para asegurar que los requerimientos del sistema estn completos y sean consistentes y relevantes. Las actividades del proceso incluyen la extraccin de requerimientos, el anlisis, la negociacin y la validacin aunque no existe un proceso nico que sea vlido de aplicar en todas las organizaciones, cada organizacin debe tomar en cuenta: el tipo de producto que se est desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniera de requerimientos.

1.- Modelo de proceso de IR Los modelos son abstracciones simplificadas y estandarizadas de actividades repetitivas, generalmente producidos desde un punto de vista determinado, por lo que pueden existir diferentes modelos para un mismo proceso. Sin embargo, en el caso del proceso de IR y desde una perspectiva "intelectual", podemos decir que todos esos diversos modelos parten de una misma base, un modelo "madre" que llamaremos "modelo-abstracto". Este modelo nos brinda una vista preliminar del proceso, una secuenciacin aproximada y general de las actividades que luego deberemos realizar. A continuacin, presentamos el siguiente ejemplo, en donde cada uno de los compartimientos cubre una seccin particular del proceso.

Las diversas necesidades de las diferentes organizaciones comienzan a surgir a partir de la aplicacin de modelos ms detallados. As, tenemos dos modelos bsicos que permiten estudiar el proceso de IR y del cual se derivan numerosas variantes que dependern del caso de estudio en cuestin. a.- Modelo tradicional en cascada Este modelo sugiere que los resultados de una tarea del proceso llevan a la siguiente, y as sucesivamente. En el ejemplo presentado, la extraccin lleva al anlisis, el anlisis desencadena la documentacin, y la documentacin inicia la validacin.

Sin embargo, debemos tener en cuenta que la realidad del proceso de IR es mucho ms compleja que lo que se muestra a partir del modelo en cascada: no existen fases claramente delimitadas ya que hay una retroalimentacin constante entre las distintas etapas; los requerimientos del sistema van cambiando por circunstancias ajenas al proceso durante el desarrollo del mismo; se descubren problemas durante la validacin que llevan a un cambio de requerimientos, etc.; y todo esto har que ms de una vez tengamos que volver "hacia atrs" en el proceso de IR. b.- Modelo en espiral Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentacin entre etapas y la repeticin de tareas, es el llamado Modelo en Espiral.

En este diagrama, el uso de la espiral implica que las diferentes actividades de la ingeniera de requerimientos son repetidas hasta que se toma la decisin final, que es la aceptacin del documento de especificacin de requerimientos. En conclusin dado el escenario de trabajo es ms vlida la aplicacin del modelo en espiral para desarrollar el proceso de IR, puesto que este modelo representa de manera ms real cmo se irn desarrollando las actividades del proceso, pues si se desconoce del tema, se genera un grado demasiado alto de incertidumbre que slo puede disminuirse al repetir el ciclo de trabajo una y otra vez, permitiendo as ajustar todos los parmetros, cada vez en mayor detalle, hasta lograr un resultado satisfactorio.

2.- Actividades de la Ingeniera de Requerimientos Usualmente podemos dividir las prcticas de la IR en 4 actividades, a saber: a.- Extraccin b.- Anlisis c.- Especificacin d.- Validacin Como toda divisin de tareas, no es una estricta representacin de la realidad, sino que se hace con el fin de sistematizar la realizacin de la IR. En general la delimitacin entre una actividad y la otra no es tan clara, ya que estn sumamente interrelacionadas, existiendo un alto grado de iteracin y retroalimentacin entre una y otra. a.- Extraccin Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aqu, los AN deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. En definitiva, descubrir los requerimientos del sistema no slo implica preguntar a las personas qu quieren: es un proceso delicado que involucra comprender a profundidad cmo es que este sistema interactuar afectar a las partes del negocio que estarn involucradas y cmo puede contribuir a lograr las metas de la empresa; finalmente, comprender las necesidades y restricciones de los usuarios del sistema, en particular, se deben entender los procesos de trabajo que se supone que el sistema apoyar y el rol de cualquier otro sistema que actualmente se involucre en dichos procesos. Es importante, entonces, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del cliente y de cuan bien asista a la automatizacin del trabajo. b.- Anlisis Usualmente se hace un anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; aqu se leen los requerimientos, se conceptan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los

problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos. Debemos destacar que no es posible convertir el anlisis en un proceso estructurado y sistemtico, lo que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la experiencia del AN. c.- Especificacin En la prctica, esta etapa se va realizando conjuntamente con el anlisis, pero podramos decir que la Especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML. d.- Validacin La validacin es la etapa final de la IR. Su objetivo es verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estn completos. La validacin representa un punto de control interno porque se debe verificar internamente lo que se est haciendo y externo, porque se debe validar con el cliente. Esta etapa puede confundirse con la de anlisis, pero la diferencia es clara: mientras que en el anlisis se trabaja sobre el boceto del documento de requerimientos, en la validacin se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados".