El documento describe la estructura estándar de un Documento de Requisitos de Software (ERS) según el IEEE 830-1998, incluyendo las siguientes secciones: Introducción, Descripción General, Requisitos Específicos, Apéndice e Índice. La Introducción presenta el propósito, alcance, definiciones y visión general del documento. La Descripción General no describe requisitos sino su contexto, incluyendo perspectivas del producto, funciones, usuarios y restricciones. Los Requisitos Específicos detallan
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
1.
2. 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
3. CONTENIDOS
• Esquema de la ERS definida en el IEEE 830-1998
• Introducción
• DescripciónGeneral
• Requisitos Específicos
• Apéndice
• Índice
5. 1. INTRODUCCIÓN DE LA ERS
En esta sección se proporcionara una
introducción a todo el documento de
Especiación de Requisitos Software(ERS).
Consta de varias subsecciones:
propósito, ámbito del sistema,
definiciones, referencias y
visión general del documento.
6. 1. INTRODUCCIÓN DE LA ERS
1.1. PROPÓSITO
En esta subsección se definirá el propósito del
documento ERS y se
especificará a quién
va dirigido el
documento.
7. 1. INTRODUCCIÓN DE LA ERS
1.2. ÁMBITO DEL SISTEMA
En 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.
8. 1. INTRODUCCIÓN DE LA ERS
1.3. DEFINICIONES, ACRÓNIMOSY
ABREVIATURAS
En esta subsección se
definirán todos los
términos, acrónimos
y abreviaturas
utilizadas en la ERS.
9. 1. INTRODUCCIÓN DE LA ERS
1.4. REFERENCIAS
En esta subsección se mostrará
una lista completa de
todos los documentos
referenciados en
la ERS.
10. 1. INTRODUCCIÓN DE LA ERS
1.5. VISIÓN GENERAL DEL
DOCUMENTO
Esta subsección describe brevemente los
contenidos y la organización
del resto de la ERS.
11. 2. DESCRIPCIÓN GENERAL
Se 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
12. 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
13. 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
14. Suposiciones y Dependencies
Estos dos aspectos son importantes en la definición de los
requerimientos, si estos factores cambian afectan
directamente a los requerimientos.
Ejemplo
Suposiciones
El cliente debe tener computadoras aptas para la
instalación y correcto funcionamiento del sistema.
Dependencia
El 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.
15. 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,
16. 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.
17. 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.
18. Funciones
• En este subtema se definen las acciones o funciones
que el sistema debe desarrollar, estas acciones de
indican como “el sistema deberá…“
19. 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
20. 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...)
21. Restricciones de Diseño
Se 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 Sistema
Se detallarán atributos como la fiabilidad, mantenibilidad,
seguridad, mecanismos de acceso restringido (password), usuarios
autorizados a realizar ciertas tareas críticas ...
22. Otros requisitos
Aquellos requerimientos que no se hayan podido incluir en ninguna
de las secciones anteriormente especificadas.
Apéndices
Se 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...
Índice
Se proporciona un índice para poder tener un acceso rápido a la
documentación presentada en la ERS.