CAPITULO IV

REQUERIMIENTOS
Definición: Los requerimientos para un sistema de software determinan lo que hará el sistema y
definen las restricciones de su operación e implementación. La IEEE define los requerimientos de
la siguiente forma: (1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento
formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).
Las descripciones de los servicios y restricciones son los requerimientos para el sistema y el
proceso para descubrir, analizar, documentar y verificar estos servicios y restricciones se llama
ingeniería de requerimientos. Los requerimientos deben ser redactados de tal forma que pueda
ser entendido por los desarrolladores quienes van a diseñar y plasmar esos requerimientos en
código.
Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son
resultado de no hacer una clara separación entre los diferentes niveles de descripción.
Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no
realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario,
requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los
motivos de fracasos

CARACTERÍSTICAS DE LOS REQUERIMIENTOS (IEEE 830-1998)

Las características de un requerimiento son sus propiedades principales. Un conjunto de

requerimientos en estado de madurez, deben presentar una serie de características tanto
individualmente como en grupo. A continuación, se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a
construir, y además su capacidad, características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es
decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que
permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o
pruebas.
Desde un punto de vista conceptual, las actividades son de 5 clases.

 Obtener requerimientos: A través de entrevistas o comunicación con clientes o usuarios,

para saber cuáles son sus deseos.
 Analizar requerimientos: Detectar y corregir las falencias comunicativas, transformando los
requerimientos obtenidos de entrevistas y requerimientos, en condiciones apropiadas para
ser tratados por el diseño.
 Documentar requerimientos: Igual que todas las etapas, los requerimientos deben estar
debidamente documentados.
 Verificar los requerimientos: Consiste en comprobar el correcto funcionamiento de un
requerimiento en la aplicación
 Validar los requerimientos: Comprobar que los requerimientos implementados se
corresponden con lo que inicialmente se pretendía.

DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que
otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes
del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada
proyecto.

TIPOS O CLASES DE REQUERIMIENTOS.

1. Requerimientos funcionales

Son declaraciones de los servicios que proveerá el sistema de la manera en que éste reaccionará a
entradas particulares y de cómo se comportará en situaciones 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 provee.
Ejemplos:
 El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos
o seleccionar un subconjunto de ella
 El sistema deberá proveer visores adecuados para que el usuario lea documentos en el
almacén de documentos.
 A cada pedido se le deberá asignar un identificador único (ID_pedido) que el usuario
podrá copiar al área de almacenamiento permanente de la cuenta.
 El sistema deberá registrar el año, mes, día, minuto de ingreso del funcionario al campus
universitario.
 El sistema deberá producir los diferentes gráficos de pastel y de gant sobre el
comportamiento de las ventas diarias, mensuales y anuales.
 El sistema deberá contener una base de datos donde se definan los usuarios que van a
utilizar el sistema de acuerdo a su rol. Además, deberá contener un administrador
encargado de la manipulación de los usuarios: crear, modificar y eliminar usuarios.
 El sistema deberá disponer para su acceso de usuarios con sus correspondientes claves de
acceso. Las claves solo podrán ser digitada a través de un teclado virtual.
 El sistema deberá contener un módulo que permita la generación de e-mail para ser
enviado a los diferentes clientes de la Entidad.
 El sistema debe permitir la lectura de código de barras para facturar los elementos
vendidos.
 El sistema también deberá permitir la captura manual del código de los elementos
facturados en caso de no poder realizarlo a través del código de barras.
 Cuando sea posible, el valor de los campos de los diferentes formularios de entrada,
deberá ser tomado de la lista de valores correspondiente al campo.
 En campos donde se captura el valor de los diferentes ítems vendidos solo debe permitir
valores numéricos con dos decimales.

2. Requerimientos no funcionales

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. Muchos requerimientos no funcionales se refieren al
sistema como un todo más que a rasgos particulares del mismo. Los requerimientos no
funcionales surgen de las necesidades del usuario, debido a restricciones en el presupuesto, a las
políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de hardware o
software o a factores externos como los reglamentos de seguridad, políticas de privatización, etc.
Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de
verificar. Se redactan para reflejar las metas generales del usuario como la facilidad de uso, la
capacidad del sistema de recuperarse de las fallas o la respuesta rápida del usuario.
Ejemplos:
Tipos de requerimientos no funcionales

Requerimientos del producto: Especifican el comportamiento del producto. Ejemplos:

 Desempeño en la rapidez de ejecución del sistema.
  Tamaño de la memoria Ram. Tamaño del disco duro
 El sistema pueda correr sin ningún problema en cualquier plataforma hardware.
 El producto de fácil uso

Requerimientos organizacionales: Se derivan de las políticas y procedimientos existentes en la

organización del cliente y en la del desarrollador. Ejemplos:
 Estándares de los procesos que deben utilizarse.
 Lenguajes de programación a ser usados.
 Métodos de diseño.
 Tiempo de entrega.

Requerimientos externos: Cubre todos los requerimientos que se derivan de los factores externos
al sistema y de su proceso de desarrollo. Ejemplos:
 Requerimientos de interoperabilidad con otros sistemas de la organización.
 Requerimientos legales que deben seguirse para para asegurar que el sistema actúa
dentro de la ley.
 Disponer de las licencias de uso.
 Confidencialidad de la información por parte del grupo desarrollador
 Requerimientos éticos.
 El sistema no deberá revelar a sus operadores alguna información personal de los clientes
excepto su nombre y número de referencia.

3. Requerimientos del dominio.

Estos se derivan del dominio del sistema más que de las necesidades específicas de los usuarios.
Pueden ser funcionales, restringir los existentes o establecer cómo se deben ejecutar cálculos
particulares. Son importantes porque reflejan los fundamentos del dominio de aplicación.
Ejemplos:
 Deberá existir una interfaz del usuario estándar para todas las bases de datos, la cual tome
como referencia el estándar Z39.50.
 Debido a las restricciones en los derechos de autor, algunos documentos deberán borrarse
inmediatamente después de su llegada. Dependiendo de los requerimientos del usuario,
estos documentos se imprimirán de forma local en el servidor del sistema para ser
distribuidos de forma manual al usuario o enviarse a la impresora de red.
 El sistema deberá instalarse en el dominio de la red institucional.
 El sistema solo tendrá acceso si se encuentra en la intranet de la entidad.

4. Requerimientos del usuario.

Describen los requerimientos funcionales y no funcionales de tal forma que sean

comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado.
 Únicamente especifican el comportamiento externo del sistema y evitan tanto como sea
posible, las características de diseño del sistema. Deben redactarse utilizando el lenguaje
natural, representaciones y diagramas intuitivos sencillos. Ejemplo:
 El editor deberá proporcionar un recurso para la cuadricula donde una matriz de líneas
horizontales y verticales proporcionarán un fondo para la ventana del editor.
 El editor deberá proporcionar un recurso a los usuarios para agregar a su diseño nodos de
un tipo específico.
 Las letras de los formularios de entrada y salida de información deberán ser tipo xxx y de
tamaño yyy. Además, el fondo será de color zzz.
 El sistema deberá bloquearse si el usuario en determinado tiempo no usa el aplicativo.

5. Requerimientos del sistema

Estas son descripciones más detalladas de los requerimientos del usuario. Sirven como base para
definir el contrato de la especificación del sistema y por lo tanto debe ser una especificación
completa y consistente del sistema. Condiciones técnicas necesarias para que un sistema
(paquete) corra sin ningún problema. Son utilizados como el punto de partida para el diseño del
sistema. En principio los requerimientos del sistema deberán establecer lo que éste hará y no la
manera en que se implantarán. Ejemplos:
El sistema debe correr sin ningún problema en el sistema operativo Linux.

Obtención y análisis de requerimientos

En esta actividad el personal técnico del software trabajará con los clientes y los usuarios finales
del sistema para determinar el dominio de la aplicación, cuales servicios debe proveer, el
desempeño requerido, las restricciones, etc.
La siguiente gráfica muestra un modelo genérico del proceso de obtención y análisis:
 Verificación de Especificación de
requerimientos requerimientos

Entrada del
Proceso Comprensión dominio Documento
Priorización
requerimientos

Resolución conflictos
Recolección de
requerimientos

Clasificación

Compresión del dominio: El analista debe desarrollar su propia comprensión del dominio de la
aplicación. Es decir, cómo opera lo que se quiere sistematizar.
Recolección de requerimientos: Este es el proceso de interactuar con los stakeholders del sistema
para descubrir sus requerimientos. La comprensión del dominio se desarrollará más durante esta
actividad.
Clasificación: Esta actividad considera la recolección no estructurada de requerimientos y los
organiza en grupos coherentes.
Resolución de conflictos: De forma inevitable, cuando existen muchos stakeholders involucrados,
los requerimientos entrarán en conflicto. Esta actividad se refiere a encontrar y resolver estos
conflictos.
Priorización: En cualquier conjunto de requerimientos, alguno de ellos será más importante que
los otros. Esta etapa comprende la interacción con los stakeholders para descubrir los
requerimientos más importantes.
Verificación de requerimientos: Los requerimientos se verifican para descubrir si están completos.
Son consistentes y acordes con lo que realmente quieren los stakeholders del sistema.

Validación de requerimientos
El costo de hacer un cambio en el sistema, el cual proviene de un problema en los requerimientos
es mucho más grande que reparar los errores de diseño o los de codificación. La razón es que un
cambio en los requerimientos por lo regular significa que el diseño y la implementación del
sistema también debe cambiar y que éste debe cambiar y probarse nuevamente. Las verificaciones
incluyen:
Verificaciones de validez: Un usuario puede pensar que se necesita un sistema para llevar a cabo
ciertas funciones. Sin embargo, el razonamiento y el análisis identifican que se requieren funciones
adicionales y diferentes. Los sistemas tienen diversos usuarios con diferentes necesidades y
cualquier conjunto de requerimientos un compromiso en el entorno del usuario.
Verificaciones de consistencia: Los requerimientos en el documento no deben contradecirse. Esto
es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del
sistema.
Verificaciones de integridad: El documento de requerimientos debe incluir requerimientos que
definan todas las funciones y restricciones propuestas por el usuario del sistema.
Verificaciones de realismo: Utilizando el conocimiento de la tecnología existente, los
requerimientos deben verificarse para asegurar que se pueden implementar. Estas verificaciones
también deben tomar en cuenta el presupuesto y calendarización del desarrollo del sistema.
Verificabilidad: Para reducir las discusiones entre el cliente y el contratista, los requerimientos
siempre deben redactarse de tal forma que sean verificables. Esto significa que puede diseñarse
un conjunto de verificaciones para demostrar que el sistema a entregar cumple esos
requerimientos.

Técnicas de validación de requerimientos

Existen varias técnicas de validación de requerimientos que pueden en conjunto o de forma

individual:
1. Revisiones de requerimientos. Los requerimientos son analizados sistemáticamente por
un equipo de revisores. Es un proceso manual que involucra a varios lectores que verifican el
documento de requerimientos tanto del personal del cliente como del contratista en cuento a
anomalías y omisiones. Los conflictos, contradicciones, errores y omisiones de los requerimientos
deberán señalarse durante la revisión y registrarse formalmente.
2. Construcción de prototipos. En este enfoque de validación, se muestra un modelo
ejecutable del sistema a los usuarios finales y a los clientes. Estos pueden hacer experimentos con
este modelo para ver si cumplen sus necesidades reales.
3. Generación de casos de prueba. De forma ideal los requerimientos deben poder probarse.
Si las pruebas para éstos se consideran como parte del proceso de validación, esto a menudo
revela los problemas de los requerimientos. Si una prueba es difícil o imposible de diseñar, por lo
regular esto significa que los requerimientos serán difíciles de implementar y deberían ser
considerados nuevamente.
4. Análisis de consistencia automático. Si los requerimientos se expresan como un modelo
del sistema en una notación estructurada o formal, entonces la herramienta CASE debe verificar la
consistencia del modelo. Para verificar la consistencia, la herramienta CASE debe construir una
base de datos de requerimientos y después utilizando las reglas del método o notación verificar
todos los requerimientos en dicha base de datos. Un analizador de requerimientos produce un
informe de las inconsistencias recién descubiertas.

Como resultado, la validación de requerimiento cambios para corregir las omisiones y las malas
interpretaciones después de que el documento se ha aprobado.

Documentación de requerimientos
Existen gran variedad de estándares, pero uno de los más utilizados y conocido es el estándar
IEEE/ANSI 830-1993 (IEEE, 1993), donde se sugiere la siguiente estructura para los documentos de
requerimientos:
I. Introducción
1.1 Propósito del documento de requerimientos.
1.2 Alcance del producto
1.3 Definiciones acrónimos y abreviaturas
1.4 Referencias
1.5 Resumen del resto del documento
II. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias
III. Requerimientos específicos

Cubre los requerimientos los requerimientos funcionales, no funcionales y de interfaz.

Debido a la gran variedad en la práctica organizacional no es apropiado definir una estructura
estándar en esta sección. Los requerimientos pueden documentar las interfaces externas,
describir la funcionalidad y el desempeño del sistema, especificar los requerimientos lógicos
 de la base de datos, las restricciones del diseño, las propiedades emergentes del sistema y las
características de calidad.

IV. Apéndice
V. Índice

Casos de uso para la obtención de requerimientos

Estos son una técnica que se basa en escenarios para la obtención de requerimientos que se
introdujeron por primera vez en el método Objetory (Jacobson, 1993). Actualmente se ha
convertido en una característica fundamental de la notación UML. La descripción y todo lo
referente a casos de uso se describirán en el siguiente capítulo UML.
Se utiliza junto a los casos de uso los diagramas de secuencia que en estos casos se utiliza para
agregar información a un caso de uso. Estos diagramas muestran a los actores involucrados en la
interacción, los objetos del sistema con los que puede interactuar y las operaciones asociadas con
estos objetos.

Los diagramas de casos de uso son unos de los tipos de diagramas de UML que se utilizan
para el modelado de los aspectos dinámicos de un sistema. Nos muestran los casos de uso,
sus actores y sus relaciones.

Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso,

actores y sus relaciones.
Ejemplo