Tipos de Requisitos de Software

lOMoARcPSD|12847418
Tipos de Requisitos de Software
Analísis Avanzado de Software (Instituto Tecnológico de Tijuana)
StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por Waldir Ozuna ([email protected])
lOMoARcPSD|12847418
TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE TIJUANA
Subdirección Académica
Departamento de Sistemas y Computación
Semestre Agosto - Diciembre 2020
CARRERA
Ingeniería en Sistemas Computacionales
MATERIA Y GRUPO
Análisis Avanzado de Software
(ADF-1702 SC8B)
ALUMNO Y NO. DE CONTROL

Acevedo Cardona Adelaid Lesdeymariet (16211957)
CORREO INSTITUCIONAL
[email protected]
TEMA
Tipos de Requisitos del Software
DOCENTE
José de Jesús Parra Galaviz
FECHA DE ENTREGA
29 de septiembre del 2020

lOMoARcPSD|12847418
Una de las actividades más importantes durante la fase de análisis cuando elaboramos un software,
es la determinación de los requerimientos que debe cubrir dicho software, los dos principales tipos
son los requerimientos funcionales y no funcionales.
Los requisitos determinan lo que hará el sistema (cómo funcionará) y las restricciones sobre su
operación e implementación.
La elicitación, análisis y especificación de requisitos es el proceso del estudio de las necesidades de

los usuarios para llegar a una definición de los requisitos del sistema.
Tipos de Requerimientos
Funcionales
Son declaraciones de los servicios que prestará el sistema y la forma en que este reaccionará cuando
se cumplan determinadas condiciones. Cuando hablamos de las entradas, no necesariamente
hablamos sólo de las entradas de los usuarios. Pueden ser interacciones con otros sistemas,
respuestas automáticas, procesos predefinidos. En algunos casos, los requisitos funcionales de los
sistemas también establecen explícitamente lo que el sistema no debe hacer. Es importante
recordar esto: un RF puede ser también una declaración negativa. Siempre y cuando el resultado de
su comportamiento sea una respuesta funcional al usuario o a otro sistema, es correcto. Y más aún,
no sólo es correcto, sino que es necesario definirlo. Y eso nos lleva al siguiente punto.
Muchos de los problemas en la ingeniería de software (hablando sobre el proceso de desarrollo en

sí mismo) comienzan con especificaciones de requisitos inexactas. Es natural que un analista de
negocio (o quien sea que esté definiendo y documentando los requerimientos del sistema) tome
algunas suposiciones como conocimiento universal, o dé por sentado algún comportamiento. Pero
hay que recordar que también es natural que un desarrollador de sistemas interprete un requisito
ambiguo de la manera más simple posible, para simplificar su implementación. Un claro ejemplo de
estos problemas se puede encontrar en las funciones comunes relacionadas con la experiencia de
usuario:
Historia de Usuario: Como usuario, quiero que la aplicación sea fácil de usar, de modo que no tenga
que pasar mucho tiempo aprendiendo a usarla.
• ¿Qué significa ser “fácil de usar”?

• ¿Fácil para quién?
• ¿Cómo se mide?
• ¿Cómo lo rastreamos?
• ¿Cómo se prueba? ¿Contra qué criterios?
Esto no es algo contra los desarrolladores, sino más bien contra el comportamiento humano. Si
nosotros asumimos algo, otros pueden asumir algo diferente, y eso está bien. Pero el analista es el
responsable de la documentación, por lo que debe ser el mismo analista el que trate de asegurarse

lOMoARcPSD|12847418
de que no hay lagunas de comprensión o puntos grises. Esta es también la razón por la que las
sesiones de Pre-Planificación y Presentación de Historias son muy importantes para asegurarse de
que todo el equipo está en la misma página con respecto a los requisitos, su objetivo de negocio y
cómo implementarlos. Volviendo al ejemplo anterior, podríamos dividir el requisito en varios
nuevos, más fáciles de entender, desarrollar, probar, rastrear y entregar. Uno de ellos podría serlo:
Historia de usuario: Como usuario, quiero que se muestre un tutorial al iniciar sesión por primera
vez, para que pueda ver para qué se utiliza cada opción de la pantalla de inicio.
• Ya sabemos qué mostrar, un tutorial.

• Ya sabemos lo que hay que comprobar, que explica cada opción en la pantalla de inicio.
• Ya sabemos cuando necesita ser mostrado, en el primer inicio de sesión del usuario
(podemos explicar más adelante si el tutorial puede ser omitido, mostrado en otros
momentos, accedido desde alguna sección dentro del menú, etc.)
Volviendo a FR, en principio, la especificación de los requisitos funcionales de un sistema debe ser
completa y coherente. Completa significa que todos los servicios solicitados por el usuario y/u otro
sistema están definidos. La coherencia significa que los requisitos no tienen una definición
contradictoria.
los requisitos funcionales se pueden dividir en:
Los requerimientos del usuario, que según Sommerville (2005) son declaraciones, en lenguaje
natural y en diagramas, de los servicios que se espera que el sistema provea y de las restricciones
bajo las cuales debe operar.
Los requerimientos del sistema, que según Sommerville (2005) establecen con detalle los servicios
y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado
especificación funcional, debe ser preciso. Este sirve como un contrato entre el comprador del
sistema y el desarrollador de software.
No Funcionales
Se trata de requisitos que no se refieren directamente a las funciones específicas suministradas por
el sistema (características de usuario), sino a las propiedades del sistema: rendimiento, seguridad,
disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo”
lo hace. Alternativamente, definen restricciones del sistema tales como la capacidad de los
dispositivos de entrada/salida y la representación de los datos utilizados en la interfaz del sistema.
Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones

presupuestarias, políticas organizacionales, la necesidad de interoperabilidad con otros sistemas de
software o hardware, o factores externos tales como regulaciones de seguridad, políticas de
privacidad, entre otros.

lOMoARcPSD|12847418
Existen diferentes tipos de requisitos y se clasifican según sus implicaciones:
Como podemos ver en el diagrama anterior hay 3 subcategorías de los requerimientos no

funcionales:
• Requisitos del Producto: Especifican el comportamiento del producto, como los requisitos
de rendimiento sobre la velocidad de ejecución del sistema y la cantidad de memoria
necesaria, los requisitos de fiabilidad que establecen la tasa de fallos para que el sistema
sea aceptable, los requisitos de portabilidad y los requisitos de usabilidad.
• Requisitos Organizativos: Se derivan de las políticas y procedimientos existentes en la
organización cliente y en la organización del desarrollador: estándares en los procesos a
utilizar; requisitos de implementación tales como lenguajes de programación o el método
de diseño a utilizar; y requisitos de entrega que especifican cuándo se entregará el producto
y su documentación.
• Requisitos Externos: Se derivan de factores externos al sistema y a su proceso de desarrollo.
Incluyen los requisitos de interoperabilidad que definen la forma en que el sistema
interactúa con los demás sistemas de la organización; los requisitos legales que deben
seguirse para garantizar que el sistema funciona dentro de la ley; y los requisitos éticos.
Estos últimos se imponen al sistema para asegurar que será aceptado por el usuario.
A veces, en la práctica, la especificación cuantitativa de este tipo de requisitos es difícil. No siempre

es posible para los clientes traducir sus objetivos en requisitos cuantitativos. Para algunos de ellos,
como el mantenimiento, puede que no se pueda utilizar ninguna métrica; el coste de la verificación
objetiva de los requisitos cuantitativos no funcionales puede ser muy elevado. Y es por eso que
también es muy importante ser muy cuidadoso al documentarlos. Un analista puede utilizar el

lOMoARcPSD|12847418
apoyo del equipo de desarrollo y del equipo de pruebas para definir criterios mensurables con el fin
de saber cuándo un requisito puede ser marcado con éxito como “Hecho”.
Al igual que hablamos de requisitos funcionales, la generalización nunca es buena, pero en este caso
es aún más importante. ¿Por qué? Porque el resultado de un desarrollo de requisitos no funcionales
puede no ser explícito para el usuario final.
Técnicas para redactar requerimientos del usuario:
• Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al

formato. Estandarizar el formato significa reducir la probabilidad de las omisiones y hacer
que los requerimientos sean fáciles de verificar.
• Utilizar el lenguaje de forma consistente. En particular, distinguir entre los requerimientos
deseables en futuro condicional.
• Distinguir entre los requisitos obligatorios y los deseables.
• Resaltar el texto (con negritas o itálicas) para ver las partes clave del requerimiento.
• Evitar, hasta donde sea posible, utilizar el lenguaje “técnico” de computación. Sin
embargo, en los requerimientos del usuario será inevitable utilizar términos técnicos
detallados provenientes del dominio de aplicación del sistema.
Bibliografía
Requeridos Blog. (2018). Requerimientos Funcionales y No Funcionales, ejemplos y tips. Recuperado el 29 de septiembre del 2020, de
Medium Sitio web: https://medium.com/@requeridosblog/requerimientos-funcionales-y-no-funcionales-ejemplos-y-tips-aa31cb59b22a
Dra. Yulia Ledeneva. (2011). Isw5 requerimientos. Recuperado el 28 de septiembre del 2020, de UAP UAEM Tianguistenco Sitio web:
https://es.slideshare.net/AnthonyRivas1/isw5-requerimientos
Demián Gutierrez. (2013). Clase 04a requerimientos introduccion. Recuperado el 28 de septiembre del 2020, de Universidad de los Andes
Sitio web: https://es.slideshare.net/piojosnos/clase-04a-requerimientosintroduccion
rvillarroel16. (2017). Requerimientos Funcionales y No Funcionales. Recuperado el 28 de septiembre del 2020, de Ingeniería de Software
Utmachala Sitio web: https://ingenieriadesoftwareutmachala.wordpress.com/2017/01/20/requerimientos-funcionales-y-no-
funcionales/
Fredy Castañeda Sánchez. (2015). Capítulo 5 - Requerimientos del Software. Recuperado el 28 de septiembre del 2020, de Universidad
Veracruzana Sitio web: https://www.uv.mx/personal/fcastaneda/files/2015/08/F_Capitulo_5_Requerimientos_del_software.pdf

Tipos de Requisitos de Software

Cargado por

Copyright:

Formatos disponibles

Tipos de Requisitos de Software

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tipos de Requisitos de Software

Cargado por

Copyright:

Formatos disponibles

lOMoARcPSD|12847418

Tipos de Requisitos de Software

Analísis Avanzado de Software (Instituto Tecnológico de Tijuana)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

TECNOLÓGICO NACIONAL DE MÉXICO

ALUMNO Y NO. DE CONTROL

Descargado por Waldir Ozuna ([email protected])

La elicitación, análisis y especificación de requisitos es el proceso del estudio de las necesidades de

Muchos de los problemas en la ingeniería de software (hablando sobre el proceso de desarrollo en

• ¿Qué significa ser “fácil de usar”?

Descargado por Waldir Ozuna ([email protected])

• Ya sabemos qué mostrar, un tutorial.

los requisitos funcionales se pueden dividir en:

Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones

Descargado por Waldir Ozuna ([email protected])

Existen diferentes tipos de requisitos y se clasifican según sus implicaciones:

Como podemos ver en el diagrama anterior hay 3 subcategorías de los requerimientos no

A veces, en la práctica, la especificación cuantitativa de este tipo de requisitos es difícil. No siempre

Descargado por Waldir Ozuna ([email protected])

Técnicas para redactar requerimientos del usuario:

• Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al

Descargado por Waldir Ozuna ([email protected])

También podría gustarte