Análisis de Sistemas I

Catedrático
Ing. Byron A. Hernández
ERS

Correo: bherdezumg@gmail.com
Especificación y Requerimientos del Software
(ERS)
Especificación y Requerimientos del Software
(ERS)
IEEE
Corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de
Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a
la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada
por profesionales de las nuevas tecnologías, como ingenieros en eléctricos, ingenieros
en electrónica, ingenieros en sistemas e ingenieros en telecomunicación.

Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir

y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para
beneficio de la humanidad y de los mismos profesionales. 

ERS
Es una colección estructurada de información que contiene los requisitos del sistema.
 Objetivos del ERS
 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 desarrolladores (como ya se ha indicado
con anterioridad), 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.
 Características de una buena ERS
• Correcta
• No ambigua
• Completa
• Verificable
• Consistente
• Clasificada
• Modificable
• Explorable
• Utilizable durante las tareas de mantenimiento y uso
 Características de una buena ERS
Correcta: La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real actual o futura.
La corrección de la ERS implica que el sistema implementado será el sistema deseado.

Ambigua: 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. Ejemplo:

Completitud: Un 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.
 Características de una buena ERS
• Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar
suficientemente el porqué 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.

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. Ejemplo:
 Características de una buena ERS
Consistencia: Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios
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?)

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.
 Características de una buena ERS
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.

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

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.
Formato ERS según estándar IEEE 830
Ingeniería de Requerimientos
 Se define como el “proceso de establecer los servicios que
el consumidor requiere de un sistema y las restricciones
sobre las cuales debe funcionar y ser desarrollado”.
Sommerville.

 Es una de las etapas mas criticas del proceso de software,

determina que se va realizar.

 Mas del 30% de los proyectos de software que fracasan lo

realizan por causa de los requerimientos mal interpretados.
 Actividad
Listar de manera individual, los requerimientos
necesarios para hacer una tasa de café.
Escribirlos en una hoja de su cuaderno.
Ingeniería de Requerimientos
Tipos de Especificación:
 Requerimientos de Usuarios: Están definidos en
lenguaje natural que esbozan los servicios y
restricciones del sistema, Escrito para consumidores.

 Requerimientos del Sistema: Están definidos de una

manera estructurada, y además de los servicios y
restricciones del sistema, da nociones concisas de
como debería ser implementado.
Tipos de Requerimientos
Requerimientos Funcionales: Son declaraciones de los servicios que
proveerá el sistema, de la manera en que éste reaccionará a entradas
particulares. En algunos casos, los requerimientos funcionales de los
sistemas también declaran explícitamente lo que el sistema no debe
hacer. Los requerimientos funcionales de un sistema describen la
funcionalidad o los servicios que se espera que éste provea.

Estos dependen del tipo de software y del sistema que se desarrolle y

de los posibles usuarios del software. Cuando se expresan como
requerimientos del usuario, habitualmente se describen de forma
general mientras que los requerimientos funcionales del sistema
describen con detalle la función de éste, sus entradas y salidas,
excepciones, etc.
Requerimientos Funcionales
Ejemplos
 El sistema deberá almacenar la información
personal de los pacientes.
 El sistema deberá poder desplegar la historia
clínica en cualquiera de los nodos de acceso.
 El sistema deberá registrar cualquier acceso o
modificación sobre una historia clínica
 Tipos de Requerimientos
Requerimientos No Funcionales: Son restricciones de los servicios
o funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo, estándares, y otros. Son
aquellos requerimientos que no se refieren directamente a las
funciones específicas que entrega el sistema, sino a las
propiedades emergentes de éste como la fiabilidad, la respuesta
en el tiempo y la capacidad de almacenamiento.

De forma alternativa, definen las restricciones del sistema como la

capacidad de los dispositivos de entrada/salida y la representación
de datos que se utiliza en la interface del sistema.
Clasificación de Requerimientos no
funcionales
Requerimientos del Producto: Requerimientos que
especifican que el productos deba comportarse de
una determinada manera.
Requerimientos Organizacionales : Requerimientos
que surgen de políticas y procedimientos del
organización (Creadora o Usuaria).
Requerimientos Externos : Requerimientos
surgidos por factores externos al proyecto de
desarrollo como tal.
Ejemplos
Requerimientos del producto:
La interfaz debe ser implementada en HTML puro (Sin applets,
Javascript, o frames).

Requerimientos Organizacionales:
El proceso de desarrollo debe estar conforme con el SGC de la
corporación.

Requerimientos Externos:
La información medica de un paciente, no debe estar al alcance
del publico general.
Usuarios del Documento de Requerimientos
del Sistema
 Actividad
Del listado realizado en la actividad anterior
(Pagar un examen extraordinario) separar a
consideración que requerimientos son
funcionales y no funcionales.
 Tarea
Leer capitulo 1 del Libro
Análisis y Diseño de Sistemas - Kendall y Kendall
- 8ed