TÉCNICAS DE DOCUMENTACIÓN Y ARCHIVO

CONTENIDO
4.1 Especificación de Requisitos de software
4 y el estándar IEEE830
4.2 Características de una buena
NORMA IEEE 830: ESPECIFICACIÓN DE especificación de requisitos de software

REQUISITOS DE SOFTWARE 4.3 Preparación y evolución de la ERS

4.4 Contenido y organización típicos de las
especificaciones de requisitos de
software
Dr. Ing. Celedonio Méndez Valdivia

4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE ¿Corresponde a TICs?

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
4.1 tipo de tecnología de información y comunicaciones
(TIC):
Especificación de Requisitos de software
• Hardware
y el estándar IEEE830
• Software
• Redes (LAN, MAN, WAN, VPN, web,
alámbricas, inalámbricas, etc.)

Cómo saber si el problema … puede resolverse con TICs?

puede resolverse con TIC • Si el problema se relaciona con almacenamiento,
procesamiento o transferencia de datos, conviene
• ¿La causa del problema está relacionada con... definir los requerimientos específicos (necesidades)
– almacenamiento de datos?
que tengamos
• Al definir claramente los requerimientos que deseamos
– procesamiento de datos? que satisfaga un software, se facilitan:
– transferencia de datos? – La estimación de su costo
– La estimación del tiempo para
• Si el problema puede resolverse por medios más diseñarlo/programarlo
baratos sin necesidad de invertir en TIC, ¿para
– La decisión sobre desarrollarlo nosotros,
qué gastar en TIC?
subcontratar o comprar
– La búsqueda de algún proveedor que pueda
programarlo/venderlo

1
 ESPECIFICACIÓN DE
REQUERIMIENTOS DE SOFTWARE
• 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
IEEE 830
Prácticas Recomendadas para la
Especificación de Requisitos de
Software
Recommended Practice for
ERS
Software Requirements
Specifications (SRS)
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
ESPECIFICACIÓN DE
REQUERIMIENTOS DE SOFTWARE
• 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
El propósito principal de esta norma es
ayudarnos a elaborar un documento muy
útil: la Especificación de Requerimientos
de Software ERS (en inglés: SRS)
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
2
 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)
CONSIDERACIONES PARA
REDACTAR LA ERS
• Su naturaleza
• Su ambiente
• Características deseables del documento
• Preparación conjunta de la ERS
• Evolución del documento
• Prototipos
• Diseño “implícito” en la ERS
• Requerimientos de proyecto “implícitos”
NATURALEZA DE LA ERS
• Frecuentemente, el usuario sólo conoce las
necesidades pero no el tipo de solución más
conveniente
• La ERS 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
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
Naturaleza de la ERS
• La ERS 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 DE LA ERS
• 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).
3
 AMBIENTE DE LA ERS
• La ERS es la fuente principal para hacer el
plan detallado de un proyecto de software
• Una ERS puede referirse a los requerimientos
deseados de todos los componentes de un
sistema grande, o a componentes (módulos)
individuales del mismo
4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE
4.2
Características de una buena especificación
de requisitos de software
Corrección
• La ERS es correcto si los requerimientos
escritos son aquellos que el software deberá
cumplir
• No hay un método para saber si la ERS es
correcto; lo importante es que se pida lo que
realmente se necesita
AMBIENTE DEL SRS
• Si se hacen ERS 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 UNA BUENA
ESPECIFICACIÓN DE REQUISITOS DE
SOFTWARE
• Correcta
• No ambigua
• Completa
• Consistente
• Ordenada con base en importancia y/o
estabilidad
• Verificable
• Modificable
• Rastreable
No ambiguo
• Una ERS es no ambigua si cada requerimiento
establecido en ella tiene una sola 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 a la ERS.
Ejemplos: planta, obra, maestro, carga, flecha
4
 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.)
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)
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 objetos 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
No ambiguo (cont.)
• El lenguaje natural es inherentemente ambiguo;
por ello, es conveniente que la ERS sea
revisada 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)
COMPLETO
La ERS es completa 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 la ERS tenga diagramas o tablas
informativas, hay que darles número o identificación
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
5
 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
– Opcional
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.
RASTREABLE
• Cada requerimiento debe identificarse con algún
número, letra o secuencia alfanumérica
• Una ERS 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
de la ERS deben usar las identificaciones de
requerimientos como fueron dadas en la ERS
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 V25, y debe responder correctamente en
el 60% de los casos”
• Contraejemplo (algo no verificable):
– “El programa tiene que funcionar bien”
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 (cont.)
• La rastreabilidad hacia delante facilita las
actividades de diseño, codificación, y
modificación del software.
6
4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE
PREPARACIÓN CONJUNTA DE LA ERS
4.3
Preparación y evolución de la ERS
EVOLUCIÓN DE LA ERS
• Una ERS 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
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
• 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
• 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
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 la ERS sea más completa y
precisa
– Reducir la cantidad de cambios durante las
etapas de diseño o desarrollo
7

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
Lo que generalmente NO necesita
escribirse en las ERS
• 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
Más ejemplos de restricciones
en diseño
• Requerimientos físicos
• 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
DISEÑO “IMPLÍCITO” EN LAS
ESPECIFICACIONES DE REQUERIMIENTO
DE SOFTWARE - ERS
• Aunque las ERS no constituyen un documento
de diseño, implícitamente está diciéndole a los
desarrolladores lo que se espera que ellos
diseñen
– Establece restricciones
• Las ERS tienen que especificar las
funcionalidades que se aplicarán sobre ciertos
datos para producir resultados en cierto lugar
para determinados usuarios
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
REQUERIMIENTOS DE PROYECTO
“IMPLÍCITOS”
• Las ERS se enfocan 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
8
 REQUERIMIENTOS DE PROYECTO
4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE
“IMPLÍCITOS” (cont.)
• Las ERS dan origen a otros documentos (por
separado) relacionados con el ciclo de vida de
un software
– Estimación de costos
4.4
– Fechas de entrega Contenido y organización típicos de las
– Reportes de avances especificaciones de requisitos de software
– 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 UNA ERS

SECCIÓN 1: INTRODUCCIÓN
CONTENIDO DE UNA ERS
1.1 Propósito del documento
1.2 Alcance SECCIÓN 1: INTRODUCCIÓN
1.3 Definiciones, acrónimos, y abreviaturas
1.4 Referencias Debe incluir una descripción general del SRS,
1.5 Descripción general del documento mostrando lo siguiente:
SECCIÓN 2: DESCRIPCIÓN GENERAL DEL SOFTWARE
2.1 Perspectiva del software
1.1 Propósito del documento
2.2 Funciones del software 1.2 Alcance
2.3 Características del usuario 1.3 Definiciones, acrónimos, y abreviaturas
2.4 Restricciones
2.5 Suposiciones y dependencias 1.4 Referencias
2.6 Posposición de requerimientos 1.5 Descripción general del documento
SECCIÓN 2: Organización de los requerimientos específicos (Sección 3)
Apéndices
Indice

… CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS

1.2 Alcance
1.1 Propósito del documento:
• Identificar por su nombre genérico (y
En esta sección se debe: específico) el producto(s) de software que se
• Explicar para qué se usará el documento estén requiriendo; por ejemplo: sistema de
administración de inventario, generador de
• Especificar a qué tipo de lectores está reportes, sistema manejador de bases de
destinado (usuarios, clientes, analistas, datos marca SúperX, etc.)
programadores, etc.)
• Explicar lo que el software hará, y, si fuera
necesario aclararlo, también lo que no se
espera que haga

9
 … CONTENIDO DE UNA ERS
… 1.2 Alcance
• Describir para qué se aplicará el software,
incluyendo sus beneficios relevantes,
objetivos, 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 UNA ERS
1.4 Referencias
• Ofrecer una lista completa de todos los
documentos a los que se haga referencia en
la ERS
• 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 UNA ERS
SECCIÓN 2: DESCRIPCIÓN GENERAL
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 de la ERS; esto los hace más fáciles
de entender.
… CONTENIDO DE UNA ERS
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 UNA ERS
1.5 Descripción general del documento
• Describir lo que contienen las secciones
restantes del documento
• Explicar cómo está organizado
… CONTENIDO DE UNA ERS
SECCIÓN 2: DESCRIPCIÓN GENERAL 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
10
 … CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS
2.1 Perspectiva del software 2.1 Perspectiva del software (cont.)
– Describir el software en perspectiva con otros – Para describir las relaciones entre el
software relacionados: similitudes y diferencias software requerido y el sistema grande,
pueden ser útiles los diagramas de bloques
– Si el software es independiente y totalmente
auto-contenido, eso tiene que decirse aquí. – En los diagramas de bloques se pueden
– Si se está requiriendo un software que formará mostrar los componentes principales del
parte de un sistema más grande, se tiene que sistema grande y su relación jerárquica (y
describir la relación de los requerimientos del de flujo de datos) con el software requerido
sistema grande con las funcionalidades del
software requerido y debe identificarse cómo se
comunicarán ambos

Ejemplo de diagrama de bloques:

Ejemplo de diagrama de bloques: Sistema
Sistema para Inscripciones
para Inscripciones

Cursos 1.0
solicitados Módulo para
Cursos disponibles
Estudiante
Verificar Este podría ser un módulo que
disponibilidad formaría parte del sistema en su
Archivo de
cursos
3.0 conjunto
Carta de Cursos
autorizados Módulo para
confirmación
Detalles de curso Notificar
inscripción
3.0 2.0
Registro Inscripción a curso
Módulo para Módulo para
Notificar Inscribir al
Datos estudiante Archivo de
inscripción estudiante
estudiantes

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

Basado en Laudon & Laudon. Sistemas de Información Gerencial.
•Prentice-Hall. México, 2002.
Prentice-Hall. México

… CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS

2.1 Perspectiva del software (cont.)
2.1 Perspectiva del software (cont.)
Describir las condiciones (restricciones) dentro
de las cuales deberá funcionar el software: 2.1.1 Interfaces de sistema: lo que hay entre
los diversos módulos del sistema
2.1.1 Interfaces de sistema
2.1.2 Interfaces de usuario – Enumerar cada interfaz de sistema
2.1.3 Interfaces de hardware – Descripción de la interfaz del software
2.1.4 Interfaces de software para hacerlo compatible con el sistema
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

11
 Veamos los módulos... Veamos los módulos...

Cursos 1.0 Cursos 1.0

solicitados Módulo para
Cursos disponibles solicitados Módulo para
Cursos disponibles
Estudiante Estudiante
Verificar Verificar
disponibilidad disponibilidad
Archivo de Archivo de
Cursos cursos Cursos cursos
Carta de Carta de
confirmación autorizados confirmación autorizados
Detalles de curso Detalles de curso
3.0 2.0 3.0 2.0
Registro Inscripción a curso Registro Inscripción a curso
Módulo para Módulo para Módulo para Módulo para
Notificar Inscribir al Notificar Inscribir al
Datos estudiante Archivo de Datos estudiante Archivo de
inscripción estudiante inscripción estudiante
estudiantes estudiantes

Basado en Laudon & Laudon. Sistemas de Información Gerencial. Basado en Laudon & Laudon. Sistemas de Información Gerencial.
Prentice-Hall. México Prentice-Hall. México

Lo que hay entre los módulos... Lo que hay entre los módulos...
1.0
Módulo para • Lo que hay entre los módulos es flujo de
Verificar
disponibilidad información; por lo tanto se tiene que especificar
qué información se entrega a cada uno de los
Cursos
autorizados
I.S. I.S. módulos que sean requeridos.
Significa
Interfaz de
• Hay que especificar cómo es esa información
3.0 I.S. 2.0
sistema (numérica, alfanumérica, rango de valores
Módulo para Módulo para
Notificar Registro Inscribir al
posibles, unidades de medida, etc.)
inscripción estudiante

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

Prentice-Hall. México

… CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS

2.1 Perspectiva del software 2.1 Perspectiva del software
2.1.2 Interfaces de usuario: lo que estará entre el 2.1.3 Interfaces de hardware: qué hardware usará el
usuario y el software software para entrada/salida de información,
– Definir las características de : incluyendo:
• Ventanas • Características de configuración (número de
• Colores puertos de comunicación, instruction sets, etc.).
• Formatos y tamaños de letra • Qué dispositivos de hardware serán soportados por
• Menús el software, y en qué forma serán soportados
• Íconos, botones • Protocolos de transferencia de datos entre
• Contenido de los reportes impresos dispositivos
• Interfaz y/o síntesis de voz
• Realidad virtual Ejemplo: un sistema para administración de
• Otras interfaces usuario/máquina (electrodos) inventarios puede requerir el uso de scanners
especiales para leer códigos de barras

12
 … CONTENIDO DE UNA ERS
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 UNA ERS
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 UNA ERS
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 UNA ERS
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 UNA ERS
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 UNA ERS
2.2 Funciones del producto
Sumario de las funciones principales; por
ejemplo, para el caso de un software de
contabilidad se mencionarí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.
13
 … CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS
2.4 Restricciones
2.3 Características de los usuarios
Información sobre posibles limitantes que
Describir sus características respecto a:
deberán respetar los diseñadores, como:
• Nivel educativo
a) Políticas regulatorias aplicables
• Experiencia profesional
b) Limitaciones en el hardware (p.ej. velocidad
• Capacidades técnicas.
del microprocesador)
Esta descripción ayuda a comprender los
c) Interfaces hacia otras aplicaciones
motivos que dan origen a los requerimientos.
d) Funcionamiento en paralelo
e) Funciones de auditoría de software

… CONTENIDO DE UNA ERS … CONTENIDO DE UNA ERS

2.5 Suposiciones y dependencias
2.4 Restricciones (cont.)
Cada uno de los factores que afecten a los
f) Protocolos de comunicaciones de redes requerimientos especificados.

g) Requerimientos de confiabilidad Estos factores no son restricciones de diseño para el

software, sino que son, más bien, cualquier cambio en
h) Criticidad de la aplicación ellos que pueden afectar a los requisitos de la ERS.

i) Consideraciones sobre seguridad física y Por ejemplo, una hipótesis puede ser que el producto de
software correrá bajo un sistema operativo determinado.
lógica
Si, en la realidad, el sistema operativo no está disponible,
entonces la ERS entonces tendrá que cambiar
correspondientemente.

Organización de los requerimientos

… CONTENIDO DE UNA ERS
específicos (Sección 3)
2.6 Especificación de requerimientos a futuro Para lograr un mejor entendimiento de los
requerimientos, conviene organizarlos con base en
alguno de los siguientes criterios:
En éste acápite se especifica qué requerimientos
pueden atenderse en las versiones futuras del • Por modo de operación del sistema
sistema • Por clase de usuario
• Por objetos
• Por características
• Por estímulos
• Por respuestas
• Por jerarquía funcional

14
 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 objetos
– “Objetos” son entidades del mundo real que
tienen una representación dentro del sistema.
Por ejemplo un sistema de monitoreo de
pacientes incluye pacientes, sensores,
enfermeras, habitaciones, médicos, 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 estímulos
– >>>
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 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 respuestas
– >>>
15
 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

16