tabajo

1. METODOLOGIA GESTION DE REQUERIMIENTOS
ENSAYO
CAP. 1 -7
Jhon jarrinson cuellar lozada
JUAN CAMILO GOMEZ JOVEL
TECNOLOGO
ANALISIS Y SISTEMAS DE DESARROLLO DE INFORMACION
CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA
SENA
GARZON-HUILA

2. Objetivos
Analizar los requerimientos que se necesitan para conocer las necesidades y
objetivos que el cliente o usuario necesita para poder desarrollar un sistema
que cumpla con aquellas necesidades.
Aprender a realizar una correcta documentación para que todo lo que se
vaya a ir actualizando se tenga en modo de carpeta escrito.

3. METODOLGIA GESTION DE REQUERIMIENTOS
Los requerimientos se enfocan a describir las necesidades del cliente, es decir
que para recabarlos hay que tener una información que se obtiene mediante
entrevistas, para que los costos del cliente no incrementen estos van
evolucionando con el tiempo es bueno y necesario tener una copia de la
documentación original del cliente.
Para que este método que se utiliza sea efectivo es necesario seguir una
secuencia que se desarrollan para la identificación de las necesidades del
cliente:
Obtener información del cliente
1. Definir el alcance
2. Identificar requerimientos funcionales y no funcionales
3. Realizar entregable de identificación de necesidades
4. Realizar entregable de identificación de necesidades
La definición del alcance tiene como propósito definir las necesidades del
cliente para esto es necesario tener en cuenta unos pasos:
1. Los entregables que hacen parte del alcance: para este se recomienda
describir listar los entregables finales estos tiene que ser aprobados
por el cliente, es bueno no mencionar documentos propios del
proyecto por ejemplo un cronograma
2. Los tipos de datos que están en el alcance y fuera de el: estos se refieren al
negocio de los entregables como datos financieros, de venta y de los
empleados

4. 3. Las fuentes de datos (bases de datos) que están en el alcance y fuera de el:
es parecido a los tipos de datos este lleva datos agregados (base de datos de
cliente, contabilidad general, sistema de facturación y cobranza
4.Áreas involucradas en el alcance y fuera de él: a veces estas ayudan a las
áreas involucradas en el proyecto delimitan el alcance
5. Condiciones fuera del alcance: es recomendable como un punto de
claridad y contraste al describir entregables que no se han creados
Las fuentes de información claves es bueno que cualquier información que se
haya creado esta debe ser usada como una base para definir el alcance de
una manera más detallada, cuando se obtienen objetivos del proyecto es
recomendable tener esto en cuenta para definir el alcance, para cumplir cada
uno de los objetivos es necesario crear uno o más entregables.

5. TECNICAS PARA IDENTIFICAR REQUERIMIENTOS
En la actualidad existen aplicaciones de software, estas utilizan diferentes
herramientas que ayudan a la identificación de los requerimientos.
Las organizaciones actuales utilizan múltiples herramientas para la
identificación de requerimientos sin saber si son los más convenientes
Técnicas para la identificación de requerimientos estas técnicas nos permiten
investigar aspectos generales para que luego sean específicos para tener un
dialogo mucho más abierto es importante estas técnicas. La entrevista es
muy utilizada para la recolección de información esta se hace a cabo
mediante conversaciones estructuradas para esto es importante que el lugar
sea tranquilo para que el cliente este en confianza. Antes de iniciar una
entrevista hay que saber unos tips:
Estudiar el tipo de personas a las cuales se les realizar la entrevista, estudiar
el entorno donde se llevara a cabo la entrevista esto sirve para identificar los
confortables que son los clientes, conocer la manera de hablar de la persona
verificar que la persona tenga la disponibilidad de dar las necesidades para
luego saber si se convierten en requerimientos, analizar como es la relación
del cliente con la organización que posterior analizara los requerimientos,
saber que es importante obtener la mayor información.
La lluvia de ideas es abierta esta se utiliza para investigar nuevos servicios o
necesidades que no son claramente identificadas es decir es necesario que
todas las personas que hacen parte del equipo de apoyo hagan parte de la
investigación. Los cuestionarios se puede dirigir al público en específico o en
general con esto se puede tener una mayor información porque se pueden
involucrar más personas para el desarrollo del cuestionario
Técnicas específicas para la identificación de requerimientos están nos
permiten completar las técnicas generales para obtener mayor información
Observación esta técnica permite revisar que no existen omisiones o una
interpretación errónea sobre el proceso esto se hace si el cliente lo permite.

6. Escenarios con esta técnica permite analizar el producto ante determinados
eventos considerando los datos, acciones y excepciones que se pueden
presentar.
Los requerimientos de software se clasifican en funcionales y no funcionales.
Los funcionales son declaraciones de los servicios que proveerá el sistema
este hace cosas que el sistema no debe realizar
Identificación de los requerimientos no funcionales es la declaración de uno
o de los servicios que muestra el sistema de la manera en que este
reaccionara a una entrada en particular, algunos de los problemas de
software vienen desde la impresión en la especificación de requerimientos se
habla con el cliente, se plantean nuevos requerimientos debido a este
cambio obliga hacer unos cambios en los requerimientos tiene que cambiar
el sistema este retrasa la entrega debido a esto se incrementa el costo.
Una especificación de requerimientos funcionales no puede faltar por ningún
motivo todo el proceso tiene que ser completo esto por supuesto tiene una
consistencia y una compleción significa que los servicios que se hayan
solicitado tienen que estar definidos y la consistencia es que los
requerimientos no tiene definiciones contradictoria
La identificación de los requerimientos no funcionales se refiere a las
restricciones en el tiempo la capacidad de almacenamiento y las fiabilidades,
estas surgen de las necesidades del usuario también es por el presupuesto,
los requerimientos del producto estos dicen el comportamiento del
producto como un requerimiento de desempeño en la ejecución del sistema
y la memoria que necesita y los requerimientos organizables estos tienen un
lenguaje de programación o un método de diseño a utilizar y los
requerimientos de entrega especifican cuando es la entrega del producto y
su documentación.
La definición de requisitos para que esto sea un éxito los requerimientos
deben ser claros y definidos es bueno realizar requerimientos revisando

7. proyectos qu8e se hayan finalizado porque en estos puede haber
información que nos va a hacer muy útil pero debe estar clara y sin ningún
error. Los requerimientos se clasifican en funcionales y no funcionales estos
son de una gran importancia para poder desarrollar una aplicación de
software por eso siempre tienen que estar escritos con claridad es bueno
obtener la mayor información posible de las necesidades del cliente.
Para una verificación de requisitos se deben añadir criterios de aceptación
por cada requisito para lograr una tarea de la calidad es bueno asegurarse de
que cada requisito cumple los criterios, la revisión de requisitos de
especificación esto es cuando ya se han identificado los requerimientos
documentados y verificados, luego se procede a hacer la revisión de los
mismos con la información que se halla recolectado con los usuarios del
sistema en la revisión participan los analistas y por supuesto los usuario que
sean necesarios para hacer un proceso de preparación es necesario tener
unos pasos hacer un plan de revisión en esta reunión se debe panear los que
deben hablar de que se va hablar y el tiempo que se va a utilizar la
documentación se debe especificar los documentos a revisar, prepara la
reunión se debe prepara el lugar de encuentro los materiales, luego de esto
se hace la reunión se revisa la especificación por parte de los interesados y
obviamente se valida que lo especificado si se cumple identificar los defectos
de la especificación se identifican los errores que tenga la especificación
realización de correcciones a los documentos si en el paso anterior hay
errores el analista del sistema debe hacer la correcciones respectivas al
documento.
técnicas para definir requisitos
Para poder desarrollar un software se debe conocer los requisitos del cliente
que se hace efectivo con ayuda de una entrevista que son métodos antiguos,
los métodos que se usan ahora son los prototipos y los casos de uso.

8. En el mercado hay muchas herramientas que sirven para la especificación y
descripción para facilitar el inicio del desarrollo del sistema lo más
recomendable utilizar son los diagramas UML que no se utilizan cuando no se
necesite o porque los va a codificar otra persona y se utilizan cuando se
necesita que otras personas lo quieran entender porque lo van a estar
trabajando a la misma vez, cuando dos personas tengan un conflicto por
elementos que crean necesarios, cuando quieras hacerlo por diversión.
Los diagramas más utilizados son:
Los de estado que cosiste en mostrar los estados que pasa en la vida.
De secuencia: estos muestran los intercambios de mensajes en un momento
dado.
De caso de uso: describen las relaciones que existen entre dos casos de uso.
Para poder definir correctamente los casos de usos identificar y categorizar
los diferentes grupos de actores se debe tener en cuenta que dichos actores
pueden llegar a ser usuarios los intereses de los actores que nos permite
desarrollo de los casos de usos y la identificación de los escenarios para
poder saber cuál va a ser la interacción que va a tener con los actores.
Los casos de uso deben ser una secuencia de relatos que especifique su
funcionalidad los intercambios entre los casos de uso y los actores y se debe
evitar describir detalles de la interfaz evitar el uso de términos como por
ejemplo entre otras y el uso de ambigüedades o preguntas que ya deberían
estar resueltas y debe contra con unas características como el caso de uso
debe cumplir con todos los requerimientos se puede definir en dos niveles
uno de sistema y otro de negocio.
Los prototipos son funcionales pero no llega a equivaler al producto final ya
que no lleva a cabo todas las funciones necesarios es importante definir un
objetivo ya que puede ser muy útiles las fases del proyecto, esta puede que
funcione como no puede funcionar, son más rápidos de hacer, tienen bajos
costos.

9. Los criterios nos permiten saber si se cumplieron con los requisitos
necesarios y si el sistema es de alto nivel puede tener gran aceptación por los
clientes y las empresas.
PRUEBAS DE REQUERIMIENTOS
Se parte desde lo anterior para que los productos desarrollados su
metodología sea correcta se debe estimar el tiempo que se requiera y el
alcance que va tener este como tal verificación del requerimiento evaluación
de los requisitos visto bueno para la aprobación.
La planeación define el alcance y las limitaciones que tiene, la estrategia que
tiene para la ejecución de esta pruébalos requerimientos para poder realizar
las pruebas.
Los casos de prueba debe tener un diseño para que funcionen, deben ser
completo todos los ítems deben estar no debe faltar ninguno, correcto no
debe tener errores, preciso no ambiguo y claro, consistente ningún ítem
debe entrar en conflicto con otro, manejable que se pueda cambiar sin
afectar los otros ítems.
En la ejecución de los casos de prueba se debe evaluar cada uno de los
requerimientos y se deben reportarlos errores y sugerencias y se deben
realizar reuniones para hacer aclaraciones y definir si las conclusiones
planteadas deben estar solucionadas.
En el cierre se dará el visto bueno una vez que se haya completado la
ejecución con resultados satisfactorios.
GESTIÓN DE CAMBIOS
Para que haya una comunicación clara y efectiva se debe hacer una
planificación para desarrollarse los objetivos y propósitos para poderse llevar
a cabo la gestión de cambios se necesita el siguiente proceso:

10. Para poder realizar una correcta identificación de los controles de cambios se
requieren los siguientes pasos:
Análisis de la solicitud se hace cuando se recibe la solicitud por el cliente ya
sea externo o interno y debe ser recibida por el líder para que este la analice
y es importante analizar el alcance y el tiempo para saber si la solicitud es
viable o de lo contrario manejarlo con un requerimiento ya que con este
análisis se puede identificar el impacto que va a tener.

11. Además se debe valorar la factibilidad de la solicitud del cliente ya sea
interno o externo donde se define si le afecta el cambio y la trazabilidad y el
líder debe analizar si los cambios afectan a los requerimientos y que tantos
requerimientos afecta este.
Para que no haya complicaciones en las modificaciones de los requerimientos
es recomendable que tenga una documentación clara para que no haya
ambigüedades y ayuda a tener control y para informar sobre las
modificaciones que se hagan.
Una vez analizado el cambio se puede negociar con el cliente si es aceptable
la continuación de lo contrario los pasos a seguir después de tener
aprobación s `planea el tiempo y los recursos necesarios para este, y una vez
aprobado el cambio se terminan de hacer las modificaciones y después
verificar por parte del líder si se cumple con los cambios en los
requerimientos y trabajar con el ultimo línea de base para siempre trabajar
con la última versión y una vez realizado el cambio se debe informar a los
interesados.
Una vez terminado el documento este no debe ser ambiguo y debe ser
validada por los clientes y empresas.
GESTIÓN DE REQUERIMIENTO
Para que el sistema sea factible por el cliente que cumpla con sus
necesidades debe cumplir con las siguientes acciones:
Matriz de relación de documento es que el que nos muestra la relación de la
documentación y la clasificación si es un negocio, usuario o sistema si sirve o

12. no y las peticiones quejas o sugerencias.
Matriz de valoración es la que nos muestra si los criterios exigidos se
cumplieron si en este caso si se cierra y se aprueba el requisito, y el
encargado de revisar deberá dar un chequeo si la documentación es correcta
y deberá dar un dictamen correcto si esta en verde es porque se cumplió el
requisito correctamente y si esta en rojo es porque el criterio no cumple
correctamente con la aceptación y si se muestra en amarrillo es porque no

13. tiene ningún problema.
Matriz de control de cambios nos permite registrar los cambios que se van
realizando se puede registrar el número de control de cambio que se le hizo y
quien lo reviso en caso de que ya lo haya revisado su porcentaje de ejecución

14. hasta llegar al 100%, los requisitos afectados entre otras.

15. Conclusiones
Que más tipos de diagramas existen con este mismo proceso?
Si los prototipos son más rápidos y con menos costos porque no son tan
funcionales?
Si el sistema no está concreto falla a quien le va a ocasionar costos al creador
del sistema o al usuario?
Si no se hace una planeación adecuada puede fallar el sistema?

16. Bibliografía
https://sites.google.com/site/metodologiareq/capit
ulo-i