Please enable JavaScript.
Coggle requires JavaScript to display documents.
ESQUEMA ERS DE LA IEEE 380 - 1998 (REQUISITOS ESPECÍFICOS Esta sección es…
ESQUEMA ERS DE LA IEEE 380 - 1998
INTRODUCCIÓN
En esta sección se proporcionará una introducción a todo el documento de Especificación de Requisitos Software.
PROPÓSITO
Aquí se define el propósito del documento ERS y se especificará a quién va dirigido el documento.
ÁMBITO DEL SISTEMA
En esta subsección se pondrá nombre al futuro sistema, se explicará lo que el sistema hará y lo que no hará, se describirá los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema y se mantendrán referencias a los documentos de nivel superior que puedan existir.
DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS
Se definirán aquí todos los términos, acrónimos y abreviaturas utilizadas en el desarrollo de la ERS.
REFERENCIAS
Se presentará una lista completa de todos los documentos referenciados en la ERS.
VISIÓN GENERAL DEL PRODUCTO
Esta subsección describirá brevemente los contenidos y la organización del resto de la ERS.
DESCRIPCIÓN GENERAL
En esta sección 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.
PERSPECTIVA DEL PRODUCTO
Esta subsección debe relacionar el futuro sistema con otros productos. Así pues, podríamos dividir ésta en pequeñas subsecciones indicando cada uno de los puntos a tener en cuenta.
Indicar si es un producto independiente o parte de un sistema mayor.
Interfaces de sistema
Interfaces de usuario
Características lógicas de la interfaz
Cuestiones de optimización de la interfaz de usuario
Interfaces hardware
Interfaces software
Descripción del producto software utilizado
Propósito de la interfaz
Definición de la interfaz: contenido y formato
Interfaces de comunicación
Limitaciones de memoria
Operaciones
Modos de operación de los distintos grupos de usuarios
Períodos de operaciones interactivas y automáticas
Funciones respaldo del procesamiento de datos
Operaciones de backup y recuperación
Requerimientos para adaptarse a la ubicación
Indicar cualquier dato o secuencia de inicialización específico de cualquier lugar, modo de operación
Características que deben ser modificadas para una instalación en particular
FUNCIONES DEL PRODUCTO
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. Para ello se pueden utilizar métodos textuales o gráficos, siempre que dichos gráficos reflejen las relaciones entre funciones y no el diseño del sistema.
CARACTERÍSTICAS DE LOS USUARIOS
Se indica aquí el tipo de usuario al que se dirige la aplicación, así como su experiencia técnica, nivel de conocimientos, etc.
RESTRICCIONES
Se debe indicar aquí cualquier tipo de limitación como pueden ser políticas de la empresa, limitaciones hardware, seguridad, protocolos de comunicación, interfaces con limitaciones que se imponen sobre los desarrolladores del producto.
SUPOSICIONES Y DEPENDENCIAS
En este apartado aparecerá cualquier factor, que si cambia puede afectar a los requerimientos. No son restricciones de diseño, p. ej. asumir que un determinado sistema operativo estará disponible, presuponer una cierta organización de las unidades de la empresa. Si cambian ciertos detalles puede ser necesario revisar los requisitos.
REQUISITOS FUTUROS
Se indican aquí posibles mejoras del sistema en el futuro. Estas mejoras deben estudiarse y analizarse una vez concluido y puesto en marcha el sistema. Son modificaciones a realizar en un futuro incierto.
REQUISITOS ESPECÍFICOS
Esta sección es de la especificación de requisitos de software que contiene todos los requerimientos hasta un nivel de detalle suficiente para permitir a los diseñadores diseñar un sistema que satisfaga dichos requisitos, y que permita diseñar las pruebas que ratifiquen que el sistema cumple con las necesidades requeridas.
Los requisitos deben describir comportamientos externos del sistema, observables por el usuario así como por parte de los operadores y otros sistemas.
Se deben indicar todos los requisitos, esta sección es la más larga de la ERS y debe cumplir los principios descritos en los primeros apartados de este informe:
Principio de corrección
No ambiegüedad
Completitud
Consistencia
Clasificación
Verificabilidad
Modificabilidad
Exploraribilidad
Mantenibilidad
Este apartado del documento debe ser perfectamente legible por el cliente y por personas de muy distinta formación. Tener en cuenta la identificación de cada uno de los requisitos mediante algún código o sistema de numeración.
INTERFACES EXTERNAS
En esta subsección se definirán los requisitos que afecten a la interfaz de usuario e interfaz con otros sistemas (hardware y software), así como a interfaces de comunicación.
FUNCIONES
En esta subsección se deben especificar todas aquellas acciones o funciones que deberá llevar a cabo el sistema a desarrollar. Las acciones que se indican como "el sistema deberá ... " son las que deben incluirse en este apartado.
Por tipo de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organización, se especifica los requisitos funcionales que le afecten o tengan mayor relación con sus tareas.
Por objetos: Los objetos son entidades del mundo real que son reflejados en el sistema. Por tanto, para cada objeto se detallan sus atributos y sus funciones. Los objetos se pueden agrupar en clases.
Por objetivos: un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo requerido al sistema, se detallarán las funciones que permitan llevarlo a cabo.
Por jerarquía funcional: La funcionalidad del sistema se especifica como una jerarquía de funciones que comparten entradas, salidas o datos del propio sistema. Para cada función y subfunción del sistema se detallará la entrada, el proceso en el que interviene y la salida. Normalmente este tipo de análisis implica que el diseño siga el paradigma de diseño estructurado. Este sistema se utiliza cuando ninguno de los anteriores se puede aplicar.
REQUISITOS DE RENDIMIENTO
En esta subsección 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 ...) 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Ñ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 de hardware, seguridad, protocolos de comunicación, entre otros.
ATRIBUTOS DEL SISTEMA
Se detallarán atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos de acceso restringido (password), usuarios autorizados a realizar ciertas tarea críticas...
OTROS REQUISITOS
Aquellos requerimientos que no se hayan podido incluir en ninguna de las secciones anteriores especificaciones.
APÉNDICES
Se incluirán aquí cualquier tipo de información relacionada con la ERS, pero que no forme parte de la misma. Por ejemplo, se incluirán los resultados del análisis de costos, restricciones especiales acerca del lenguaje de programación.
ÍNDICES
Se proporciona un índice para poder tener un acceso rápido a la documentación presentada en la ERS.
CONCLUSIONES
El éxito de cualquier desarrollo de software se basa en la comprensión total de los requisitos del usuario. No importa lo bien diseñado o codificado que pueda estar, si no se ha analizado correctamente puede defraudar al usuario y frustrar al desarrollador
El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero , en realidad, el contenido del análisis es muy denso y abundan las malas interpretaciones o la falta de información. Es muy difícil evitar la ambigüedad.
El análisis de requisitos es la fase más importante en el desarrollo de un proyecto software, ya que es en esta fase en la que el usuario indica las especificaciones del futuro sistema, porque de un correcto análisis dependerá la correcta implementación de la aplicación.
El documento de especificación de requisitos de software supone una especie de contrato entre el cliente y el proveedor del desarrollo en el que el usuario indica sus necesidades y otros se limitan a implementar lo que se indica en el documento. Por esto es que es tan importante la fase de análisis de requisitos.
La tarea del análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificación y, por lo tanto, el analista y el cliente tienen un papel muy activo en la obtención de estas necesidades.
El UML es la herramienta moderna que se utiliza para el diseño de proyectos de software orientado a objetos. Los casos de uso modelan el sistema desde el punto de vista del usuario, permitiéndole así la comprensión completa del futuro sistema. El nuevo producto se muestra en forma de "historieta"
Esta fase es la más costosa (temporalmente) en el desarrollo de un producto de software. Esto se debe en general a que el cliente no sabe lo que quiere y requiere de la ayuda de los analistas para completar las funcionalidades que se han de implementar.