Se explora el proceso asociado al levantamiento de requerimientos, se establecen algunas áreas de esfuerzo que requerirá el proceso y se dan algunas recomendaciones sobre que hacer para estas actividades. Los principios operativos también se mencionan, con la definición de las funciones, el dominio, los modelos. Por otro lado las directrices como entender el problema, el empleo de prototipos, las prioridades y la eliminación de ambigüedades son consideradas. De igual manera se introduce el termino de Stakeholder y se especifica las técnicas de levantamiento de información, como entrevista, encuesta, observación y talleres. Las consultas se pueden efectuar a: josefabiandiazs@gmail.com

1. Ingeniería de Requisitos
Recolectando la información

2. Áreas de esfuerzo de la Ing.
Requerimientos
• Reconocimiento del problema
• Evaluación y síntesis
• Modelado
• Especificación
• Revisión

3. Reconocimiento del problema
• Es necesario identificar de la manera mas pronta el
problema que se quiere resolver.
Centrarse en lo necesario por encima de lo
deseado.

4. Evaluación y Síntesis
• Posterior a la identificación del problema se debe
invertir tiempo en efectuar la evaluación del mismo
y tratar de expresarlo de la manera mas simple.
"Si no puedes explicar algo de forma sencilla, es
que ni tú mismo lo has entendido lo suficiente“.
Albert Einstein

5. Modelado
• Es una serie de actividades encaminadas a expresar
de manera gráfica o textual los elementos que
conforman la solución al problema identificado.
“Con el modelado se mejora la comunicación
con el equipo de trabajo, clientes y usuarios“.

6. Especificación
• Posterior al modelado ya se tiene un conocimiento
avanzado de los requerimientos, pero hace falta
expresarlos de manera completa; esto se realiza en
la especificación.
“Existen diversos formatos, normas y
recomendaciones para efectuar la
especificación“.
IEEE380

7. Revisión
• La especificación debe ser validada y por ello es
necesario realizar una revisión general que
involucre los clientes y usuarios.
“El cliente siempre tiene la razón“.
Desde que se llegue a los acuerdos
necesarios.

8. PRINCIPIOS
OPERATIVOS

9. Representar
Dominio
1
Entender
Información del
problema

10. Definir
Funciones
2
Que realizara el
software

11. Representar
Comportamiento
3
Del Software

12. Dividirse en
Modelos
4
Ver el software por
capas

13. Refinamiento
Niveles de abstracción
5
De lo general a lo
particular.

14. PRINCIPIOS
Directrices

15. Entienda el
problema antes
de iniciar el
modelamiento
1

16. Emplee Prototipos.
De esta forma el
usuario entenderá
su relación con el
software.
2

17. Registre el orden
de los
requerimientos y
la razón de los
mismos.
3

18. Exprese los
requerimientos
de más de una
forma.
4

19. Asigne
prioridades a los
requerimientos.
5

20. Elimine la
ambigüedad y
haga de esto una
política.
6

21. Stakeholders
“Quienes pueden afectar o son
afectados por las actividades de
una empresa”

22. Proceso de la
Ingeniería de Requisitos

23. Proceso de
Ingeniería de
Requisitos.
Sistemas
existentes
Necesidades
Stakeholders
Estándares y
regulaciones.
Información del
dominio.
Requisitos
acordados.
Especificación de
requisitos.
Modelos del
sistema
Proceso de Ingeniería de Requisitos

24. Actividades comunes Ing.Req

25. Técnicas de
Recolección de
INFORMACIÓN

26. Entrevista
“Realice cuantas pueda efectuar, en diversos
momentos y con variedad de usuarios.”
Deben emplear formatos establecidos,
validados y correctamente documentados.

27. Encuesta
“Una técnica eficiente para conocer la opinión
de lo usuarios”.
Hay que tener cuidado en no generalizar los
resultados con una pequeña muestra.

28. Taller
“Se acostumbra realizar cuando existen
grupos homogéneos. Validan rápidamente la
información y permiten estructurar soluciones
no contempladas de otra manera”.
Se deben organizar y contar con una estrategia
establecida para planear el objetivo de los
mismos.

29. Observación
“Es la mejor forma de identificar falencias en
los requerimientos o ambigüedades en las
especificaciones”.
Algunas cosas son las que se dicen, otras las
que se documentan y muy diferentes las que
se hacen.

30. Revisión documental
“Se recomienda siempre ir por la fuente
primaria, verificar la documentación que
soporte los requerimientos”.
Lo que esta escrito, escrito esta.

31. Análisis de datos
“La información que se requiere, quizás ya
esta dentro de los datos recolectados, por ello
es preciso efectuar un análisis de todos los
elementos recibidos al inicio del proyecto”.
En este punto es útil recordar llevar un
registro y trazabilidad de los requerimientos.

32. • Basado en:
Ingeniería de Software.
Sommerville, Ian
6ta. Edición

33. @josefabiandiaz
josefabiandiazs@Gmail.com
https://www.youtube.com/user/fabiandiazs
Msc.Ing.Jose Fabián Diaz Silva
Consultas