Tareas de ingenieria en requisitos

TAREAS DE INGENIERIA EN
REQUISITOS
Erik Ivan Mancilla Romero | Fundamentos de ingeniería
de software | Catedrático Rita Hernandez Flores
Introducción
La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo
que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar
unasolución razonable, especificar la solución sin ambigüedades, validar
laespecificación, y administrar los requisitos conforme estos se transforman en
unsistema operacional. Existen muchos procesos de desarrollo de software con
unagran serie de estándares para medir.En el proceso de la ingeniería de
requisitosse ejecutan las tareas de inicio, obtención, elaboración, negociación,
especificación, validación y gestión. Dichas funciones deben adaptarse a
lasnecesidades y particularidades de cada proyecto. En este caso se hablara de
las tareas, actividades o funciones que debe efectuar para llegar a esta meta.
Definición
Se define como un conjunto de actividades en los cuales, utilizando tecnicas y
herramientas, se analiza un problema y se concluye con la especificación de una
solución. La ingeniería de requisitos es el proceso de desarrollar una
especificación de software.
Tareas
 Inicio
Tiene por objetivo identificar el ámbito del proyecto general. Comienza con
una serie de conversaciones informales entre los participantes del mismo.
Esta fase suele ser acompañada de los documentos de definición de la
visión global y la visión del dominio del sistema. Se inicia muchas veces
por: se descubre un nuevo mercado y se descubre un nuevo servicio.
 Obtención
Se sugiere a los ingenieros recopilar requisitos de manera organizada,
preguntando a los usuarios y otros interesados cuales son os objetivos para
el sistema o producto, que es lo que se debe lograr, de que forma el
producto satisface las necesidades del negocio y como se utilizara el
producto día d día. Se identifican una serie de problemas que ayudan a
entender porque es difícil la obtención de requisitos:
 Problema de ámbito
 Problema de comprensión
 Problemas de volatilidad
 Elaboración
Los ingenieros de software crean un modelo de análisis con la
informaciónobtenida del cliente en las fases de inicio y obtención. El modelo
de análisisdefine el dominio de la información, las funciones y el
compartimiento del
problema.La información conseguida con el cliente durante el inicio y
obtención seexpande y se refina durante la elaboración. Esta actividad de la
ingeniería derequisitos se enfoca en el desarrollo de un modelo técnico
refinado de lasfunciones, características y restricciones del software.La
elaboración del modelado del análisis y su componente de una serie de
tareasde modelado y refinamiento. La elaboración se conduce mediante la
creación yrefinamiento de escenarios del usuario que describen la forma en
que el usuariofinal (y otros actores) interactuaran con el sistema. Cada
escenario del usuario seanaliza para obtener clases del análisis: entidades
del dominio de negociosvisibles para el usuario final. Se definen los
atributos de cada clase de análisis yse identifican los servicios que requiere
cada clase. Se identifican las relaciones yla colaboración entre las clases y
se produce una variedad de diagramas de UMLcomplementarios.El
resultado final de la elaboración es un modelo de análisis que definen
eldominio de la información, las funciones y el comportamiento del
problema.
 Negociación
En esta etapa el ingeniero de requisitos debe negociar con el cliente los
alcances y límites del sistema. De forma iterativa los requisitos se prioriza,
modifican, combinan o eliminan buscando acuerdos que beneficien a todas
las partes. Se identifican y analizan los riesgos asociados con cada
requisito.
 Especificaciones
Es el producto final de la ingeniería de requisitos, y se convierte en la
materia prima para las actividades posteriores en el proceso de desarrollo
del sistema. Una especificación puede ser un documento escrito, un
conjunto de modelos gráficos, un modelo matemático formal, una colección
de escenarios de uso, un prototipo o cualquier combinación de estos.
 Validación
Un equipo de validación toma el producto de la fase de especialización, lo
revisa para detectar errores, conflictos u omisiones y los corrige con el fin
de garantizar la consistencia de los requisitos.La calidad de los productos
de trabajo procedentes de la ingeniería de requisitos se evalúa durante un
paso de validación. La validación de requisitos examina la especificación
para asegurar que todos los requisitos de software se han establecidos de
manera precisa; que se han detectado las inconsistencias omisiones y
errores y queestos han sido corregidos, y que los producto de trabajo
cumplen con los estándares establecidos para el proceso, proyecto y
producto.El mecanismo primario para la validación de requisitos es la
revisión técnica formal. El equipo de revisión que valida los requisitos
incluye ingenieros de software, clientes, usuarios y otros interesados que
examinan la especificación y buscan errores en el contenido o la
interpretación, áreas que tal vez requieran una clasificación, información
faltante, inconsistencia (que es problema importante) cuando se desarrollan
productos o sistemas grandes), conflictos entre los requisitos, o requisitos
irreales (inalcanzables).
 Gestión de requisitos
Ayuda a rastrear los requisitos según las características de los mismos, el
código fuente relacionado, dependencia entre requisitos, subsistemas e
interfaces internas y externas de forma que pueda identificarse con rapidez
para entender como afectara una modificación diferentes aspectos del
sistema a construir. Es un conjunto de actividades que ayudan al equipo de
proyecto a identificar, controlar y rastrear los requisitos y los cambios a
estos en cualquier momento mientras se desarrolla el proyecto.
La gestión de requisitos es un conjunto de actividades que ayudan al equipo de
proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en
Cualquier momento mientras se desarrolla el proyecto. Muchas de estas
actividades son idénticas a las actividades de la gestión de la configuración del
software (GGS).La gestión de requisitos comienza con la identificación. Cada
requerimiento se asigna a un solo identificador. Una vez identificados los
requisitos se desarrollan las tablas de rastreabilidad que son las siguientes:
Tabla de rastreabilidad de las características:
Muestra la manera en que los requisitos se relacionan con las características del
sistema/producto observables para el cliente.
Tabla de rastreabilidad de la fuente:
Identifica la fuente de cada requisito.
Tabla de rastreabilidad de dependencia:
Indica la forma en que los requisitos están relacionados entre sí.
Tablas de rastreabilidad del subsistema:
Establece categorías entre los requisitos de acuerdo con el (los) subsistema(s)
que gobierna(n).
Tablas de rastreabilidad de la interfaz:
Muestra la forma en que los requisitos se relacionan con las interfaces internas y
externas del sistema.
En muchos casos, esas tablas de rastreabilidad se mantienen como parte de la
base de datos de los requisitos de forma que pueda buscársele con rapidez para
entender como el cambio en un requisito afectara diferentes aspectos del sistema
que se construirá. Los requerimientos en un proyecto no solo comprenden las
tareas de captura y manejo de los cambios a lo largo de todo el proyecto, también
comprenden de estas otras tareas:
 Identificar los stakeholders (se refiere a «quienes pueden afectar o son
afectados por las actividades de una empresa»): Se describe una lista de
toda la persona interesada en el desarrollo del sistema.
 Entender las necesidades de los usuarios y clientes necesarias para
planear el sistema y sus expectativas.
 Identificar los requerimientos: Inicialmente los requerimientos provienen de
los objetivos que plantea el negocio. En esta actividad los requerimientos se
indican por medio de sentencias. En un escenario de negocio se usa para
entender los requerimientos del negocio.
 Aclarecer y refinar los requerimientos: Esta actividad se ejecuta cuando se
tiene plena seguridad plena certeza de que los requerimientos indican las
necesidades reales del cliente y que estos pueden ser usados por el resto
de equipos en el proyecto.
 Analizar los requerimientos: Se realiza cuando los requerimientos se
encuentran bien definidos y cumplen con el criterio de un buen
requerimiento.
 Definir los requerimientos de forma estándar para los stakeholders: Debido
a que cada stakeholders tiene una perspectiva diferente del sistema y sus
requerimientos, es importante esforzar un poco de tiempo en la descripción
de los requerimientos usando un vocabulario adecuado.
 Especificar los requerimientos: Cada requerimiento debe expresarse en
forma detallada de tal manera que pueda ser incluido en otros documentos
de especificación o en otros proyectos.
 Priorizar los requerimientos: Todos los requerimientos tienen niveles
diferentes de importancia para los clientes y usuarios. Unos tienen prioridad
críticas, otros no tanta y otros de bajo nivel de prioridad. La priorización de
los requerimientos es una actividad que nos va a permitir desarrollar nuevas
versiones de nuestro proyecto de forma continua sin verse retrasadas por
tiempo en sus salidas.
 Derivar los requerimientos: Esta actividad nos permite detallar
requerimientos no visibles para nuestros clientes o usuarios que no se han
logrado identificar, pero que son importantes para el funcionamiento
adecuado del requerimiento en detalle.
 Particionar los requerimientos: donde se clasifican los requerimientos en
diferentes criterios: Hardware, software y entrenamiento.
 Asignar los requerimientos: Esta actividad asigna los requerimientos a
diferentes subsistemas y componentes internos.
 Hacer seguimiento a los requerimientos: Se desarrolla la capacidad de
permitir que un requerimiento satisfecho pueda ser referenciado dentro del
sistema.
 Manejar los requerimientos: Se desarrolla un sistema de control de los
requerimientos, necesario para adicionar, modificar y borrar requerimientos,
al igual que la implantación de un repositorio para estos.
 Probar y verificar los requerimientos: En esta actividad se validan los
requerimientos, diseños, código, etc... Para asegurarse que los
requerimientos están bien.
 Validar los requerimientos: Finalmente se confirman los requerimientos
reales que han sido implementados.
Ejemplos
MODELO
Actividades
Oliver and
Steiner 1996
EIA / IS-632
IEEE Std 1220- CMM nivel
1994
Repetitivo (2)
Evaluar la
información
disponible
Análisis de
Análisis de
Identificación de
requerimientos Requerimientos requerimientos
RUP
Análisis del Problema
Definir métricas Análisis
efectivas
funcional
Estudio de los Identificación de
Comprender las
requerimientos restricciones del
necesidades de los
sistema a desarrollar involucrados
Crear un
Síntesis
modelo del
comportamiento
del sistema
Validación de Análisis de los
requerimientos requerimientos
Definir el sistema
Crear un
modelo de los
objetos
Análisis
funcional
Representación de
los requerimientos
Analizar el alcance
del proyecto
Ejecutar el
análisis
Evaluación y
estudio de
funciones
Comunicación de
los requerimientos
Modificar la
definición del sistema
Crear un plan
secuencial de
construcción y
pruebas
Verificación de Validación de
funciones
requerimientos
Análisis y
control del
sistema
Administrar los
cambios de
requerimientos
Síntesis
Estudio y
evaluación del
diseño
Verificación
física
Control
Conclusión
Es de mucha importancia tomarse el tiempo necesario para conocer a los clientes
y usuarios, así como su ambiente de trabajo. Esto ayuda a establecer una buena
relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es
realmente necesario que los clientes y usuarios participen en la definición de sus
requerimientos, y con estos tareas, funciones o actividades que acabamos de ver,
son necesario porque ponen una serie de estándares para medir y certificar
localidad tanto del sistema que está a desarrollar, como también del proceso de
desarrollo que con lleva ya que esto son los que deciden el destino del proyecto y
se decide del gusto o inconformidad y además del financiamiento que dará de
fruto el proyecto.
Referencias
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htmhttp://es.scribd.com/doc/270431/Ingenieriarequerimientos
http://www.monografias.com/trabajos6/resof/resof.shtmlhttp://redalyc.uaemex.mx/pdf/666/666
61111.pdf
http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdfhttp://es.scribd.com/doc/19083744/ING
ENIERIA-DE-REQUERIMIENTOS
http://www.monografias.com/trabajos5/inso/inso2.shtml
http://www.arcos.inf.uc3m.es/~ii_si/IngReqCIII.pdf
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php