NORMA IEEE 830

PARA
ESPECIFICACIÓN DE
REQUERIMIENTOS DE
SOFTWARE
Antes de describir la
norma IEEE 830...
Una vez que se ha detectado algún problema
que afecte a la calidad del producto/servicio, o
a la satisfacción del cliente...

conviene analizar si puede resolverse

mediante algún tipo de tecnología de
información y telecomunicaciones (TIT):

•Hardware
•Software
•Redes
(LAN, MAN, WAN, VPN, web, alámbricas,
inalámbricas, etc.)
Cómo saber si el problema puede
resolverse con TIT
 ¿La causa del problema está relacionada
con...
– almacenamiento de datos?
– procesamiento de datos?
– transferencia de datos?

 Si el problema puede resolverse por medios

más baratos sin necesidad de invertir en
TIT, ¿para qué gastar en TIT?
 Si el problema se relaciona con
almacenamiento, procesamiento o transferencia
de datos, conviene definir los requerimientos
específicos (necesidades) que tengamos

 Al definir claramente los requerimientos que

deseamos que satisfaga un software, se
facilitan:
– La estimación de su costo
– La estimación del tiempo para diseñarlo/programarlo
– La decisión sobre desarrollarlo nosotros, subcontratar
o comprar
– La búsqueda de algún proveedor que pueda
programarlo/venderlo
 Definir los requerimientos de un software puede
parecer algo sencillo, pero es común que el
usuario/cliente o el desarrollador cometan
errores u omisiones importantes

 Muchos problemas en los proyectos de software

se deben a una inadecuada especificación de
requerimientos
 Para definir los requerimientos de un
software, podemos apoyarnos en una norma
que nos guía para hacer las preguntas
pertinentes: IEEE 830

 Esta norma le sirve tanto al usuario/cliente como

al desarrollador
IEEE 830
Recommended
Practice for
Software
Requirements SRS
Specifications
 El propósito principal de esta norma es
ayudarnos a elaborar un documento muy útil:
el SRS

 Es esencialmente una guía para redacción

IEEE 830
 Quién la hizo: Software Engineering Standards
Committee, del IEEE Computer Society

 IEEE (Institute of Electric and Electronic

Engineers, en E.U.A.)

 Cuándo: 1998

 ¿Es de uso obligatorio? NO

IEEE 830
 Quién la puede usar:

– Un cliente/usuario que vaya a definir

requerimientos (características) de un software
que necesite

– Un desarrollador (interno/externo) que haga

software “a la medida” mediante proyecto

– Un desarrollador que haga software “de

paquete” que se venda masivamente
IEEE 830 sirve para que...
 Un cliente describa claramente lo que quiere

 Un proveedor entienda claramente lo que el

cliente quiere

 Se establezcan bases para un contrato de

desarrollo (o de compra-venta)

 Se reduzca el esfuerzo de análisis, diseño, y

programación (evitando re-trabajos)
IEEE 830 sirve para que...
 Se tenga una base o referencia para validar o
probar el software solicitado

 Se facilite el traspaso del software a otros

clientes/usuarios

 Se le puedan hacer mejoras (o innovaciones) a

ese software
CONSIDERACIONES PARA
REDACTAR EL SRS
 Su naturaleza
 Su ambiente
 Características deseables del documento
 Preparación conjunta del SRS
 Evolución del documento
 Prototipos
 Diseño “implícito” en el SRS
 Requerimientos de proyecto “implícitos”
Naturaleza del SRS
 El SRS es una especificación para un producto
de software en particular, ya sea un sólo
programa, o un conjunto de programas, que
realicen ciertas funciones en un ambiente
específico

 A veces el usuario no sabe si necesitará un

solo programa o más de uno
NATURALEZA DEL SRS
 Frecuentemente, el usuario sólo conoce las
necesidades pero no el tipo de solución más
conveniente
 El SRS puede escribirse por uno o más
representantes del proveedor, uno o más del
cliente, o por ambos
 Lo más recomendable es que haya
representantes de ambas partes
 El usuario/cliente puede redactar un borrador
inicial y después revisarlo con el proveedor
NATURALEZA DEL SRS (cont.)
 Funcionalidades deseadas
 Interfaces externas
 Desempeño

 Atributos
(seguridad, portabilidad, mantenibilidad, etc.)

 Restricciones de diseño impuestas a la

implementación (estándares técnicos propios o
internacionales, lenguaje de progr., sistema
operativo, límites de recursos, políticas
internas).
AMBIENTE DEL SRS

 El SRS es la fuente principal para hacer el plan

detallado de un proyecto de software

 Un SRS puede referirse a los requerimientos

deseados de todos los componentes de un
sistema grande, o a componentes (módulos)
individuales del mismo
AMBIENTE DEL SRS
 Si se hacen SRS por separado para varios
módulos, tiene que mantenerse la consistencia
en los documentos

 Si un software necesita interactuar con

otro, tienen que especificarse los
requerimientos de esa interacción
(interfaces), definiendo sus funcionalidades y
el nivel de desempeño deseado
CARACTERÍSTICAS DE UN BUEN
SRS
 Correcto
 No ambiguo
 Completo
 Consistente
 Ordenado con base en importancia y/o
estabilidad
 Verificable
 Modificable
 Rastreable
Correctez

 El SRS es correcto si los requerimientos

escritos son aquellos que el software deberá
cumplir

 No hay un método para saber si el SRS es

correcto; lo importante es que se pida lo que
realmente se necesita
No ambiguo
 Un SRS es no ambiguo si cada requerimiento
establecido en él tiene una sóla interpretación
posible, tanto por el cliente/usuario como por el
desarrollador

 En casos donde alguna palabra pudiera tener

múltiples significados, se debe incluir su
definición precisa en un glosario que se
adicione al SRS.
– Ejemplos: planta, obra, maestro, carga, flecha
No ambiguo (cont.)
 Problema: El usuario/cliente y el desarrollador
generalmente tienen diferentes perfiles
profesionales, y por ello describen los
requerimientos en diferente forma

 Problema: Las descripciones que pudieran ser

más claras para el desarrollador, podrían ser
difíciles de entender para el usuario, y
viceversa.
No ambiguo (cont.)
 El lenguaje natural es inherentemente ambiguo;
por ello, es conveniente que el SRS sea
revisado por un tercero que no haya participado
en la redacción

 Se han creado lenguajes formales para

especificación de requerimientos de
software, que se basan en reglas matemáticas
y lógicas para evitar la ambigüedad (como la
Notación Z, ISO/IEC Z Standard 13568:2002)
 Ejemplo de uso de Notación Z
RAdd Birthday
Birthday Book
name?: NAME
date?: DATE
result!: REPORT
(name? known
birthday’= birthday {name? Date?}
result!= ok) V
(name? known
birthday’ = birthday
result != already_known)
No ambiguo (cont.)
 Métodos de representación de requerimientos:
– Basados en objetos: identificar clases de objetos
similares (alumno, empleado, producto, etc.).
– Basados en procesos (compras, ventas, cobranza)
– Basados en conductas (la conducta de un robot)
COMPLETO
 El SRS es completo si incluye:
– Todos los requerimientos significativos sobre
funcionalidades, desempeño, restricciones de
diseño, atributos, o interfaces externas
– Las respuestas que debería dar el software a todas
las posibles entradas de datos en todas las
situaciones posibles (entradas aceptables o no
aceptables: validación)
– Especificación de unidades de medida (si son
aplicables)
– En caso de que el SRS tenga diagramas o tablas
informativas, hay que darles número o identificación
CONSISTENTE
 Los diversos requerimientos escritos tienen que
ser compatibles entre sí; no debe haber
contradicciones ni conflictos entre ellos.
 Para lograr la consistencia deben evitarse los
siguientes conflictos:
– En características especificadas de objectos del
mundo real
– De lógica o de tiempo entre dos actividades
– Referencia a un mismo objeto del mundo real pero
usando diferentes palabras para el mismo objeto
ORDENADO POR GRADO DE
IMPORTANCIA O ESTABILIDAD
 Cada requerimiento especificado debe tener
alguna identificación (número, letra, secuencia
alfanumérica) para indicar su grado de
importancia o de estabilidad

 Algunos requerimientos son más importantes

que otros

 Al “rankearlos” se puede dar a cada

requerimiento la atención que se merece
ORDENADO POR GRADO DE
IMPORTANCIA O ESTABILIDAD
 Grado de estabilidad: número de cambios que
se podrían esperar para un
requerimiento, debido a eventos futuros que
afecten a la organización, las
responsabilidades, y las personas que usarán
el software

 Grado de necesidad:
– Esencial
– Condicional
VERIFICABLE
 Un requerimiento es verificable si existe algún
método rentable mediante el cual se pueda
analizar si el software cumple ese
requerimiento.
 Ejemplo:
– “La respuesta del programa deberá darse dentro
de los 20 seg posteriores a la apertura de la válvula
VX389, y debe responder correctamente en el 60%
de los casos”
 Contraejemplo (algo no verificable):
– “El programa tiene que funcionar bien”
VERIFICABLE (cont.)
 Si no existe algún método para saber si el
software cumple o no un
requerimiento, entonces ese requerimiento
debe ser revisado o eliminado.
MODIFICABLE
 Es modificable si la estructura y estilo de
redacción permiten la realización de cambios
en forma fácil, completa y consistente

 Para esto es recomendable:

– Incluir índice, tabla de contenido y tabla de
referencias cruzadas
– Cada requerimiento debe aparecer sólo una vez (la
redundancia propicia errores de inconsistencia)
– Poner cada requerimiento separado de los demás
RASTREABLE
 Cada requerimiento debe identificarse con
algún número, letra o secuencia alfanumérica
 Un SRS es rastreable si el origen de cada
requerimiento es claro, y si facilita el
seguimiento de cada requerimiento a lo largo
del proyecto de software
 Dos tipos de rastreabilidad:
– Hacia atrás: en cada requerimiento se menciona
explícitamente su fuente documental
– Hacia delante: los documentos que se deriven del
SRS deben usar las identificaciones de
requerimientos como fueron dadas en el SRS
RASTREABLE (cont.)
 La rastreabilidad hacia delante facilita las
actividades de diseño, codificación, y
modificación del software.
PREPARACIÓN CONJUNTA DEL
SRS

 El desarrollo de un software solamente debería

iniciar cuando el cliente y el proveedor estén
de acuerdo acerca de lo que el software
deberá hacer
EVOLUCIÓN DEL SRS
 Un SRS puede necesitar cambios mientras el
software está en etapas de diseño o de
desarrollo

 Los cambios pueden estar motivados por:

deficiencias, errores, omisiones o
imprecisiones en el documento original

 Cada requerimiento debe documentarse tan

completo como sea posible, aún si pudiera
necesitar cambios posteriormente
EVOLUCIÓN DEL SRS
 Los cambios en los requerimientos tienen que
documentarse con el propósito de:
identificarlos, controlarlos, rastrearlos, y
reportarlos

 Tanto el cliente como el proveedor deben

designar a su respectivo responsable de
autorizar (o rechazar) cambios en los
requerimientos
CREACIÓN DE PROTOTIPOS
 Un prototipo es un pequeño programa parecido
al software solicitado que sirve de
ejemplo, muestra o modelo para que el cliente
vaya especificando sus requerimientos en
forma progresiva junto con el desarrollador
CREACIÓN DE PROTOTIPOS
 El prototipo es útil para:

– Que el cliente/usuario vea y describa más fácilmente

las funcionalidades que desea

– Prever aspectos de la conducta del

sistema, haciendo que el SRS sea más completo y
preciso

– Reducir la cantidad de cambios durante las etapas de

diseño o desarrollo
CREACIÓN DE PROTOTIPOS
(cont.)

 Un prototipo puede ayudar al usuario a definir

detalles específicos de la interfaz humana o de
las funcionalidades que requiera

 Puede facilitarle al desarrollador el diseño y la

programación del software
DISEÑO “IMPLÍCITO” EN EL SRS
 Aunque el SRS no constituye un documento de
diseño, implícitamente está diciéndole a los
desarrolladores lo que se espera que ellos
diseñen
– Establece restricciones

 El SRS tiene que especificar las

funcionalidades que se aplicarán sobre ciertos
datos para producir resultados en cierto lugar
para determinados usuarios
Lo que generalmente no necesita
escribirse en el SRS
 Cómo se deben organizar los módulos del
software
 Cómo se deben asignar funcionalidades
específicas a cada módulo
 Cómo será el flujo de datos o el control de
ejecución de los módulos
 Elección de estructuras de datos que se
usarán dentro del código
Sin embargo…
 Algunas situaciones especiales pueden inducir
requerimientos estrictos de diseño

 Ejemplo: las restricciones de seguridad contra

ataques en Internet pueden requerir que:
– Algunas funcionalidades del software se localicen
en módulos (programas) separados
– Sólo se permita una comunicación limitada entre
ciertos módulos
– Se verifique la integridad de datos para variables
críticas
Más ejemplos de restricciones en
diseño
 Requerimientos físicos (ej. peso en el shuttle)
 Requerimientos de desempeño
 Uso de estándares de desarrollo de software
 Estándares de aseguramiento de la calidad del
software
 Los requerimientos se establecen siempre
desde el punto de vista del usuario/cliente
REQUERIMIENTOS DE PROYECTO
“IMPLÍCITOS”
 El SRS se enfoca en el software como
producto, no en su proceso de creación

 Implícitamente establece restricciones sobre la

planeación y administración del proyecto
correspondiente
REQUERIMIENTOS DE PROYECTO
“IMPLÍCITOS” (cont.)
 El SRS da origen a otros documentos (por
separado) relacionados con el ciclo de vida de
un software
– Estimación de costos (¿cómo calcularlos?)
– Fechas de entrega
– Reportes de avances
– Métodos de desarrollo
– Aseguramiento de la calidad
– Criterios de validación y verificación
– Procedimientos de aceptación
CONTENIDO Y ORGANIZACIÓN
TÍPICOS DE UN SRS
 ( Del documento )
( Del software )

Contenido y organización típicos de un SRS

CONTENIDO DE UN SRS
 SECCIÓN 1: INTRODUCCIÓN
– Debe incluir una descripción general del
SRS, mostrando lo siguiente:
1.1 Propósito del documento
1.2 Alcance
1.3 Definiciones, acrónimos, y abreviaturas
1.4 Referencias
1.5 Descripción general del documento
CONTENIDO DE UN SRS

1.1 Propósito del documento: aquí se

tiene que:

 Explicar para qué se usará el documento

 Especificar a qué tipo de lectores está

destinado
(usuarios, clientes, analistas, programado
res, etc.)
CONTENIDO DE UN SRS
1.2 Alcance – Aquí se tiene que:
 Identificar por su nombre genérico (y
específico) el producto(s) de software que se
estén requiriendo; por ejemplo: sistema de
administración de inventario, generador de
reportes, sistema manejador de bases de datos
marca SúperX, etc.)

 Explicar lo que el software hará, y, si fuera

necesario aclararlo, también lo que no se
espera que haga
CONTENIDO DE UN SRS
1.2 Alcance – Aquí se tiene que:
 Describir para qué se aplicará el
software, incluyendo sus beneficios
relevantes, objectivos, y metas

 Ser consistente con las disposiciones que se

hayan dado en especificaciones de mayor nivel
jerárquico (si existen); por ejemplo, las de algún
sistema de mayor jerarquía
CONTENIDO DE UN SRS
1.3 Definiciones, acrónimos, y
abreviaturas
 Dar las definiciones de todos los
términos, acrónimos (siglas) y abreviaturas que
sean pertinentes para el adecuado
entendimiento del SRS
 Esta información puede ofrecerse mediante
referencias a uno o más apéndices del SRS o
referencias hacia otros documentos (manuales
de la organización, procedimientos de
aseguramiento de calidad, hojas de
registro, etc.)
CONTENIDO DE UN SRS
1.4 Referencias
 Ofrecer una lista completa de todos los
documentos a los que se haga referencia en el
SRS
 Identificar cada documento mediante su
título, número de reporte (si es
aplicable), fecha, y organización que lo publicó
 Especificar las fuentes de las cuales pueden
obtenerse los documentos referenciados
 Esta información puede ofrecerse haciendo
alusión a un apéndice o hacia otro documento
CONTENIDO DE UN SRS
1.5 Descripción gral. del documento
 Describir lo que contienen las secciones
restantes del documento
 Explicar cómo está organizado
CONTENIDO DE UN SRS
 SECCIÓN 2: DESCRIPCIÓN GRAL. DEL
SOFTWARE

Aquí no se establecen los requerimientos

específicos, sino que se describe el fondo general que
da lugar a los requerimientos, los cuales se definen
detalladamente hasta la sección 3 del SRS; ésto los
hace más fáciles de entender.
CONTENIDO DE UN SRS
 SECCIÓN 2: DESCRIPCIÓN GRAL. DEL
SOFTWARE
– Usualmente se incluyen estas 6 subsecciones:
2.1 Perspectiva del software
2.2 Funciones del software
2.3 Características del usuario
2.4 Restricciones
2.5 Suposiciones y dependencias
2.6 Posposición de requerimientos
CONTENIDO DE UN SRS
2.1 Perspectiva del software
– Describir el software en perspectiva con otros
software relacionados: similitudes y diferencias
– Si el software es independiente y totalmente auto-
contenido, eso tiene que decirse aquí.
– Si se está requiriendo un software que formará
parte de un sistema más grande, se tiene que
describir la relación de los requerimientos del
sistema grande con las funcionalidades del software
requerido y debe identificarse cómo se comunicarán
ambos
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)

– Para describir las relaciones entre el software

requerido y el sistema grande, pueden ser útiles los
diagramas de bloques

– En los diagramas de bloques se pueden mostrar los

componentes principales del sistema grande y su
relación jerárquica (y de flujo de datos) con el
software requerido
Ejemplo de diagrama de bloques:
Sistema para Inscripciones
1.0
Estudiante Cursos Cursos
Módulo para
solicitados Verificar disponibles
disponibilidad
Archivo de
Cursos cursos
Carta de
confirmación autorizados
Detalles de curso
3.0 2.0
Módulo para
Registro Módulo para Inscripción a curso
Notificar Inscribir
al Datos Archivo de
inscripción
estudiante estudiantes
estudiante

Basado en Laudon & Laudon. Sistemas de Información Gerencial.

Prentice-Hall. México, 2002.
Ejemplo de diagrama de bloques:
Sistema para Inscripciones

Este podría ser un software que estamos

3.0 requiriendo, que formaría parte del
Módulo para sistema grande
Notificar
inscripción

Basado en Laudon & Laudon. Sistemas de Información Gerencial.

Prentice-Hall. México, 2002.
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)
– Describir las condiciones (restricciones) dentro de
las cuales deberá funcionar el software:
2.1.1 Interfaces de sistema (*)
2.1.2 Interfaces de usuario
2.1.3 Interfaces de hardware
2.1.4 Interfaces de software
2.1.5 Interfaces de comunicaciones
2.1.6 Restricciones de memoria
2.1.7 Operaciones
2.1.8 Requerimientos de adaptación a un lugar
(*) ¿Qué es una interfaz?
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)

2.1.1 Interfaces de sistema: lo que hay entre

los diversos módulos del sistema

– Enumerar cada interfaz de sistema

– Descripción de la interfaz del software para
hacerlo compatible con el sistema
Veamos los módulos...
1.0
Estudiante Cursos Cursos
Módulo para
solicitados Verificar disponibles
disponibilidad
Archivo de
Cursos cursos
Carta de
confirmación autorizados
Detalles de curso
3.0 2.0
Módulo para
Registro Módulo para Inscripción a curso
Notificar Inscribir
al Datos Archivo de
inscripción
estudiante estudiantes
estudiante
 1.0
Estudiante Cursos Cursos
Módulo para
solicitados Verificar disponibles
disponibilidad
Archivo de
Cursos cursos
Carta de
confirmación autorizados
Detalles de curso
3.0 2.0
Módulo para
Registro Módulo para Inscripción a curso
Notificar Inscribir
al Datos Archivo de
inscripción
estudiante estudiantes
estudiante
Lo que hay entre los módulos...
1.0
Módulo para
Verificar
disponibilidad
I.S. significa
Cursos Interfaz de
autorizados I.S.
sistema
I.S.
3.0 2.0
Módulo para Módulo para
Notificar Inscribir
Registro al
inscripción
estudiante

Basado en Laudon & Laudon. Sistemas de Información Gerencial.

Prentice-Hall. México, 2002.
Lo que hay entre los módulos...

• Lo que hay entre los módulos es flujo de

información; por lo tanto se tiene que
especificar qué información alimenta a cada
uno de los módulos que sean requeridos

• Hay que especificar cómo es esa

información (numérica, alfanumérica, rango
de valores posibles, unidades de
medida, etc.)
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.2 Interfaces de usuario: lo que estará entre el
usuario y el software
– Definir las características de :
 Ventanas
 Colores
 Formatos y tamaños de letra
 Menús
 Íconos, botones
 Contenido de los reportes impresos
 Interfaz mediante A.S.R. y/o síntesis de voz
 Realidad virtual
 Otras interfaces usuario/máquina (electrodos)
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.3 Interfaces de hardware: qué hardware usará el
software para entrada/salida de
información, incluyendo:
 Características de configuración (número de puertos de
comunicación, instruction sets, etc.).
 Qué dispositivos de hardware serán soportados por el
software,y én qué forma serán soportados
 Protocolos de transferencia de datos entre dispositivos
Ejemplo: un sistema para administración de
inventarios puede requerir el uso de scanners
especiales para leer códigos de barras
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.4 Interfaces de software: qué otros software se
necesitarán para que el software requerido pueda
funcionar, por ejemplo:
 Sistemas operativos: Windows, Linux, AIX, Solaris, etc.
 Sistemas manejadores de bases de datos:
Oracle, Sybase, MySQL, DB2, etc.
 Intérpretes de lenguajes (como PERL)
 Shells para sistemas expertos (como Sictus Prolog)
 Paquetes comerciales para ejecutar programas que usan
redes neuronales (como MatLab)
También los programas para que el software pueda
interactuar con los demás módulos
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.5 Interfaces de comunicación:

Qué tecnología de redes se usará para comunicar

a las computadoras en las cuales se usará el
software:
– Nombre genérico de la tecnología:
LAN, WAN, MAN, VPN, WWW, WiFi, etc.
– Topología de la red: anillo, estrella, bus
– Protocolos de comunicación:
Ethernet, TCP/IP, ATM, FrameRelay, PPP
– Tipo de cableado: fibra óptica, par trenzado, coaxial
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.6 Restricciones de memoria
Se debe especificar si existe o no algún límite en
cuanto a la memoria (tanto primaria como
secundaria) que podrá tener disponible el software
para ser ejecutado

Memoria primaria: la RAM (Random Access

Memory)

Memoria secundaria: disco, cinta

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.7 Operaciones
Especificar los diferentes modos de operación del
software por parte del usuario, por ejemplo:

– Operaciones “normales” versus especiales (inscribir

alumno versus respaldo de archivos)
– Operaciones interactivas y actividades que no
requieran atención del usuario
– Operaciones iniciadas por el usuario versus
operaciones que se activen automáticamente
CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.8 Adaptación a un lugar específico

– Definir los requerimientos respecto a datos o

secuencias de inicialización del software que sean
específicas para un lugar, una misión o un modo
operacional específico

– Especificar las características relacionadas con el

lugar o la misión que deban ser modificadas para
adaptar el software a una instalación específica
CONTENIDO DE UN SRS
2.2 Funciones del producto

Sumario de las funciones principales; por

ejemplo, para el caso de un software de
contabilidad se mencionría el mantenimiento de
cuentas de cliente, el registro de sus
transacciones, la preparación de facturas, pero
sin mencionar los detalles requeridos de esas
funciones.
CONTENIDO DE UN SRS
2.3 Características de los usuarios

Describir sus características respecto a:

 Nivel educativo
 Experiencia profesional
 Capacidades técnicas.

Esta descripción ayuda a comprender los motivos

que dan origen a los requerimientos.
CONTENIDO DE UN SRS
2.4 Restricciones
Información sobre posibles limitantes que
deberán respetar los diseñadores, como:

a) Políticas regulatorias aplicables

b) Limitaciones en el hardware (p.ej. velocidad
del microprocesador)
c) Interfaces hacia otras aplicaciones
d) Funcionamiento en paralelo
e) Funciones de auditoría de software
CONTENIDO DE UN SRS
2.4 Restricciones (cont.)

f) Protocolos de comunicaciones de redes

g) Requiremientos de confiabilidad
h) Criticidad de la aplicación
i) Consideraciones sobre seguridad física y lógica
CONTENIDO DE UN SRS
2.5 Suposiciones y dependencias

Cada uno de los factores que afecten a los requiremientos

especificados.
Estos factores no son restricciones de diseño para el software, sino
>>>>>>but are, rather, any changes to them that can affect
the requirements in the SRS. For example, an assumption may be
that a speciÞc operating system will be
available on the hardware designated for the software product. If, in
fact, the operating system is not avail-
able, the SRS would then have to change accordingly.
CONTENIDO DE UN SRS
2.6 Distribución (apportioning) de
requerimientos

Aquí se dice cuáles son los requerimientos que

pueden atenderse hasta versiones futuras del
sistema
Organización de los requerimientos
específicos (Sección 3)
Para lograr un mejor entendimiento de los
requerimientos, conviene organizarlos con
base en alguno de los siguientes criterios:
 Por modo de operación del sistema
 Por clase de usuario
 Por objetos
 Por características
 Por estímulos
 Por respuestas
 Por jerarquía funcional
Organización de los requerimientos
específicos (Sección 3)
 Por modo de operación del sistema

– P. ej. si se desea un sistema de control para una

planta industrial, sus modos de operación podrían
ser: modo de entrenamiento, modo normal, y modo
de emergencia
– Hay que definir las funcionalidades del sistema para
cada tipo de modo
– Usar las plantillas A.1 o A.2, la primera si los
diversos modos de operación requieren diferentes
interfaces; la segunda si requieren diferentes tipos
de desempeño
Organización de los requerimientos
específicos (Sección 3)

 Por clase de usuario

– Algunos sistemas ofrecen diferentes conjuntos de

funciones para cada tipo de usuario. P. ej., un
sistema de sucursal bancaria ofrece diferentes
funciones para el personal de cajas, para los
ejecutivos de cuenta o para el gerente

– Usar plantilla A.3

Organización de los requerimientos
específicos (Sección 3)
 Por objetos
– “Objetos” son entidades del mundo real que tienen
una representación dentro del sistema. P. ej. un
sistema de monitoreo de pacientes incluye
pacientes, sensores, enfermeras, habitaciones, médi
cos, medicinas, etc.

– Para cada objeto se define un conjunto de atributos

y funcionalidades (denominadas servicios o
métodos).

– Usar plantilla A.4

Organización de los requerimientos
específicos (Sección 3)
 Por características
– Una característica es una funcionalidad del sistema
que puede requerir una secuencia de entradas de
datos para producir un resultado o una acción
– Ej. en la programación de los circuitos de un aparato
telefónico, las características son: llamada
local, transferencia de llamada, y llamada en
conferencia (conference call)
– Cada característica se describe generalmente como
una secuencia de pares de estímulo-respuesta
– Usar plantilla A.5
Organización de los requerimientos
específicos (Sección 3)
 Por estímulos
– >>>
Organización de los requerimientos
específicos (Sección 3)
 Por respuestas
– >>>
Organización de los requerimientos
específicos (Sección 3)
 Por jerarquía funcional
– Cuando ninguna de las plantillas resulta útil, la
funcionalidad general del sistema puede organizarse
en una jerarquía de funciones, ya sea con base en
entradas comunes, salidas comunes, o accesos
comunes a los datos

– Se pueden usar diagramas de flujo de datos y

diccionarios de datos para mostrar las relaciones
entre las diversas funciones, entre los diversos
datos, y entre las funciones y los datos

– Usar plantilla A.7

¿Preguntas o
comentarios?