PIR

Procesos de la Ingeniería de Requerimientos
 Introducción

Este presente trabajo está referido a la especificación de los procesos de la ingeniería y sus respectivos requerimientos, dando a entender el significado de cada uno de sus derivados los cuales involucran el estudio de la viabilidad, obtención y análisis, especificación de requerimientos, etc.

ESTUDIO DE VIABILIDAD O FACTIBILIDAD

Es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de como este pretende contribuir a los procesos del negocio o organización.

Para todos los sistemas nuevos, el proceso de Ingeniería de Requerimientos empieza con un estudio de viabilidad  que consiste con:

Entrada:  descripción resumida del sistema y cómo se utilizará dentro de una organización.

Salida:  un informe que recomienda si es conveniente llevar a cabo la Ingeniería de Requerimientos  y el proceso de desarrollo de un sistema.

Un estudio de factibilidad o viabilidad es corto y orientado y se lleva a cabo resolviendo ciertas interrogantes principales  como:

1. ¿El sistema contribuye a los objetivos generales de la organización? ya sean Mejoras económicas, políticas o sociales

2. ¿El sistema se puede implementar utilizando la tecnología actual y con las restricciones de costo y tiempo?

3. ¿El sistema puede integrarse a otros que existen en la organización?

para poder resolver las interrogantes se requieren de fases que serían:

Recolección de información: se puede llevar a cabo por medio de las fuentes de información que pueden incluir ya sea a los

Administradores de departamentos

Expertos en tecnología

Usuarios finales del sistema

Evaluación de la Información:  identifica la información requerida para contestar a las preguntas anteriores.

En la evaluación se cuestionan las fuentes de información para descubrir las respuestas a las preguntas.

¿Cómo se las arreglará la organización si no se lleva a cabo este sistema?

¿Cuáles son los problemas con los procesos actuales y cómo ayudaría el nuevo sistema a resolverlos?

¿Cuál es la contribución directa que hará el sistema a los objetivos del negocio?

¿La información se puede obtener y transferir a otros sistemas de la organización?

¿El sistema requiere de tecnología que no se ha utilizado previamente en la organización? ¿A qué debe ayudar el sistema y a que necesita ayudar?

Cuando la información está terminada se prepara el Informe del Estudio de Factibilidad que contendrá:

Recomendación de cuándo debe continuar el desarrollo del sistema.

Propuesta de cambios en el alcance y el presupuesto.

Calendarización del sistema.

Sugerencias sobre requerimientos adicionales de alto nivel.

OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS

En este proceso los ingenieros de software trabajan con los clientes y los usuarios finales para poder determinar el dominio de la aplicación, ver los servicios que la aplicación proporcionará, los requerimientos necesarios para el funcionamiento correcto de la aplicación, las restricciones que tendrá el hardware. Para lo cual requiere ser creativos para determinar lo que los clientes requieren lo cual conlleva a revisar la situación.

• Entrevistar al cliente para comprender los requisitos que quiere.
• La realización de un video sobre como podria funcionaria el nuevo sistema.

La obtencion y analisis de requerimiento puede afectar a varias personas de la empresa. EL término Stakeholder es usado para referirse a una persona o ya sea un grupo de personas que será afectado por el sistema ya sea directa o indirectamente. Aunque cabe mencionar que obtener y comprender los requerimientos que los stakeholder, ya que a menudo no conocen lo que desean obtener del sistema informático exceptuando en términos muy generales ya que estos pueden hacer demandas irreales o resultarles difícil expresar lo que quieren que haga el sistema.


La obtención de los requerimientos, es donde obtenemos la información sobre el sistema que el cliente haya propuesto, durante esta fase se incluyen la documentación, y las especificaciones que cumplira el sistema. Las tecnicas de obtencion de requerimientos son varias pero las más conocidas son: entrevistas, escenarios, prototipos y etnografias.

ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE (ERS) (SRS)

Es un documento donde se especifican los términos acordados por usuario y desarrollador al momento de construir un programa. en este se especifican los requerimientos funcionales de la misma, así como como también los no funcionales

REQUERIMIENTOS FUNCIONALES

son todos los requisitos que se enfocan en especificar las funciones esenciales del programa, tales como botones de acceso, almacenamiento, opciones de recuperación, rutas de salida.

REQUERIMIENTOS NO FUNCIONALES.

son todos aquellos que no interfieren directamente con la funcionalidad del programa más bien se enfocan en los estándares bajo los cuales se construyó el programa.

CARACTERÍSTICAS DE UN BUEN (SRS)

segun el estandar IEEE 830-1998, un buen srs debe contar con las siguientes características para garantizar su entendimiento para ambas partes involucradas en el desarrollo de programa, (cliente y desarrollador)

1)CORRECTO. un SRS se considera correcto solo si cada requisito acordado en el documento es verificable en el programa.

2)INEQUÍVOCO. cada requisito declarado en el documento debe tener una sola interpretación para ambas partes, para ello se deben utilizar términos únicos al describir el programa.

para evitar que un término tenga interpretaciones distintas se debe incluir un glosario y esta misma debe ser en el idioma natural de ambas partes.

3)COMPLETO. para considerarse completo un SRS debe incluir los elementos siguientes

  a) todos los requisitos deben estar relacionados a la funcionalidad, el diseño, las características y las interfaces externas, y todas las restricciones también deben ser incluidas.

   b)debe describir las reacciones del programa a las distintas entradas y las contestaciones o las respuestas de la misma a las entradas validas e invalidas.

   c)debe definir las etiquetas, figuras, tablas y diagramas contenidos en el programa. asi como también definir todas las unidades de medida y condiciones.

nota: si un SRS utiliza el término "to be determined" (TBD) no se considera completo.

si un requerimiento aun no es definido, se debe especificar las condiciones que pueden provocar el requerimiento cambie o los pasos a seguir para eliminarla. para que esta pueda considerarse resuelta .

4) CONSISTENTE, un SRS se considera consistente solo si es compatible con cualquier otro documento de nivel superior. en el caso de existir conflictivas con algún requerimiento de sistema, el SRS ya no se considera consistente..

un ejemplo de inconsistencia es que un controlador de batería indique que cuando la batería está llena la luz es verde pero en otros sistemas puede ser azul.

5) DELINEAR QUE TIENE IMPORTANCIA Y/O ESTABILIDAD. Un SRS debe contar con un identificador para indicar cuando un requisito es importante o estable siendo bien específicos en grado de estabilidad y necesidad. como y cuando un elemento es esencial, condicional y optativo.

6) COMPROBABLE, para que un SRS se considere comprobable, deben utilizarse términos finitos e indicar con exactitud la ejecución de un proceso, para que una máquina o un humano pueda medir exactamente en cuanto tiempo o cuantas veces se realizara un proceso.

términos como "trabaja bien, interface humana buena, o normalmente pasara", se consideran procesos no verificables por lo tanto se debe evitar su uso en un SRS.

7) MODIFICABLE. un SRS debe tener una estructura que garantice un cambio a los requisitos sin alterar el diseño original.

para facilitar la modificación de requisitos se debe evitar que el mismo aparezca en más de una vez en el documento.

cada requisito debe tratarse por separado y no mezclarlo con otros requisitos.

8) IDENTIFICABLE. Cada requisito en un SRS debe ser claro y se le debe incluir una referencia para facilitar su documentación en procesos futuros. Existen dos tipos de identificabilidad.

 a) identificable hacia atrás, esto quiere decir que un requisito debe ser fácil de encontrar en las fases anteriores de desarrollo.

 b) identificable delantero, cada requisito debe contar con un numero de indentificacion para poder determinar si puede resultar afectado durante un proceso de mantenimiento o modificación y asi tener un dato exacto de que requisitos se alteraron y cuales permanecen intactas.

                  

PARTES DE UN SRS.

1 INTRODUCCIÓN.

  esta es una apreciación global de contenido del documento, en esta parte se pueden incluir;

  - El propósito del programa

  - El alcance.

  - Definiciones, siglas y abreviaciones

  - Referencias.

2. DESCRIPCIÓN GLOBAL. En esta parte se mencionan todos los detalles de las funciones del programa tales como:

   - Perspectiva del programa

   - Funciones

   - Características del usuario

   - Restricciones

   - Atención y dependencias.

3. REQUISITOS ESPECIFICOS. esta el la parte más importante del SRS ya que esta debe ser lo suficientemente clara y explicita para garantizar que tanto desarrollador, usuario, auditor y todas las partes involucradas puedan entenderlo de la misma forma.

a) se deben especificar todos los requisitos de acuerdo con todas la características descritas.

b) cada requisito específico debe tener una referencia para garantizar su compatibilidad con cualquier otro documento de mayor validez o mas actualizado.

c) ningún requisito puede ser identificado igual a otro, cada un debe ser identificado individualmente.

d) todos lo requisitos deben estar organizados de manera que  no sean complicado encontrarlos.

VALIDACIÓN DE REQUERIMIENTOS

Es la actividad de la IR que tiene como objetivo comprobar que los requerimientos (funcionales y no funcionales) definidos en el sistema son los correctos es decir, los  que realmente quiere el cliente y ésta solo se puede hacer con la activa participación del cliente/usuario.

Para el logro de la comprobación, estos deben de ser:

• Consistentes: No deben de haber contradicciones entre unos requisitos y otros.
• Completos: Deben de estar todos los requisitos.
• Realistas: Se pueden implementar con tecnología actual.
• Verificables: Tiene que existir alguna forma de comprobar que cada requisito se cumple.

En este punto es necesario recordar que las SRS(Especificaciones de requerimientos de software) debe de estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad(IEEE 830_1998).

Revisión de los requerimientos:  (informales ó formales)

Es un proceso manual que involucra a distintas personas. Ellos verifican el documento de requerimientos en cuanto anomalías y omisiones.

Informales

• Los desarrolladores deben tratar los requerimientos con tantos stakeholders(usuarios) como sea posible.

Formales

• El equipo de desarrollo debe conducir al cliente/usuario, explicándole las implicaciones de cada requerimiento.
• Antes de cada revisión formal es conveniente realizar una revisión informal.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar.

En la validación de requerimientos pueden surgir cambios en los requerimientos que impliquen que se realizen nuevamente las actividades de obtención y especificación de requerimientos.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos.

• Evaluación = verificación de propiedades de cada requerimiento.
• Validación = revisión de cumplimiento de las SRS.

Es suficiente validar después del desarrollo del software?

Según estadísticas, no.  La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollo aún así,     validar en la fase de SRS puede ayudar a evitar costosas correcciones después del desarrollo.

Gestión de requerimientos

La Gestión de Requisitos es un componente vital en el desarrollo de un proyecto software ya que es una de las actividades de la Ingeniería de Requisitos más importantes. Los requisitos se inician cuando empieza un proyecto en las etapas de análisis y especificación de requisitos, posteriormente, dichos requisitos en el ciclo de vida de un proyecto pueden ser modificados por lo que se establece el concepto de Gestión de Requisitos, que es el tratamiento y control de las actualizaciones y cambios a los mismos. Debido a que un proyecto informático es susceptible de cambios, habría que proceder a su actualización o a la incorporación de nuevas funcionalidades o eliminar otras, esto obliga a mantener controlado y documentado el producto. Los cambios de requisitos deben ser gestionados para asegurar que la calidad de los mismos se mantenga, los problemas suscitados por los cambios de requisitos podrían incurrir en altos costos, siendo el requisito factor crítico de riesgo.

Más formalmente el Manejo de Requisitos es una forma sistemática de descubrir, organizar y documentar los requisitos del sistema. Además es el proceso que establece y mantiene un consenso entre el cliente y el grupo del proyecto en el cambio de los requisitos del sistema.

El término Gestión de Requisitos incluye:

Técnicas para Descubrimiento/Recogida de Requisitos

Recoger las peticiones del usuario y determinar las verdaderas necesidades de éste.

Técnicas de Análisis

Especificación y verificación

Manejo de Requisitos

Tareas principales de la Gestión de Requisitos:

Durante el proceso de la gestión de requisitos, hay que planear algunas actividades, dentro de las que se pueden mencionar las siguientes: la identificación de los requisitos, en proceso de gestión de los cambios, las políticas de trazabilidad, la cantidad de información sobre las relaciones entre los requerimientos que se mantiene, entre otras.

Actividades y su descripción:

Recolección: Recolección y documentación de requisitos es una actividad de comunicación iterativa entre clientes, gerentes y practicantes, para descubrir, definir, refinar y registrar una representación precisa de los requisitos del producto. Varios métodos son utilizados para la recolección de requisitos. Algunos análisis iniciales como es la agrupación, categorización, priorización son desarrollados durante esta actividad.

Documentación: Después que los requisitos han sido recolectados, hay que analizarlos a detalle y documentarlos en una especificación de requisitos. El resultado de la especificación de requisitos y de cualquier especificación de requisitos de componentes hardware/software derivado sirve como registro de convenio con el cliente y compromiso con el proveedor. Estas especificaciones son rastreadas utilizando una matriz de trazabilidad de requerimientos y son sujetos a verificación y gestión de cambio a través del ciclo de vida del producto.

Verificación: Una vez que la especificación de requisitos ha sido desarrollada, los requisitos son verificados. La verificación de requisitos es un proceso para asegurar que la especificación de requisito del producto es una representación exacta de las necesidades del cliente. Este proceso también asegura que los requisitos sean trazados y verificados a través de varias fases del ciclo de vida; particularmente en el diseño, implementación y pruebas. Además, todos estos requerimientos deben ser trazados al diseño, implementación y pruebas para asegurarse que los requerimientos han sido satisfechos.

Gestión de Cambios: Gestión de cambios es un proceso formal para identificar, evaluar, trazar y reportar cambios propuestos y aprobados a la especificación del producto. Como el proyecto va evolucionando, los requerimientos pueden cambiar o expandirse para ajustar algunas modificaciones en el alcance o diseño del proyecto. Un proceso de gestión de cambios proporciona un rastreo completo y preciso de todos los cambios que son pertinentes al proyecto. El proceso del ciclo de vida de la Gestión de Requisitos, debe ser flexible y adaptable para reunir las necesidades del proyecto. Las características del alcance e implementación del proceso del ciclo de vida de la Gestión de Requisitos en un proyecto, variará dependiendo de algunos factores claves.

Tamaño y complejidad del proyecto

Experiencia del personal del proyecto

Experiencia de los clientes del proyecto

Dominio de la aplicación

El propósito y uso de esta aplicación

El conjunto de pautas de esta área se fundamentan en las actividades que forman parte del Procedimiento para la gestión de requisitos del proceso general de Ingeniería de Requisitos.

Las Herramientas de Gestión de Requerimientos

El uso de herramientas de la gestión de requisitos es alentador para mejorar tanto la productividad como la calidad en el desarrollo de un proyecto software. Existen varias herramientas tanto hechas en casa como en el mercado que auxilian a las tareas de gestión.

Rational RequisitePro, es una herramienta centrada en documentos, que almacena los requisitos asociándolos a documentos (aunque también permite guardarlos directamente en la base de datos), mientras que las otras herramientas están orientadas a requisitos.

Se auxilia especialmente en el control de cambio de requisitos, con trazabilidad para especificaciones de software y pruebas. La herramienta permite el uso de Oracle sobre Unix o Windows y también soporta SQL Server sobre Windows. Beneficios de RequisitePro

Permite el trabajo en equipo por medio de un repositorio compartido de información.

Permite la clasificación de requerimientos, en base a las necesidades de cada empresa.

Define atributos para todos los tipos de requerimientos especificados.

Ayuda a manipular el alcance del proyecto mediante la asignación de prioridad de desarrollo a cada uno de los requerimientos planteados.

Permite características avanzadas de rastreo, por medio de matrices, que permiten visualizar las dependencias entre requerimientos dentro de un proyecto o en diferentes proyectos.

Administración de cambios mediante el rastreo y la visualización histórica de los cambios efectuados al requerimiento, cuándo y quién los realizó.

Interactúa con los demás productos Rational para el ciclo de vida, así como con herramientas de Microsoft Office.

Ayuda a determinar en forma automatizada cuántos requerimientos tienen el proyecto.

Ayuda a determinar responsables y actores en cada uno de los requerimientos.

RequisitePro, permite organizar los requerimientos, establecer y mantener relaciones padre/hijo entre ellos.

El uso de una herramienta de gestión de requisitos proporciona al proyecto:

Ahorro en costes de especificación y de desarrollo minimizando el impacto de errores.

Mejora la calidad mediante un adecuado análisis y gestión de los requisitos.

Reduce las no-conformidades del sistema.

Permite controlar la especificación.

Permite administrar más fácilmente la especificación.

Ayuda a cumplir con estándares de calidad.

Permite centralizar toda la información del problema.

Proporciona una trazabilidad completa de la especificación, etc.

Otras Herramientas de la Gestión de Requisitos en el Mercado:

Las herramientas seleccionadas proporcionan casi todas las necesidades básicas exigibles. Además, estas herramientas están ampliamente difundidas y son muy reconocidas. Todas las herramientas asumen que la estructura de los requisitos es jerárquica, de forma que un requisito puede estar formado o tener asociados otros requisitos de nivel inferior, y la mayoría permite extraer párrafos de ficheros generados por procesadores de texto comerciales y convertirlos en requisitos. Otras de las características comunes a la mayor parte de las herramientas es la posibilidad de realizar consultas sobre los requisitos en función de determinados valores de sus atributos. Estas herramientas son: IRqA 3.0, CaliberRM y DOORS IRqA 3.0 es una herramienta de ingeniería de requisitos especialmente diseñada para soportar el proceso completo de ingeniería de requisitos. En IRqA el ciclo de especificación completo incluye la captura de requisitos, análisis, especificación de sistema, validación y la organización de requisitos es soportada por modelos estándares.

CaliberRM es para sistemas grandes y complejos y proporciona una base de datos de requisitos con trazabilidad. Se ve a los requisitos como parte del proceso al igual de gestión de la calidad del software, las pruebas (testing) y el trazado de defectos (defect tracking). Caliber está basado en internet y maneja referencia de documentos, responsabilidad de usuario, trazabilidad, prioridad y estado entre otras características.

DOORS a diferencia del resto de las herramientas, considera los requisitos como objetos y  documentos como módulos. Tiene una orientación basada en objetos, frente a RequisitePro y Caliber-RM, que manejan solamente requisitos y sus atributos. Es una herramienta para organizaciones grandes que necesitan controlar complejos conjuntos de usuarios y requisitos de sistemas con una completa trazabilidad. Proporciona buena visualización de tales documentos como jerárquicas, y su lenguaje de extensión permite una gran variedad de soporte de herramientas a ser construidas.

Conclusión

Para asegurar que  el proceso de la ingeniería de requerimientos esté bien estructurada, es importante realizar varios bocetos preliminares al documento final, y también es importante tomar en cuenta cada posible cambio a futuro.