INGENIERÍA DE SOFTWARE I

Documento de requerimientos de software estándar IEEE 830-1998

Definir y Caracterizar cada uno de las partes que componen el Documento de requerimientos de software estándar IEEE 830-1998

OBJETIVO

Necesidad de conocer la estructura del Documento de requerimientos de software estándar IEEE 830-1998

PROBLEMA

CONTENIDOS

• Esquema de la ERS definida en el IEEE 830-1998• Introducción• Descripción General• Requisitos Específicos• Apéndice• Índice

ESQUEMA DE LA ERS DEFINIDA EN EL IEEE 830-1998

1. INTRODUCCIÓN DE LA ERS

En esta sección se proporcionara una introducción a todo el documento deEspeciación de Requisitos Software(ERS).

Consta de varias subsecciones:propósito, ámbito del sistema,definiciones, referencias yvisión general del documento.

1. INTRODUCCIÓN DE LA ERS

1.1. PROPÓSITOEn esta subsección se definirá el propósito del documento ERS y seespecificará a quiénva dirigido eldocumento.

1. INTRODUCCIÓN DE LA ERS

1.2. ÁMBITO DEL SISTEMAEn esta subsección:• Se podrá dar un nombre al futuro

sistema• Se explicará lo que el sistema hará y lo

que no hará.• Se describirán los beneficios, objetivos

y metas que se espera alcanzar con el futuro sistema.• Se referenciarán todos aquellos documentos de nivel superior.

1. INTRODUCCIÓN DE LA ERS

1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURASEn esta subsección sedefinirán todos lostérminos, acrónimosy abreviaturasutilizadas en la ERS.

1. INTRODUCCIÓN DE LA ERS

1.4. REFERENCIASEn esta subsección se mostraráuna lista completa detodos los documentosreferenciados enla ERS.

1. INTRODUCCIÓN DE LA ERS

1.5. VISIÓN GENERAL DEL DOCUMENTOEsta subsección describe brevemente los contenidos y la organizacióndel resto de la ERS.

2. DESCRIPCIÓN GENERALSe describen todos aquellos factores que afectan al producto y a sus requisitos. En esta sección no se describen los requisitos, sino su contexto

Perspectivas del producto

2. DESCRIPCIÓN GENERAL

• Esta subsección debe proporcionar un resumen de las funciones principales que el software debe llevar a cabo.

• Las funciones deben estar organizadas de manera que el cliente o cualquier otra persona lo entienda perfectamente.

• En una metodología orientada a objetos, el funcionamiento y las relaciones del futuro sistema se modelarían a través de los Casos de Uso.

Funciones del producto

2. DESCRIPCIÓN GENERAL

• Se indica aquí el tipo de usuario al que se dirige la aplicación, así como su experiencia técnica, nivel de conocimientos, etc.

Características de los Usuarios

Restricciones• Aquí se indica cualquier tipo de limitación como

pueden ser: políticas de la empresa, limitaciones hardware, seguridad, protocolos de comunicación, interfaces con otras aplicaciones, estándares de la empresa en cuanto a interfaces, etc.

• Limitaciones que se imponen sobre los desarrolladores del producto

Suposiciones y DependenciesEstos dos aspectos son importantes en la definición de los requerimientos, si estos factores cambian afectan directamente a los requerimientos.EjemploSuposicionesEl cliente debe tener computadoras aptas para la instalación y correcto funcionamiento del sistema.DependenciaEl sistema seguirá una arquitectura Cliente/Servidor, por lo que la disponibilidad del sistema dependerá de la conexión entre las máquinas en las que residirá el programa cliente y la máquina servidora de datos.

Requisitos Futuros

• Una vez que el sistema esta funcionando puede darse futuros requisitos, las cuales deben analizarse y tomarse en cuenta para mejorar el sistema, estos requisitos tienen futuro incierto,

Requisitos Específicos• Este documento debe ser legible y entendible

por cualquier persona de muy distinta información. Aquí se detallan las especificaciones de requisitos del software y es el que permite a los diseñadores modelar un sistema que cumpla todas las exigencias requeridas y da una pauta, para que al m omento de realizar las pruebas ratifiquen la correcta funcionalidad del sistema.

Interfaces Externas

• Aquí se definen los requerimientos que intervienen en la interfaz de usuario e interfaces que están relacionados con otro sistema.

• De igual manera la interfaz de comunicación del sistema se la define en este apartado.

Funciones• En este subtema se definen las acciones o

funciones que el sistema debe desarrollar, estas acciones de indican como “el sistema deberá…“

El estándar IEEE 830, en sus últimas versiones, permite la organización de esta subsección de múltiples formas y simplemente sugiere alguna manera para hacerlo, dejando la oportunidad de utilizar cualquier otra justificando suficientemente la utilización de ésta.

FUNCIONES

Por tipo de usuario: Para cada clase de usuario que exista en la organización, se especifican los requisitos funcionales que le afecten o tengan mayor relación con sus tareas

Por objetos: Para cada objeto se detallan sus atributos y sus funciones.

Por objetivos: Para cada objetivo requerido al sistema, se detallarán las funciones que permitan llevarlo a cabo

Por jerarquía funcional: Para cada función y subfunción del sistema se detallará la entrada, el proceso en el que interviene y la salida

Requisitos de Rendimiento

Se incluyen los requisitos relacionados con la carga que se espera que tenga que soportar el sistema (número de usuarios simultáneos, número de terminales ...). Asimismo, se pueden incluir los requisitos que afecten a la información que se vaya a guardar en la base de datos (cantidad de registros en una base de datos, frecuencia de uso...)

Restricciones de DiseñoSe incluyen aquí todas las restricciones que afecten al diseño de la aplicación, como pueden ser estándares internos de la organización, limitaciones hardware, etc.

Atributos del SistemaSe detallarán atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos de acceso restringido (password), usuarios autorizados a realizar ciertas tareas críticas ...

Otros requisitosAquellos requerimientos que no se hayan podido incluir en ninguna de las secciones anteriormente especificadas.

ApéndicesSe incluirá aquí cualquier tipo de información relacionada con la ERS, pero que no forme parte de la misma. Por ejemplo, se incluirían los resultados del análisis de costes, restricciones especiales acerca del lenguaje de programación...

ÍndiceSe proporciona un índice para poder tener un acceso rápido a la documentación presentada en la ERS.