TEMA 2.

PROCESO DE ANÁLISIS PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN

COMPETENCIA ESPECÍFICA: El estudiante aplica técnicas y herramientas para el análisis de un sistema de información.

2.1. Ingeniería de requisitos

La única frase que ningún analista de sistemas querrá escuchar nunca de un cliente es: “Sé que éste es el sistema de
información que yo pedí, pero no es lo que quería”. En otras palabras, cuando se realiza la definición de requisitos, la
tarea principal de los analistas de sistemas del equipo de requisitos es trabajar con el cliente y con los futuros usuarios
del sistema de información para determinar qué requieren, lo cual tal vez no sea lo que creen necesitar.

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la
perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del
sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que
los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás
modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es más fácil de hacer,
y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en
la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

 La ingeniería de requisitos o los requisitos en sí, constituyen el enlace entre las necesidades reales de los clientes,
usuarios y otros participantes vinculados al sistema.

 La ingeniería de requisitos es un área de investigación que procura atacar un punto fundamental en el proceso,
que es la definición de lo que se quiere producir.

 Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 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. Una representación documentada de una condición o capacidad de un
sistema.

 La Ingeniería de Requerimientos en si cumple un papel primordial en el proceso de construcción y producción de

un software, es decir que, estará basado en función de las necesidades planteadas por los clientes en un nivel
muy general, donde se descubre, documenta, analiza y se define los servicios o componentes de lo que se desea
producir, además de las restricciones que tendrá el producto o software.

 Es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden comunicar las
necesidades del sistema del cliente a los desarrolladores del sistema. Trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en
computadora, de forma sistemática y repetible.

1
Los principales beneficios que se obtienen de la Ingeniería de Requisitos son:

 Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la Ingeniería de
Requisitos consiste de una serie de pasos organizados y bien definidos.

 Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La Ingeniería de Requisitos
proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como
estimación de costos, tiempo y recursos necesarios.

 Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal
desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante
la Especificación de Requisitos.

 Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requisitos
(Funcionalidad, Facilidad de Uso, Confiabilidad Desempeño, etc.).

 Mejora la comunicación entre equipos: La especificación de requisitos representa una forma de consenso entre
clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

 Evita rechazos de usuarios finales: La Ingeniería de Requisitos obliga al cliente a considerar sus requisitos
cuidadosamente y revisarlos dentro del marco del problema.

El propósito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los modelos
no solamente se verifican contra el modelo de requisitos, sino que también se desarrollan directamente de él. El modelo
de requisitos sirve también como base para el desarrollo de las instrucciones operacionales y los manuales ya que todo lo
que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo de requisitos no es un proceso
mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así clarificar
ambigüedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas
con el diseño e implementación. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar
restringir la flexibilidad de la implementación. Durante el diseño se debe extender el modelo de requisitos con
especificaciones de rendimiento y protocolos de interacción con sistemas externos, al igual que provisiones sobre
modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes
de programación particulares.

1Los tres ejes de modelado del modelo de requisitos

2
  El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidad que
ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves: actores para
representar los distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para representar
qué pueden hacer los actores con respecto al sistema.
 El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el sistema con actores
externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el
usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de
ellas.
 El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema.
Este modelo conceptualiza el sistema según los objetos que representan las entidades básicas de la aplicación.
Aunque en muchas metodologías se permite especificar la funcionalidad completa del sistema utilizando el modelo
del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un modelo de
requisitos expresado sin casos de uso, el modelo del dominio del problema será de mucha más ayuda como apoyo
al modelo de casos de uso y no como una entidad totalmente independiente.

Es importante resaltar que esta separación en tres ejes de modelado independientes es la base para una mayor estabilidad
en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

Actividades
Existen cuatro actividades básicas (extracción, análisis, especificación y validación) que se tienen que llevar a cabo para
completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene, para el desarrollo de un proyecto de
software, realizar una especificación y administración adecuada de los requisitos de los clientes o usuarios.

 Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las
actividades involucradas en el descubrimiento de los requisitos del sistema.

 Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase. Usualmente se hace un
análisis luego de haber producido un bosquejo inicial del documento de requisitos; aquí se leen los requisitos,
se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se
buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requisitos.

 Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de
detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero se podría decir que la
Especificación es el “pasar en limpio”.

 Validación: La validación es la etapa final de la IR. Su objetivo es verificar todos los requisitos que aparecen
en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del
sistema que se debe implementar.

3
 Herramientas
Existen diversas técnicas y herramientas que se utilizan para llevar a cabo cada una de las actividades del proceso de
Ingeniería de Requisitos, una de las razones por las cuales surgen los errores a la hora del levantamiento es la existencia
de una gama de herramientas. No existe una especie de guía para el uso de los desarrolladores, estos utilizan incluso en
la captura más de una técnica en cada de las actividades que contiene el proceso.

Herramientas Extracción Análisis Especificación Validación

Entrevistas y Cuestionario X

Sistemas Existentes X X

Grabaciones de video y de audio. X X

Brainstorming (Tormenta de Ideas) X X

Sistemas Existentes X X

Arqueología de Documentos X X

Aprendiz X

Observación X

Run Use Case WorkShop X

Prototipo Bosquejado X X X

Prototipo Tangible/usable X X X

FODA X

Cadena de Valor X

Modelo de clase conceptual X X

Diagrama de actividad X X

ESRE X X X X

Casos de uso X X X X

Casa de calidad o QFD X

Checklist X X

Sistemas Existentes X X

4
 Herramientas más Usadas

 Entrevistas y cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente
de personas o grupos, información que se obtiene conversando con el encuestado. Las preguntas suelen
distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados
respondan con su propia terminología, mientras que las preguntas cerradas predeterminan todas las posibles
respuestas y el interrogado elige entre las opciones presentadas.

 Grabaciones de video y de audio: Básicamente existen dos formas de utilizar las grabaciones: como registro
y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es
importante porque permite centrar la atención en la entrevista en sí, en vez de distraerse tomando notas de
todo lo que se dice. Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobre
todo las filmaciones de video) porque permite ver y analizar en detalle ese proceso la cantidad de veces que
sea necesario.

 Brainstorming (tormenta de ideas): Este es un modelo que se usa para generar ideas. La intención en su
aplicación es la de generar la máxima cantidad posible de requisitos para el sistema. No hay que detenerse
en pensar si la idea es o no del todo utilizable.

Tipos de requisitos

Un requisito determina lo que un sistema realizará, es decir, como funcionará, estos requisitos son solicitados por quien se
conoce como “cliente”. Para lograr conocerlos, es necesario realizar un análisis, el cual deberá de ser procesado
exhaustivamente hasta obtener una definición de lo que se desea realice el sistema.

Es factible definir requisito como: una condición o capacidad que necesita el usuario para resolver un problema o
conseguir un objetivo determinado, esto nos da a entender que primero debe existir una problemática o algo que se
desee y un usuario que determinará qué es lo que se necesita y el por qué lo solicita, todo esto nos define que un requisito
se deberá aplicar para satisfacer a él (los) usuario(s) y obviamente realizar de forma correcta un sistema de información.

Existen a su vez, varios tipos de requisitos que se clasifican de acuerdo a su función y/o características, entre estos
tenemos:

a) Requisitos de Usuario y del Sistema: estos permiten representar y acceder archivos externos creados por otras
herramientas, estos requisitos como su nombre lo indica mantienen una estrecha relación con el usuario y el
sistema al ser un porqué se solicita y él para que dé una solución factible.

Ejemplos de requisitos del sistema:

 El software debe ser escrito en un lenguaje compatible con el existente.

 La base de datos será Oracle 10 sobre HP-UX.

Identificar y verificar requisitos de usuario implica una relación y conocimiento entre el diseñador y los usuarios del
producto. Si en tu empresa el diseñador «sólo pone colores», tienes muchos puntos para que tu proyecto no
produzca ningún beneficio.

5
 b) Requisitos funcionales: Describen el cómo funciona el sistema y lo que este debería hacer, cómo debe
reaccionar a las entradas particulares y su comportamiento ante situaciones particulares.

c) Requisitos no funcionales: Restricciones que afectan a los servicios o funciones del sistema, tales como
restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc. Define que tan fiable es un sistema, los
tiempos de respuesta y las capacidades de almacenamiento, se puede incluir un lenguaje de programación que
se desee. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad
de uso, etc.
Estos a su vez se subdividen en requisitos del producto, organizacionales y externos.
 Del Producto: Especifican el comportamiento del producto obtenido como lo es la velocidad de ejecución,
memoria requerida, porcentajes de fallos aceptables, etc.
 Organizacionales: Políticas y procedimientos.
 Externos: Legales y éticos

Características
Los requisitos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta
hacerlo.
Necesario: Lo que pida un requisito debe ser necesario para el producto.
No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado,
aunque aun así debe referenciar los aspectos importantes.
Consistente: Ningún requisito debe entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo, el
lenguaje empleado entre los distintos requisitos debe ser consistente también.
Completo: Los requisitos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas
que los expliquen con más detalle.
Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos
disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificación puede
lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema.
Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de
algún modo, pueden sustituir o mapear con esta lista de características.