Facultad de Ciencias Económicas y de Administración

Requerimientos de Sistemas de Información

Junio 2019

El presente texto ha sido preparado por los docentes de la Unidad Académica Sistemas
para el curso de Sistemas de Información.

Está basado en el trabajo monográfico de fin de carrera:

“Evaluación desde la visión del profesional de las CCEE de las metodologías

para la determinación de requerimientos de sistemas de gestión”

Realizado por:

Leticia Chapuis, María Sofía Ugarte, Nicolás Ugarte

Facultad de Ciencias Económicas y de Administración - agosto 2010

ABSTRACT

Los requerimientos son las propiedades necesarias y suficientes que deberá tener un
software para asegurarse que la solución diseñada alcance los objetivos de los usuarios y el
negocio. En este trabajo presentamos las diferentes técnicas y metodologías para su análisis
y determinación y su relación con los conceptos de administración estratégica. El análisis
está desarrollado desde la visión del profesional de las ciencias económicas, a partir de los
diferentes roles que puede representar en el proyecto. Contrastamos los conocimientos
analizados con la realidad de 50 empresas de plaza mediante una encuesta y con las
opiniones de proveedores de este tipo de software, para finalmente
exponer nuestras conclusiones y proponer las recomendaciones.
INTRODUCCIÓN

El presente trabajo constituye un análisis de diferentes métodos y técnicas para la determinación de

requerimientos de software de gestión, desde la perspectiva del profesional de las ciencias
económicas, como cliente al adquirir software para la empresa en la que trabaja o dirige, cómo
consultor en la selección de la mejor solución para las empresas que asesora o cómo integrante de
empresas proveedoras de software. Este análisis tiene la finalidad de contribuir a mejorar el
entendimiento y utilización de estas herramientas. Para cumplir con este fin, se han analizado los
diferentes métodos desarrollados en el marco teórico, se ha realizado un trabajo de campo para
estudiar la situación de la problemática en las empresas y finalmente se han cotejado con opiniones
de proveedores de software y propuesto sugerencias para el mejoramiento del proceso de
determinación de requerimientos.

Requerimientos
Es muy frecuente escuchar entre los conocedores del desarrollo de software, que un gran número de
los proyectos de software fracasan por no realizar una adecuada definición, especificación, y
administración de los requerimientos. Dentro de esa mala administración se pueden encontrar
factores como la falta de participación del usuario, requerimientos incompletos y el mal manejo del
cambio a los requerimientos. (11)

Figura 6 – Ingeniería de Requerimientos (11)

El principal desafío consiste en la generación de especificaciones correctas que describan con
claridad, sin ambigüedades, en forma consistente y compacta, las necesidades de los usuarios
o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestión
de los requerimientos en el desarrollo de sistemas.
(http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requerimientos.php)

Definiciones:

IEEE [4] Requerimiento: 1-Una condición o capacidad necesitada por un usuario para resolver
un problema o alcanzar un objetivo.2-Una condición o capacidad que debe alcanzar o poseer un
sistema o componente de sistema para así satisfacer un contrato, estándar, especificación u otro
documento formal impuesto. Una representación documentada de una condición o capacidad
descripta en (1) y (2)

Ellen Gottesdiener [5]: Los requerimientos de software son las propiedades necesarias y
suficientes del software que aseguran que la solución alcanza lo que fue diseñada para lograr
para sus usuarios y para el negocio.

Sommerville [1,p108]: Los requerimientos para un sistema son la descripción de los servicios
proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las
necesidades de los clientes de un sistema que ayude a resolver algún problema.

Sommerville y Sawyer[ ]: los requerimientos son “...una especificación de lo que debería ser
implementado. Son descripciones de como debe comportarse el sistema, o son una propiedad
o atributo del sistema. Podrían ser restricciones en el proceso de desarrollo del sistema.”
Sommerville, I., Sawyer, P. (1997b). Requirements Engineering - A Good Practice Guide. 978-
0471974444. John Wiley.

Requerimientos de dominio: Son requerimientos que provienen del dominio de aplicación del
sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales
o no funcionales.

NIVELES DE DESCRIPCION DE LOS REQUERIMIENTOS

Requerimientos del usuario

Son declaraciones, en lenguaje natural y en diagramas, de las funciones que se espera que el
sistema proporcione y de las restricciones bajo las cuales debe funcionar.

Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y
no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento
técnico detallado. Únicamente deben especificar el comportamiento externo del sistema y deben
evitar, tanto como sea posible, las características de diseño del sistema. Si se están redactando
los requerimientos del usuario, no se debe utilizar jerga del software, notaciones estructurales o
formales, o describir los requerimientos por la descripción de la implementación del sistema.
Debe redactarse en un lenguaje sencillo, con tablas y formularios sencillos y diagramas intuitivos.

Es una buena práctica separar en el documento de requerimientos los requerimientos del usuario
de los detallados del sistema, los lectores no técnicos de los requerimientos del usuario se
pueden confundir con detalles que solo son relevantes a los lectores técnicos.

Los requerimientos del usuario que incluyen demasiada información restringen la libertad del
desarrollador del sistema para proporcionar soluciones innovadoras a los problemas del usuario
y son difíciles de comprender. Los requerimientos del usuario deben simplemente enfocarse a
los recursos principales que se deben proporcionar. Cuando sea posible, se debe intentar asociar
un fundamento a cada requerimiento del usuario. El fundamento debe explicar porque se ha
incluido el requerimiento y es particularmente útil cuando estos cambian.

Los requerimientos del sistema

Establecen con detalle las funciones, servicios y restricciones operativas del sistema. El
documento de requerimientos del sistema debe ser preciso. Debe definir exactamente qué es lo
que se va a implementar. Puede ser parte del contrato entre el comprador del sistema y los
desarrolladores del software.

Son versiones extendidas de los requerimientos de usuario que son utilizados por los ingenieros
de software como punto de partida para el diseño del sistema. Agregan detalle y explican cómo
el sistema debe proporcionar los requerimientos del usuario.

EL DOCUMENTO DE REQUERIMIENTOS DE SOFTWARE.

Es la declaración de qué deben implementar los desarrolladores del sistema. Debe incluir tanto
los requerimientos del usuario para el sistema como una especificación detallada de los
requerimientos del sistema.

El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos
cargos de la organización que pagan por el sistema, hasta los ingenieros responsables de
desarrollar el software.

La diversidad de los posibles usuarios significa que el documento de requerimientos tiene que
presentar un equilibrio entre la comunicación de los requerimientos a los clientes, la definición de
los requerimientos en el detalle exacto para los desarrolladores y probadores y la inclusión de
información sobre la posible evolución del sistema. La información sobre cambios previstos
puede ayudar a los diseñadores del sistema a evitar decisiones de diseño restrictivas y a los
encargados del mantenimiento del sistema, quienes tienen que adaptar el sistema a los nuevos
requerimientos.
EL CICLO DE VIDA DE LOS REQUERIMIENTOS DEL SISTEMA

Al describir el ciclo de vida de los requerimientos de sistema se describen las distintas fases o
etapas por las que se puede transitar para llegar a obtener un documento de requerimientos que
refleje las necesidades y objetivos de la empresa de forma eficiente y clara.

Previo al desarrollo o adquisición de un paquete, de una manera formal o informal se analiza que
tan viable o inviable es la informatización de los sistemas de información de una empresa. En
base a los requerimientos, o más bien las necesidades identificadas por la empresa se puede
elaborar una idea o descripción de lo que se pretende lograr.

Sommerville en [1] describe esta etapa desde el punto de vista formal de los ingenieros de
sistemas; en base a un conjunto de requerimientos de negocio preliminares, una descripción
resumida del sistema, y de cómo este pretende contribuir a los procesos del negocio, se elabora
un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y
el proceso de desarrollo del sistema.

Es un estudio corto y orientado a resolver varias cuestiones:

1. ¿Contribuye el sistema a los objetivos generales de la organización?

2. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las

restricciones de costo y tiempo?

3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización?

La cuestión de si el sistema contribuye o no a los objetivos del negocio es crítica, porque si no lo

hace no tiene un valor real en el negocio. El estudio de viabilidad comprende la evaluación y
recopilación de información y la redacción de informes.

En el informe se pueden proponer cambios, en el alcance, el presupuesto y la confección de

agendas del sistema y sugerir requerimientos adicionales.

Si se considera que el proyecto es viable y contribuye a los objetivos que se pretende alcanzar
comienza lo que decidimos llamar el ciclo de vida de los requerimientos:

Elicitación, Análisis, Especificación y Validación.

Ya sea que se trate del desarrollo de un enorme sistema ERP o una la adquisición de un paquete
contable para una pequeña empresa, siempre es posible identificar de estas etapas, por supuesto
con las características particulares del tipo de proyecto que se trate.

Al describir el ciclo de vida de los requerimientos los hacemos con el mayor grado de análisis
posible, dentro del cual se puedan abarcar la mayor cantidad posible de proyectos y sus
particularidades.
TÉCNICAS

Entrevistas

Las entrevistas formales o informales con los usuarios del sistema forman parte de la mayoría de
los procesos de desarrollo e implementación del software. Se trata de extraer información de
primera mano sobre los sistemas que se utilizan, los procesos de trabajo y el sistema a
desarrollar. Los requerimientos se pueden extraer de la información recopilada en estas
entrevistas.

Las entrevistas pueden ser de dos tipos:

1. Entrevistas cerradas: donde se responden un conjunto predefinido de preguntas.

2. Entrevistas abiertas: donde no hay un programa predefinido. Se examina una serie de

cuestiones para desarrollar una mejor comprensión de las necesidades de la empresa.

En la práctica lo más frecuente es una mezcla de ambas clases, las respuestas a algunas
preguntas pueden concluir en otras cuestiones que se discuten de una forma menos
estructurada. Las discusiones completamente abiertas raramente salen bien; la mayoría de las
entrevistas requieren algunas preguntas para empezar y para mantener la entrevista centrada en
el sistema.

Las entrevistas sirven para obtener una comprensión general de lo que hacen los usuarios, cómo
podrían interactuar con el sistema y las dificultades a las que se enfrentan con los sistemas
actuales. Sin embargo, no son de tanta utilidad para la comprensión de los requerimientos del
dominio de la aplicación.

Es difícil obtener conocimiento durante la entrevista, debido a dos razones:

 Los especialistas de la aplicación utilizan terminología y jerga especifica de un dominio.

Es imposible para ellos discutir requerimientos de dominio sin utilizar esta terminología.
Normalmente la utilizan de un de un modo preciso y sutil, por lo que es fácil que la
malinterpreten los ingenieros de requerimientos.

 Cierto conocimiento del dominio es tan familiar para los usuarios que o lo encuentran
difícil de explicar o piensan que es tan básico que no merece la pena mencionarlo.

Las entrevistas no son una técnica eficaz para obtener conocimiento sobre los requerimientos y
restricciones organizacionales debido a que existen sutiles poderes e influencias entre los
usuarios en la organización. Las estructuras organizacionales publicadas rara vez coinciden con
la realidad de la toma de decisiones en una organización, pero los entrevistados pueden desear
no revelar la estructura real en vez de la teórica a un desconocido. En general la mayoría de la
gente es reacia a discutir cuestiones políticas y organizacionales que puedan influir en los
requerimientos.

La información de las entrevistas complementa la obtenida por otros medios, el sistema de

documentos, observaciones de los usuarios etc. Algunas veces, aparte de la información de los
documentos, las entrevistas pueden ser la única fuente de información sobre los requerimientos
del sistema. Sin embargo, las entrevistas por si mismas, tienden a omitir información esencial por
lo que deberían ser utilizadas junto con otras técnicas de obtención de requerimientos.

Escenarios

Las personas encuentran más fácil dar ejemplos de la vida real que descripciones abstractas.
Pueden comprender y criticar un escenario de como podrían interactuar con el sistema y luego
los ingenieros utilizar esta información para formular los requerimientos reales del sistema. Los
escenarios pueden ser especialmente útiles

para agregar detalle a un esbozo de la descripción de requerimientos. En forma general un

escenario puede incluir:

1. Una descripción de lo que esperan del sistema y los usuarios cuando el escenario
comienza.

2. Una descripción del flujo normal de eventos en el escenario.

3. Una descripción de lo que puede ir mal y cómo manejarlo.

4. Información de otras actividades que se podrían llevar a cabo al mismo tiempo.

5. Una descripción del estado del sistema cuando el escenario termina.

Los escenarios se pueden redactar como texto, complementado por diagramas, fotografías de
las pantallas, etc. De forma alternativa, se puede adoptar un enfoque más estructurado como los
escenarios de evento o los casos de uso.

Observación directa

Los sistemas de software no existen de forma aislada: se utilizan en un contexto social y

organizacional, y los requerimientos de sistemas de software se pueden derivar y restringir según
este contexto. Satisfacer estos requerimientos sociales y organizacionales es crítico para el éxito
del sistema.

En particular, la etnografía, es una técnica de observación que se puede utilizar para entender
los requerimientos sociales y organizacionales. Un analista se sumerge por si solo en el entorno
laboral donde se utilizará el sistema. Observa el trabajo diario y anota las tareas reales en las
que los participantes están involucrados, El valor de la etnografía es que ayuda a los analistas a
descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales en
los que la gente esta involucrada. Las prácticas de trabajo real son mucho más ricas, más
complejas y más dinámicas que los modelos sencillos supuestos por los sistemas de
automatización de oficinas.

La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:

 1. Los requerimientos que derivan de la forma en que la gente trabaja realmente,

2. Los requerimientos que se derivan de la cooperación y conocimiento de las actividades

de la gente.

La etnografía se puede combinar con la construcción de prototipos. La etnografía suministra

información al desarrollo del prototipo de forma que se requieren menos ciclos de refinamiento.

Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas
de obtención de requerimientos a menudo olvidan. Puesto que se centran en el usuario final, este
enfoque no es apropiado para descubrir los requerimientos organizacionales o de dominio, debe
utilizarse para complementar otros enfoques, como el análisis de los casos de uso.

Reingeniería.

Si una empresa cuenta con un producto de software que le ha servido bien, que lo utiliza
regularmente, pero que se está volviendo obsoleto, mediante la reingeniería podrá crear un
producto con mejor funcionalidad, mejor desempeño, fiabilidad, así como una mejor facilidad de
funcionamiento. El proceso de la reingeniería de software incluye el análisis de inventarios,
reestructura de documentos, ingeniería inversa reestructuración de programas y datos e
ingeniería avanzada. La finalidad es crear versiones de programas existentes que muestren
mayor calidad y mayor facilidad de mantenimiento.

Reutilización

La primera vez que se habló formalmente de reutilización en el ámbito de ingeniería de software

fue en 1968, cuando se propuso la creación de fábricas de elementos de software análogas a las
ya existentes de componentes de hardware. Esta propuesta ha evolucionado, aunque todavía
queda mucho por hacer en este ámbito.

La reutilización responde al principio de aprovechar esfuerzos previos y exitosos para completar

un nuevo desarrollo. La reutilización se considera clave para mejorar la calidad y la productividad
a nivel de desarrollo de software.

Tradicionalmente se han diferenciado dos metodologías para enfocar la reutilización de software;

la primera se basa en la obtención de un nuevo sistema por composición de elementos ya
existentes y la segunda en la generación del nuevo sistema utilizando como base una estructura
o modelo.
Se puede decir que, la definición de reutilización más ampliamente aceptada corresponde a que
la define como:

"Reutilización de software es el proceso de creación de sistemas de software a partir de software

existente en lugar de construirlos a partir de cero"

Debido a la flexibilidad de la definición, utilizaremos esta y nos referiremos a la reutilización como

a la aplicación de artefactos de software ya existentes para la creación de un sistema nuevo, es
decir, la reutilización de “cualquier tipo de información ya existente que necesite el desarrollador
de sistemas para la elaboración de un nuevo sistema”

Recopilación de Documentos

Consiste en analizar toda la documentación que utiliza la empresa en sus diferentes

transacciones, con el objetivo recopilar información relativa a los procesos actuales. Como, por
ejemplo, recibos, facturas, órdenes de compra, órdenes de pago.

Anticipación de Requerimientos

La anticipación se refiere a los conocimientos previos con los que se cuenta al momento de iniciar
un proyecto. Estos permiten establecer con anterioridad algunos requerimientos sin tener ningún
tipo de conocimiento sobre la operativa del cliente. Los conocimientos pueden haber sido
adquiridos en base a la experiencia o por medio de estudios académicos. Por ejemplo: un
contador al asesorar sabe de antemano cuales son las normas contables adecuadas que deben
ser contempladas por un programa contable.

2.2.2- ANALISIS

Luego de las primeras instancias de intercambio de información entre la empresa y el proveedor

es posible realizar un análisis de esta información con el objetivo de elaborar una hoja de ruta
para encaminar los esfuerzos de construir o implementar el nuevo sistema. Se descompone la
información obtenida en la elicitación sobre las necesidades del negocio y se estructura de forma
que la misma sea precisa y completa. Es el proceso en el cual los administradores y técnicos
analizan, especifican, documentan y validan los requerimientos de un negocio durante el proceso
de cambio. Se procede a representar los requerimientos de múltiples formas, para que sean
entendidos de manera suficiente por todos los usuarios, para que el cliente pueda priorizar sus
necesidades y para que el Proveedor pueda diseñar y construir o recomendar la solución óptima.

A pesar de que las etapas del ciclo de vida de los requerimientos tienen un cierto orden, la
elicitación, análisis y especificación son procesos iterativos por lo que puede volverse sobre
alguno de ellos en cualquier momento.

La misión crítica es traducir la información de requerimientos del negocio descubierta en la

elicitación en una estructura coherente. Dado que los sistemas son invisibles por esencia, el
esfuerzo por representar la empresa en forma de diagramas estructurados del negocio permite
que la empresa sea “visualizable”. En el análisis de requerimientos se debe hacer foco en que es
lo que se debe hacer y no en cómo debe hacerse. De esta manera se generan modelos que son
independientes del software y la tecnología utilizada. Los modelos de análisis describen el
negocio sin tener en cuenta la solución que podría ser construida para satisfacer sus
necesidades. De esta forma se deja en libertad al proveedor, de encontrar soluciones sin ideas
preconcebidas.

El producto obtenido del proceso de análisis son los modelos de análisis; requerimientos del
negocio representados por una combinación de diagramas y texto estructurado en forma de
listas, tablas, o matrices. Los modelos de análisis complementan a los requerimientos
especificados en la etapa de elicitación, que son escritos en lenguaje natural.

2.2.2.1 DESAFIOS EN EL ANALISIS DE REQUERIMIENTOS

No es una tarea sencilla la de identificar a los usuarios más relevantes, darles la participación
necesaria en la definición y validación de requerimientos y documentar sus perspectivas
claramente. Los desafíos son varios en el proceso de análisis de requerimientos, pero pueden
resumirse en tres grandes categorías:

 Personas – Las personas involucradas en el proyecto deberían contar con la adecuada

experiencia, conocimientos, y habilidades para comunicar.

 Prejuicios – La idea inicial sobre cómo debería ser la solución generalmente difiere de lo
que realmente se necesita, en un comienzo las ideas son incompletas y optimistas.

 Complejidad – Existe una gran diversidad de métodos para el análisis de requerimientos.

La dificultad de utilizar estas herramientas complejas puede ser un desafío para los
gerentes y administradores.

2.2.2.2 HERRAMIENTAS DE REQUERIMIENTOS

Las herramientas de requerimientos son representaciones de algún aspecto del sistema a ser
desarrollado o adquirido, y toman múltiples formas. Las herramientas típicas son, los modelos
gráficos, modelos estructurados, tablas de datos, y descripciones o declaraciones estructuradas
o no estructuradas. Estas herramientas, una vez que han sido organizadas e integradas en un
paquete útil de información proveen detalles esenciales sobre el alcance del proyecto, los
requerimientos y las especificaciones funcionales.

Los requerimientos deben ser claros y concisos porque son usados por absolutamente todos los
involucrados en el proyecto, por lo general se usa el lenguaje natural, no técnico. Por otro lado,
los diagramas pueden expresar más claramente la estructura y las interrelaciones. Pero para
una definición precisa de conceptos el lenguaje natural articulado es superior a los diagramas.
Es por esto, que las representaciones tanto en texto como en diagrama son esenciales para
establecer los requerimientos.

De todas las herramientas de requerimientos, los modelos del tipo diagramas son por lejos los
más complejos y específicos a los requerimientos. Los modelos pueden ser usados cómo
simulaciones para relacionar varios componentes, o pueden ser utilizados aisladamente, como
herramientas para evaluar diferentes encares usando diferentes supuestos. Los modelos pueden
ser utilizados para ilustrar un proceso, para investigar un riesgo conocido, o para evaluar un
atributo de una función de negocio. Los modelos de software son construidos para probar o
demostrar su viabilidad.

En el caso de los modelos para entender los requerimientos (modelos en los cuales estamos
interesados), los diagramas son desarrollados para demostrar el entendimiento del problema de
la empresa que está evaluando desarrollar o adquirir un software, o para tratar de averiguar qué
es lo que la empresa necesita.

2.2.3 ESPECIFICACION DE REQUERIMIENTOS

Las actividades de especificación implican traducir los requerimientos a especificaciones de

requerimientos redactadas en términos entendibles para todos los usuarios. Esta tarea lleva un
tiempo y esfuerzo sustancial, porque cada usuario puede tener diferente nivel de entendimiento,
expectativas o perspectivas de los requerimientos. Las especificaciones de requerimientos son
elaboradas a partir de y ligados a los modelos de alcance y de análisis, y estructurados
lógicamente en un documento. Es a través de esta elaboración progresiva que se detectan áreas
que no han sido suficientemente definidas.

El documento de requerimientos prescribe en una forma completa, precisa, verificable, los

requerimientos, diseño, comportamiento o características de un sistema o componente de un
sistema. La especificación de lo que debe ser logrado integra todas las herramientas de
requerimientos que han sido creadas. La especificación toma el set completo de modelos de
requerimientos y los organiza en un todo cohesivo y estructurado, para que pueda ser utilizado y
entendido fácilmente por el equipo de desarrollo.

La especificación en esencia, es el proceso de organizar, refinar, y finalizar los requerimientos.

El documento de requerimientos es el resultado de esta etapa, el cual incluye o se remite a la
totalidad de herramientas que se utilizaron para extraer los requerimientos del sistema.

El valor del documento de requerimientos reside en que:

 Provee un documento que integra a todas las herramientas de requerimientos.

 Provee detalle, en forma de texto, para la información que no está en los modelos de
alcance y análisis

 Aporta consenso entre los grupos de usuarios en cuanto a lo que debe hacer el sistema.

 Sirve como un vehículo para obtener el consentimiento por parte de los equipos
administrativos y técnicos de que las necesidades del negocio han sido entendidas.

 Sirve como un puente entre los requerimientos del negocio y del sistema.
2.2.3.1 CATEGORIZACION DE REQUERIMIENTOS

Los requerimientos son categorizados dependiendo de su fuente y aplicabilidad. Entender los

tipos de requerimientos ayuda a documentarlos y priorizarlos. Al revisar la lista de tipos de
requerimientos ayuda a identificar las áreas que pueden necesitar una investigación más
profunda. En general los requisitos son divididos en funcionales y no-funcionales (o
suplementarios). Además, las limitaciones impuestas a los requerimientos o la solución son
capturadas como parte del proceso de categorización.

Requerimientos funcionales

Describen las capacidades que tendrá el sistema en términos de comportamientos u operaciones

que disparan una respuesta o acción específica del sistema. Los requerimientos funcionales se
describen mejor mediante un verbo o frase que describa una acción. Incluyen:

-Especificaciones para la funcionalidad del sistema (que es lo que el sistema o producto hace)
Por ejemplo: “El sistema deberá permitir una función cronograma que asigna a determinado
empleado a un turno en particular.”

-Acciones que el sistema deberá tomar (calcular, chequear, archivar, extraer). Por ejemplo:
“Cuando no hay staff disponible para determinado turno, el sistema deberá permitir al planificador
seleccionar a una persona de la lista de contratistas”

Los requerimientos funcionales frecuentemente están definidos por los casos de uso, que son
una forma efectiva de organizar los requerimientos funcionales. Cada caso de uso constituye una
línea de conducta iniciada por un actor, y especifica la interacción que sucede entre el actor y el
sistema. Las recopilaciones de los casos de uso especifican las diferentes formas de utilizar el
sistema.

Requerimientos no-funcionales, o suplementarios

Estipulan una característica física o de performance y sirven como limitaciones a las capacidades
del sistema. Son las propiedades o cualidades que hacen de la solución atractiva, usable, rápida
o confiable, y generalmente incluyen:

 Requerimientos de apariencia y sensación- Apariencia de la interfase de usuarios y

reportes.
 Requerimientos de usabilidad- la facilidad de uso, y cualquier consideración especial de
usabilidad.
 Requerimientos de performance- Que tan rápida, segura y precisa tiene que ser la
funcionalidad.
 Requerimientos operacionales- El entorno operativo del sistema, y que consideraciones
deben ser hechas para este entorno.
 Requerimientos de mantenimiento y portabilidad-cambios esperados y el tiempo
permitido para hacerlos.
  Requerimientos de seguridad- La seguridad y confidencialidad de la información
contenida en el sistema.
 Requerimientos culturales y políticos-Requerimientos especiales que surgen como
consecuencia de las personas que forman parte del desarrollo y operaciones.

Restricciones

Constituyen restricciones a las diferentes opciones de software.

Las limitaciones técnicas pueden incluir requerimientos de usar determinado lenguaje o base de
datos o un hardware específico. Las limitaciones técnicas también pueden especificar
restricciones del tipo tamaño y tiempo del mensaje y, tamaño del software, número y tamaño
máximo de los archivos, registros, datos, y cualquier otro Standard a los cuales se deba ajustar
el sistema.

Las limitaciones de negocio incluyen limitaciones presupuestales, restricciones referentes al

factor humano, cantidad de personas y habilidades de las mismas.

Las limitaciones técnicas y de negocios constituyen restricciones en el diseño de un sistema o el

proceso mediante el cual es desarrollado el sistema. No afectan el comportamiento externo del
sistema, pero deben ser satisfechos para alcanzar las obligaciones técnicas, de negocio, o
contractuales. Aunque las fuentes son varias, las limitaciones de diseño generalmente se
originan de tres fuentes:

1. Restricciones en las opciones de diseño (Ej.: uso de un software de gestión de bases de

datos, específico)

2. Condiciones expuestas en el proceso de desarrollo (frecuentemente basados en la

infraestructura existente y en el ambiente de negocio)

3. Regulaciones y estándares impuestos.

2.2.4 VALIDACIÓN DE REQUERIMIENTOS

La validación de requerimientos se trata de mostrar que estos realmente definen el sistema que
el cliente desea. Coincide parcialmente con el análisis ya que éste implica encontrar problemas
con los requerimientos.

Durante el proceso de validación se deben llevar a cabo las siguientes verificaciones:

 Verificaciones de validez. Un usuario puede pensar que necesita un sistema para llevar a
cabo ciertas funciones. Sin embargo, el razonamiento y el análisis pueden identificar que
se requieren funciones adicionales o diferentes. Los sistemas tienen diversos
stakeholders con diferentes necesidades, y cualquier conjunto de requerimientos es
inevitablemente un compromiso en el entorno del stakeholder.
  Verificaciones de consistencia. Los requerimientos en el documento no deben
contradecirse. Esto es, no debe haber restricciones o descripciones contradictorias de la
misma función del sistema.

 Verificaciones de completitud. El documento de requerimientos debe incluir aquellos 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 puedan implementar. Estas
verificaciones también tienen que tener en cuenta el presupuesto y la agenda para el
desarrollo del sistema.

 Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente y el contratista,

los requerimientos deben siempre redactarse de forma tal que sean verificables. Se debe
poder escribir un conjunto de pruebas que demuestren que el sistema a entregar cumple
con cada uno de los requerimientos especificados.

Pueden utilizarse en conjunto o en forma individual, varias técnicas de validación de

requerimientos:

1-Revisiones de requerimientos. Los requerimientos son analizados sistemáticamente por un

equipo de revisores.

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 experimentar con este modelo
para ver si cumple con sus necesidades reales.

3-Generación de casos de prueba. Los requerimientos deben poder probarse. Si las pruebas
para estos se conciben como parte del proceso de validación, a menudo revela los problemas en
los requerimientos. Si una prueba es difícil o imposible de diseñar, normalmente significa que los
requerimientos serán difíciles de implementar y deberían ser considerados nuevamente.
Desarrollar pruebas para los requerimientos del usuario antes de que se escriba código es una
parte fundamental de la programación extrema.

No debes subestimarse los problemas de validación de requerimientos. Es difícil demostrar que

un grupo de requerimientos cumple con las necesidades del usuario. Los usuarios deben
imaginarse el sistema en funcionamiento y cómo este encajaría en su trabajo. Para los
informáticos expertos es difícil llevar a cabo este tipo de análisis abstracto, para los usuarios del
sistema es aun más difícil. Como consecuencia, rara vez se encuentran todos los problemas con
los requerimientos durante el proceso de validación de los mismos. Es inevitable que haya
cambios adicionales de requerimientos para corregir las omisiones y las malas interpretaciones
después que el documento de requerimientos haya sido aprobado.

Revisiones de Requerimientos

Es un proceso manual que involucra a personas tanto de la organización del cliente como de la
del contratista. Ellos verifican el documento de requerimientos en cuanto a anomalías y
omisiones. Pueden ser informales o formales. Debe chequear la Verificabilidad,
Comprensibilidad, Rastreabilidad, Adaptabilidad.

Los conflictos, contradicciones, errores y omisiones en los requerimientos deben ser señalados
por los revisores y registrarse formalmente en un informe de revisión. Queda en los usuarios, la
persona que adquiere el sistema y el desarrollador de este negociar una solución para estos
problemas identificados.

MODELOS

Los modelos son representaciones de los procesos de negocios y de los sistemas, que facilita el
análisis, comprensión y mejora de los mismos. También son utilizados para representar la
información, las actividades, relaciones y limitaciones relevantes al proceso de cambio. Un
modelo puede representarse en forma de diagrama, documento estructurado, un simple listado,
o una tabla y aportan valor al análisis por los siguientes motivos:

 Permiten que el desarrollo de requerimientos sea más interesante logrando el

compromiso de todos los usuarios. Al utilizar gran variedad de modelos visuales y
textuales permiten que los involucrados comprendan los requerimientos desde diferentes
perspectivas.

 Se descubren requerimientos nuevos, erróneos y confusos. Al unir los diferentes modelos

surgen inconsistencias que permiten corregir errores a tiempo disminuyendo las
probabilidades de cambiar los requerimientos en etapas más avanzadas del proceso.

 Se adaptan a diferentes necesidades. Los requerimientos representados en textos son

apropiados cuando se necesitan definiciones precisas, mientras que las
representaciones gráficas son apropiadas cuando es necesario mostrar una secuencia
de eventos.

 Facilitan la comunicación entre el equipo técnico y los administradores ya que los

requerimientos se muestran desde diferentes perspectivas.

Dado que los negocios y las empresas son de naturaleza compleja y variada los proveedores de
software no solo deben entender cómo aplicar un amplio rango de herramientas de modelaje,
sino que también deben saber elegir como seleccionar la herramienta de modelaje adecuada.

También se deberá determinar qué tipos de modelos basados en texto (listas, tablas, matrices)
necesitan ser creados para acompañar a los modelos gráficos. Como la meta es entender los
requerimientos, no sólo crear modelos que los representen, se debe seleccionar sólo aquellos
que agregan valor al proyecto en términos de comprensión y validación de los requerimientos del
sistema.
Los diferentes aspectos de la empresa que deben ser modelados para su mejor comprensión
son:

-Datos: ¿Qué información será utilizada por el software?

-Procesos de Negocio: ¿Como las actividades del negocio serán abarcadas en el software?

-Organización: ¿Que departamentos, grupos o unidades del negocio estarán involucradas?

En algunos casos será necesario realizar modelos que representen tanto la situación presente
como futura del negocio, pero en otros casos sólo se deberá abarcar uno de estos aspectos.

EL UML Y SUS MODELOS

INTROCUCCIÓN AL UML

El UML (Lenguaje Unificado de Modelado) es una de las herramientas más utilizadas en el mundo
del desarrollo de software. Su utilidad de ve reflejada en el hecho que permite a los creadores de
sistemas generar diseños que plasmen sus ideas en una forma convencional y fácil de
comprender para otras personas.

Este lenguaje unificado fue necesario ya que en los inicios del desarrollo de software los
programadores comenzaban a escribir el programa desde el principio, y el código necesario se
escribía conforme se necesitaba. Hoy en día se debe contar con un plan bien analizado de
manera que un cliente pueda comprender de antemano que es lo que hará el equipo de
desarrolladores. La clave está en organizar el proceso de diseño de forma tal que los analistas,
clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo
comprendan y convengan con él. El UML proporciona tal organización. El UML es la notación de
diseño entendible y común para los analistas, desarrolladores y clientes.

DIAGRAMAS DEL UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar
diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales
elementos.

La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se

les conoce como modelo. El modelo UML describe lo que supuestamente hará un sistema, pero
no dice cómo implementar dicho sistema.

UML 2.0 define trece tipos de diagramas divididos en tres categorías:

 Los diagramas de estructura, que enfatizan en los elementos que deben existir en el
sistema modelado:

1. Diagrama de clases
 2. Diagrama de componentes

3. Diagrama de objetos

4. Diagrama de estructura compuesta

5. Diagrama de despliegue

6. Diagrama de paquetes

Referencia: www.uml.org

CASOS DE USO

Historia

Durante mucho tiempo, tanto en el desarrollo orientado a objetos como en el tradicional, las
personas se auxiliaban de escenarios típicos que les ayudaban a comprender los requerimientos.
Estos escenarios, sin embargo, se trataban de modo muy informal; siempre se construían, pero
pocas veces se documentaban. Ivar Jacobson (uno de los creadores del lenguaje UML) cambió
esto con su método Objetory, elevando la visión del caso de uso a tal punto que lo convirtió en
un elemento primario de la planificación y desarrollo de proyectos.

Definición

En esencia los casos de uso son una interacción típica entre un usuario y un sistema de cómputo.
Los casos de uso son una técnica que se basa en escenarios para la obtención de
requerimientos. Actualmente se ha convertido en una característica fundamental de la notación
UML. Los casos de uso describen el comportamiento del sistema desde la perspectiva del
usuario. Es la especificación de una secuencia de acciones que un sistema puede efectuar que
a su vez muestra las interacciones con los distintos actores involucrados en el sistema.

(UML 2.0) Los casos de uso describen los requerimientos de sistema y especifican con precisión
el valor que el sistema le está entregando al usuario. Como los casos de uso son los
requerimientos funcionales del sistema en si, deben ser la primera visión que debe mostrar un
modelo antes de comenzar con el proyecto.

La ventaja de presentar los requerimientos como casos de uso es que los usuarios pueden ver
por anticipado si esos requerimientos agregan o no valor al sistema promoviendo que puedan
ser descartados de antemano significando tanto un ahorro de dinero como de tiempo.
Diagramas de casos de uso

Los diagramas de casos de uso son representaciones gráficas de los mismos que nos permiten
mostrar los casos de uso a los usuarios para que ellos nos puedan dar más información. A su
vez nos permite relacionar los casos de uso con otro tipo de diagramas.

Para poder representar los casos de uso en formas de diagramas debemos comenzar por definir
a los actores. Se utiliza el término actor para llamar así al usuario, cuando desempeña ese papel
con respecto al sistema. Los actores llevan a cabo casos de uso. Un mismo actor puede realizar
muchos casos de uso, a la inversa, un caso de uso puede ser realizado por varios actores. No es
necesario que los actores sean seres humanos, a pesar que estén representados por figuras
humanas en el diagrama. El actor puede ser también un sistema externo que necesite cierta
información del sistema actual. También debemos definir lo que son la inclusión (uses) y la
extensión (extends). Además de los vínculos entre los actores y los casos de uso, hay otros dos
tipos de vínculos que se dan entre los casos de uso. Se usa la relación “extiende” cuando se tiene
un caso de uso similar a otro pero que hace aún un poco más. Las relaciones “uses” ocurren
cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no
se quiere copiar la descripción de tal conducta. Ambas relaciones implican la factorización de
comportamientos comunes de varios casos de uso, dejando sólo uno que es el empleado, o
extendido por otros varios casos de uso. En sus vínculos con los actores, sin embargo, implican
cosas diferentes.

Los casos de uso pueden verse desde el punto de vista formal o informal. Los informales son
aquellos que surgen de los primeros esfuerzos del proceso de modelado de requerimientos. En
estos los pasos son descriptos de forma breve ofreciendo información escasa que únicamente
servirá para tener una idea del proceso y nada más.
Los casos de uso formalizados brindan información mucho más detallada y son la base del
proyecto.

A continuación, se presenta un ejemplo de estos representados en forma de plantillas.

Ejemplo de caso de uso informal aplicado a la inscripción de un alumno a un seminario.

Nombre: Inscripción a un seminario

Identificador: CU 17

Procedimiento:

 El estudiante ingresa su usuario y su contraseña

 Es sistema chequea que el estudiante cuente con la habilitación para inscribirse.
Si esto no se cumple el estudiante es informado y el caso de uso finaliza.
 El sistema muestra una lista con los seminarios disponibles.
 El estudiante opta por un seminario.
 El sistema valida que el estudiante está habilitado para dicho seminario.
Si esto no sucede se consulta al estudiante para inscribirse a otro.
 El sistema valida que el seminario encaja en el calendario del alumno.
 El sistema calcula y muestra las tarifas.
 El estudiante verifica el costo e indica si quiere inscribirse o no.
 El sistema inscribe al estudiante en el seminario y carga el costo al estudiante.

 El sistema emite un comprobante de inscripción. .

En una notación mas formal, los casos de uso se especifican con los siguientes elementos:
Diagrama de casos de uso

El diagrama contiene el “Actor” que es quien interactúa con el Sistema, puede ser un usuario, un
equipo u otro Sistema.

Rectángulo que establece los límites del diagrama

Dentro de cada rectangulo están los casos de uso propiamente dichos representados con óvalos.
Cada caso de uso tiene un código que lo identifica y un nombre.
Plantilla para especificación de un caso de uso:

La plantilla indica cómo se debe especificar un caso de uso. Esta compuesta por:

 Autor
o Persona o grupo que especifico el caso de uso

 Precondiciones
o Indica que es necesario hacer para poder realizar el caso de usop. Por ejemplo,
Para retirar dinero de un cajero es necesario tener una tarjeta y conocer el pin.

 Flujo normal
o Detalla los pasos a realizar de forma clara y precisa.

 Flujo alternativo
o Detalla los pasos que se realizan en caso de producirse alguna situación poco
frecuente o anormal.
 o Por ejemplo, en el caso del cajero, lo que se hace en caso de querer retirar dinero y
el cajero no tiene. Son situaciones que pueden ocurrir pero que no son frecuentes o
no se desa que ocurran.

 Poscondiciones,
o Indica en qué estado queda el sistema, que datos se modifican luego de realizar el
caso de uso. En el ejemplo del cajero se indicaría que se actualiza la cuenta del
cliente restando el monto del dinero retirado.

Ejemplos:
Dar de alta un cliente