REQUERIMIENTOS DE LOS SISTEMAS DE INFORMACION

-
 DESARROLLO
DEFINICIÓN DE REQUERIMIENTO
En términos de ingeniería del software y el desarrollo de sistemas, un requerimiento es una
necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio.

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o
cualidades que necesita cumplir un sistema o un sistema de software para que tenga valor y utilidad
para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son
necesarias para un proyecto.

También se puede definir como "conjunto de actividades en las cuales, utilizando técnicas y
herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces
más de una)."

Las etapas de fase de los requerimientos son:

 Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los
grupos de interés (usuarios, clientes, proveedores, gobierno, etc.).
 Análisis: comprobación de la consistencia y completitud de los requerimientos. Aquí se leen
los requerimientos, 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 requerimientos.
 Verificación: constatación de que los requerimientos especificados sean correctos. Se
documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.

La clasificación de los requerimientos son las siguientes:

 Requerimientos funcionales: qué debe hacer el sistema o software.
 Requerimientos no funcionales: cómo debe funcionar el sistema o software (esto no debe
ser su implementación), por ej. calidad, rendimiento, facilidad de uso, etc.
 Requerimientos externos: a qué se debe atener el sistema o software con respecto a su
entorno: compatibilidad con otros sistemas, adecuación a determinadas leyes, etc.

REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales, son aquellos que describen cualquier actividad que este deba
realizar, en otras palabras, el comportamiento o función particular de un sistema o software cuando
se cumplen ciertas condiciones.

Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas, descripciones
de los flujos de trabajo a ser desempeñados por el sistema y otros requerimientos de negocio,
cumplimiento, seguridad u otra índole.

Los requerimientos funcionales deben redactarse de tal forma que el lector pueda entender el
funcionamiento del sistema sin tener conocimientos técnicos particulares de su funcionamiento.

Lo importante es definir una forma estándar para expresar los requerimientos y ser consistente con
la misma en todos los documentos.

Ejemplo: requerimiento de una área de seguridad de una empresa

-El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados. Los usuarios deben
ingresar al sistema con un nombre de usuario y contraseña.
-El sistema enviará una alerta al administrador del sistema cuando ocurra alguno de los siguientes
eventos: Registro de nueva cuenta, ingreso al sistema por parte del cliente, 2 o más intentos fallidos
en el ingreso de la contraseña de usuario y cambio de contraseña de usuario.
-Los integrantes del grupo de usuarios de analistas pueden ingresar solicitudes pero no pueden
aprobarlas o borrarlas.
-Los integrantes del grupo de usuarios de gerentes pueden ingresar y aprobar solicitudes, pero no
pueden borrarlas.
-Los integrantes del grupo de usuario de administradores no pueden ingresar o aprobar solicitudes,
pero si pueden borrarlas.
-Cualquier intercambio de datos vía internet que realice el software se realizará por medio del
protocolo encriptado https

REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales representan características generales y restricciones de la

aplicación o sistema que se esté desarrollando.

Estos requerimientos no funcionales suelen presentar dificultades en su definición dado que su

conformidad o no conformidad podría ser sujeto de libre interpretación, por lo cual es recomendable
acompañar su definición con criterios de aceptación que se puedan medir.
Ejemplos:
Comprobabilidad: Grado en que un sistema, software o servicio de TI permite y facilita que sea
probado en un determinado contexto.

Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado en un período
determinado. También puede definirse el grado en que un sistema está en un estado operable
definido cada vez que se necesite.

Extensibilidad: Grado en que la implementación del sistema toma en consideración y facilita su

crecimiento en el futuro.

Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una creciente carga de trabajo,

por ejemplo mayor número de conexiones o usuarios. No debe confundirse con extensibilidad, que
mide la capacidad del sistema de crecer en funcionalidades.

Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al producto (en este caso al
software o servicio de TI), con la finalidad de: Desarrollar nuevos requerimientos, Aislar los defectos
y sus causas, corregir estos defectos y atender las demandas del entorno cambiante.

Seguridad: Grado de protección de los datos, software y plataforma de tecnología de posibles

pérdidas, actividades no permitidas o uso para propósitos no establecidos previamente.

Usabilidad: Definido como la facilidad de uso y aprendizaje de un Sistema, Software o Servicio de

Tecnología de Información.

VALIDACIÓN DE REQUERIMIENTOS
Es importante tener que asegurar la validez de los requisitos previamente antes de empezar un
desarrollo de software. Para ello se debe de hacer una comprobación de la correspondencia entre
las descripciones iniciales y si el modelo es capaz de responder al planteamiento inicial. Para llevar
esto a cabo, se suele realizar una comprobación en que el modelo obtenido responda de la misma
forma deseada que la que el cliente pide por un lado, y por otro la inversa si otras respuestas del
modelo hacen convencer al cliente. En algunos casos es necesario construir prototipos con una
funcionalidad muy similar reducida para que el cliente se tenga una idea aproximada del resultado
que se va a obtener.
La validación de los requisitos, tiene como objetivo comprobar que estos sean correctos. En esta
fase se debe realizarse o de lo contrario se corre el riesgo de que se implementa una mala
especificación, ya que el costo que eso conlleva. Los parámetros a validar en los requisitos son:
 Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener
puntos de vista distintos y necesitar otros requisitos.
 Consistencia: No debe de haber contradicciones entre requisitos y otros.
 Completitud: Esta deben estar en todos los requisitos. Esto es imposible en un desarrollo
iterativo, pero, al menos, deben estar disponibles todos los requisitos de la iteración que
estén en curso.
 Realismo: Se pueden implementar usando la tecnología actual.
 Verificabilidad: En esta tiene que existir alguna forma en que se debe comprobar que cada
requisito se cumple.

TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN

1. OBSERVACION DIRECTA:
Es un instrumento de recolección de información muy importante y consiste en el registro
sistemático, válido y confiable de comportamientos o conducta manifiesta.
Esta puede utilizarse como instrumento de medición en muy diversas circunstancias” según
la definición de (Sampieri, 1997; 259-261).Puede servir para determinar la aceptación de un
grupo respecto a su profesor, analizar conflictos dentro del aula, relaciones entre pares, etc.
Existen dos tipos de observación; participante o no participante. En la primera, el observador
interactúa con los sujetos observados y en la segunda no ocurre esta interacción.

2. ENCUESTA:
La entrevista, es una forma específica de interacción social. El investigador se sitúa frente al
investigado y le formula preguntas, a partir de cuyas respuestas surgen los datos de interés.
En que se establece un diálogo, pero un diálogo peculiar, asimétrico, donde una de las partes
busca recoger informaciones y la otra se nos presenta como fuente de estas informaciones.
Otra definición es un dialogo en el que la persona (entrevistador), generalmente un periodista
hace una serie de preguntas a otra persona (entrevistado), con el fin de conocer mejor sus
ideas, sus sentimientos su forma de actuar.
Una encuesta es un conjunto de preguntas normalizadas dirigidas a una muestra
representativa de la población o instituciones, con el fin de conocer estados de opinión o
hechos específicos.

3. LLUVIA DE IDEAS:
Es un proceso didáctico y práctico mediante el cual se intenta generar una creatividad mental
respecto de un tema. Tal como lo dice su nombre, supone el pensar rápida y de manera
espontánea las ideas, conceptos o palabras que se puedan relacionar con un tema
previamente definido y que, entonces, puedan servir a diferentes fines. El proceso de lluvia
de ideas es muy utilizado hoy en día en espacios tales como reuniones laborales, en clases,
en debates, etc.

La noción de lluvia de ideas parte del hecho de ampliar la participación o democratizarla a

 todos los presentes en el espacio en el cual la reunión o el evento se llevan a cabo. Es así
porque se considera que muchas mentes, con sus particularidades, contribuyen mejor a la
generación de ideas y de posibles proyectos, que una sola. La lluvia de ideas entonces
comienza con la definición de un tema o quizás también con el establecimiento de un
problema o conflicto a resolver. Luego se invita a que los miembros o los presenten
propongan ideas, conceptos, posibles soluciones, formas de actuar, respecto de ese tema o
conflicto planteado. Es por esto mucho menos estructurado y rígido que otras técnicas de
planeamiento conocidas.

4. APRENDIZ
Esta herramienta se basa en la idea del maestro y el aprendiz, y es una buena forma de
observar el trabajo real. Aquí, el aprendiz es representado por el analista de sistemas, y el
usuario/cliente cumple el rol de maestro.
El aprendiz se sienta con el maestro a aprender por medio de la observación, haciendo
preguntas como ¿por qué hizo eso? y ¿qué significa eso?, y también realizando algún trabajo
bajo la supervisión del maestro.
A medida que el trabajo es observado y explicado, el analista de sistemas puede realizar
bosquejos para cada una de las tareas realizadas, y también puede bosquejar como se
conectan por medio de los distintos flujos de datos.
La aplicación de esta herramienta es muy útil, ya que a veces es difícil para el cliente/usuario
el explicar cómo realiza su trabajo. Es también una técnica apropiada para un proyecto
donde el problema no es estructurado, ya que es una de las mejores formas de obtener el
conocimiento que se encuentra en la "cabeza" del cliente.
Una de las posibles objeciones que se le pueden hacer a esta herramienta es que su
implementación requiere de mucho tiempo.

5. PROTOTIPOS
Son una visión preliminar del sistema futuro en que se va a implantar. Para la elaboración de
prototipos de un sistema de información hay que decir que es una técnica valiosa para la
recopilación rápida de información en que se especificara a cerca de los requerimientos de
información de los usuarios.
Los prototipos para que sean efectivos deben hacerse tempranamente el ciclo de vida del
desarrollo de sistemas, durante la fase de determinación de los requerimientos.
De esta forma el analista estará buscando las reacciones iniciales de los usuarios y de la
administración hacia el prototipo, las sugerencias de los usuarios sobre cambios o limpieza
del sistema para que se construya un prototipo, las posibles innovaciones y los planes de
revisión en que se detallan que parte del sistema se necesita realizarse primero.

6. REVISION DE DOCUMENTOS
La revisión de documentos debe permitir a los investigadores obtener otros datos
relacionados en que asunto se van a estudiar. Así, por ejemplo, es vital que una empresa
revise encuestas anteriores sobre tendencias de consumo de sus clientes. Esto les va a
permitir contrastar la nueva información con otros datos que se han obtenido en estudios
pasados. Siempre debe ser importante conocer los antecedentes del hecho para determinar
cómo ha evolucionado esto a través del tiempo. O también, para identificar en qué manera se
ha cambiado el comportamiento o la actitud de las personas con relación a un tema
específico. Entre los documentos que se pueden consultar pueden ser los reportes, libros
especializados, estados financieros, informes, registros, fichas de observación y formularios
de captura de datos. También es probable que se puedan usar memorandos, consultas,
manuales de procedimiento y políticas empresariales.
 EJERCICIOS/ACTIVIDADES
-Desarrollar ésta actividad en grupos de 3. Mandar al correo mhzakzuk@gmail.com hasta el
viernes 29 de mayo a las 18:00Hrs.

Williwonk’s Chocolates de St. Louis fabrica varios tipos de dulces y novedades de chocolate. La
empresa tiene seis tiendas en la ciudad: cinco en los principales aeropuertos metropolitanos y una
pequeña sucursal de pedidos por correo. Williwonk’s tiene un pequeño sistema de información
computarizado que rastrea el inventario en su planta, ayuda a programar la producción y algunas
otras cosas más, pero este sistema no está enlazado directamente con ninguna de sus tiendas de
menudeo. El sistema de pedidos por correo se administra en forma manual. Hace poco, varias
tiendas de Williwonk’s experimentaron una erupción de quejas de los clientes de pedidos por
correo, debido a que los dulces llegaban echados a perder, que no llegaban cuando se les prometía
o que nunca llegaban; la empresa también recibió varias cartas en las que se quejaban de que los
dulces en varios aeropuertos sabían rancios. Williwonk’s ha estado vendiendo una nueva forma
dietética de chocolate bajo en calorías, formulada con un edulcorante artificial. Las ventas han sido
activas, pero han surgido problemas por enviar el tipo incorrecto de chocolate a la dirección en la
que vive una persona diabética. Hubo varias quejas, por lo que Williwonk’s envió varias cajas gratis
de chocolate como desagravio. A la gerencia le gustaría vender productos a través de Web, pero
cuentan con sólo algunas páginas Web con información sobre la compañía y un formulario de
pedidos que se puede imprimir. No existen los pedidos a través de Web. A uno de los ejecutivos
principales le gustaría vender chocolates personalizados con el nombre de una persona en cada
pieza. Aunque el área de producción aseguró a la gerencia que esto se podría hacer fácilmente, no
hay un método para pedir tales chocolates personalizados. Otro de los ejecutivos principales
mencionó que Williwonk’s se asoció con varios fabricantes de chocolate europeos y que importará
chocolate de varios países. En la actualidad hay que hacer esto a través del teléfono, por correo
electrónico o por correo convencional. El ejecutivo desea un sitio Web interno que permita a los
empleados realizar pedidos directamente a las empresas asociadas. Todo esto ha provocado que
varios gerentes soliciten un análisis de tendencias. Cuando hay inventario en exceso algunos
chocolates se arrancian, mientras que otras veces hay escasez de ciertos tipos de chocolate. Las
tendencias de variación por temporadas y días festivos podrían ayudar a Williwonk’s a mantener un
inventario adecuado. El gerente de control de inventario insiste en que es necesario implementar
todos los cambios antes de la siguiente temporada festiva. “Hay que tener una fecha absoluta
definida para que todo esté terminado”, recalcó Candy, una de los gerentes de nivel superior.
“Debemos asegurarnos de que todo esté trabajando perfectamente antes de que el sitio se haga
público”, continuó. “¡No quiero clientes que reciban los chocolates incorrectos!”. Además, el gerente
de procesamiento de pedidos mencionó que el sistema debe ser seguro. Usted llevaba trabajando
dos semanas con Williwonk’s en varias modificaciones para su sistema de información de inventario
cuando escuchó a dos gerentes discutir sobre estas cuestiones.

1. Determine los requerimientos funcionales y no funcionales para este sistema.

2. Elabore una entrevista con mínimo 9 preguntas que les permitan a ustedes determinar
nuevos requerimientos del sistema, ¿Qué personas escogería usted para hacerle la entrevista?,
¿Es válida la misma entrevista para todas ellas?
3. En el grupo de trabajo generen una Lluvia de Ideas para determinar nuevos requerimientos
para el sistema. Clasifiquen estos nuevos requerimientos en funcionales y no funcionales.
(Obviamente debe mostrarse constancia de la Lluvia de Ideas, indicando qué ideas se aceptaron y
qué ideas desecharon y por qué).
5. Hagan estudio de sistemas existentes que sean parecido al que requiere Williwonk’s .
Describan las características, Ventajas y desventajas de cada uno. Qué tomarían de estos sistemas
para el sistema requerido. (Analice por lo menos 3).

BIBLIOGRAFIA

http://www.alegsa.com.ar/Dic/requerimientos.php
http://www.pmoinformatica.com/2017/02/requerimientos-funcionales-ejemplos.html
http://www.pmoinformatica.com/2015/05/requerimientos-no-funcionales-ejemplos.html
https://cjimenez13requerimientos.files.wordpress.com/2014/09/validacion-de-
requerimientos.pdf
http://www.ub.edu/ice/recerca/fitxes/fitxa3-cast.htm
https://instrumentos-investigacion.wikispaces.com/3.+Encuestas
https://www.definicionabc.com/comunicacion/lluvia-de-ideas.php
https://es.slideshare.net/myjuankiz1/desarrollo-de-prototipos-5662958
https://es.slideshare.net/VERDECALI2006/recoleccion-de-datos-1833269