ARSI_U2AA1_Documentación_uveg_ok

Versión: Julio 2016

Revisado: Leticia Pureco

 Documentación  y  gestión  de  requerimientos  

Por: Leticia Pureco Reyes

La documentación de requerimientos consiste en

poner por escrito y de manera formal cada una de las
funcionalidades que realizará el sistema, así como
sus restricciones. Algunos autores denominan a esta
tarea especificación de requerimientos.

En dicho documento, únicamente se mencionan los

requerimientos del sistema pero no se considera la
clasificación que se ha manejado. Uno de los objetivos
de documentar los requerimientos es que exista un
respaldo, tanto para los desarrolladores como para
los usuarios y los clientes.
Figura 1.Business Man Signing In Paper (Pong &
Freedigitalphoto.net, 2011).Publicada
en:http://www.freedigitalphotos.net/images/Gestures_g185-
Business_Man_Signing_In_Paper_p53677.html

Al poner en papel las características funcionales, de rendimiento, de interfaz de usuario, de información,

y de relación con otros sistemas que deba cumplir el software,resulta más sencillo identificar las pruebas
que se realizarán y los aspectos a considerar cuando se desee evaluar el sistema.

Además, este procedimiento permitirá determinar la calidad del software,para de esta forma evitar malos
entendidos o posibles demandas por incumplimiento de parte del cliente hacia el equipo de desarrollo.

Pressman (2002) señala los siguientes principios para realizar la descripción formal de los
requerimientos:

• Separar la funcionalidad de la programación.

• Elaborar un modelo del funcionamiento del sistema considerando los datos y las respuestas
esperadas.
• Determinar el contexto en que operará el software.
• Crear un modelo intuitivo.
• Reconocer que el requerimiento es una abstracción y puede ser perfectible o modificable.
• Determinar que un requerimiento puede necesitar cambios.

Para poder aplicar esos principios a la realidad, Pressman (2002), recomienda utilizar las siguientes
directrices:

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.
ARSI_U2AA1_Documentación_uveg_ok
Versión: Julio 2016
Revisado: Leticia Pureco

El formato de la representación y el contenido deberían estar relacionados con

el problema.

La información contenida dentro de la especificación debería estar escalonada.

Los diagramas y otras formas de notación deberían restringirse en número.

Las representaciones deben permitir revisiones (p. 194).

Es muy importante considerar que el documento de requerimientos será dirigido a diversos lectores,
entre los que tenemos: usuarios, clientes, diseñadores y programadores, entre otros. Por este motivo,
hay que poner especial cuidado en la redacción, elaboración de diagramas y otros elementos, ya que
cada persona dará diferente trato a la información.

Tomando como base a Sommerville (2005), en la figura 2 se muestran algunas de las personas que
deberán consultar el documento de especificación de requerimientos.

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.
ARSI_U2AA1_Documentación_uveg_ok
Versión: Julio 2016
Revisado: Leticia Pureco

Figura 2. Personas a las que va dirigido un documento de requerimientos (Sommerville, 2005, p.124).

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.
ARSI_U2AA1_Documentación_uveg_ok
Versión: Julio 2016
Revisado: Leticia Pureco

Si al momento de estar elaborando el documento, el analista considera que la cantidad de

requerimientos es muy amplia, cabe la posibilidad de dividir el documento en dos. Por ejemplo: un
documento que lleve por nombre Requerimientos de sistema y otro llamado Requerimientos de usuario.

Hay una inmensa variedad al momento de realizar la especificación de los elementos. Podría decirse
que cualquier persona puede determinar el contenido que a su consideración debe integrar el
documento.

Pressman (2002) propone la siguiente estructura:

• “Introducción”(p. 194). Describe el contexto del sistema, el alcance, las metas y objetivos del
proyecto de software que se pretende desarrollar.

• “Descripción de la información” (p.194). Describe ampliamente la situación problemática

identificada en la organización y que se pretende resolver con la implementación del sistema.
Describe las interfaces, hardware, software, elementos internos y relaciones externas con otros
sistemas.

• “Descripción funcional” (p.195). Describe todos los requerimientos funcionales del sistema, se
mencionan las restricciones y características operativas y de rendimiento.

• “Criterios de validación” (p.195). Se detallan las pruebas que se realizarán para asegurar la
funcionalidad del sistema y determinar la calidad de éste.

• “Bibliografía” (p. 195). Referencias que hayan sido utilizadas para conocer la organización o
como fuente de información.

• “Apéndices” (p. 195). Elementos adicionales que apoyen la descripción del contenido, tales
como gráficas o imágenes.

Debido a la necesidad de homogenizar el contenido que debería tener un documento de especificación

de requerimientos de software, el Institute of Electrical and Electronics Engineers (IEEE) y otras
organizaciones se han dado a la tarea de crear un estándar que permita a cualquier desarrollador
conocer los aspectos que dicho documento deberá incluir.

Uno de los estándares más utilizados es el IEEE/ANSI 830-1998 (IEEE, 1998) en el cual se
recomiendan incluir los siguientes apartados dentro del documento de especificación:

• “Introducción” (p. 10).Propósito y descripción del documento, alcance del proyecto y

definiciones. Por ejemplo: organización, estructura organizacional, áreas involucradas, usuarios
identificados, etc.

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.
ARSI_U2AA1_Documentación_uveg_ok
Versión: Julio 2016
Revisado: Leticia Pureco

• “Descripción global”(p. 10).Funciones, restricciones, suposiciones y entorno del software, así

como las características del usuario.

• “Requisitos específicos”(p. 10).Requerimientos de sistema y de usuario.

• “Apéndices” (p. 10).Información importante relacionada con el documento.

• “Índice”. (p. 10).

Una vez terminada esta documentación, la ingeniería de documentos prácticamente concluiría. Aquí lo
importante será revisar que cada aspecto incluido en el escrito efectivamente sea cumplido durante el
desarrollo.

Una vez iniciada la etapa de diseño del ciclo de vida, será importante asegurar que los requerimientos
documentados se cumplan y no existan modificaciones durante el proceso de desarrollo. En algunos
casos los requerimientos iniciales deben reformarse ya que se presentan cambios inesperados.
También puede suceder que el proyecto es muy grande, pero con el paso del tiempo las necesidades
organizacionales sufren cambios, por lo que es importante realizar algunos ajustes a dichos
requerimientos. A este proceso se le denomina gestión de requerimientos.

Un ejemplo de lo anterior, se da en el siguiente caso:

Si al momento de iniciar el proyecto de un SI que apoye a la facturación de una organización el IVA

es del 15%, todos los cálculos y procesos se realizarán con esa tasa. Sin embargo, si existe una
modificación y el IVA sube al 17%, será necesario modificar el requerimiento y ajustar todas las
operaciones que involucren ese dato.

Según Somerville (2005), “la gestión de requerimientos

es el proceso de comprender y controlar los cambios en
los requerimientos del sistema” (p. 146).

Finalmente, para administrar los cambios, es importante considerar el punto de vista del cliente, de
los usuarios y del equipo de desarrollo, por ello se recomienda crear un comité para controlar las
modificaciones; esta entidad será la responsable de determinar si el cambio es factible y si debe
realizarse.

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.
ARSI_U2AA1_Documentación_uveg_ok
Versión: Julio 2016
Revisado: Leticia Pureco

Referencias    

Institute of Electrical and Electronics Engineers [IEEE]. (1998). Especificaciones de

los requisitos del software. Recuperado el 16 de marzo de 2012, de
http://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf

Pressman, R. S. (2002). Ingeniería del Software (5a. ed.). México: McGraw-Hill.

Sommerville, I. (2005). Ingeniería del software (7a. ed.; M. I. Alfonso, A. Botía, F.

Mora, y J. P. Trigueros, Trads.). Madrid, España: Pearson Education
[Versión en línea]. Recuperado el 16 de marzo de 2012, de
http://books.google.com.mx/books?id=gQWd49zSut4C&printsec=frontco
ver&dq=ingenier%C3%ADa+de+software&hl=en&sa=X&ei=HXdjT9CZG8
ni2QXujO3cCA&ved=0CDEQ6AEwAA#v=onepage&q=ingenier%C3%AD
a%20de%20software&f=false

Referencia  de  la  imagen  

Pong & Freedigitalphoto.net. (2011). Business Man Signing In Paper. Recuperada el

04 de julio de 2012, de
http://www.freedigitalphotos.net/images/Gestures_g185-
Business_Man_Signing_In_Paper_p53677.html

©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o
sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por
escrito de la Universidad Virtual del Estado de Guanajuato.