Ensayo de requerimientos

Jesus Leonardo Rodriguez Gutiérrez

1151390
Marzo 2020

Universidad Francisco de Paula Santander

Análisis y Diseño
Son algo esencial al momento de elaborar cualquier tipo de sistemas de información, ya que
dentro de estos se representan las necesidades de los usuarios, en otras palabras, las
funcionalidades que tendrán dichos sistemas de información están descritas en los
requerimientos, es ahí donde surgen la mayoría de problemáticas del análisis de
requerimientos; las restricciones que puedan llegar a desarrollarse en su entorno o a lo largo
del desarrollo y así comprender completamente en qué contexto se desarrollara el sistema
de información. (Bail, 2010), establece que, en el desarrollo de sistemas, los responsables
de la mayoría de las fallas son los requerimientos. Una sugerencia que se acopla más a los
sistemas integrados y que se trabajan en tiempo real.

Se debe tener un gran nivel de tolerancia ante las fallas que puedan presentarse, los
aspectos que no suelen satisfacerse al momento de llevar a cabo el análisis de requisitos son
la sincronización y la latencia. Se sobreentiende que la ingeniería de requerimientos forma
parte de la ingeniería de software, hay que tener en cuenta lo antes mencionado para poder
entender las bases de dicha problemática. Se debe tener un buen nivel de comprensión
lectora al momento de realizar la toma de requerimientos, puesto que muchos problemas al
momento de llevar a cabo dicha acción se deben a una mala comprensión. (Holtmann,
Bernijazov, Meyer, Schmelter, & Tschirner, 2015), a continuación, nos indican tres roles de
gran importancia al momento de elaborar un sistema de información: Requirements Owner
(Dueño de Requisitos), es quien inicia la definición de los requerimientos técnicos a nivel
del sistema (requisitos del sistema) basado en los requisitos dados por el cliente. Luego el
System Designer (Diseñador de Sistemas), basado en los requisitos del sistema, crea la
arquitectura del sistema a alto nivel, lo que usualmente se trata de la definición de las
funciones del sistema. Por último, el System Analyst (Analista de Sistemas), se asegura de
que la arquitectura del sistema cumpla con los requisitos del sistema, esto ayuda a reducir la
incertidumbre y el riesgo en las etapas tempranas del proyecto. Con lo establecido
anteriormente por los autores, se puede concluir que, si el dueño de requerimientos
interpreta mal los requisitos dados por el cliente, el trabajo del diseñador de sistemas y el
analista de sistemas se verá afectado por la mala toma de requerimientos.

En el segundo taller internacional de Ingeniería de Requerimientos y Pruebas el profesor

Mats Heimdahl, discutia sobre la necesidad de llevar a cabo la cobertura de requerimientos
además de solo la cobertura del código. Mientras que la cobertura del código es usada para
medir la calidad de las pruebas, la cobertura de los requerimientos da un indicador de que
tan bien se está llevando a cabo el software con respecto a los requerimientos del mismo.
Dichas medidas podían usarse para indicar que tan bien se cumplen las expectativas de los
clientes y usuarios finales. (Bjarnason et al., 2015), planean organizar de nuevo el taller
para los próximos años, debido a que el tema es de gran relevancia para la industria y el
aprendizaje.
Bibliografia.

Bail, W. (2010). Effective requirements engineering. ​Proceedings of the ACM SIGAda

Annual International Conference on SIGAda - SIGAda ’10,​ 1.
https://doi.org/10.1145/1879063.1879065
Bjarnason, E., Borg, M., Morandini, M., Unterkalmsteiner, M., Felderer, M., & Staats, M.
(2015, July 31). Proceedings - 2nd International Workshop on Requirements
Engineering and Testing, RET 2015. ​Proceedings - 2nd International Workshop on
Requirements Engineering and Testing, RET 2015​, Vol. 40, pp. 39–42.
https://doi.org/10.1145/2815021.2815036
Holtmann, J., Bernijazov, R., Meyer, M., Schmelter, D., & Tschirner, C. (2015). Integrated
systems engineering and software requirements engineering for technical systems.
ACM International Conference Proceeding Series​, ​24​-​26-​ ​Augu​, 57–66.
https://doi.org/10.1145/2785592.2785597