La comprension de los requisitos de un problema esta entre las tareas mas dificiles que enfrenta un ingeniero de software, debido a que en muchas ocaciones los clientes no saben a detalle que es lo que en verdad necesitan y si al caso lo saben a detalle los requisitos pueden cambiar durante el desarrollo del sistema.
La ingenieria de requisitos ayuda al ingeniero de software a entender mejor el prolema en cuya solucion trabajara, nos ayuda a entender cual sera el impacto del software para el negocio que es lo que el cliente quiere y como interactuaran los usuarios finales con el software, es importante ya que un buen programa pero que resuelva el problema incorrecto no satisface los problemas de nadie, por ello es de gran importancia entender lo que el cliente quiere antes de iniciar a diseñar y construir software.
Aun que la ingenieria de requisitos no es una solucion para los retos, pero proporciona un enfoque solido para abordar dichos desafios. Al igual que las diferentes actividades de ingenieria de software la ingenieria de requisitos debe adaptarse al equipo, las necesidades del proceso el producto.
Es importante que el equipo haga un esfuerzo por entender los requisitos antes de intentar resolver el problema.
La ingenieria de requisitos establece una base solida para el diseño y construccion. Sin ella el software resultante tiene una alta probabilidad de no satisfacer las necesidades. del cliente.
La ingenieria de requisito se lleba a cabo a traves de 7 pasos
inicio
obtencion
elaboracion
negociacion
especificacion
validacion
gestion
por que es dificil obtener informacion
Problemas de ambito. los limites del sistemas estan mal definidos o se especifican detalles tecnicos inecesarios que pudeden confundir en lugar de clarificar.
Problemas de comprension. los clientes/usuarios no estan seguros por completo de lo que se necesita
Problemas de volatilidad. los problemas cambian conforme transcurre el tiempo.
una negociacion exitosa debe ser del tipo en que todos ganan
INICIO DEL PROCESO DE LA INGENIERIA DE REQUISITOS
1. Identificacion de los interesados.
son todos aquellos que se benefician en forma directa o indirecta del sistema en desarrollo. cada interesado tiene un enfoque distinto del sistema, obtiene diferentes beneficios y esta abierta a diferentes riesgos.
a cada uno de los interesados se le preguntara ¿con quien mas piensa que se deberia hablar?
2. Reconocimiento de multiples puntos de vista
Se debe tener cuidado al obtener requisitos de los distintos puntos de vista ya que pueden existir requisitos que entren en conflictos con otros o puedan ser inconsistentes.y por lo tanto el ingeniero debe categorizar la informacion de los interesados en una forma que permita a quienes tomen las desiciones elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna
3. Trabajo con respecto a la colaboracion
Se deben identificar areas en comun y areas en conflicto o inconsistencia
4. Formulacion de las primeras preguntas.
las primeras preguntas al inicio del proyecto deben ser libres del contexto y estas deben enfocarse en el cliente y otros interesados, metas generales y en los beneficios algunos ejemplos de preguntas pueden ser
¿quien esta detras de la solicitud de este trabajo?
¿quien usara la solucion?
¿cual sera el beneficio economico de una solucion exitosa?
¿existe otra fuente para la solucion requerida?
la siguiente serie de preguntas permite que el equipo comprenda mejor el problema y deja que el cliente exprese sus percepciones acerca de una solucion.
La serie final de preguntas se enfoca en la efectividad de la actividad de comunicacion en si misma. llamadas "metapreguntas"
¿Es usted la persona adecuada para contestar esta pregunta?
¿sus respuestas son oficiales?
¿mis preguntas son relevantes para su problema?
¿estoy haciendo demasiadas preguntas?
¿alguien mas puede proporcionar informacion adicional?
¿Deberia preguntarle alguna otra cosa?
OBTENCION DE REQUISITOS
Recopilacion conjunta de requisitos
algunas directrices basicas son para recopilacion conjunta de requisitos.
las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de software o un cliente
se establecen reglas para preparacion y participacion
un moderado
se utiliza un mecanismo de definicion
la meta es identificar el problema, proponer elementos de solucion, negociar diferentes enfoques y especificar un conjunto de requisitos de solucion preliminares que conduzcan al cumplimiento de la meta
si el proyecto o sistema servira a muchos usuarios los requisitos se deben obtener de una muestra significativa de lo contrario si unicamente se toma una muestra muy pequeña se corrie un riesgo alto de rechazo.
se debe mantener la mente abierta y no se debe desechar una idea del cliente por costosa o poco practica, mas bien se debe negociar todo lo que sea posible.
Despliegue de funcion de calidad
traduce la necesidades del cliente en requisitos tecnicos del software QFD resalta una comprension de lo que es valioso para el cliente y despues despliegua estos valores durante el proceso de ingenieria.
QFD identifica tres tipos de requisitos
Requisitos normales
Requisitos esperados
Requisitos Estimulantes
algunos de los productos obtenidos de la fase de requisitos pueden ser
enunciado de necesidad y factibilidad
enunciado del ambito del sistema o producto
una lista de interesados
una descripcion del ambiente tecnico del sistema
una lista de requisitos
una lista de casos de uso
cualquier prototipo desarrollado para definir de mejor forma los requisitos
DESARROLLO DE CASOS DE USO
Un caso de uso captura un contrato que describe el comportamiento del sistema en diferentes condiciones mientras este responde a la peticion de uno de los usuarios.
Al escribir un caso de uso primero se definen los actores esto son diferentes personas o dispositivos que utilizan el sistema o producto dentro del contexto que se describira, es algun elemento que se comunica con el sistema o producto y es externo al sistema en si mismo.
los actores primarios interactuan para lograr la funcion requerida del sistema y obtienen un beneficio del mismo, el actor secundario dan soporte al sistema
NEGOCIACION DE REQUISITOS
Algunas directrices.
1. reconocer que no es una competencia
2. diseñar una estrategia
3. escuchar de manera activa
4. enfocarse en los intereses de la otra parte
5. no dejar que se vuelva personal
6. ser creativo
7. estar listo para pactar
La ingenieria de requisitos ayuda al ingeniero de software a entender mejor el prolema en cuya solucion trabajara, nos ayuda a entender cual sera el impacto del software para el negocio que es lo que el cliente quiere y como interactuaran los usuarios finales con el software, es importante ya que un buen programa pero que resuelva el problema incorrecto no satisface los problemas de nadie, por ello es de gran importancia entender lo que el cliente quiere antes de iniciar a diseñar y construir software.
Aun que la ingenieria de requisitos no es una solucion para los retos, pero proporciona un enfoque solido para abordar dichos desafios. Al igual que las diferentes actividades de ingenieria de software la ingenieria de requisitos debe adaptarse al equipo, las necesidades del proceso el producto.
Es importante que el equipo haga un esfuerzo por entender los requisitos antes de intentar resolver el problema.
La ingenieria de requisitos establece una base solida para el diseño y construccion. Sin ella el software resultante tiene una alta probabilidad de no satisfacer las necesidades. del cliente.
La ingenieria de requisito se lleba a cabo a traves de 7 pasos
inicio
obtencion
elaboracion
negociacion
especificacion
validacion
gestion
por que es dificil obtener informacion
Problemas de ambito. los limites del sistemas estan mal definidos o se especifican detalles tecnicos inecesarios que pudeden confundir en lugar de clarificar.
Problemas de comprension. los clientes/usuarios no estan seguros por completo de lo que se necesita
Problemas de volatilidad. los problemas cambian conforme transcurre el tiempo.
una negociacion exitosa debe ser del tipo en que todos ganan
INICIO DEL PROCESO DE LA INGENIERIA DE REQUISITOS
1. Identificacion de los interesados.
son todos aquellos que se benefician en forma directa o indirecta del sistema en desarrollo. cada interesado tiene un enfoque distinto del sistema, obtiene diferentes beneficios y esta abierta a diferentes riesgos.
a cada uno de los interesados se le preguntara ¿con quien mas piensa que se deberia hablar?
2. Reconocimiento de multiples puntos de vista
Se debe tener cuidado al obtener requisitos de los distintos puntos de vista ya que pueden existir requisitos que entren en conflictos con otros o puedan ser inconsistentes.y por lo tanto el ingeniero debe categorizar la informacion de los interesados en una forma que permita a quienes tomen las desiciones elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna
3. Trabajo con respecto a la colaboracion
Se deben identificar areas en comun y areas en conflicto o inconsistencia
4. Formulacion de las primeras preguntas.
las primeras preguntas al inicio del proyecto deben ser libres del contexto y estas deben enfocarse en el cliente y otros interesados, metas generales y en los beneficios algunos ejemplos de preguntas pueden ser
¿quien esta detras de la solicitud de este trabajo?
¿quien usara la solucion?
¿cual sera el beneficio economico de una solucion exitosa?
¿existe otra fuente para la solucion requerida?
la siguiente serie de preguntas permite que el equipo comprenda mejor el problema y deja que el cliente exprese sus percepciones acerca de una solucion.
La serie final de preguntas se enfoca en la efectividad de la actividad de comunicacion en si misma. llamadas "metapreguntas"
¿Es usted la persona adecuada para contestar esta pregunta?
¿sus respuestas son oficiales?
¿mis preguntas son relevantes para su problema?
¿estoy haciendo demasiadas preguntas?
¿alguien mas puede proporcionar informacion adicional?
¿Deberia preguntarle alguna otra cosa?
OBTENCION DE REQUISITOS
Recopilacion conjunta de requisitos
algunas directrices basicas son para recopilacion conjunta de requisitos.
las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de software o un cliente
se establecen reglas para preparacion y participacion
un moderado
se utiliza un mecanismo de definicion
la meta es identificar el problema, proponer elementos de solucion, negociar diferentes enfoques y especificar un conjunto de requisitos de solucion preliminares que conduzcan al cumplimiento de la meta
si el proyecto o sistema servira a muchos usuarios los requisitos se deben obtener de una muestra significativa de lo contrario si unicamente se toma una muestra muy pequeña se corrie un riesgo alto de rechazo.
se debe mantener la mente abierta y no se debe desechar una idea del cliente por costosa o poco practica, mas bien se debe negociar todo lo que sea posible.
Despliegue de funcion de calidad
traduce la necesidades del cliente en requisitos tecnicos del software QFD resalta una comprension de lo que es valioso para el cliente y despues despliegua estos valores durante el proceso de ingenieria.
QFD identifica tres tipos de requisitos
Requisitos normales
Requisitos esperados
Requisitos Estimulantes
algunos de los productos obtenidos de la fase de requisitos pueden ser
enunciado de necesidad y factibilidad
enunciado del ambito del sistema o producto
una lista de interesados
una descripcion del ambiente tecnico del sistema
una lista de requisitos
una lista de casos de uso
cualquier prototipo desarrollado para definir de mejor forma los requisitos
DESARROLLO DE CASOS DE USO
Un caso de uso captura un contrato que describe el comportamiento del sistema en diferentes condiciones mientras este responde a la peticion de uno de los usuarios.
Al escribir un caso de uso primero se definen los actores esto son diferentes personas o dispositivos que utilizan el sistema o producto dentro del contexto que se describira, es algun elemento que se comunica con el sistema o producto y es externo al sistema en si mismo.
los actores primarios interactuan para lograr la funcion requerida del sistema y obtienen un beneficio del mismo, el actor secundario dan soporte al sistema
NEGOCIACION DE REQUISITOS
Algunas directrices.
1. reconocer que no es una competencia
2. diseñar una estrategia
3. escuchar de manera activa
4. enfocarse en los intereses de la otra parte
5. no dejar que se vuelva personal
6. ser creativo
7. estar listo para pactar
Comentarios