Universidad Mariano Gálvez de Guatemala
Sololá
Ingeniería en Sistemas
Análisis de Sistemas I
Inge: Antonio Escobar
Vicente Bixcúl Coroxón
2290-18-15744
Introducción
En base al recorrido que se realiza en las diferentes etapas al momento de desarrollar un sistema,
los documentos de recopilación de información y de requisitos juegan un papel muy importante,
en ambos lados, (Cliente y programados), ya que herramientas en donde se quedan plasmadas las
ideas que el sistema va a tener, en nuestro caso es indispensable adquirir esos conocimientos para
nuestro futuro, tanto como futuros programadores, o como responsable de equipo de desarrollo,
a continuación se presenta información de dos documentos las cuales nos ayudaran al momento
de plantear las ideas de futuros sistemas a desarrollar.
DERCAS
¿Qué es?
El Documento de Especificaciones, Requerimientos y Criterios de Aceptación de Software, es el
lugar donde se da descripción a las características y requisitos de un software, producto, programa
o conjunto de programas. Los requisitos se expresan en lenguaje natural, sin consideraciones ni
términos técnicos.
¿Cuándo se utiliza?
La especificación de requisitos de software es el resultado del levantamiento de información con
el usuario o cliente del producto. Son un método para una comunicación más concisa y clara entre
los encargados de desarrollar el software y el área de negocio o clientes que usaran el producto.
Se ha hecho muy evidente que una especificación deficiente de los requisitos del software puede
conducir a proyectos fallidos, de allí es que este documento es cada vez adquiera mayor
importancia.
Descripción del contenido del documento.
Propósito: Nombre o título del software que se está especificado en el documento, incluyendo su
número de versión. También se describen cuales componentes o partes del alcance del producto
están incluidas en el documento, estableciendo si cubre la totalidad del software, sólo una parte
del sistema, subsistema o subgrupo de procesos.
Alcance del producto / Software: Descripción corta del alcance del software que se está
especificando, incluyendo: Propósito u objetivo general, beneficios que brinda al área de negocio y
organización, relación de los objetivos del software con los objetivos corporativos y estrategias de
negocio. Se puede hacer referencia a otros documentos.
Referencias: Aquí se pueden incluir otros documentos impresos, documentos electrónicos o
direcciones electrónicas que complementen la documentación de requerimientos de software.
Funcionalidades del producto: Lista de las funcionalidades del software que se están
especificando en el documento de requerimientos. Cada funcionalidad puede estar compuesta por
uno o varios requerimientos funcionales de software. Solo se incluye una lista numerada de las
principales funcionalidades.
Clases y características de usuarios: Se clasifican los usuarios que utilizaran el producto. La
clasificación puede ser en función a la frecuencia de uso, grupo de funcionalidades utilizadas,
privilegios de seguridad, nivel de experiencia y otros parámetros.
Entorno operativo: Se describe el entorno operativo en el que se desenvolverá el sistema,
software, módulo o grupo de funcionalidades, mencionando aspectos como la plataforma de
hardware, versiones de sistema operativo y otros sistemas o componentes con los que debe
coexistir.
Requerimientos funcionales: En esta sección de la plantilla, ilustramos como organizar los
requerimientos funcionales de software por funcionalidad de producto o sistema. Aquí se listan las
funcionalidades y para cada una a su vez se listan los requerimientos funcionales. Los
requerimientos funcionales también se pueden documentar en una matriz de trazabilidad de
requerimientos.
Reglas de negocio: Listado de reglas y principios que aplican a todo el conjunto de
requerimientos de software contenidos en el documento. Un ejemplo es cuales individuos o roles
pueden desempeñar cierta función bajo ciertas circunstancias.
Requerimientos de interfaces externas: Describe las características y atributos de las
interfaces con el usuario (GUI), interfaces con el hardware, interfaces con otros sistemas y las
interfaces de comunicaciones.
Requerimientos no funcionales: Los requerimientos no funcionales son los que especifican
criterios para evaluar la operación de un servicio de tecnología de información, en contraste con
los requerimientos funcionales que especifican los comportamientos específicos.
Otros requerimientos: Requerimientos no cubiertos en ninguna otra sección del documento de
requerimientos de software, por ejemplo: Requerimientos de bases de datos, internacionalización,
legales y objetivos de reúso de componentes de software.
Glosario: Descripción de términos y siglas necesarias para el entendimiento del documento de
requerimientos de software.
ERS
Objetivos.
• Ayudar a los clientes a describir claramente lo que se desea obtener mediante un
determinado software: El cliente debe participar activamente en la especificación
de requisitos, ya que éste tiene una visión mucho más detallada de los procesos
que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.
• Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En
muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS
permite al cliente definir todos los requisitos que desea y al mismo tiempo los
desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena
especificación de requisitos, los costes de desarrollo pueden incrementarse
considerablemente, ya que se deben hacer cambios durante la creación de la
aplicación.
• Servir de base para desarrollos de estándares de ERS particulares para cada
organización: Cada entidad puede desarrollar sus propios estándares para definir
sus necesidades.
Una buena especificación de requisitos software ofrece una serie de ventajas entre las que destacan
el contrato entre cliente y, la reducción del esfuerzo en el desarrollo, una buena base para la
estimación de costes y planificación, un punto de referencia para procesos de verificación y
validación, y una base para la identificación de posibles mejoras en los procesos analizados.
La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe decirlas de una
determinada manera. En este documento se presentará una de las formas que viene especificada
por el estándar IEEE 830.
Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto,
debe definir correctamente todos los requerimientos, pero no más de los necesarios. Esta
documentación no debería describir ningún detalle de diseño, modo de implementación o gestión
del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos.
Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementación.
Así pues, el grado y el lenguaje utilizado para la documentación de los requisitos estarán en función
del nivel que el usuario tenga para entender dichas especificaciones.
Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que se indican
en el IEEE son las siguientes [Chalmeta, 2000][Piattini, 1996]:
· Correcta
· No ambigua
· Completa
· Verificable
· Consistente
· Clasificada
· Modificable
· Explorable
· Utilizable durante las tareas de mantenimiento y uso
• Corrección
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real. La
corrección de la ERS implica que el sistema implementado será el sistema deseado.
• Ambigüedad
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación.
Cada característica del producto final debe ser descrita utilizando un término único y, en caso de
que se utilicen términos similares en distintos contextos, se deben indicar claramente las diferencias
entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado específicamente.
Los analistas deben poner un cuidado especial a la hora de especificar los requisitos. El hecho de
utilizar el lenguaje natural para hacer la ERS comprensible a los usuarios supone un riesgo muy
elevado, porque el lenguaje natural puede llegar a ser muy ambiguo.
Ejemplo:
En términos generales, el lenguaje natural es de los más ambiguos. Por el contrario, existen los
lenguajes formales que no son ambiguos, pero son más difíciles desaprender y menos
comprensibles para el que no los conoce.
Todos los clientes tienen el mismo campo de control
1.- ¿Todos tienen el mismo valor en el campo de control?
2.- ¿Todos los campos de control tienen el mismo formato?
3.- ¿Un campo de control se usa para todos los clientes?
E78. Ingeniería del Software ERS según el estándar IEEE 830 4
• Completitud
Una ERS es completa si:
· Incluye todos los requisitos significativos del software (relacionados con la funcionalidad,
ejecución, diseño, atributos de calidad o interfaces externas).
· Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en
todas las posibles situaciones.
· Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe
razonar suficientemente por qué no se ha utilizado dicho apartado.
· Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los
términos y unidades de medida empleados.
La ERS debe ser siempre completa, aunque en ocasiones esto no será posible. Por ejemplo, si
todavía no se han determinado los formatos de los informes finales o por cualquier razón se está
esperando la publicación de un Real Decreto o un reglamento sobre impuestos.
• Verificabilidad
Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual
una persona o una máquina pueda chequear que el software satisface dicho requerimiento.
• Consistencia
Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella es contradictorio
o entran en conflicto. Se pueden dar tres casos:
· Requisitos que describen el mismo objeto real utilizando distintos términos.
· Las características especificadas de objetos reales. Un requisito establece que todas las luces son
verdes y otro que son azules.
· Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos
acciones serían perfectamente válidas (¿sumar o multiplicar?)
No verificables:
El producto debería funcionar bien
El producto debería tener una buena interfaz de usuario
Verificable:
La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en
los 30 segundos siguientes en el 100% E78. Ingeniería del Software ERS según el estándar IEEE
8305
• Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos
criterios:
· Importancia: Pueden ser esenciales, condicionales u opcionales.
· Estabilidad: Cambios que pueden afectar al requisito.
Lo ideal es el establecimiento de prioridades, de modo que la implementación de un requisito de
menor prioridad no emplee excesivos recursos.
• Modificabilidad
Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y
consistente. Para ello, es deseable tener una organización coherente y fácil de usar en la que
aparezca el índice o una tabla de contenidos fácilmente accesible.
También es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en más
de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa será mucho más
cómoda si no tenemos que buscar el mismo requisito en varios lugares.
• Explorabilidad
Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que
puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que
realizan dicho requisito).
Cuando un requisito de la ERS representa un desglose o una derivación de otro requisito, se debe
facilitar tanto las referencias hacia atrás como hacia adelante en el ciclo de vida.
Las referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del
software. Cuando el código y los documentos son modificados, es esencial poder comparar el
conjunto total de requisitos que puedan verse afectados por estas modificaciones.
• Utilizable durante las tareas de mantenimiento y uso
En la ERS también se deben tener en cuenta las necesidades de mantenimiento. El personal que
no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su
mantenimiento. Así, dicha ERS actúa a modo de plano de la aplicación, permitiendo incluso
modificaciones que no requieran un cambio en el diseño.
En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal que se encargue
del mantenimiento no tiene por qué tener. Por esta razón es necesaria una correcta
documentación de las funciones,
ya que, si no se conoce en detalle su origen, difícilmente podrán ser modificadas.
Conclusiones
• La importación de la documentación en los procesos de desarrollo de sistemas es grande,
ya que en ella quedara plasmada la idea principal del o los sistemas.
• El Documento de Especificaciones, Requerimientos y Criterios de Aceptación de Software,
describe las características y requisitos de un software.
• Ayudar a los clientes a describir claramente lo que se desea obtener mediante un
determinado software: El cliente debe participar activamente en la especificación de
requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan
a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.
