NDICE

Ingeniera de Requisitos Software

1. INTRODUCCIN.3 1.1. Conceptos.3 1.2. Roles y Responsabilidades.5 2. DESARROLLO DE REQUISITOS.6 2.1. Obtencin de requisitos7 2.2. Anlisis y negociacin de requisitos...8 2.3. Especificacin de requisitos..10 2.4. Validacin de requisitos.11 2.5 Consideraciones prcticas12 3. GESTIN DE LOS REQUISITOS.13 3.1. Gestin de cambios13 3.1.1 Evaluar el impacto13 3.1.2. Aceptacin del cambio 13 3.1.3. Implementacin del cambio...14 3.2. Trazabilidad..14 4. MEJORES PRCTICAS14 4.1. Mejores prcticas en el desarrollo de requisitos14 4.2. Mejores prcticas en la gestin de requisitos.15 5. ENFOQUE DE ALGUNOS MODELOS16

1.

INTRODUCCIN 2

Ingeniera de Requisitos Software

Los mejores productos, desde el punto de vista del usuario, son aquellos creados por desarrolladores que tienen muy claro lo que se pretende conseguir con el producto y cmo obtenerlo. Para llegar a este punto, se debe entender el trabajo del usuario, cmo afectar el producto a su trabajo y cmo se adecuar a los objetivos de la organizacin. Lo que hace el producto y las condiciones que debe satisfacer en este contexto son los requisitos del producto. Por qu necesitamos requisitos? El coste de una buena obtencin de requisitos y anlisis del sistema a desarrollar es menor comparado con el coste resultante de tener requisitos pobres, es decir, el coste de reparar productos deficientes o de poca calidad, el coste de los proyectos cancelados y el coste de haber perdido la oportunidad de tener el producto correcto en el momento correcto. El fundamento bsico de cualquier software recae sobre su proceso de ingeniera de requisitos. El xito o fallo del software depende casi siempre de cmo de bien se hayan capturado, entendido y usado los requisitos como base para el desarrollo. La ingeniera de requisitos es la fase de la ingeniera del software donde se definen las propiedades y la estructura del software. La ingeniera de requisitos comprende el desarrollo y gestin de requisitos. El desarrollo de requisitos implica entender los requisitos de negocio, identificar los requisitos de usuario y trasladar los requisitos de usuario y de negocio a requisitos de sistema/software. La gestin de requisitos implica gestionar los cambios de requisitos y mantener la consistencia entre los requisitos y otros productos de trabajo del proyecto. 1.1. Conceptos

Qu es la Ingeniera de Requisitos? Es el proceso de comprensin de los requisitos de un sistema software. Es el proceso que cubre todas las actividades envueltas en descubrir, analizar, especificar, y mantener un conjunto de requisitos para un sistema basado en computadoras. La IR implica todas las actividades del ciclo de vida dedicadas a la elicitacin u obtencin (educcin) de los requisitos de usuario, al anlisis y negociacin de requisitos para derivar requisitos adicionales, a la especificacin de los requisitos como documentacin, y a la validacin de los requisitos documentados contra las necesidades de usuario, as como los procesos que apoyan estas actividades. Qu es un requisito? Un requisito es algo que el producto debe hacer o una caracterstica que debe tener. Un requisito existe por el tipo de demanda que tiene el producto o porque el cliente quiere que el requisito sea parte del producto entregado. La tarea de todo analista de requisitos es hablar con la gente, entenderla, escuchar lo que dicen y tambin lo que no dicen, para entender lo que necesitan.

Tipos de requisitos 3

Descripcin

Ingeniera de Requisitos Software

Requisitos de producto Los requisitos de producto son los requisitos del software a desarrollar

Requisitos de proceso Requisitos Funcionales

Los requisitos de proceso son las limitaciones en el proceso de desarrollo Son aquellos que describen las funciones que el sistema debe realizar. Tambin son conocidos como capacidades Son aquellos que actan como limitaciones de la solucin. Tambin son conocidos como requisitos de calidad. Son aquellos que no pueden ser tratados por un solo componente, los cuales su satisfaccin depende de la interoperabilidad de todos los componentes software. Los requisitos deben ser declarados de forma clara y sin ambigedades como sea posible y de forma cuantitativa. Es importante evitar vagar en requisitos no verificables, los cuales dependan de interpretaciones o juicios subjetivos.

Requisitos No Funcionales

Requisitos emergentes

Requisitos cuantificables

Requisitos del sistema

Requisitos del sistema completo. Incluyendo los componentes software, los requisitos software derivados de los requisitos del sistema.

Requisitos software

Requisitos tanto funcionales como no funcionales del producto software a desarrollar.

Ingeniera de Requisitos Software

1.2. Roles y responsabilidades Los roles y responsabilidades que toman parte en el proceso de desarrollo y gestin de los requisitos son los siguientes: Roles: RM Gerente PM Jefe de proyecto SQA Responsable de Aseguramiento de la Calidad del Software CCB Equipo de Control de Configuracin Responsabilidad Preparaci n Identificar los proveedore s de requisitos y las autoridades firmantes Documentar los requisitos de usuario y de negocio Documentar los requisitos de software/ sistema Jefe de Proyecto Revisi n Aprobacin Responsabilida d Jefe de Proyecto Salida

Actividad

Equipo de proyecto

Cliente / Gerente

Cliente /Gerente

Jefe de Proyecto

Requisitos de usuario y de negocio

Equipo de proyecto

Cliente / Gerente

Cliente /Gerente

Jefe de Proyecto

Especificaci n de requisitos software y especificacin de casos de uso Matriz de trazabilidad de requisitos

Preparar y actualizar la matriz de trazabilidad de requisitos Analizar los requisitos

Equipo de proyecto

SQA

Jefe de Proyecto/SQ A

Jefe de Proyecto

Equipo de proyecto/ Jefe de Proyecto 5

Matriz de trazabilidad de requisitos

Ingeniera de Requisitos Software

Verificar y validar los requisitos. Obtener acuerdo

Cliente

Cliente

Jefe de Proyecto

Requisitos de usuario y de negocio, especificacin de requisitos software, especificacin de casos de uso Lnea base de los requisitos de usuario y de negocio, de la especificacin de requisitos software y de la especificacin de casos de uso Registro de peticiones de cambio, matriz de trazabilidad requisitos.

Lnea base de los requisitos

SQA

Jefe de Proyecto

Gestionar cambios a los requisitos

Jefe de Proyecto

SQA

CCB

Jefe de Proyecto

1. DESARROLLO DE REQUISITOS Las principales actividades realizadas durante el proceso de desarrollo de requisitos son las que se muestran en el grfico siguiente:

2.1.

OBTENCIN DE REQUISITOS

Ingeniera de Requisitos Software

La obtencin de requisitos se define como el proceso de identificar las necesidades del negocio, solucionando las posibles disparidades entre las personas involucradas en el mismo, con el propsito de definir y destilar los requisitos para cumplir las restricciones impuestas por las distintas partes. Un buen proceso de obtencin de requisitos soporta el desarrollo de la especificacin de los requisitos, de tal forma que tengan los siguientes atributos:

Deben ser completos, consistentes y han de estar dentro del alcance del proyecto Deben tener un nico identificador Cumplen con los objetivos de los clientes Son viables y apropiados para el desarrollo Los requisitos han de ser testeables (deben tener capacidad de prueba).

TCNICAS DE OBTENCIN DE REQUISITOS Existen mltiples tcnicas que pueden ayudar a la hora de recoger los requisitos de un producto. Tcnicas Entrevistas Descripcin Medios tradicionales de sacar requisitos. Es importante entender las ventajas y limitaciones de las entrevistas y cmo deben ser conducidas. El propsito de stas es intentar alcanzar un efecto aditivo por el que un grupo de gente puede obtener ms penetracin en los requisitos del software que trabajando individualmente. Los ingenieros de software aprenden sobre las tareas del usuario sumergindose en la observacin de cmo los usuarios obran recprocamente con su software. Estas tcnicas son relativamente costosas, pero son instructivas porque ilustran que muchas tareas del usuario y procesos del negocio son demasiado sutiles y complejos para que sus agentes los describan fcilmente. Describen las interacciones entre el usuario y el sistema, centrndose en qu hace el sistema para el usuario, es decir, la totalidad del comportamiento del sistema.

Reuniones

Observacin

Casos de Uso

Ingeniera de Requisitos Software

Prototipos Un prototipo es un borrador de un producto potencial o de una parte del mismo. Es una simulacin de los requisitos. Los prototipos se pueden utilizar cuando los analistas de requisitos no pueden continuar su trabajo porque les faltan datos debido a:

El usuario no ha dado suficientes detalles El producto es tan innovador que nadie conoce realmente sus requisitos

Escenarios

Son una descripcin paso a paso de la funcionalidad de un caso de uso del producto o del negocio, sin demasiado detalle, con el objetivo de hacer entender cmo funciona este caso de uso. Los pasos estn escritos en el lenguaje que utilizan las personas involucradas en el negocio

2.1.

ANALISIS Y NEGOCIACIN DE REQUISITOS

Este asunto se refiere al proceso de analizar requisitos para Detectar y resolver los conflictos entre los requisitos Descubrir los lmites del software y cmo debe obrar recprocamente con su ambiente Elaborar los requisitos del sistema para derivar requisitos software. La vista tradicional del anlisis de requisitos ha sido que est reducida a modelado conceptual utilizando uno de varios mtodos de anlisis tales como Anlisis Estructurados y Tcnicas de Diseo (SADT). Mientras que el modelado conceptual es importante, nosotros incluimos la clasificacin de requisitos para ayudar a informar a compensaciones entre los requisitos (clasificacin de los requisitos) y el proceso de establecer estas compensaciones (negociacin de los requisitos). El cuidado se debe tomar para describir requisitos con exactitud, suficientemente como para permitir que los requisitos sean validados, su implementacin sea verificada, y sus costes estimados.

CLASIFICACION DE LOS REQUISITOS(Anlisis de Requisitos) 8

Ingeniera de Requisitos Software

Tipos de requisitos Requisitos Funcionales Y No funcionales Requisitos derivados o emergentes Descripcin Son las capacidades y los requisitos de calidad Si el requisito est derivado de uno o ms requisitos de alto nivel o una propieda emergente o est impuesto directamente ante el software por un tenedor de apuestas u otro fuente. La prioridad del requisito. Generalmente cuanta ms alta es la prioridad, ms esencial es el requisito para satisfacer las metas finales del software. Algunos requisitos cambiarn durante el ciclo de vida del software, y se igualarn durante el proceso de desarrollo.

Requisitos prioritarios

Requisitos voltiles

MODELADO CONCEPTUAL El desarrollo de modelos de problemas del mundo real son la clave para el anlisis de los requisitos software. El propsito es comprender el problema, en lugar de disear la solucin. Comprenden modelos de entidades del dominio del problema configurados para reflejar las relaciones con el mundo real. ASIGNACIN ARQUITECTONICA DEL DISEO Y DE LOS REQUISITOS Diseo arquitectnico Es el punto en el cual el proceso de requisitos se traslapa con el diseo del sistema o del software, e ilustra de forma clara como es posible separar las dos tareas. LOCALIZACIN DE REQUISITOS Permite el anlisis de requisitos detallado. Una vez que se han identificado los requisitos para un componente, se pueden analizar individualmente los requisitos para descubrir requisitos adicionales, a dems de saber cmo los componentes deben interactuar con otros componentes para satisfacer los requisitos localizados NEGOCIACIN DE LOS REQUISITOS Se relaciona con la resolucin de problemas ocasionados por los requisitos estipulados por dos stakeholders y que poseen caractersticas mutuamente incompatibles, ya sea entre requisitos o recursos.

Ingeniera de Requisitos Software

2.1.

ESPECIFICACIN DE REQUISITOS

Se refiere tpicamente a la produccin de un documento, o a su equivalente electrnico, que puede estar sistemticamente repasado, evaluado, y aprobado. Para los sistemas complejos, particularmente sos que implican componentes no-software, se elaboran tres tipos de documentos: definicin de sistema, sistema requisitos, y requisitos del software. Para sistemas simples, solamente el tercero de stos es requerido. Documento de definicin del sistema Este documento registra todos los requisitos del sistema. Est definido en alto nivel desde la perspectiva del dominio. Incluye una lista de requisitos del sistema, su entorno objetivo y las declaraciones de las limitaciones, supuestos, y requisitos no funcionales. Podra incluir diseos de modelos conceptuales para ilustrar el contexto del sistema, uso de escenarios, y las principales entidades del dominio as como el flujo de trabajo. Especificacin de los requisitos del sistema Son todas las descripciones relacionadas la combinacin de elementos que interactan para cumplir un objetivo definido, los cuales incluyen hardware, software, firmware, personas, informacin, tcnicas, servicios y otros elementos de soporte Especificacin de los requisitos software Establecen las bases para los acuerdos entre los clientes y proveedores sobre el producto software a desarrollar as como lo que no se espera hacer. Permite una evaluacin rigurosa de los requisitos antes de que se inicie el diseo. Est escrito en lenguaje natural, aunque podra utilizarse descripciones formales o semi-formales Buenas prcticas Los requisitos son escritos de una forma tecnolgicamente neutra, es decir, especifican lo que el producto hace y no qu tecnologa se usar para crearlo. Su especificacin no debe ser ambigua. Eliminar todos los pronombres de la especificacin de requisitos, sustituyndolos por los sujetos. Tener cuidado con adjetivos y adverbios ya que pueden llevar a confusiones. Se debe evitar usar palabras que lleven a confusin al escribir los requisitos, como debera, ya que da a entender que el requisito es opcional. Al escribir los requisitos una buena tcnica es leerlos en alto. Y si es posible pedir a alguien que los lea. Confirmar que los involucrados en el negocio tienen el mismo entendimiento acerca de los requisitos que la persona que los escribe. Utilizar una convencin de nombres y definiciones comn dentro de la organizacin. De esta forma se aseguran que en todos los proyectos se est usando el mismo vocabulario.

10

Ingeniera de Requisitos Software

2.1.
VALIDACIN DE REQUISITOS

En esta fase, el usuario final aade criterios de aceptacin para cada requisito. Adems, apoya el hecho de que los requisitos han de ser correctos antes de que sean entregados a los diseadores y desarrolladores. La puerta de calidad es un punto por el que pasan cada uno de los requisitos antes de formar parte de la especificacin. Una de las tareas de las puertas de calidad es asegurarse de que cada requisito cumple con el criterio que tiene asignado. Este criterio es una medida del requisito que le hace entendible y con capacidad para ser probado. Otra razn por la que el proyecto tiene puertas de calidad es para prevenir posibles fugas de requisitos. Los requisitos, algunas veces, aparecen en las especificaciones sin que nadie realmente sepa de donde vienen o qu valor aaden al producto. Asegurndose de que la nica forma de que los requisitos entren a formar parte de las especificaciones sea a travs de las puertas de calidad, el equipo del proyecto tiene un total control de los requisitos. MEDIOS DE VALIDACIN Nombre Revisiones de los requisitos Descripcin Asignan un grupo de revisores en un escrito para buscar errores, asunciones confundidas, la carencia de la claridad, y la desviacin de la costumbre. La composicin del grupo que conduce la revisin es importante. Prototipar es comnmente el medio para validar la interpretacin del ingeniero del software de los requisitos del software, as como para sacar nuevo requisitos. La ventaja de usar prototipos es que pueden hacer ms fcil la interpretacin de las asunciones del ingeniero del software dan la explicacin til de porqu son incorrectas. Validacin de modelos Es tpicamente necesario validar la calidad de los modelos desarrollados durante el anlisis. Una caracterstica esencial de un RS es que debe ser posible validar que el producto final lo satisface. Una tarea es por lo tanto planear cmo verificar cada requisito. En la mayora de los casos, el diseo de pruebas de aceptacin hace esto. Identificar y disear pruebas de aceptacin pueden ser difcil para los 11

Prototipados

Pruebas de Aceptacin

Ingeniera de Requisitos Software

requisitos no funcionales. Para ser validados, deben ser analizados al punto donde pueden ser expresados cuantitativamente. 2.2. CONSIDERACIONES PRCTICAS Descripcin Los requisitos iteran tpicamente hacia un nivel de calidad y detallan que es suficiente permitir las decisiones del diseo y de la consecucin que se harn. En algunos proyectos, esto puede dar lugar a requisitos antes de que todas sus caractersticas se entiendan completamente. Esto arriesga a una reanudacin costosa si los problemas emergen tarde en el proceso de la ingeniera del software. Sin embargo, los ingenieros del software son obligados necesariamente por planes de la gerencia de proyecto y deben por lo tanto tomar medidas para asegurarse de que la calidad de los requisitos es tan alta como sea posible dado los recursos disponibles. Cambiar a Gestin La gestin del cambio es central en el anlisis de requisitos. Este asunto describe el papel de la gestin del cambio, los procedimientos que necesitan estar preparados, y el anlisis que se debe aplicar a los cambios propuestos. Los requisitos deben consistir no slo una especificacin de qu se requiere, sino tambin de la informacin ancilar que las ayudas manejan e interpretan los requisitos. Esto debe incluir varias dimensiones de la clasificacin del requisito y el mtodo de la verificacin o el plan de prueba de aceptacin. Puede tambin incluir la informacin adicional tal como un resumen-anlisis razonado para cada requisito, la fuente de cada requisito, y una historia del cambio. Los requisitos ms 12

Nombre Naturaleza iterativa del proceso de los requisitos

Cualidades de los requisitos

Ingeniera de Requisitos Software

importantes atribuyen un identificador que permite requisitos identificados inequvocamente. El remontar de los requisitos El remontar de los requisitos se refiere a la fuente recuperacin de requisitos y de predecir los efectos de esos requisitos. El trazado es fundamental para el anlisis de la ejecucin del impacto cuando los requisitos cambian. Un requisito debe ser detectable al revs a requisitos y los stakeholders que lo motivaron.

Requisitos que miden

Como cuestin prctica, es tpicamente til tener cierto concepto del volumen de los requisitos para un producto de software particular. Este punto es til evaluando el tamao de un cambio en requisitos, en estimar el coste de una tarea del desarrollo o del mantenimiento, o simplemente para el uso como el denominador en otra medida. La medida funcional del tamao (FSM) es una tcnica para evaluar el tamao de un cuerpo de requisitos funcionales.

3. GESTIN DE LOS REQUISITOS La gestin de requisitos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Es decir, la gestin de requisitos consiste en gestionar los cambios de los requisitos, las relaciones entre ellos, las dependencias entre la especificacin de requisitos y otros documentos producidos por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los requisitos y el sistema construido. Por lo tanto, los objetivos principales del proceso de gestin de requisitos sern: Gestionar la recogida de requisitos Obtener la aprobacin de los participantes del proyecto Gestionar los cambios (trazabilidad)

La gestin de requisitos es un proceso que se desarrolla a lo largo de toda la vida del producto. 2.1. GESTIN DE CAMBIOS Los requisitos cambian durante todo el ciclo de vida de desarrollo del producto como se vio en apartados anteriores. Los cambios deben controlarse y documentarse, es decir, hay que convivir con ellos y por ello la gestin de cambios es esencial para tratar dichos cambios. 13

Ingeniera de Requisitos Software

Cuando, durante el proyecto y una vez aceptada la lnea base de requisitos, se solicita un cambio sobre esta lnea base, estos cambios no se pueden aceptar sin ms ya que podran afectar al desarrollo de todo el sistema, o alguna parte esencial del mismo. Podemos destacar tres importantes actividades dentro del proceso de gestin de cambios: 2.1.1. Evaluar el impacto La primera tarea a realizar tras recibir una peticin de cambio es valorar el impacto del mismo. Para ello se deber ir recorriendo todo el rbol de requisitos viendo como les afecta el cambio, y aqu es donde entra la trazabilidad de los requisitos. 2.1.2. Aceptacin del cambio Una vez analizado el impacto del cambio, se debe tomar una decisin. Si se acepta el cambio, tras negociarlo con el cliente, se continuar con la actividad de implementar el cambio. En caso contrario, se deber negociar con el cliente el siguiente paso a realizar. 2.1.3. Implementacin del cambio Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que resulten afectados por dicho cambio (si el cambio es mnimo algunos productos como el plan del proyecto, puede que no sea necesario modificar). Adems se deber generar un nuevo punto de partida (lnea base) de requisitos. 2.2. Trazabilidad Un concepto clave en el proceso de gestin de cambios es la Trazabilidad. Los requisitos deben ser trazables, es decir, rastreables. Se podra decir que un requisito es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requisito. Todos los requisitos deberan ser trazables para mantener consistencia entre los distintos documentos de un proyecto. Es importante conocer aspectos de los requisitos tales como:

Su origen (Quin los propuso) Necesidad (Por qu existe) Relacin con otros requisitos (Dependencias) Relacin con otros elementos (Dependencias)

El uso de matrices de trazabilidad es una buena tcnica para llevar a cabo esta actividad de forma eficiente. En la matriz se irn registrando los requisitos de negocio. Por cada requisito de negocio se identificarn los requisitos de usuario correspondientes. De cada requisito de usuario se identificarn cuales son los requisitos de sistema asociados a cada uno de ellos, y as sucesivamente se ir rellenando toda la matriz de requisitos. 2. MEJORES PRCTICAS En el desarrollo de software, una mejor prctica es un mtodo bien definido que contribuye a una implementacin exitosa del proyecto software. Las organizaciones crean mejores prcticas para que les ayuden a resolver problemas pudiendo disminuir la tasa de fallo de sus proyectos. 4.1. MEJORES PRCTICAS EN EL DESARROLLO DE REQUISITOS A continuacin se describen una serie de mejores prcticas orientadas al desarrollo de requisitos: 14

Ingeniera de Requisitos Software

4.1. Documentar el alcance y visin del proyecto: esto permitir tener un mejor entendimiento de los requisitos y asegurar que todas las personas involucradas en el proyecto trabajen hacia la misma meta. Mantener un glosario del proyecto: facilitar una comunicacin efectiva asegurando un entendimiento unnime. Uso de tcnicas de obtencin de requisitos de usuario: para facilitar esta tarea. Involucrar a toda la gente implicada: asegura una validacin temprana del entendimiento de los requisitos. Desarrollo incremental de requisitos: puede minimizar la cantidad de re-trabajo del proyecto. Captura de requisitos usando casos de uso: ser ms fcil gestionar los requisitos y hacer un seguimiento de los mismos. Validar requisitos: para mejorar el xito de los proyectos es crtico que se validen los requisitos de forma adecuada. Verificar requisitos: para asegurar que los requisitos proporcionan una base adecuada para llevar a cabo el diseo, la construccin y las pruebas. MEJORES PRCTICAS EN LA GESTIN DE REQUISITOS

A continuacin se muestran una serie de mejores prcticas relacionadas con la gestin de requisitos:

Priorizar requisitos: para determinar aquellos que se deberan cumplir en la primera versin o producto y aquellos que pueden llevarse a cabo en sucesivas versiones. Establecer lneas base de los requisitos: para asegurar que cualquier modificacin en los requisitos que cambie la lnea base se trata como cambios de alcance. Comunicacin abierta: para asegurar que la informacin relacionada con los requisitos se comunica de forma consistente. Una comunicacin abierta tambin implica comunicar a la gente correcta y al conjunto mnimo de personas. Gestin de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva y eficiente. Uso de herramientas para la gestin de requisitos: para facilitar la gestin de requisitos. Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito. Establecer un plan de mejora de procesos para la ingeniera de requisitos: para cumplir con las necesidades actuales y futuras de forma ms eficiente y con mayor calidad. Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tienen el conocimiento, entre otros aspectos, de cmo escribir buenos requisitos, etc.

15

Ingeniera de Requisitos Software

4. ENFOQUE DE ALGUNOS MODELOS Tanto la gestin como el desarrollo de requisitos son procesos contemplados por los principales modelos de mejora de procesos orientados al desarrollo de software. CMMI y SPICE son modelos de mejora de procesos que describen los procesos que una organizacin debe ejecutar para la adquisicin, desarrollo y mantenimiento de productos y servicios software. Ambos modelos contemplan, entre sus reas de proceso, la gestin y desarrollo de requisitos. Para implementar correctamente esta rea, ambos modelos proponen una serie de prcticas a seguir. Segn CMMI, el propsito de la gestin de requisitos es gestionar los requisitos de los productos del proyecto y de sus componentes e identificar las inconsistencias entre requisitos, planes del proyecto y productos de trabajo. Las prcticas que propone para llevarlo a cabo son: Obtener un entendimiento de requisitos Obtener un compromiso con los requisitos Gestionar los cambios de los requisitos Mantener una trazabilidad bidireccional de los requisitos Identificar inconsistencias entre los requisitos y los productos de trabajo del proyecto.

CMMI tambin contempla el desarrollo de requisitos. Su propsito en aqu es producir y analizar requisitos de usuario, de producto, y de los componentes de producto. Las metas que habra que cumplir para satisfacer esta rea de proceso son: Desarrollar los requisitos de cliente Desarrollar los requisitos de producto Analizar y validar los requisitos

Por otra parte, los procesos del modelo SPICE que contemplan las actividades de desarrollo y gestin de requisitos son: Recogida de requisitos: recoger, procesar y registrar las necesidades y requisitos cambiantes del cliente a lo largo de la vida del producto y/o servicio para establecer una lnea base de los requisitos que sirva de base para definir los productos de trabajo necesarios. Anlisis de requisitos del sistema: para transformar los requisitos definidos por el cliente en un conjunto de requisitos tcnicos deseados que guiarn el diseo del sistema. Anlisis de requisitos del software: para establecer los requisitos de los elementos software del sistema. 16

Ingeniera de Requisitos Software

17