REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DE EDUCACIN SUPERIOR INSTITUTO UNIVERSITARIO POLITCNICO SANTIAGO MARIO ESCUELA INGENIERIA DE SISTEMAS

INGENIERIA DE REQUERIMIENTOS

Asesora: Ing. Germaina Briceo

Autor: Medina, Csar C.I. 17.241.328

Sistamas II Seccin V Nocturno

Maturn, Noviembre de 2011

1. Ingeniera de requerimientos: conceptos y caractersticas

La Ingeniera de Requerimientos (IR) cumple un papel primordial en el proceso de produccin de software, ya que se enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestin de requerimientos en el desarrollo de sistemas. los

La ingeniera de requerimientos sirve como una base slida en el proceso de desarrollo de software, por lo que antes de pasar a tratar los aspectos referentes a la administracin adecuada de los requerimientos, es importante primero definir lo que es un requerimiento y cuales seran las caractersticas deseables que deberan de tener. 2. Qu son Requerimientos?

Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo que es un Requerimiento:

Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62).

Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (Std 610.12-1900, IEEE: 62).

Tambin, Ian Sommerville presenta una definicin acerca de lo que es un Requerimiento:

Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108).

Analizando las definiciones anteriores, un requerimiento es una descripcin de una condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso. 3. Tipos de Requerimientos

Los requerimientos de software pueden dividirse en 2 categoras: requerimientos funcionales y requerimientos no funcionales.

Los requerimientos funcionales son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben hacer esas trans formaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema.

Por otra parte los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad,

estndares, entre otros.

4. Caractersticas de un Requerimiento

Es importante no perder de vista que un requerimiento debe ser:

 Especificado por escrito: Como todo contrato o acuerdo entre dos partes.  Posible de probar o verificar: Si un requerimiento no se puede comprobar, entonces cmo se sabe si se cumpli con l o no?

 Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

 Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin.

 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector.

5. Dificultades para definir los requerimientos.

Durante la etapa de especificacin de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir, a continuacin se presenta un listado con los problemas ms comunes en este proceso:

 Los requerimientos no son obvios y vienen de muchas fuentes.  Son difciles de expresar en palabras (el lenguaje es ambiguo).  La cantidad de requerimientos en un proyecto puede ser difcil de manejar.  Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.  El usuario no puede explicar lo que hace.  Tiende a recordar lo excepcional y olvidar lo rutinario.  Hablan de lo que no funciona.  Los usuarios tienen distinto vocabulario que los desarrolladores.  Usan el mismo trmino con distinto significado.

6. Ingeniera de requerimientos.

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniera de requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa.

Algunos otros conceptos de ingeniera de requerimientos son:

Ingeniera de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a

comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. (Pressman, 2006: 155).

La ingeniera de requerimientos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. (Sommerville, 2005: 82).

En sntesis, el proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente. 7. Importancia de la ingeniera de requerimientos.

Segn la autora Lizka Johany Herrera en su documento de la ingeniera de requerimientos, los principales beneficios que se obtienen de la Ingeniera de Requerimientos son (2003: 3):

 Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

 Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y

recursos necesarios.

 Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.

 Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.).

 Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso.

 Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. 8. Actividades de la ingeniera de requerimientos.

Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro actividades bsicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificacin y administracin adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades son: extraccin, anlisis, especificacin y validacin, y sern explicadas a continuacin cada una de ellas.

8.1. 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 analistas de requerimientos 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, entre otros. Es importante, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del cliente. 8.2.Anlisis.

Sobre la base de la extraccin realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema

identificados hasta el momento. Usualmente se hace un anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa 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. 8.3.Especificacin.

En esta fase se documentan los requerimientos acordados con el cliente, en un

nivel apropiado de detalle. En la prctica, esta etapa se va realizando conjuntamente con el anlisis, se puede decir que la especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML (Lenguaje de Modelado Unificado), que es un estndar para el modelado orientado a objetos, por lo que los casos de uso y la obtencin de requerimientos basada en casos de uso se utiliza cada vez ms para la obtencin de requerimientos.

8.4.Validacin.

La validacin es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, 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.

Se puede apreciar que el proceso de ingeniera de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificacin de requerimientos, que es el documento final, de carcter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso nico que sea vlido de aplicar en todas las organizaciones. Cada organizacin debe desarrollar su propio proceso de acuerdo al 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. Hay muchas maneras de organizar el proceso de ingeniera de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva ms objetiva que las personas involucradas en el proceso.

9. Tcnicas utilizadas en las actividades de Ingeniera de requerimientos. 9.1.Entrevistas y Cuestionarios.

Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo comn, los encuestados son usuarios de los sistemas existentes o

usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l. El xito de esta tcnica, depende de la habilidad del entrevistador y de su preparacin para la misma. 9.2.Sistemas existentes.

Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de informacin que se maneja y cmo es manejada, por otro lado tambin es til analizar las distintas salidas que los sistemas producen (listados, consultas, entre otros), porque siempre pueden surgir nuevas ideas sobre la base de estas. 9.3.Lluvia de ideas (Brainstorm).

Este es un modelo que se usa para generar ideas. La intencin en su aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intencin de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irn eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", entre otros.

Las reglas bsicas a seguir son:

 Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtencin de una cantidad mayor de ideas creativas.

 Conviene suspender el juicio crtico y se debe permitir la evolucin de cada

una de las ideas, porque sino se crea un ambiente hostil que no alienta la generacin de ideas.

 Por ms locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente til.

 A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.

 Escribir las ideas sin censura.

9.4.Prototipos.

Durante la actividad de extraccin de requerimientos, puede ocurrir que algunos requerimientos no estn demasiado claros o que no se est muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiendo conseguir una importante retroalimentacin en cuanto a si el sistema diseado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se renen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un diseo rpido. El diseo rpido se centra en una representacin de aquellos aspectos del

software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo. 9.5.Casos de Uso.

Los casos de uso son una tcnica para especificar el comportamiento de un sistema. El sitio en Internet wikipedia.org, define a un caso de uso como:

Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/o otros sistemas (http://es.wikipedia.org/wiki/Caso_de_uso).

Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor, es una descripcin de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayora de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Segn el autor Sommerville, los casos de uso son una tcnica que se basa en escenarios para la obtencin de requerimientos. Actualmente, se han convertido en una caracterstica fundamental de la notacin UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos. 10. Herramientas automatizadas para la Administracin de Requerimientos.

En el desarrollo de software se cuenta con una ventaja proporcionada por las herramientas CASE. Las herramientas CASE (Ingeniera del Software Asistida por Computadora) se le conoce a todo aquel software que es usado para ayudar a las actividades del proceso de desarrollo del software, en donde se ubica la ingeniera de

requerimientos. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificacin de requisitos.

Existen muchas y muy variadas herramientas CASE que pueden ser utilizadas por los desarrolladores de software en sus proyectos, y de la forma ms conveniente para ellos. Si es importante hacer ver que estas herramientas fungen como un medio facilitador para agilizar y mejorar los procesos involucrados en todo el ciclo de vida presentado por la IR , y que en conjunto ayudan a la construccin final de un producto de software terminado. Estas herramientas permiten entre otras cosas tener un mayor control en proyectos complejos, reducir costos y retrasos en los proyectos, ayudan a determinar la complejidad y los esfuerzos necesarios.