Está en la página 1de 16

TÉCNICAS DE DOCUMENTACIÓN Y ARCHIVO

4

NORMA IEEE 830: ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE

Dr. Ing. Celedonio Méndez Valdivia

4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE

4.1

Especificación de Requisitos de software y el estándar IEEE830

Cómo saber si el problema puede resolverse con TIC

• ¿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 TIC, ¿para qué gastar en TIC?

CONTENIDO

4.1 Especificación de Requisitos de software y el estándar IEEE830

4.2 Características de una buena especificación de 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

¿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 tipo de tecnología de información y comunicaciones (TIC):

• Hardware

• Software

• Redes (LAN, MAN, WAN, VPN, web, alámbricas, inalámbricas, etc.)

… puede resolverse con TICs?

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

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 Software Requirements Specifications (SRS)

ERS

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

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 Especificación de Requisitos de Software corresponde a 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 programación, sistema operativo, límites de recursos, políticas internas).

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

Correcta

• La ERS es correcta si los requerimientos escritos son aquellos que el software deberá cumplir

• No hay un método para saber si la ERS es correcta; 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 ambigua

• 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

No ambigua (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 ambigua (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 ambigua (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)

COMPLETA

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

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 10 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.

4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE

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

PREPARACIÓN CONJUNTA DE LA ERS

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

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

REQUERIMIENTOS DE PROYECTO “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

– 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 UNA ERS

SECCIÓN 1: INTRODUCCIÓN

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

SECCIÓN 2: DESCRIPCIÓN GENERAL DEL SOFTWARE

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

SECCIÓN 2: Organización de los requerimientos específicos (Sección 3) Apéndices Indice

… CONTENIDO DE UNA ERS

1.1 Propósito del documento:

En esta sección se debe:

• Explicar para qué se usará el documento

• Especificar a qué tipo de lectores está destinado (usuarios, clientes, analistas, programadores, etc.)

4. NORMA IEEE 830 ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE

4.4

Contenido y organización típicos de las especificaciones de requisitos de software

CONTENIDO DE UNA ERS

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 UNA ERS

1.2 Alcance

• 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 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

… CONTENIDO DE UNA ERS

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

Ejemplo de diagrama de bloques:

Sistema para Inscripciones

Cursos solicitados Estudiante
Cursos
solicitados
Estudiante
1.0 Módulo para Verificar disponibilidad
1.0
Módulo para
Verificar
disponibilidad

Cursos disponibles

 
     

Archivo de

 

Carta de

 

Cursos

 

cursos

   

confirmación

autorizados

 
 

Detalles de curso

3.0 Módulo para Notificar inscripción
3.0
Módulo para
Notificar
inscripción
 
2.0 Módulo para Inscribir al estudiante
2.0
Módulo para
Inscribir al
estudiante
3.0 Módulo para Notificar inscripción   2.0 Módulo para Inscribir al estudiante

Registro

Inscripción a curso

 

Datos estudiante

 

Archivo de

 

estudiantes

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

… CONTENIDO DE UNA ERS

2.1Perspectiva 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

… CONTENIDO DE UNA ERS

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

3.0 Módulo para Notificar inscripción
3.0
Módulo para
Notificar
inscripción

Este podría ser un módulo que formaría parte del sistema en su conjunto

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

… CONTENIDO DE UNA ERS

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

Cursos solicitados Estudiante
Cursos
solicitados
Estudiante
1.0 Módulo para Verificar disponibilidad
1.0
Módulo para
Verificar
disponibilidad

Cursos disponibles

 
     

Archivo de

 

Carta de

 

Cursos

 

cursos

   

confirmación

autorizados

 

Detalles de curso

3.0 Módulo para Notificar inscripción
3.0
Módulo para
Notificar
inscripción
 
3.0 Módulo para Notificar inscripción  

Registro

2.0 Módulo para Inscribir al estudiante
2.0
Módulo para
Inscribir al
estudiante

Inscripción a curso

 

Datos estudiante

 

Archivo de

 

estudiantes

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

Lo que hay entre los módulos

1.0 Módulo para Verificar disponibilidad Cursos I.S. autorizados
1.0
Módulo para
Verificar
disponibilidad
Cursos
I.S.
autorizados

I.S.

Significa

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

3.0 Módulo para Notificar inscripción
3.0
Módulo para
Notificar
inscripción
I.S.
I.S.

Registro

Módulo para Notificar inscripción I.S. Registro 2.0 Módulo para Inscribir al estudiante Interfaz de
2.0 Módulo para Inscribir al estudiante
2.0
Módulo para
Inscribir al
estudiante

Interfaz de

sistema

… CONTENIDO DE UNA ERS

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 y/o síntesis de voz

Realidad virtual

Otras interfaces usuario/máquina (electrodos)

Veamos los módulos Cursos 1.0 Cursos disponibles solicitados Módulo para Estudiante Verificar disponibilidad
Veamos los módulos
Cursos
1.0
Cursos disponibles
solicitados
Módulo para
Estudiante
Verificar
disponibilidad
Archivo de
cursos
Cursos
Carta de
autorizados
confirmación
Detalles de curso
3.0
2.0
Registro
Inscripción a curso
Módulo para
Módulo para
Inscribir al
Notificar
Datos estudiante
Archivo de
estudiante
inscripción
estudiantes
Basado en Laudon & Laudon. Sistemas de Información Gerencial.
Prentice-Hall. México

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 se entrega 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 UNA ERS

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 en 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 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.

… CONTENIDO DE UNA ERS

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 UNA ERS

2.4 Restricciones (cont.)

f) Protocolos de comunicaciones de redes

g) Requerimientos de confiabilidad

h) Criticidad de la aplicación

i) Consideraciones sobre seguridad física y lógica

… CONTENIDO DE UNA ERS

2.6 Especificación de requerimientos a futuro

En éste acápite se especifica qué requerimientos pueden atenderse en las versiones futuras del sistema

… CONTENIDO DE UNA ERS

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 UNA ERS

2.5 Suposiciones y dependencias

Cada uno de los factores que afecten a los requerimientos especificados.

Estos factores no son restricciones de diseño para el software, sino que son, más bien, cualquier cambio en ellos que pueden afectar a los requisitos de la ERS.

Por ejemplo, una hipótesis puede ser que el producto de software correrá bajo un sistema operativo determinado. Si, en la realidad, el sistema operativo no está disponible, entonces la ERS entonces tendrá que cambiar correspondientemente.

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 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

>>>

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

entre las diversas funciones, entre los diversos datos, y entre las funciones y los datos –