INSTITUTO TECNOLOGICO

SUPERIOR DE LAS CHOAPAS

INGENIERIA EN SISTEMAS COMPUTACIONALES

INGENIERIA DE REQUISITOS
CONCEPTOS Y CARACTERÍSTICAS DE
LOS REQUERIMIENTOS

Ariana Uscanga Córdova

Fundamentos de Ingeniera del Software
INSTITUTO TECNOLOGICO SUPERIOR
DE LAS CHOAPAS
ingeniería En Sistemas Computacionales
MATERIA
Fundamentos de ingeniería del software
DOCENTE
Dr. Alfonso Gómez Sánchez
ALUMNA
Ariana Uscanga Córdova
ACTIVIDAD
Problemática
LUGAR
Instituto Tecnológico Superior De Las Choapas
GRADO Y GRUPO
5B
Requerimientos funcionales
Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería
reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en
situaciones específicas. En algunos casos los requerimientos funcionales también expresan
lo que el sistema no debe hacer. Refieren lo que el sistema debe hacer.
Los requerimientos funcionales de un sistema son aquellos que describen cualquier
actividad que este deba realizar, en otras palabras, el comportamiento o función particular
de un sistema o software cuando se cumplen ciertas condiciones.
Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas,
descripciones de los flujos de trabajo a ser desempeñados por el sistema y otros
requerimientos de negocio, cumplimiento, seguridad u otra índole
Requerimientos no funcionales
Los requerimientos no funcionales representan características generales y restricciones de
la aplicación o sistema que se esté desarrollando.
Suelen presentar dificultades en su definición dado que su conformidad o no conformidad
podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su
definición con criterios de aceptación que se puedan medir.
Son requerimientos que no se relacionan directamente con los servicios específicos que el
sistema entrega a sus usuarios, pueden relacionarse con propiedades emergentes del
sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento.
Requerimientos de usuario y de sistema
Enunciados en un lenguaje natural junto con diagramas, acerca de qué servicio esperan los
usuarios del sistema y de las transiciones con las cual este debe operar.
Un requerimiento debe cumplir ciertos criterios y características:
• Único: El requerimiento debe poder ser interpretado inequívocamente de una sola
manera.
• Verificable: Su implementación debe poder ser comprobada. El test debe dar como
resultado CORRECTO o INCORRECTO.
• Claro: Los requerimientos no deben contener terminología innecesaria. Deben ser
establecidos de forma clara y simple.
• Viable (realista y posible): El requerimiento debe ser factible según las restricciones
actuales de tiempo, dinero y recursos disponibles.
 • Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita
el requerimiento o bien si la retirada de dicho requerimiento no tiene ningún efecto.
Además de los criterios para los requerimientos individuales, para el conjunto de ellos debe
cumplirse:
• Independiente: Para comprender el requerimiento no debe ser necesario el
conocimiento de otro.
• Consistente: No debe existir ningún conflicto entre requerimientos. Los conflictos
pueden ser:
• Directos: Cuando ante una misma situación, cabe esperar comportamientos
diferentes.
• Indirectos: Se produce cuando no es posible cumplir con dos requisitos al mismo
tiempo, aunque describan funcionalidades distintas.
• No redundante: Cada requerimiento debe ser formulado una sola vez, y no
sobreponerse con otros requerimientos.
• Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las
condiciones que puedan ocurrir.
CARACTERISTICAS
Las características de un buen SRS son:
Cada característica se aborda con mayor detalle a continuación:
Sin ambigüedad. Una SRS es inequívoca si- y solo si- cada requisito en ella tiene una única
interpretación.
• Como mínimo, esto requiere que cada característica del producto final se describa
utilizando un único termino.
• En los casos en los que un término utilizado en un contexto particular pueda tener
múltiples significados, el termino debe incluirse en un glosario donde se especifique
su significado.
Completa. Un SRS es completo si posee las siguientes cualidades:
• Inclusión de todos los requisitos significativo, ya sean relativos a la funcionalidad, el
rendimiento, las limitaciones de diseño, los atributos o las interrelaciones externas.
• Definición de las respuestas de software a todas las clases realizables de datos de
entrada en todas las clases realizables de situaciones. Obsérvese que es importante
especificar la respuesta a los valores de entrada válidos y no validados.
 • Conformidad con cualquier norma del SRS que le sea aplicable. Si una sección
particular de la norma no es aplicable, el SRS debe incluir el número de sección y
una explicación de porque no es aplicable.
Verificable. Un SRS es verificable si, y solo si, todos los requisitos establecidos en el son
verificables.

• Ejemplos de requisitos no verificables, estas son declaraciones como: a)El producto

debe funcionar bien, o el producto debe tener una buena interfaz humana. Estos
requisitos no pueden verificarse porque es imposible definir los términos bueno o
bien. b)El programa nunca debe entrar en un bucle infinito. Este requisito no es
verificable porque la comprobación de esta cualidad es teóricamente imposible.
Coherente. Un buen SRS es consistente si y solo si ningún conjunto de requisitos
individuales descritos en ella entra en conflicto. Hay tres tipos de conflictos principales en
un SRS:
• Dos o más requisitos pueden describir el mismo objeto del mundo real, pero utilizar
termino diferentes para ese objeto. Por ejemplo, la solicitud de una entrada de
usuarios por parte de un programa puede denominarse “prompt” en un requisito
y “cue” en otro.
• Las características especificadas de los objetos del mundo real pueden entrar en
conflicto. Por ejemplo: 1)El formato de un informe de salida puede describirse en un
requisito como «tabular” pero en otro como “textual” 2) Un requisito puede
establecer que todas las luces deben ser verdes mientras que otro establece que
todas las luces deben ser azules. 3) Puede haber un conflicto lógico o temporal entre
dos acciones específicas. Por ejemplo; a) Un requisito podría especificar que el
programa sumará dos entradas y otro especificar que el programa las
multiplicará. b) Un requisito puede establecer que A debe seguir a B, mientras que
otros requieren que A y B ocurran simultáneamente.
Modificable. Un SRS es modificable si su estructura y estilo son tales que cualquier cambio
necesario en el requisito puede realizarse de forma fácil, completa y coherente. Los cambios
en un SRS generalmente requieren:
• Tener una organización coherente y fácil de usar, con un índice y referencias cruzada
explicitas.
• No ser redundante; es decir, el mismo requisito no debe aparecer en otras partes
en el SRS.
Trazable. Una SRS es trazable si el origen de cada uno de sus requisitos es claro y se facilita
la referencia de cada requisito de la futura documentación de desarrollo o mejora. Se
recomiendan dos tipos de trazabilidad:
 • La trazabilidad hacia atrás (es decir, hacia etapas anteriores de desarrollo) depende
de que cada requisito haga referencia explícita a su fuente en documentos
anteriores.
• La trazabilidad hacia adelante (es decir, hacia todos los documentos generados por
el SRS) depende que cada requisito del SRS tenga un nombre o número de referencia
único.
Utilizable durante la fase de operación y mantenimiento. El SRS debe atender las
necesidades de la fase de operación y mantenimiento, incluyendo la eventual sustitución
del software.
• El mantenimiento suele ser realizado por personal no relacionado con el desarrollo
original. Los cambios locales (correcciones) pueden aplicarse mediante un código. Si
embargo, para los cambios de mayor alcance, la documentación sobre el diseño y
los requisitos es esencial. Esto implica dos acciones:
• El SRS debe ser modificable
• El SRS debe contener un registro de todas las disposiciones especiales que aplican a
los componentes individuales, tales como:
• Su criticidad
• Su relación con las necesidades sólo temporales.
• Su origen
• Este tipo de conocimiento se da por sentado en la organización de desarrollo, pero
a menudo falta en la organización de mantenimiento. Si no se entiende la razón o el
origen de una función, a menudo es imposible realizar un mantenimiento adecuado
del software.
 BIBLIOGRAFIA
Eriksson U. (lunes, 6 de febrero de 2017) “Requerimientos funcionales”, Recuperado de
[Link]
Dominga Canseco. (2014) “Requerimientos del Usuario y Requerimientos del Sistema 3ero
BB”. Recuperado de [Link]
Libertad Delgado (Jul 16, 2021) “Clase 3 características de Un Requerimiento”. Recuperado
de [Link]
requerimiento
Jibaez (Oct 10, 2009) “Gestión de requerimientos II: Características de los requerimientos ”,
Recuperado de [Link]
ii-caracteristicas-de-los-requerimientos/
Deappharma (2, mayo 2022) “Características de un buen SRS (Software Requirements
Specification) especificación de requerimientos de software”, Recuperado de
[Link]
specification-especificacion-de-requerimientos-de-software/