Especificación de Requisitos de Software - Historial de revisiones

Rodolfo.jc.baire.scu en 19:17 25 abr 2012

2012-04-25T19:17:55Z

Arletisjcconsolacion en 20:43 2 nov 2011

2011-11-02T20:43:58Z

Jaruco1 jc: /* Características que debe poseer la ERS */

2011-11-01T19:58:32Z

‎Características que debe poseer la ERS

Jaruco1 jc: Página creada con '{{Definición |nombre=Especificación de Requisitos de Software |imagen= |tamaño= |concepto=La Especificación de Requisitos de Software (ERS) es una “colección estructurada...'

2011-11-01T19:46:43Z

Página creada con '{{Definición |nombre=Especificación de Requisitos de Software |imagen= |tamaño= |concepto=La Especificación de Requisitos de Software (ERS) es una “colección estructurada...'

Página nueva

{{Definición
|nombre=Especificación de Requisitos de Software
|imagen=
|tamaño=
|concepto=La Especificación de Requisitos de Software (ERS) es una “colección estructurada de información, que contiene los requisitos del sistema”. (IEEE '98)
}}
==El contexto de la ERS==
La ERS está dirigida a dos audiencias, que a su vez, brindan una retroalimentación al proceso de elaboración de esta. Pero hay un tercer factor que influye en el proceso: el ambiente; el cual puede imponer restricciones de mercado, culturales, físicas, técnicas, entre otras. (IEEE '98a)
===Interesados===
Los interesados son el elemento más importante en el contexto de la ERS. La meta del proceso de software es desarrollar un sistema que satisfaga sus necesidades y expectativas. (IEEE '98a; JACOBSON y otros. '04). Los [[analistas]], quienes forman parte de la Comunidad Técnica, obtienen de los interesados los requisitos del sistema y con ellos construyen de manera iterativa la ERS. La ERS es validada por los interesados a través de una representación de esta en un lenguaje que sea fácilmente comprensible por ellos. Los elementos resultantes de estas validaciones constituyen una retroalimentación para el desarrollo de la ERS.
===Ambiente===
El ambiente en el cual se desarrolla la ERS impone restricciones y reglas a los requisitos e influye sobre ellos. Según el Estándar [[1223]]-[[1998]] ([[IEEE]] '98a) las influencias del ambiente pueden clasificarse en los siguientes grupos que se solapan: políticas, de mercado, estándares y regulaciones técnicas, culturales, organizacionales y físicas. Estas restricciones, reglas de negocio e influencias deben ser registradas en la ERS.
===Comunidad Técnica===
La Comunidad Técnica es la encargada de construir el software que necesitan los interesados, por tanto, deberá desarrollar el diseño, implementación, prueba, integración y mantenimiento del sistema. Mientras se desarrollan estas actividades la Comunidad Técnica propondrá cambios, eliminaciones en la ERS y nuevos requisitos, retroalimentando así el desarrollo de esta. Por ello, es recomendable involucrar tempranamente a la Comunidad Técnica en la elaboración de la ERS.
==Características que debe poseer la ERS==
Una ERS debe ser, según la norma IEEE 830 – 1998 (IEEE '98b):
*Correcta. La ERS es correcta sí, y sólo sí, contiene todos los requisitos que el software debe satisfacer. No hay una herramienta o procedimiento que garantice esta característica, sin embargo, limitarse a obtener de una vez lo que “quiere” el cliente pone en riesgo el logro de esta característica. Realizar un proceso iterativo, donde se involucren los interesados, seguir la traza de los requisitos y validarlos con los interesados contribuyen a lograr una ERS correcta. (LEISHMAN y COOK '02)
*No ambigua. La ERS es no ambigua sí, y sólo sí, cada requisito tiene una única interpretación. Para elaborar una ERS no ambigua es necesario mantener y documentar un acuerdo entre el equipo de desarrollo y los interesados respecto a los requisitos. Cuando se usa el lenguaje natural para documentar los requisitos pueden introducirse ambigüedades, sin embargo, este es fácilmente comprendido por los interesados, a diferencia de los lenguajes formales, que requieren conocimientos específicos pero permiten reducir la ambigüedad.
*Completa. La ERS es completa sí, y sólo sí, incluye los siguientes elementos:
Todos los requisitos funcionales y no funcionales son conocidos y documentados en la ERS.
Están definidas todas las responsabilidades del sistema respecto a los datos de entrada, tanto válidos como no válidos y respecto a los datos de salida.
En los documentos de la ERS todas las figuras, tablas, diagramas y definiciones de términos están nombrados y referenciados.

Desarrollar de forma iterativa la ERS de software, validarla y usar múltiples representaciones contribuyen a lograr la completitud. (LEISHMAN y COOK '02; PRESSMAN '05)
*Consistente. La ERS es consistente sí, y sólo sí, ningún subconjunto de la misma entra en contradicción con otro subconjunto (IEEE '98a). Las revisiones técnicas y el uso de diferentes representaciones para los requisitos contribuyen a identificar inconsistencias.
*Clasificada por importancia. La ERS cumple con esta característica si cada requisito puede ser identificado de manera única y tiene un atributo que indica su importancia desde el punto de vista de los interesados. Todos los requisitos no son igualmente importantes, algunos son críticos para el sistema y otros son deseables, conocer estos atributos es útil para planificar las iteraciones.
*Comprobable. La ERS es comprobable sí, y sólo sí, se puede comprobar por una persona o máquina mediante un procedimiento finito y cuya relación costo-beneficio sea aceptable que cada requisito está en el sistema desarrollado.
*Modificable. La ERS es modificable sí, y sólo sí, puede ser modificada fácilmente manteniendo la completitud y consistencia. Mantener la traza de los requisitos, organizarlos adecuadamente y usar referencias cruzadas contribuye a hacerla modificable.
*Posible de rastrear. La ERS es posible de rastrear si está claro el origen de cada requisito y es posible determinar los elementos relacionados en etapas posteriores del desarrollo.
==Prácticas recomendadas para desarrollar la ERS==
*Comprender el contexto del sistema. El software debe añadir valor al negocio que está automatizando, para lograrlo es necesario que el equipo de desarrollo comprenda el negocio y que los requisitos del sistema se correspondan con los procesos, metas y reglas del negocio.
*Comprender el problema. Antes de buscar una solución es necesario llegar a un acuerdo en el problema que será resuelto, identificar los interesados en la solución, definir los límites e identificar las restricciones impuestas al sistema.
*Evaluación y síntesis de la solución. Una vez obtenido un acuerdo en cuanto al problema a resolver los analistas e interesados evalúan y proponen una solución, centrándose en el qué y no en el cómo.
*Verificación y validación. El costo de encontrar y corregir los errores se incrementa en la medida en que el proyecto se adentra en nuevas fases del desarrollo, por ello es importante verificar y validar los requisitos tempranamente. Esto puede hacerse mediante revisiones formales, sesiones de validación con los clientes, prototipos y entregas a corto plazo de pequeñas partes funcionales del software.
*Documentar los requisitos. ¿Qué y cuánta documentación generar durante la Ingeniería de Requisitos? La respuesta a la interrogante anterior recibirá variadas respuestas de acuerdo a la metodología de desarrollo. Sin embargo, la mayoría coinciden en que es necesario documentar los requisitos del software: RUP propone hacerlo mediante la Especificación de Requisitos de Software, las Especificaciones Suplementarias y el Modelo de Casos de Uso; XP sugiere el empleo de Historias de Usuario; Crystal indica utilizar un Archivo de requisitos y Desarrollo Manejado Por Rasgos (Feature Driven Development-FDD) plantea documentar los requisitos como Rasgos, que son similares a las Historias de Usuario. El Modelado Ágil, es un complemento a las metodologías ágiles para facilitar el modelado y documentación efectiva de sistemas de software, uno de sus principios es sólo desarrollar los artefactos que sean necesarios para el proyecto, con lo cual coinciden otros autores que indican que cada proyecto adecue los procesos de desarrollo y artefactos a sus necesidades. (HURTADO y BASTARRICA '05; JACOBS '04; ORANTES '07)
*Priorizar los requisitos. Es necesario definir qué requisitos serán incluidos en cada iteración del desarrollo, para ello se deben priorizar los requisitos a partir de criterios que cada equipo de proyecto tendrá que definir, la importancia para los interesados, como se señaló anteriormente, no debe omitirse.
*Exigir que los interesados se involucren. Para que los interesados queden satisfechos con el producto final es necesario que sean parte activa del equipo, fundamentalmente durante la modelación del negocio y la captura de requisitos; las metodologías ágiles sugieren que haya un cliente o representante de este junto al equipo de desarrollo durante todo el ciclo de vida del proyecto.(HURTADO y BASTARRICA '05) (ORANTES '07)
*Obtener los requisitos de forma iterativa. Cuando se inicia la captura de requisitos muchos aspectos del sistema en construcción no están claros, según avanza la definición de la solución el conocimiento sobre los requisitos se enriquece, aparecen nuevos requisitos y se clarifican detalles sobre los ya existentes. Obtenerlos en iteraciones sucesivas permite registrar esta nueva información. (ADOLPH y BRAMBLE '01) (COCKBURN '00)
*Controlar los cambios a los requisitos. El mundo está en constante evolución, los negocios, la economía, la política y la sociedad están cambiando continuamente y suponer que los requisitos no van a cambiar durante el desarrollo de software no es realista. Lo importante es estar preparados para asumir los cambios mediante un proceso de gestión de cambios que garantice la completitud y consistencia de la ERS.
*Mantener la traza de cada requisito. Para evitar el riesgo de implementar “requisitos inútiles” debe conocerse el origen de cada requisito y con el objetivo de evaluar el impacto de los cambios cada requisito debe seguirse hacia los elementos relacionados.
*Mantener un glosario de términos. Debe mantenerse entre el equipo de desarrollo de software y los interesados en el proyecto un entendimiento común sobre los requisitos, cuando se utiliza el lenguaje natural para documentar los requisitos pueden introducirse ambigüedades; mantener un glosario de términos contribuye a mejorar el entendimiento.
==Fuente==
*http://ucipedia.uci.cu 1 de noviembre del 2011
*Elaborado por la Ing. Dunia Pineda Medina
[[Category:Ingeniería_de_software]]

@@ Línea 1: / Línea 1: @@
-{{normalizar}}{{Definición
+{{Definición
 |nombre=Especificación de Requisitos de Software
-|imagen=
+|imagen=especificacion_de_requisitos_de_software.jpeg
 |tamaño=
-|concepto=La Especificación de Requisitos de Software (ERS) es una “colección estructurada de información, que contiene los requisitos del sistema”. (IEEE '98)
+|concepto=La Especificación de Requisitos de [[Software]] (ERS) es una “colección estructurada de información, que contiene los requisitos del sistema”. (IEEE '98)
 }}
 ==El contexto de la ERS==
@@ Línea 12: / Línea 12: @@
 El ambiente en el cual se desarrolla la ERS impone restricciones y reglas a los requisitos e influye sobre ellos. Según el Estándar [[1223]]-[[1998]] ([[IEEE]] '98a) las influencias del ambiente pueden clasificarse en los siguientes grupos que se solapan: políticas, de mercado, estándares y regulaciones técnicas, culturales, organizacionales y físicas. Estas restricciones, reglas de negocio e influencias deben ser registradas en la ERS.
 ===Comunidad Técnica===
-La Comunidad Técnica es la encargada de construir el software que necesitan los interesados, por tanto, deberá desarrollar el diseño, implementación, prueba, integración y mantenimiento del sistema. Mientras se desarrollan estas actividades la Comunidad Técnica propondrá cambios, eliminaciones en la ERS y nuevos requisitos, retroalimentando así el desarrollo de esta. Por ello, es recomendable involucrar tempranamente a la Comunidad Técnica en la elaboración de la ERS.
+La Comunidad Técnica es la encargada de construir el [[Software]] que necesitan los interesados, por tanto, deberá desarrollar el diseño, implementación, prueba, integración y mantenimiento del sistema. Mientras se desarrollan estas actividades la Comunidad Técnica propondrá cambios, eliminaciones en la ERS y nuevos requisitos, retroalimentando así el desarrollo de esta. Por ello, es recomendable involucrar tempranamente a la Comunidad Técnica en la elaboración de la ERS.
 ==Características que debe poseer la ERS==
 Una ERS debe ser, según la norma IEEE 830 – 1998 (IEEE '98b):
-*Correcta. La ERS es correcta sí, y sólo sí, contiene todos los requisitos que el software debe satisfacer. No hay una herramienta o procedimiento que garantice esta característica, sin embargo, limitarse a obtener de una vez lo que “quiere” el cliente pone en riesgo el logro de esta característica. Realizar un proceso iterativo, donde se involucren los interesados, seguir la traza de los requisitos y validarlos con los interesados contribuyen a lograr una ERS correcta. (LEISHMAN y COOK '02)
+*Correcta. La ERS es correcta sí, y sólo sí, contiene todos los requisitos que el [[Software]] debe satisfacer. No hay una herramienta o procedimiento que garantice esta característica, sin embargo, limitarse a obtener de una vez lo que “quiere” el cliente pone en riesgo el logro de esta característica. Realizar un proceso iterativo, donde se involucren los interesados, seguir la traza de los requisitos y validarlos con los interesados contribuyen a lograr una ERS correcta. (LEISHMAN y COOK '02)
 *No ambigua. La ERS es no ambigua sí, y sólo sí, cada requisito tiene una única interpretación. Para elaborar una ERS no ambigua es necesario mantener y documentar un acuerdo entre el equipo de desarrollo y los interesados respecto a los requisitos. Cuando se usa el lenguaje natural para documentar los requisitos pueden introducirse ambigüedades, sin embargo, este es fácilmente comprendido por los interesados, a diferencia de los lenguajes formales, que requieren conocimientos específicos pero permiten reducir la ambigüedad.
 *Completa. La ERS es completa sí, y sólo sí, incluye los siguientes elementos: Todos los requisitos funcionales y no funcionales son conocidos y documentados en la ERS.
@@ Línea 21: / Línea 21: @@
 En los documentos de la ERS todas las figuras, tablas, diagramas y definiciones de términos están nombrados y referenciados.
-Desarrollar de forma iterativa la ERS de software, validarla y usar múltiples representaciones contribuyen a lograr la completitud. (LEISHMAN y COOK '02; PRESSMAN '05)
+Desarrollar de forma iterativa la ERS de [[Software]], validarla y usar múltiples representaciones contribuyen a lograr la completitud. (LEISHMAN y COOK '02; PRESSMAN '05)
 *Consistente. La ERS es consistente sí, y sólo sí, ningún subconjunto de la misma entra en contradicción con otro subconjunto (IEEE '98a). Las revisiones técnicas y el uso de diferentes representaciones para los requisitos contribuyen a identificar inconsistencias.
 *Clasificada por importancia. La ERS cumple con esta característica si cada requisito puede ser identificado de manera única y tiene un atributo que indica su importancia desde el punto de vista de los interesados. Todos los requisitos no son igualmente importantes, algunos son críticos para el sistema y otros son deseables, conocer estos atributos es útil para planificar las iteraciones.
@@ Línea 29: / Línea 29: @@
 ==Prácticas recomendadas para desarrollar la ERS==
-*Comprender el contexto del sistema. El software debe añadir valor al negocio que está automatizando, para lograrlo es necesario que el equipo de desarrollo comprenda el negocio y que los requisitos del sistema se correspondan con los procesos, metas y reglas del negocio.
+*Comprender el contexto del sistema. El [[Software]] debe añadir valor al negocio que está automatizando, para lograrlo es necesario que el equipo de desarrollo comprenda el negocio y que los requisitos del sistema se correspondan con los procesos, metas y reglas del negocio.
 *Comprender el problema. Antes de buscar una solución es necesario llegar a un acuerdo en el problema que será resuelto, identificar los interesados en la solución, definir los límites e identificar las restricciones impuestas al sistema.
 *Evaluación y síntesis de la solución. Una vez obtenido un acuerdo en cuanto al problema a resolver los analistas e interesados evalúan y proponen una solución, centrándose en el qué y no en el cómo.
-*Verificación y validación. El costo de encontrar y corregir los errores se incrementa en la medida en que el proyecto se adentra en nuevas fases del desarrollo, por ello es importante verificar y validar los requisitos tempranamente. Esto puede hacerse mediante revisiones formales, sesiones de validación con los clientes, prototipos y entregas a corto plazo de pequeñas partes funcionales del software.
+*Verificación y validación. El costo de encontrar y corregir los errores se incrementa en la medida en que el proyecto se adentra en nuevas fases del desarrollo, por ello es importante verificar y validar los requisitos tempranamente. Esto puede hacerse mediante revisiones formales, sesiones de validación con los clientes, prototipos y entregas a corto plazo de pequeñas partes funcionales del [[Software]].
-*Documentar los requisitos. ¿Qué y cuánta documentación generar durante la Ingeniería de Requisitos? La respuesta a la interrogante anterior recibirá variadas respuestas de acuerdo a la metodología de desarrollo. Sin embargo, la mayoría coinciden en que es necesario documentar los requisitos del software: RUP propone hacerlo mediante la Especificación de Requisitos de Software, las Especificaciones Suplementarias y el Modelo de Casos de Uso; XP sugiere el empleo de Historias de Usuario; Crystal indica utilizar un Archivo de requisitos y Desarrollo Manejado Por Rasgos (Feature Driven Development-FDD) plantea documentar los requisitos como Rasgos, que son similares a las Historias de Usuario. El Modelado Ágil, es un complemento a las metodologías ágiles para facilitar el modelado y documentación efectiva de sistemas de software, uno de sus principios es sólo desarrollar los artefactos que sean necesarios para el proyecto, con lo cual coinciden otros autores que indican que cada proyecto adecue los procesos de desarrollo y artefactos a sus necesidades. (HURTADO y BASTARRICA '05; JACOBS '04; ORANTES '07)
+*Documentar los requisitos. ¿Qué y cuánta documentación generar durante la Ingeniería de Requisitos? La respuesta a la interrogante anterior recibirá variadas respuestas de acuerdo a la metodología de desarrollo. Sin embargo, la mayoría coinciden en que es necesario documentar los requisitos del [[Software]]: [[RUP]] propone hacerlo mediante la Especificación de Requisitos de [[Softwar]]e, las Especificaciones Suplementarias y el Modelo de Casos de Uso; XP sugiere el empleo de Historias de Usuario; Crystal indica utilizar un Archivo de requisitos y Desarrollo Manejado Por Rasgos (Feature Driven Development-FDD) plantea documentar los requisitos como Rasgos, que son similares a las Historias de Usuario. El Modelado Ágil, es un complemento a las metodologías ágiles para facilitar el modelado y documentación efectiva de sistemas de software, uno de sus principios es sólo desarrollar los artefactos que sean necesarios para el proyecto, con lo cual coinciden otros autores que indican que cada proyecto adecue los procesos de desarrollo y artefactos a sus necesidades. (HURTADO y BASTARRICA '05; JACOBS '04; ORANTES '07)
 *Priorizar los requisitos. Es necesario definir qué requisitos serán incluidos en cada iteración del desarrollo, para ello se deben priorizar los requisitos a partir de criterios que cada equipo de proyecto tendrá que definir, la importancia para los interesados, como se señaló anteriormente, no debe omitirse.
 *Exigir que los interesados se involucren. Para que los interesados queden satisfechos con el producto final es necesario que sean parte activa del equipo, fundamentalmente durante la modelación del negocio y la captura de requisitos; las metodologías ágiles sugieren que haya un cliente o representante de este junto al equipo de desarrollo durante todo el ciclo de vida del proyecto.(HURTADO y BASTARRICA '05) (ORANTES '07)
@@ Línea 39: / Línea 39: @@
 *Controlar los cambios a los requisitos. El mundo está en constante evolución, los negocios, la economía, la política y la sociedad están cambiando continuamente y suponer que los requisitos no van a cambiar durante el desarrollo de software no es realista. Lo importante es estar preparados para asumir los cambios mediante un proceso de gestión de cambios que garantice la completitud y consistencia de la ERS.
 *Mantener la traza de cada requisito. Para evitar el riesgo de implementar “requisitos inútiles” debe conocerse el origen de cada requisito y con el objetivo de evaluar el impacto de los cambios cada requisito debe seguirse hacia los elementos relacionados.
-*Mantener un glosario de términos. Debe mantenerse entre el equipo de desarrollo de software y los interesados en el proyecto un entendimiento común sobre los requisitos, cuando se utiliza el lenguaje natural para documentar los requisitos pueden introducirse ambigüedades; mantener un glosario de términos contribuye a mejorar el entendimiento.
+*Mantener un glosario de términos. Debe mantenerse entre el equipo de desarrollo de [[Software]] y los interesados en el proyecto un entendimiento común sobre los requisitos, cuando se utiliza el lenguaje natural para documentar los requisitos pueden introducirse ambigüedades; mantener un glosario de términos contribuye a mejorar el entendimiento.
 ==Fuente==
 *http://ucipedia.uci.cu 1 de noviembre del 2011
 *Elaborado por la Ing. Dunia Pineda Medina
 [[Category:Ingeniería_de_software]]