IEEE Std 830-1998
Software Requirements Specification (SRS)
El objetivo de este documento se relaciona con el contenido y cualidades de una buena especificación
de requisitos (SRS). Este estándar está dirigido a especificar los requisitos de software a ser
desarrollado, pero también se puede aplicar para la selección de productos de software comercial.
Esta es una práctica recomendada para la escritura de especificaciones de requisitos de software. En
él se describe el contenido y las cualidades de una buena especificación de requerimientos de software
(SRS) y presenta varias muestras SRS.
El SRS es una especificación para un producto software determinado, programa o conjunto de
programas que realiza ciertas funciones en un entorno específico. El SRS puede escribirse por uno o
más representantes del proveedor, uno o más representantes del cliente, o por ambos.
Introducción
Esta recomendación describe los criterios recomendados para la especificación de requisitos de
software. Se basa en un modelo en el que el resultado del proceso de especificación de requisitos de
software es un documento de especificación inequívoca y completa. Se espera que ayude a:
a) Los clientes de Software para describir con precisión lo que desean obtener;
b) Los proveedores de software para entender exactamente lo que quiere el cliente;
c) Las personas para lograr los siguientes objetivos:
1) Desarrollar una especificación de requisitos software estándar (SRS) para sus propias
organizaciones;
2) Definir el formato y el contenido de sus especificaciones de requisitos de software específicos;
3) Desarrollar elementos de apoyo locales adicionales, tales como una lista de comprobación de la
calidad de SRS, o un manual de SRS.
Para los clientes, proveedores y otras personas, un buen SRS debe proporcionar varios beneficios
específicos, tales como los siguientes:
Establecer las bases para el acuerdo entre los clientes y los proveedores en lo que el producto
de software es hacer. La descripción completa de las funciones a realizar por el software
especificado en el SRS ayudará a los usuarios potenciales, para determinar si el software
especificado se ajuste a sus necesidades y la forma en que el software debe ser modificado
para satisfacer sus necesidades.
Reducir el esfuerzo de desarrollo. La preparación del SRS obliga a los diversos grupos
interesados en la organización del cliente a considerar rigurosamente todos los requisitos
antes de que el diseño comience y reduce posteriores rediseño, recodificación, volver a
probar. Una cuidadosa revisión de los requisitos en el SRS puede revelar omisiones,
malentendidos e incoherencias al principio del ciclo de desarrollo cuando estos problemas son
más fáciles de corregir.
Proporcionar una base para estimar los costos y calendarios. La descripción del producto a ser
desarrollado como se indica en el SRS es una base realista para la estimación de los costos del
proyecto y puede ser usado para obtener la aprobación de las ofertas o de las estimaciones de
precios.
Proporcionar una base de referencia para la validación y verificación. Las organizaciones
pueden desarrollar su validación y verificación de planes de manera mucho más productiva
desde un buen SRS. Como parte del contrato de desarrollo, el SRS proporciona una base
sobre la cual se puede medir el cumplimiento.
Facilitar la transferencia. El SRS hace que sea más fácil de transferir el producto de software
para los nuevos usuarios o nuevas máquinas. Los clientes por lo tanto es más fácil de
transferir el software a otras partes de la organización, y los proveedores les resulta más fácil
la transferencia a nuevos clientes.
Sirve como base para la mejora. Debido a que el SRS discute el producto pero no el proyecto
que lo desarrolló, el SRS sirve como base para la mejora posterior del producto acabado. El
SRS puede necesitar ser alterado, pero proporciona una base para la evaluación continua de la
producción.
Consideraciones para la producción de un buen SRS
Esta cláusula se proporciona información básica que se debe considerar al escribir un SRS. Esto
incluye la siguiente:
a) Naturaleza del SRS
b) Medio Ambiente del SRS
c) Características de un buen SRS
d) La preparación conjunta del SRS
e) Evolución SRS
f) Desarrollo de Prototipos
g) Integrar diseño en el SRS
h) Integrar requisitos del proyecto en el SRS.
Naturaleza del SRS
El SRS es una especificación para un determinado producto software, programa o conjunto de
programas que realiza ciertas funciones en un entorno específico. El SRS puede escribirse por uno o
más representantes del proveedor, uno o más representantes del cliente, o por ambos (lo cual es
recomendado).
Las cuestiones básicas que el escritor SRS (s) deberá abordar son los siguientes:
a) Funcionalidad. ¿Qué es el software supone que debe hacer?
b) Interfaces externas. ¿Cómo funciona el software de interactuar con la gente, el hardware del
sistema, otro tipo de hardware y otro software?
c) Funcionamiento. ¿Cuál es la velocidad, disponibilidad, tiempo de respuesta, el tiempo de
recuperación de las diversas funciones de software, etc.?
d) Atributos. ¿Cuáles son las consideraciones de portabilidad, la corrección, mantenimiento,
seguridad, etc.?
e) Limitaciones de diseño impuestas en una implementación. ¿Existen normas exigidas en lenguaje de
implementación, las políticas de integridad de la base de datos, los límites de los recursos, el entorno
operativo (s), etc.?
En el SRS se debe evitar relacionar cualquier requisito de diseño o de proyecto.
Ambiente del SRS
El software puede contener esencialmente toda la funcionalidad del proyecto o puede ser parte de un
sistema más grande. En el último caso, normalmente habrá un SRS de la cual se indicará las
interfaces entre el sistema y su parte de software, y colocará el rendimiento externo y requisitos de
funcionalidad de la parte de software. Por supuesto, el SRS debe entonces estar de acuerdo y ampliar
estos requisitos del sistema.
Dado que el SRS tiene un papel específico que desempeñar en el proceso de desarrollo de software, el
escritor SRS (s) se debe tener cuidado de no ir más allá de los límites de dicha función. Esto significa
que el SRS:
a) Debe definir correctamente todos los requisitos de software. Un requisito de software puede existir
debido a la naturaleza de la tarea que hay que resolver o debido a una característica especial del
proyecto.
b) No debe describir detalles de diseño o implementación. Estos deben ser descritos en la etapa de
diseño del proyecto.
c) No debe imponer restricciones adicionales sobre el software. Se especifican adecuadamente en
otros documentos, como un plan de aseguramiento de la calidad del software.
Por lo tanto, un SRS correctamente escrito limita la gama de diseños válidos, pero no especifica
diseño particular.
Características de un buen SRS
Un SRS debe ser:
a) Correcto
b) Sin ambigüedades
c) Completo
d) Consistente
f) Verificable
g) Modificable
h) Trazable.
Tabla de contenido del documento de especificación de requisitos
1. introducción
1.1 Objetivo
a) Delimitar el propósito del SRS;
b) Especificar la audiencia prevista para el SRS.
1.2 Ámbito de aplicación
a) Identificar el producto software que se produce por su nombre.
b) Explicar lo que el producto software será, y si es necesario, no será
c) Describir la aplicación del software especificado, incluyendo beneficios pertinentes, objetivos y
metas;
d) Ser coherente con las declaraciones similares en especificaciones de nivel superior (si existen).
1.3 Definiciones, acrónimos y abreviaturas
1.4 Referencias
a) Proporcionar una lista completa de todos los documentos referenciados en el SRS en otra
parte;
b) Identificar cada documento por título, número de informe (si procede), fecha, y la organización
de edición;
c) Especificar las fuentes de donde se pueden obtener las referencias.
1.5 Información general
a) Describir lo que el resto del SRS contiene;
b) Explicar cómo el SRS es organizado.
2. Descripción general
2.1 Perspectiva del producto
Esta subdivisión del SRS debe poner el producto en perspectiva con otros productos. Si el
producto es independiente y totalmente autónomo, que debe indicarse aquí. Si el SRS define un
producto que es un componente de un sistema mayor, como ocurre con frecuencia, a
continuación, esta subdivisión debe relacionar los requisitos de ese sistema más grande a la
funcionalidad del software y debe identificar las interfaces entre dicho sistema y el software. Un
diagrama de bloques que muestra los componentes principales del sistema más grande,
interconexiones, y las interfaces externas puede ser útil. Esta sub-sección también debe describir
cómo el software opera dentro de diversas limitaciones. Por ejemplo, estas limitaciones pueden
incluir:
2.1.1 Las interfaces del sistema;
Se debe listar cada interfaz del sistema e identificar la funcionalidad del software para
llevar a cabo los requisitos del sistema y la descripción de la interfaz para que coincida con
el sistema.
2.1.2 Las interfaces de usuario;
Se relaciona con las características lógicas de cada interfaz entre el producto de software y
sus usuarios. Esto incluye las características de configuración (pe., formatos requeridos de
pantalla, página o diseños de ventana, el contenido de los informes, menús o
disponibilidad de las teclas de función programables) necesarias para cumplir los requisitos
de software.
Se deben considerar todos los aspectos de la optimización de la interfaz con el usuario del
sistema. Esto puede comprender simplemente una lista de funciones por hacer y no hacer,
en el aspecto que tendrá el sistema para el usuario. Un ejemplo puede ser un requisito
para la opción de mensajes de error largos o cortos. Al igual que todos los demás, estos
requisitos deben ser verificables, por ejemplo, "un empleado mecanógrafo grado 4 puede
hacer la función de X en Z min después de 1 h de la formación" en lugar de "un
mecanógrafo puede hacer la función de X." (Esto también se puede especificar como
atributos del sistema en una sección titulada Facilidad de Uso.)
2.1.3 Las interfaces de hardware;
Esto debe especificar las características lógicas de cada interfaz entre el producto de
software y los componentes de hardware del sistema. Esto incluye características de
configuración (número de puertos, conjuntos de instrucciones, etc.). También cubre temas
tales como qué dispositivos deben ser compatibles, cómo van a ser apoyados y protocolos.
2.1.4 Las interfaces de software;
Se debe especificar el uso de otros productos de software necesarios (pe. un DBMS, un
sistema operativo, o un paquete matemático) y las interfaces con otros sistemas de
aplicación (pe., la vinculación entre un sistema de cuentas por cobrar y un sistema
contable). Para cada producto de software requerido, se debe proporcionar: Nombre;
mnemotécnico; Número de especificación, el número de versión; Fuente.
Para cada interfaz, debe proporcionar lo siguiente:
La discusión de la finalidad del software de interconexión en relación con este producto de
software. La definición de la interfaz, en términos de contenido de los mensajes y el
formato. No es necesario detallar cualquier interfaz bien documentado, pero se requiere
una referencia al documento de la definición de la interfaz.
2.1.5 Interfaces de comunicaciones;
Esto debe especificar las diversas interfaces de comunicaciones, tales como protocolos de
red locales, etc.
2.1.6 De memoria;
Esto debe especificar las características y los límites de la memoria primaria y secundaria
aplicables.
2.1.7 Operaciones;
Esto debe especificar las operaciones normales y especiales requeridos por el usuario, tales
como:
a) Las diversas modalidades de operaciones de la organización de usuarios (por
ejemplo, las operaciones iniciadas por el usuario);
b) Los períodos de las operaciones interactivas y períodos de operaciones
desatendidas;
c) Las funciones de apoyo de procesamiento de datos;
d) Las operaciones de backup y recuperación.
2.1.8 Los requisitos de adaptación del sitio.
a) Definir los requisitos para cualquier dato o secuencias de inicialización que son
específicos para un sitio determinado, modo de misión, o de funcionamiento (por
ejemplo, los valores de la red, los límites de seguridad, etc.);
b) Especificar las características relacionadas con la misión el sitio, que se debe
modificadas para adaptar el software a una particular instalación.
2.2 Funciones del producto
Esta sub-sección del SRS debe proporcionar un resumen de las principales funciones que el
software ejecutará. Por ejemplo, un SRS para un programa de contabilidad puede utilizar esta
parte para abordar el mantenimiento de cuenta del cliente, el estado del cliente y la preparación
de la factura sin mencionar la gran cantidad de detalles que cada una de estas funciones
requiere.
A veces el resumen de funciones necesario para esta parte puede ser tomado directamente de la
sección de la especificación de nivel superior (si existe) que asigna a funciones particulares del
producto de software. Por claridad, se debe en cuenta:
a) Las funciones deben organizarse de tal forma que la lista de funciones sea comprensible
para el cliente o para cualquier otra persona que lea el documento.
b) Métodos textuales o gráficos pueden ser usados para mostrar las distintas funciones y sus
relaciones. Tal diagrama no está destinado a mostrar un diseño del producto sino que
simplemente muestra las relaciones lógicas entre las variables.
2.3 Características de los usuarios
Esta subdivisión del SRS debe describir las características generales de los usuarios previstos del
producto, incluyendo el nivel de educación, experiencia y conocimientos técnicos. No se debe
utilizar para indicar los requisitos específicos, sino más bien debe proporcionar las razones por las
cuales ciertos requisitos específicos se especifican.
2.4 Limitaciones
Esta subdivisión del SRS debe proporcionar una descripción general de otras cosas que van a
limitar las opciones de sistema operativo para desarrolladores. Estos incluyen:
a) Políticas regulatorias;
b) Limitaciones de hardware (por ejemplo, los requisitos de tiempo de señal);
c) Interfaces a otras aplicaciones;
d) Funcionamiento en paralelo;
e) Funciones de auditoría;
f) Funciones de control;
g) Requisitos lingüísticos de orden superior;
h) Protocolos de intercambio de señalización (por ejemplo, XON-XOFF, ACK-NACK);
i) Requisitos de fiabilidad;
j) Criticidad de la aplicación;
k) Consideraciones de seguridad.
2.5 Suposiciones y dependencias
Esta subdivisión del SRS debe enumerar cada uno de los factores que afectan a los requisitos
establecidos en el SRS. Estos factores no diseñan limitaciones en el software, pero cualquier
cambio en ellos que pueden afectar a los requisitos en el SRS. Por ejemplo, una hipótesis puede
ser que un sistema operativo específico estará disponible en el hardware designado para el
producto de software. Si, de hecho, el sistema operativo no está disponible, el SRS tendría que
cambiar en consecuencia.
3. Requisitos específicos
Esta sección del SRS debe contener todos los requisitos de software a un nivel de detalle suficiente
para dar a los diseñadores objetivos de diseño y para los probadores comprobar que el sistema
cumple con los requisitos.
A lo largo de esta sección, cada requisito declarado debe ser externamente perceptible por los
usuarios, operadores u otros sistemas externos. Estos requisitos deben incluir como mínimo una
descripción de cada entrada (estímulo) en el sistema, cada salida (respuesta) del sistema y todas
las funciones realizadas por el sistema en respuesta a una entrada o en apoyo de una salida. Como
esto es a menudo la parte más grande y más importante del SRS, se debe considerar que todos los
requisitos deben identificados en forma única y que se debe prestar especial atención a su
organización para maximizar su legibilidad.
3.1 Interfaces externas
Esto debe ser una descripción detallada de todas las entradas y salidas en el sistema de software.
Se debe complementar las descripciones de la interfaz anteriormente relacionadas y no se debe
repetir información. Se debe incluir tanto contenido y el formato de la siguiente manera:
a) Nombre de la pieza;
b) Descripción del objeto;
c) Fuente de entrada o destino de la producción;
d) Rango válido, exactitud y/o la tolerancia;
e) Las unidades de medida;
f) Plazos;
g) Relaciones con otras entradas/salidas;
h) Los formatos de pantalla/organización;
i) Los formatos de ventana/organización;
j) Los formatos de datos;
k) Formato de comandos;
l) Mensajes finales.
3.2 Funciones (Requisitos funcionales)
Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el
software, en la aceptación, procesamiento de los insumos y la generación de salidas. Estos
generalmente aparecen como declaraciones "deberá" que comienzan con "El sistema deberá …".
Estos incluyen:
a) Validez de los controles de los insumos
b) La secuencia exacta de las operaciones
c) Las respuestas a las situaciones anormales, incluyendo
1) Overflow
2) Servicios de comunicación
3) Tratamiento de errores y recuperación
d) El efecto de parámetros.
e) Relación de las salidas a las entradas, incluyendo
1) Secuencias de Entrada/salida
2) Las fórmulas para la entrada a la conversión de salida.
Puede ser apropiado dividir los requisitos funcionales en sub-funciones o subprocesos, lo cual no
implica que el diseño de software también se dividirá así.
3.3 Requisitos de desempeño
Se debe especificar tanto los requisitos numéricos dinámicos y estáticos, localizados en el
software o en la interacción humana con el software en su conjunto. Los requisitos numéricos
estáticos pueden incluir los siguientes:
a) El número de terminales a ser soportadas.
b) El número de usuarios simultáneos a ser soportados.
c) La cantidad y tipo de información a ser manejada.
Los requisitos numéricos estáticos se identifican a veces en una sección separada titulada
Capacidad. Los requisitos numéricos dinámicos pueden incluir, por ejemplo, el número de
transacciones, tareas y cantidad de datos que se procesan dentro de ciertos plazos para
condiciones normales y pico de carga de trabajo. Todos estos requisitos deben expresarse en
términos mensurables.
Por ejemplo,
El 95% de las transacciones deben ser procesadas en menos de 1 s.
En lugar de,
El operador no tiene que esperar a que la transacción sea completada.
4.3 Requisitos lógicos de base de datos
Se debe especificar los requisitos lógicos para cualquier información que se va a colocar en una
base de datos. Esto puede incluir la siguiente:
a) Tipos de información usada por las diversas funciones;
b) La frecuencia de uso;
c) Capacidades de acceso;
d) Las entidades de datos y sus relaciones;
e) Las restricciones de integridad;
f) Los requisitos de retención de datos.
4.4 Restricciones del diseño
Se debe especificar las restricciones de diseño que pueden ser impuestas por otras normas,
limitaciones de hardware, etc.
4.5 Cumplimiento de las normas
Esta subdivisión debe especificar los requisitos derivados de las normas o reglamentos vigentes.
Se pueden incluir los siguientes:
a) Formato del informe;
b) Los datos de nombres;
c) Los procedimientos de contabilidad;
d) el seguimiento de auditoría.
Por ejemplo, esto podría especificar el requisito de software para rastrear la actividad de
procesamiento.
Dichos rastros son necesarios para algunas aplicaciones para satisfacer las normas
reglamentarias o financieras mínimas. Un requisito de rastro de auditoría puede ser, por ejemplo,
que todos los cambios en una base de datos de la nómina deban registrarse en un archivo de
seguimiento con valores anteriores y posteriores.
4.6 Atributos del sistema de software.
Hay un número de atributos de software que puede servir como requisitos. Es importante que los
atributos requeridos se puedan especificar para que su logro se pueda verificar de manera
objetiva.
4.6.1 Confiabilidad
Se debe especificar los elementos necesarios para establecer la confiabilidad requerida del
sistema de software en el momento de la entrega.
4.6.2 Disponibilidad
Se debe especificar los factores necesarios para garantizar un nivel de disponibilidad definida para
todo el sistema, tales como punto de control, la recuperación, y reiniciar.
4.6.3 Seguridad
Esto debe especificar los factores que protegen el software del acceso accidental o intencional,
uso, modificación, destrucción o divulgación. Los requisitos específicos en esta área podrían
incluir la necesidad de:
a) Utilizar algunas técnicas criptográficas;
b) Mantener registro específico o conjuntos de datos de historia;
c) Asignar determinadas funciones a los diferentes módulos;
d) restringir las comunicaciones entre algunas áreas del programa;
e) Comprobar la integridad de los datos de las variables críticas.
4.6.4 Mantenibilidad
Se deben especificar atributos de software relacionados con su facilidad de mantenimiento. Puede
haber alguna necesidad de cierta modularidad, las interfaces, la complejidad, etc. Los requisitos
no deben ser colocados aquí sólo porque se piensa que son buenas prácticas de diseño.
4.6.5 Portabilidad
Esto debe especificar atributos de software que relaciona a la facilidad de portar el software a
otras máquinas de acogida y/o sistemas operativos. Esto puede incluir la siguiente:
a) Porcentaje de los componentes con el código de host-dependiente;
b) Porcentaje de código que depende de acogida;
c) El uso de un lenguaje portable probada;
d) El uso de un compilador en particular o subconjunto de idiomas;
e) El uso de un sistema operativo en particular.
4.7 Organización de los requisitos específicos.
Para cualquier sistema los requisitos detallados tienden a ser extensos. Por esta razón, se
recomienda que una cuidadosa consideración la posibilidad de organizar éstos de una manera
óptima para la comprensión. No hay una organización óptima de todos los sistemas. Las
diferentes clases de sistemas se prestan a diferentes organizaciones de los requisitos de la
Sección 3 del SRS.
4.7.1 Por modo del sistema
Algunos sistemas se comportan de manera muy diferente dependiendo del modo de operación.
Por ejemplo, un sistema de control puede tener diferentes conjuntos de funciones, según el modo
de: formación, normales o de emergencia.
Al organizar esta sección por el modo, se debe utilizar el contorno en A.1 o A.2. La elección
depende de si las interfaces y el rendimiento dependen de la modalidad.
4.7.2 Por Clase de usuario
Algunos sistemas proporcionan diferentes conjuntos de funciones para diferentes clases de
usuarios. Por ejemplo, un sistema de control de ascensor presenta diferentes capacidades a los
pasajeros, trabajadores de mantenimiento, y los bomberos. Al organizar esta sección por clase de
usuario, se debe utilizar el contorno en A.3.
4.7.3 Por Objetos
Los objetos son entidades del mundo real que tienen una contraparte en el sistema. Por ejemplo,
en un sistema de monitorización del paciente, los objetos incluyen pacientes, sensores,
enfermeras, salas, médicos, medicinas, etc. Asociado con cada objeto hay un conjunto de
atributos (de ese objeto) y funciones (realizado por ese objeto). Estas funciones también se
llaman servicios, métodos o procesos. Al organizar esta sección por el objeto, el contorno en A.4
debe ser utilizado. Tenga en cuenta que los conjuntos de objetos pueden compartir atributos y
servicios. Estos se agrupan en clases.
4.7.4 Por características
Una característica es un servicio deseado externamente por el sistema que puede requerir una
secuencia de entradas para llevar a cabo el resultado deseado. Por ejemplo, en un sistema de
teléfono, las características incluyen llamada local, el desvío de llamadas y llamada en
conferencia. Cada característica se describe generalmente en una secuencia de pares de
estímulo-respuesta. Al organizar esta sección por función, se debe utilizar el contorno en el punto
A.5.
4.7.5 Por estímulo
Algunos sistemas pueden organizarse mejor describiendo sus funciones en términos de estímulos.
Por ejemplo, las funciones de un sistema automático de aterrizaje de los aviones pueden ser
organizados en secciones de la pérdida de poder, la cizalladura del viento, cambio repentino en
rollo, velocidad vertical excesiva, etc. Al organizar esta sección por el estímulo, el esquema n A.6
deben ser utilizado.
4.7.6 Por Respuesta
Algunos sistemas pueden organizarse mejor describiendo todas las funciones de apoyo a la
generación de una respuesta. Por ejemplo, las funciones de un sistema de personal pueden ser
organizados en secciones correspondientes a todas las funciones asociadas con la generación de
cheques de pago, todas las funciones asociadas con la generación de una lista actual de los
empleados, etc. El contorno en A.6 (con todas las ocurrencias de estímulo reemplazados con
respuesta) se debe utilizar.
4.7.7 Por jerarquía funcional
Cuando ninguno de los esquemas organizativos anteriores resultar útil, la funcionalidad global
puede organizarse en una jerarquía de funciones organizadas por cualquiera de las entradas
comunes, salidas comunes o comunes de acceso de datos interna. Diagramas de flujo de datos y
diccionarios de datos pueden ser utilizados para mostrar las relaciones entre y dentro de las
funciones y datos. Al organizar esta sección por la jerarquía funcional, se debe utilizar el contorno
en A.7.
4.7.8 Comentarios adicionales
Cada vez que un nuevo SRS se contempla, más de una de las técnicas de organización dadas en
[Link] pueden ser apropiadas. En tales casos, organizar los requisitos específicos para múltiples
jerarquías adaptados a las necesidades específicas del sistema bajo especificación. Por ejemplo,
véase A.8 para una organización que combina la clase de usuario y función. Los requisitos
adicionales que se pueden poner en una sección separada al final del SRS.
Hay muchas anotaciones, métodos y herramientas de soporte automatizadas disponibles para
ayudar en la documentación de requisitos. En su mayor parte, su utilidad es una función de la
organización.
Por ejemplo, al organizar el modo de espera, las máquinas de estados finitos o gráficos estatales
pueden ser útiles, al organizar por el objeto, el análisis orientado a objetos pueden ser útiles, al
organizar por rasgo, secuencias de estímulo-respuesta pueden ser de gran ayuda, y cuando la
organización por la jerarquía funcional, diagramas de flujo de datos y diccionarios de datos
pueden ser útiles.
En cualquiera de los esquemas que figuran en A.1 a A.8, esas secciones llamadas "Requisito
Funcional" puede describirse en el lenguaje nativo (por ejemplo, Inglés), en pseudocódigo, en un
lenguaje de definición del sistema, o en cuatro sub-secciones titulado: Introducción, insumos,
procesamiento y salidas.
