Escuela Militar de Ingeniería

“Mcal. Antonio José de Sucre”

La Paz - Bolivia

“INVESTIGACIÓN - DOCUMENTACIÓN DE
REQUERIMIENTO”

ESTUDIANTE: Reyes Guillen Alejandro Javier

ASIGNATURA: Ingeniería de Software II

CÓDIGO SAGA: A24516-X

C.I.: 12604524 LP

SEMESTRE: Octavo

CARRERA: Ingeniería de Sistemas

La Paz, 11 de septiembre de 2023

 INVESTIGACIÓN – DOCUMENTACIÓN DE
REQUERIMIENTOS
MOSTRAR ESPECIFICACION DE REQUERIMIENTOS, OTRO EJEMPLO DE COMO
DOCUMENTAR, FORMAS DIFERENTES DE DOCUMENTAR LOS
REQUERIMIENTOS

Para la documentación de requerimientos existen diferentes maneras, sin embargo,

existen similitudes entre cada manera, a continuación, se mostrarán dos maneras
diferentes de documentar la especificación de requerimientos de software, la primera es
una forma de documentar encontrada en una fuente de internet, la segunda es una forma
de documentación que está establecida en un estándar:
La norma IEEE830 Especificación de Requerimientos de Software, esta norma se utiliza
en el campo de la ingeniería de software para documentar y comunicar de manera
efectiva los requisitos de un sistema de software a los desarrolladores, diseñadores,
probadores y otros interesados en el proyecto.

PRIMERA FORMA: Fuente: https://www.studocu.com/es-ar/document/instituto-superior-juan-

vucetich/ingenieria-de/documento-de-requerimientos-de-software-plantilla/17302180

CARÁTULA

ÍNDICE
PÁGINA SIGUIENTE

1. Propósito
En esta sección se define el nombre o título del software que se está especificando
en el documento, incluyendo su número de versión o Release. Luego se describe
cuáles componentes o partes del alcance del producto están incluidas en el
documento, estableciendo si este documento cubre la totalidad del software, solo una
parte del sistema, subsistema o subgrupo de procesos.

2. Alcance del producto / Software

Se incluye una corta descripción del alcance del software que se está especificando,
incluyendo:
- Su propósito u objetivo general.
- Beneficios que brinda al área de negocio y organización.
- Objetivos y metas. Es recomendable establecer la relación de los objetivos del
software con los objetivos corporativos y estrategias de negocio. Se puede hacer
referencia a otros documentos, por ejemplo, una definición de alcance o acta de
constitución del proyecto.

3. Referencias
Aquí se pueden incluir otros documentos impresos, documentos o direcciones
electrónicos que complementen la documentación de requerimientos de software, por
ejemplo: Documentos de visión, definición de alcance, otros documentos de
especificación de requerimientos de software, flujogramas, políticas, procedimientos
de la organización, entre otros. Para cada referencia es recomendable incluir el título,
autor, versión, fecha y ubicación física o electrónica.

4. Funcionalidades del producto

Lista de las funcionalidades del software que se están especificando en el documento
de requerimientos. Cada funcionalidad puede estar compuesta por uno o varios
requerimientos funcionales de software. Aquí solo se incluye una lista numerada de
las principales funcionalidades; la información detallada de requerimientos
funcionales se documenta en la sección 7.

5. Clases y características de usuarios

En esta sección se clasifican los usuarios que utilizarán el producto. La clasificación
puede ser en función a la frecuencia de uso, grupo de funcionalidades utilizadas,
privilegios de seguridad, nivel de experiencia y otros parámetros. Se puede usar una
lista para enumerar los usuarios tipo que utilizarán el software, describiendo las
características de cada uno. Para cada tipo de usuario, se pueden mencionar las
funcionalidades de producto (Sección 4) que les sean relevantes.

6. Entorno operativo
En esta sección se describe el entorno operativo en el que se desenvolverá el
sistema, software, módulo o grupo de funcionalidades, mencionando aspectos como
la plataforma de hardware, versiones de sistema operativo y otros sistemas o
componentes con los que debe coexistir.

7. Requerimientos funcionales
Los requerimientos funcionales de un sistema son aquellos que describen cualquier
actividad que este deba realizar, es decir, el comportamiento o función particular de
un sistema o software cuando se cumplen ciertas condiciones. Los requerimientos
funcionales describen una interacción entre el sistema y su ambiente, describen cómo
debe comportarse el sistema ante determinado estímulo. Son declaraciones de los
servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar
a entradas particulares y de cómo debe comportarse en situaciones particulares. En
algunos casos, también pueden declarar explícitamente lo que el sistema no debe
hacer.

En esta sección de la plantilla, ilustramos cómo organizar los requerimientos

funcionales de software por funcionalidad de producto o sistema. Aquí se listan las
funcionalidades y para cada una, a su vez, se listan los requerimientos funcionales.
A continuación, se muestra cómo documentar cada funcionalidad:
 7.1. (Nombre de la funcionalidad 1)
En el título de la funcionalidad, se recomienda utilizar nombres lo más descriptivos
posible para cada funcionalidad. No limitarse a nombrarlas "Funcionalidad 1". Un
buen ejemplo podría ser "Autorización de pedido de compra".

- Descripción: Descripción corta de la funcionalidad.

- Prioridad: Nivel bajo, medio o alto de prioridad. Esta debe ser establecida por el
área funcional.
- Acciones iniciadoras y comportamiento esperado: Secuencia de acciones de
usuario y respuestas esperadas del sistema para esta funcionalidad.
- Requerimientos funcionales: Lista detallada de los requerimientos funcionales
asociados a esta funcionalidad. Para cada requerimiento funcional se establece
cómo debe mostrarse el software y cuáles comportamientos debe desempeñar
para que el usuario pueda realizar la función que necesita. Es recomendable
incluir cómo el software debe responder a condiciones de error y entradas de
datos inválidas. Cada requerimiento debe ser identificado unívocamente, para lo
cual se recomienda usar un número de secuencia, que tenga algún significado y
un formato común a toda la organización. Por ejemplo:

- REQ-1:
- REQ-2:
- REQ-3:

7.2. (Nombre de la funcionalidad 2)

Seguir los mismos lineamientos de la funcionalidad 1 para tantas funcionalidades
tenga el sistema.

7.3. (Nombre de la funcionalidad N)

Seguir los mismos lineamientos de la funcionalidad 1 para tantas
funcionalidades tenga el sistema.

8. Reglas de negocio
Listado de reglas y principios que aplican a todo el conjunto de requerimientos de
software contenidos en el documento. Un ejemplo es cuáles individuos o roles pueden
desempeñar cierta función bajo ciertas circunstancias. Para hacer cumplir las reglas
de negocio, podría ser necesaria la definición de requerimientos funcionales que
aplican a todo el sistema, no a una funcionalidad específica.

9. Requerimientos de interfaces externas

9.1. Interfaces de usuario

Aquí se describen las características de cada interfaz con el usuario.
- Se pueden clasificar por tipos o áreas del sistema con interfaz distinta.
- Pueden incluirse ejemplos de pantallas.
- Describir los estándares de interfaz gráfica (GUI).
 - Guías de estilo sobre organización de pantalla, estándares para botones,
funciones que se mostrarán en todas las pantallas.

9.2. Interfaces de hardware

Información sobre cuáles tipos de dispositivos soporta el sistema, por ejemplo:
Computadoras, dispositivos móviles, impresoras, otros dispositivos.

9.3. Interfaces de software

Aquí se describen las interacciones entre el software y otros componentes,
incluyendo: Otros componentes de software y sistemas, y de ser aplicables bases
de datos, sistemas operativos, herramientas, librerías, componentes de software
comercial, entre otros.

10. Requerimientos no funcionales

Los requerimientos no funcionales son los que especifican criterios para evaluar la
operación de un servicio de tecnología de información, en contraste con los
requerimientos funcionales que especifican los comportamientos específicos.

11. Otros requerimientos

Requerimientos no cubiertos en ninguna otra sección del documento de requerimientos
de software, por ejemplo: Requerimientos de bases de datos, internacionalización,
legales y objetivos de reúso de componentes de software.

12. Glosario
Descripción de términos y siglas necesarios para el entendimiento del documento de
requerimientos de software.

SEGUNDA FORMA: Especificación de Requisitos según el estándar de IEEE 830 - IEEE

Std. 830-1998 - 22 de octubre de 2008

CARÁTULA
SIGUIENTE PÁGINA

FICHA DEL DOCUMENTO

ÍNDICE DEL CONTENIDO
1. INTRODUCCIÓN
La introducción de la especificación de requisitos de software (SRS) debe
proporcionar una vista general de la SRS. Debe incluir el objetivo el alcance las
definiciones y acrónimos, las referencias, y la vista general del SRS.

1.1. Propósito
• Propósito del documento
• audiencia a la que va dirigido

1.2. Alcance

Identificación del producto a desarrollar mediante un nombre

consistencia con definiciones similares de documentos de mayor nivel (ejemplo
de descripción del sistema) que puedan existir.

1.3. Personal involucrado

Nombre
Rol
Categoría Profesional
Responsabilidades
Información de contacto
Aprobación

Relación de personas involucradas en el desarrollo del sistema, con información

de contacto.
Esta información es útil para que el gestor del proyecto pueda localizar a todos
los participantes y recabar la información necesaria para la obtención de
requisitos, validaciones de seguimiento, etc.

1.4. Definiciones, acrónimos y abreviaturas

Definición de todos los términos, abreviaturas y acrónimos necesarios para

interpretar apropiadamente este documento. En ella se pueden indicar
referencias a uno o más apéndices, o a otros documentos.
 1.5. Referencias

Referencia Título Ruta Fecha Autor

Relación completa de todos los documentos relacionados en la especificación de

requisitos de software, identificando de cada documento el título, referencia,
fecha y organización que lo proporciona.

1.6. Resumen

• Descripción del contenido del resto del documento

• Explicación de la organización del documento

2. DESCRIPCIÓN GENERAL

2.1. Perspectiva del producto

Indicar si es un producto independiente o parte de un sistema mayor punto en el

caso de tratarse de un producto que forma parte de un sistema mayor coma un
diagrama que sitúe el producto dentro del sistema e identifique sus conexiones
facilitando la comprensión.

2.2. Funcionalidad del producto

Resumen de las funcionalidades principales que el producto debe realizar coma

sin entrar en información de detalle.
en ocasiones la información de esta sección puede tomarse de un documento de
especificación del sistema de mayor nivel (ej. Requisitos del sistema).
las funcionalidades deben estar organizadas de manera que el cliente o cualquier
interlocutor pueda entenderlo perfectamente punto para ello se puede utilizar
métodos textuales o gráficos.

2.3. Características de los usuarios

Tipo de usuario
Formación
Habilidades
Actividades

Descripción de los usuarios del producto, incluyendo nivel educacional,

experiencia y experiencia técnica.
 2.4. Restricciones
Descripción de aquellas limitaciones a tener en cuenta a la hora de diseñar y
desarrollar el sistema tales como el empleo de determinadas metodologías de
desarrollo con lenguajes de programación normas particulares, restricciones de
hardware coma de sistema operativo, etc.

2.5. Suposiciones y dependencias

Descripción de aquellos factores que coma si cambian, pueden afectar a los
requisitos. por ejemplo, una Asunción puede ser que determinado sistema
operativo está disponible para el hardware requerido. De hecho, coma si el
sistema operativo no estuviera disponible, la SRS debería modificarse.

2.6. Evolución previsible del sistema

Identificación de futuras mejoras al sistema coma que podrán analizarse e
implementarse en un futuro.

3. Requisitos específicos
Esta es la sección más extensa e importante del documento.
Debe contener una lista detallada y completa de los requisitos que debe cumplir el
sistema desarrollar. el nivel de detalle de los requisitos debe ser el suficiente para que
el equipo de desarrollo pueda diseñar un sistema que satisfaga los requisitos y los
encargados de las pruebas puedan determinar si éstos se satisfacen.
los requisitos se dispondrán en forma de listas numeradas para su identificación,
seguimiento, trazabilidad y validación (ej. RF 10, RF 11, etc.).

Y realizar a continuación la descripción del requisito.

hoy la distribución de los párrafos que forman este punto puede diferir del propuesto
en esta plantilla coma si las características del sistema aconsejan otra distribución
para ofrecer mayor claridad en la exposición.

3.1. Requisitos comunes de los interfaces

Descripción detallada de todas las entradas y salidas del sistema de software.

3.1.1. Interfaces de usuario

Hoy describir los requisitos del interfaz de usuario para el producto punto esto
puede estar en la forma de descripciones del texto o pantallas del interfaz.
Por ejemplo, posiblemente el cliente ha especificado el estilo y los colores del
 producto. Describa exactamente como el producto aparecerá en su usuario
previsto

3.1.2. Interfaces de hardware

Espera especificar las características lógicas para cada interfaz entre el
producto y los componentes de hardware del sistema. se incluirán
características de configuración.

3.1.3. Interfaces de software

Indicar si hay que integrar el producto con otros productos de software, para
cada producto se software debe especificarse lo siguiente:
- Descripción del producto software utilizado
- propósito del interfaz
- definición del interfaz: contiendo y formato
3.1.4. Interfaces de comunicación
Describir los requisitos del interfaz de comunicación si hay comunicaciones
con otros sistemas y cuáles son los protocolos de comunicación.

3.2. Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir
información, procesarla y producir resultados.
En ellas se incluye:
o Comprobación de validez de las entradas
o Secuencia exacta de operaciones
o Respuesta a situaciones anormales (desbordamientos,
recuperación de errores)
o Parámetros
o Generación de salidas
o Relaciones entre entradas y salidas
o Especificación de los requisitos lógicos para la información que será
almacenada en base de datos

Los requisitos funcionales pueden ser divididos en subsecciones

3.2.1. Requisito funcional 1

3.2.2. Requisito funcional 2
3.2.3. Requisito funcional n

3.3. Requisitos no funcionales

3.3.1. Requisitos de rendimiento

Especificación de los requisitos relacionados con la carga que se espera que

tenga que soportar el sistema. Todos estos requisitos deben ser mesurables.
 3.3.2. Seguridad
Especificación de elementos que protegerán al software de accesos, usos y
sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas
o accidentales. Los requisitos pueden especificar:
- Empleo de técnicas criptográficas.
- Registro de ficheros con looks de actividad.
- Asignación de determinadas funcionalidades a determinados
módulos
- Restricciones de comunicación entre determinados módulos
- Comprobaciones de integridad de información crítica

3.3.3. Fiabilidad
Especificación de los factores de fiabilidad necesaria del sistema esto se
expresa generalmente como el tiempo entre los incidentes permisibles, o el
total de incidentes permisible.

3.3.4. Disponibilidad
Especificación de los factores de disponibilidad final exigidos al sistema.
normalmente expresados en porcentaje de tiempo en los que el software
tiene que mostrar disponibilidad.

3.3.5. Mantenibilidad
Identificación del tipo de mantenimiento necesario del sistema.
especificación de quien debe realizar las tareas de mantenimiento y
especificación de cuándo debe realizarse las tareas de mantenimiento

3.3.6. Portabilidad
Hoy especificación de atributos que debe presentar el software para facilitar
su traslado a otras plataformas u entornos.

3.4. Otros Requisitos

Cualquier otro requisito que no encaje en ninguna de las secciones anteriores,
Por ejemplo:
- Requisitos culturales y políticos
- Requisitos legales

4. Apéndices

Pueden contener todo tipo de información relevante para la SRS, pero qué,
propiamente, no forme parte de la SRS.