Tema N° 14 Especificación de Requisitos del Software

Profa. Sara Alcántara
ESPECIFICACIÓN
DE REQUISITOS
Tema Nº 14
✓ Introducción, Definiciones
✓ Objetivos, Implicaciones
✓ Ventajas, Usuarios, Evolución
DEL SOFTWARE (ERS)

Introducción de la ERS
01
02
03
04
05
06
07
08
Implicaciones de la ERS
Ventajas de la ERS
Características Fundamentales de la ERS
Características Deseables para un buen ERS
Usuarios de la ERS
Evolución de la ERS
Estructura de la ERS
3
5
7
8
9
10
13
14
09
10 16
CONTENIDO
Definición de la ERS
Objetivos de la ERS 6
Referencias
11 17

Introducción:
ERS Después de haber realizado la elicitación de los requisitos del
software es necesario llevar un registro documentado (aplicando
técnicas y/o estándares de documentación) con el fin de pasar en
limpio el análisis realizado a los requisitos, esta documentación
debe ser actualizada cuando se realiza su validación, verificación y
negociación con el cliente o los usuarios finales a fin de establecer
una documentación detallada y depurada, este proceso se llama
especificación de requisitos de software (ERS).
Para escribir la Especificación de Requisitos de software se utiliza
como guía un estándar, como el de la IEEE-830, el PSS-05 de la
Agencia Espacial Europea o la plantilla "Volere" (Robertson y
Robertson, 1999). Estas plantillas proveen con una estructura
específica para presentar los requerimientos. Por ejemplo, en la
IEEE-830: introducción, descripción general, requerimientos
específicos, apéndices e índice.
Especificación de Requisitos del Software (ERS)

Introducción:
ERS Para realizar bien el desarrollo de software es esencial tener una
especificación completa de los requisitos. Independientemente de
lo bien diseñado o codificado que esté, un sistema pobremente
especificado decepcionará al usuario y su mantenimiento será
difícil.
La Especificación de Requisitos suministra al técnico y al cliente, los
medios para valorar la calidad del sistema que se entrega ya
terminado.
De la experiencia se sabe que el costo de reparar un error se
incrementa en un factor de diez (Pfleeger, 2006) de una fase de
desarrollo a la siguiente, por lo tanto, la preparación de una
Especificación de Requisitos adecuada, reduce los costos y los
riesgos asociados con el desarrollo del proyecto.

Definición:
ERS Según el estándar IEEE, 1990 se define:
Especificación: Documento que define, de forma completa,
precisa y verificable, los requisitos, el diseño, el
comportamiento u otras características de un sistema o de
un componente de un sistema.
Software: Conjunto de programas, procedimientos y
documentación asociada a la operación de un sistema
informático.
Con estas premisas puede definirse la Especificación de Requisitos
del Software (ERS): como la documentación de los requisitos
esenciales (funciones, rendimiento, diseño, restricciones y
atributos) del software y de sus interfaces externas (IEEE, 1990).

Objetivos:
ERS
Las características deseables para una buena ERS son las siguientes (IEEE 1984B):
3
2
1
Ayudar a los clientes
a describir
claramente lo que se
desea obtener
mediante un cierto
software.
Ayudar a los
desarrolladores a
entender qué
quiere
exactamente.
Servir de base para
desarrollos de
estándares de ERS
particulares para
cada organización.

Implicaciones:
ERS Las exigencias para una ERS conducen a no excederse a
la hora de definirla y construirla, sino mas bien a
abordar la descripción de lo que hay que desarrollar, no
el cómo, el cuándo, etc. Se desarrolla el software. Esto
implica:
Describir correctamente todos los requisitos de
software sin incluir requisitos innecesarios.
No describir ningún detalle de diseño de
software, de su verificación, de la dirección del
proyecto, excepto las restricciones impuestas al
diseño que influyen en los requisitos.

Ventajas:
ERS
Reducción del
esfuerzo de
desarrollo.
Base para la
estimación de
costes y
planificación.
Punto de referencia
para procesos de
verificación y
validación.
Las principales ventajas de realizar la ERS son:
Contrato cliente –
desarrolladores.
Base para posibles
mejoras.

Características Fundamentales:
ERS Las dos características fundamentales de una ERS eficaz
son:
Incluir información veraz, es decir, coherente con
las necesidades reales del usuario que se desean
satisfacer.
Comunicar dicha información de forma veraz, es
decir, de tal manera que se pueda comprender
perfectamente.

Características Deseables:
ERS
3
Fácil de verificar. Existencia de algún
procedimiento finito y efectivo en coste para
que se compruebe que el software satisface
dicho requisito.
1
No ambigua. Cada requisito descrito debe tener
una única interpretación.
2
Completa. Lo será si:
- Incluye todos los requisitos significativos del
software.
- Define la respuesta del software a todas las
posibles clases de datos de entrada y en todas
las posibles situaciones, tanto para los datos
válidos como para los que no lo son.
- Está conforme con el estándar de especificación
que se deba cumplir.
- Están etiquetadas y referenciadas en el texto
todas las figuras, tablas y diagramas.
- Si algún término está por determinar, se debe
acompañar de una descripción de las
condiciones que lo han causado y una posible
descripción para eliminarlo.

ERS
6
Fácil de modificar. La estructura y el estilo de
la ERS deben permitir que cualquier cambio
necesario en los requisitos pueda realizarse de
forma fácil, completa y consistente. Esto
implica que la ERS debe:
- Tener una organización coherente y
manejable (con una tabla de contenidos, un
índice y referencias cruzadas).
- No ser redundante, es decir, el mismo
requisito no debe aparecer en más de un
lugar en la ERS.
4
Consistente. Lo será sí y sólo sí ningún
conjunto de requisitos entran en conflicto entre
ellos.
Pueden darse tres tipos de conflictos (Davis,
1993):
- Dos o más requisitos pueden describir el
mismo objeto real pero utilizan términos
distintos para designarlo.
- Las características especificadas de objetos
reales pueden estar en conflicto.
- Puede haber conflicto lógico o temporal
entre dos acciones determinadas.
5
Facilidad de utilización durante la fase de
explotación y de mantenimiento. La ERS debe
considerar las necesidades de mantenimiento,
incluyendo una eventual sustitución del software,
especialmente debido a:
- El personal que se encarga del mantenimiento no
ha estado relacionado con el desarrollo del
producto software.
- Gran parte de los conocimientos y de la
información necesaria para el mantenimiento se
dan por supuestos en la organización del
desarrollo, pero suelen estar ausentes en la
organización de mantenimiento.

ERS
7
Facilidad para identificar el origen y las consecuencias de cada requisito (facilidad de traza). Se dice que una ERS facilita las referencias con
otros productos del ciclo de vida si establece un origen claro para cada uno de los requisitos y si posibilita la referencia de estos requisitos en
desarrollos futuros o en incrementos de la documentación.
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
las referencias hacia delante en el ciclo de vida. Estas últimas son especialmente importantes para el
mantenimiento del software. Cuando el código o la documentación son modificados, es esencial poder comprobar el conjunto total de
requisitos que pueden verse afectados por estas modificaciones.

Usuarios de la ERS:
ERS
Especifican los
requisitos y los leen
para chequear que
atienden sus
necesidades.
Especifican cambios en
los requisitos.
Clientes del Sistema
1
Usan los documentos de
requisitos para
planificar una propuesta
(oferta) para el sistema
y planificar el proceso de
desarrollo.
Gerentes
Usan los requisitos para
entender qué sistema
tiene que ser
desarrollado.
Ingenieros de Sistemas
2
desarrollar pruebas de
validación para el
sistema.
Ingenieros de Pruebas
4
ayudar a entender los
sistemas y las
relaciones entre sus
partes.
Ing. de Mantenimiento
5
3

Evolución:
ERS Normalmente, la ERS deberá ser cambiada a medida que progresa
el producto software ya que es casi imposible especificar algunos
detalles en el momento en el que se inicia el proyecto y es casi
seguro que se realizarán cambios adicionales como consecuencia
de haber encontrado deficiencias, defectos e inexactitudes que se
descubren a medida que el producto evoluciona.
En este proceso deben tenerse en cuenta las consideraciones
siguientes:
El requisito debe ser especificado de la forma mas completa
posible, aun en el caso en que se prevean de forma inevitable
revisiones en el proceso de desarrollo.
Debe iniciarse un proceso formal de cambio para identificar,
controlar, seguir e informar de cambios proyectados tan
pronto como sean identificados.

Evolución:
ERS Los cambios aprobados en los requisitos deben incluirse en la ERS
de forma que permita:
Suministrar una revisión precisa y completa del rastro de las
modificaciones.
Permitir un examen de fragmentos actuales y reemplazados
en la ERS.

Estructura del ERS de acuerdo a la IEEE Std. 830-1998 (IEEE, 1999b):
ERS
1. Introducción
1.1 Objetivo
1.2 Ámbito
1.3 Definiciones, acrónimos y abreviaturas
1.4 Referencias
1.5 Descripción del resto del documento
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Limitaciones generales
2.5 Supuestos y dependencias
3. Requisitos específicos
3.1 Requisitos funcionales
3.2 Requisitos de interfaz externa
3.3 Requisitos de ejecución
3.4 Requisitos de diseño
3.5 Atributos de calidad
3.6 Otros requisitos
4. Apéndices
5. Índice
3. Requisitos específicos
3.1 Requisitos funcionales
3.1.1 Requisito funcional 1
.
.
.
3.1.2 Requisito funcional 2
……………..
3.1.n Requisito funcional n
3.2 Requisitos de interfaz externa
3.2.1 Interfaces de usuario
3.2.2 interfaces hardware
3.2.3 interfaces software
3.2.4 interfaces de comunicaciones
3.3 Requisitos de ejecución
3.4 Requisitos de diseño
3.4.1. Acatamiento de estándares
3.4.2. Limitaciones hardware
………………..
3.5 Requisitos no funcionales (Atributos de
calidad)
3.5.1. Seguridad
3.5.2. Mantenimiento
………………..
3.6 Otros requisitos
3.6.1. Base de datos
3.6.2. Operaciones
3.6.3 Adaptación de situación

Referencias Electrónicas
Referencias Bibliográficas
Bibliográficas y Electrónicas:
Referencias

Gomez M., Cervantes J. & Gonzalez P. (2019). Fundamentos de Ingeniería de Software , 1era. Edición. Mexico, D.F.:
Universidad Autónoma Metropolitana.
Bibliográficas:
Referencias

García, A. & García, F. (2018, Febrero). Ingeniería de Software I - Tema 4: Ingeniería de Requisitos. [Archivo PDF].
https://repositorio.grial.eu/bitstream/grial/1143/1/IS_I%20Tema%204%20-%20Ingenieria%20de%20Requisitos.pdf
García, D. (2015, Octubre). Análisis de requisitos en el desarrollo del software [Archivo PDF]. https://e-
archivo.uc3m.es/bitstream/handle/10016/26008/PFC_Dalila_Garcia_Notario.pdf
Guevara, J (s. f.). Introducción al análisis de requisitos (A.R.). Sites.Google, de
https://sites.google.com/site/adai6jfm/home/introduccin-al-anlisis-de-requisitos-ar
IEEE (2008, Octubre). Especificación de Requisitos según el estándar de IEEE 830 [Archivo PDF].
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
Rodríguez, N. (2018, Febrero). Ingeniería de Software - Unidad 2: Especificación de Requerimientos Trimestre I. [Diapositiva de
PowerPoint]. Slideshare de https://es.slideshare.net/Norerod/mv-unidad-2-t1?
Roliva, F. (s. f.). Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión 1º D.A.I. – Tema 3 Análisis de los Requisitos
[Archivo PDF]. http://www.jroliva.com/fernando/An%C3%A1lisis/Teoria/Tema3.pdf
Electrónicas:
Referencias

Docente:
PNF en Informática
MSC.
salcantara3@gmail.com
Ingeniería del Software II - Trimestre I
SARA ALCÁNTARA
Recurso:
El recurso puede ser utilizado bajo condiciones Creative Commons.
Atribuciones:
Algunas de las imágenes utilizadas son de libre uso,
descargadas desde:

Tema N° 14 Especificación de Requisitos del Software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tema N° 14 Especificación de Requisitos del Software

Similar a Tema N° 14 Especificación de Requisitos del Software (20)

Más de SaraEAlcntaraR

Más de SaraEAlcntaraR (9)

Último

Último (20)

Tema N° 14 Especificación de Requisitos del Software