Está en la página 1de 51

REQUERIMIENTOS

Es un tema de la Ingeniería de Sistemas, en la definición de


requerimiento tiene diferentes significados.
• Desde el Proceso de Información,
• Proceso de Bases de Datos y
• el Proceso de Transmisión de Datos,

con el fin de colocar los resultados donde el Usuario los necesite,


teniendo en cuenta que los datos deben ser procesados en forma
confiable, segura y oportuna con el fin de dar confidencialidad,
integridad y disponibilidad
De acuerdo con lo anterior las definiciones que existen para
requerimiento, se presenta como aparece en el glosario de la IEEE.
(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), por el Sistema
Una colección de requisitos describe las características o atributos del
sistema deseado.
Se omite el cómo debe lograrse su implementación, ya que esto debe
ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el
énfasis está puesto en el propio software.
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.

Los requerimientos funcionales: definen las funciones que el sistema


será capaz de realizar.
Describen las transformaciones que el sistema realiza sobre las
entradas para producir salidas.
La mayoría de los requerimientos funcionales proviene directamente
de un requisito del usuario, es decir de una descripción en lenguaje
natural que el usuario ha hecho llegar a los desarrolladores a través
de las entrevistas mantenidas durante la obtención de requisitos.
Así si tomamos como ejemplo un pequeño negocio de venta y alquiler
de herramientas, algunos requisitos funcionales son:
1.- Imprimir los Contratos de Alquiler
2.- Almacenar la Información Relativa a los contratos de alquiler de
vigor.
3.- Guardar información de ventas y pagos.
4.- Realizar un seguimiento por cliente, del estado de los pagos.
5.- Gestionar el inventario de productos en venta y en alquiler
Durante la determinación de los requisitos funcionales deben tenerse
muy en cuenta los riesgos derivados de una imprecisa especificación.
Es necesario que los desarrolladores se familiaricen con el sistema y
comienzan a analizar los requisitos más obvios para ir descubriendo
aquellos menos evidentes, los desarrolladores y usuarios pueden
interpretar un mismo requisito de manera distinta.
Los requerimientos no funcionales:

tienen que ver con características que de una u otra forma puedan
limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad,
estándares, la disponibilidad, el testeo, el mantenimiento, la facilidad
de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma
indirecta al producto.
Estas pueden ir desde la compatibilidad con cierto Sistema Operativo
hasta la adecuación a leyes o regulaciones aplicables al producto

Este tiene que ver con restricciones y exigencias de calidad del


sistema, entre los que se encuentran los requisitos de rendimiento, de
interfaces externas como, por ejemplo:
.- Tiempos de respuesta
.- Facilidad de mantenimiento
.- Seguridad, fiabilidad y eficiencia.
.- Capacidad de almacenamiento
Los requerimientos no funcionales son difíciles de validar y a menudo
su validación se lleva a cabo de manera subjetiva como validar
por ejemplo si un sistema de banca online realiza una transferencia
entre cuentas en un tiempo razonable para el usuario, como
cuantificar si el sistema es amigable.
• Requisito del producto:

Aquellos que detallan limitaciones o comportamientos exigidos al


producto resultante.
Por ejemplo, la cantidad de memoria requerida o la velocidad de
respuesta en operaciones interactivas.
• Requisitos de la Organización:

Aquellos relacionados con las normativas de funcionamiento de la


Organización que lleva a cabo el desarrollo, sus procedimientos y
políticas
Por ejemplo los estándares de desarrollo, la documentación o
entregar con el producto, los plazos de entrega.
• Requisitos externos:

Cubren aspectos externos al sistema y a su proceso de desarrollo.


Por ejemplo, interoperabilidad con otros sistemas, requisitos legales
etc.
CARATERISTICAS DE LOS REQUERIMIENTOS PARA CREARLOS
Y FORMULARLOS

Ya que visualizamos la importancia de los requerimientos en un


sistema de información, debemos definir qué características deben
poseer los requerimientos para formularlos adecuadamente.
Los requerimientos deben ser:
• Posibles de probar o verificar: Si un requerimiento no se puede
comprobar, entonces ¿cómo sabemos si cumplimos con él o no?
• Especificados por escrito: Como todo contrato debe ser realizado de
acuerdo entre las dos partes.
• Deben tener como fundamento las necesidades de los usuarios
actuales o potenciales del sistema de información.
• Descritos como una característica del sistema a entregar. Esto es:
Que es lo que el sistema debe de hacer (y no como debe de hacerlo)
• Lo más claro y conciso posible. Para evitar malas interpretaciones.
CARACTERÍSTICAS DE LOS REQUERIMIENTOS DE ACUERDO A
SUS PROPIEDADES

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.
• Necesarios:
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.

• Concisos:
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.
• Completos:
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.

• Consistentes:
Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
• No ambiguos:
Un requerimiento no es ambiguo cuando tiene una sola interpretación.
El lenguaje usado en su definición, no debe causar confusiones al
lector.

• Verificables:
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.
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.
ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS DEL
SISTEMA DE INFORMACIÓN

En este es el primer paso que se debe adelantar en este proceso, es


la búsqueda de las necesidades de los usuarios, proceso que se
denomina análisis de requerimientos.
Los requerimientos son las necesidades de los usuarios.
Los requerimientos son la Pieza fundamental en un proyecto de
desarrollo de software, ellos son la guía para:

Construir software de alta calidad, en tiempo y presupuesto


estimados.
Planear el proyecto y los recursos que se usarán en él. Los líderes del
proyecto usan los requerimientos como una base para la estimación
del esfuerzo necesario en un proyecto.

Especificar el tipo de verificaciones que se habrán de realizar al


sistema. Por ejemplo: cuando se está tratando de alinearse a cierta
norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el
sistema. Los requerimientos son la base sobre la cual se decide si un
caso de prueba fue ejecutado exitosamente por el sistema o no.

Son el fundamento del ciclo de vida del proyecto. Los requerimientos


documentados son la base para crear la documentación del sistema
De ahí su importancia de que se deban definir y manejar de la forma
más adecuada posible.
COMO REALIZAR EL ANÁLISIS DE REQUERIMIENTOS.

Los requerimientos de un sistema de software, cuando se ven en su


conjunto son extensos y detallados, y además contienen múltiples
relaciones entre sí.

Obtenemos la posibilidad de especificar sistemas complejos al


documentar especificaciones simples y concisas para el sistema.
Esto se logra mediante la clasificación, estructuración y organización
de todo lo que el sistema debe de hacer.
En otras palabras, el análisis de requerimientos consiste brevemente
en lo siguiente:
1. Obtener información por diferentes medios de lo que los
usuarios desean y dejar escritas esas necesidades.
2. Clasificar esas necesidades para poder estructurar los
requerimientos o necesidades del sistema.
3. Identificar los niveles de jerarquía del sistema y empezar a
alojar los requerimientos en el nivel que les corresponda.
4. Especificar los requerimientos de acuerdo al nivel de audiencia
que se requiera
5. Especificar completamente cada necesidad, sin ahorrar tiempo y
espacio en su descripción.
6. Entender correctamente las necesidades y cuando afecten dos
o más usuarios, para llegar a acuerdos entre las partes.
7. Manejar las expectativas y estar dispuesto a realizar cambios.
8. Involucrar a todos los que tengan inherencia en el proyecto
(Jefes, subalternos, usuarios en general)
9. Se debe mantener una perfecta comunicación entre todos
quienes participan en el proceso de levantamiento de los
requerimientos
COMO OBTENER INFORMACIÓN

Los requerimientos son el punto de acuerdo entre el usuario y el


proyecto de desarrollo de software, este entendimiento es necesario
para poder construir software que satisfaga las necesidades de los
usuarios.

Si los requerimientos se enfocan a describir las necesidades del


usuario, entonces es lógico que para recabarlos haya que obtener la
información de primera mano.
Esto es, mediante entrevistas con el usuario o recabando
documentación que describa la manera que el usuario desea que
funcione el sistema de software.
Las necesidades y/o requerimientos del usuario evolucionan con el
tiempo y cada cambio involucra un costo.
Por eso es necesario tener archivada una copia de la documentación
original del usuario, así como cada revisión o cambio que se haga a
esta documentación.
Para poder establecer o estimar el costo de un proyecto es necesario
contar con los requerimientos iniciales en su mejor nivel de detalle
Como cada necesidad del sistema de información es tratada de
diferente forma, es necesario clasificar estas necesidades para saber
cuáles de ellas serán satisfechas por el software que se quiere
desarrollar y cuales por algún otro producto del sistema.
TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE
REQUERIMIENTOS

1. Un problema puede surgir de la diferencia entre las cosas como se


realizaron y como se desean.
Por eso es necesario tener en cuenta que en el proceso de
levantamiento o búsqueda de requerimientos se pueden presentar
problemas que es necesario solucionar.
2. Para solucionar el problema se deben tener en cuenta:
a) Generar acuerdo entre las partes involucradas
b) Construir un vocabulario común
c) Identificar los involucrados
d) Definir los límites del sistema
e) Identificar restricciones
f) Dejar todo claro y definido en un documento.
3. Manejar diferentes técnicas de levantamiento
a) Entrevistas
b) Encuestas
c) Talleres de requerimientos
d) Lluvia de ideas
e) Prototipos
f) Escenarios
4. Mecanismos de fácil comunicación
Durante el proceso se debe facilitar la comunicación entre todos los
participantes, de tal forma que todos los usuarios puedan participar
aportando sus puntos de vista y sus necesidades.
5. Se debe realizar una especificación formal de todos los
acuerdos con las diferentes personas, para que quede constancia
expresa de que se tuvieron en cuenta los puntos de vista de los
diferentes usuarios.
6. Administrar los cambios. Se debe estar presto a realizar las
modificaciones que se presenten durante el proceso de análisis de
requerimientos. Después puede ocasionar costos o demoras en el
proceso de desarrollo.
CLASIFICACIÓN DE LOS REQUERIMIENTOS

El clasificar requerimientos es una forma de organizarlos, hay


requerimientos que por sus características no pueden ser tratados
iguales. Por ejemplo, los requerimientos de entrenamiento de
personal no son tratados de la misma manera que los requerimientos
de una conexión a Internet.
La siguiente es una recomendación de cómo pueden ser clasificados
los requerimientos, aunque cada proyecto de software pueda usar sus
propias clasificaciones.
• Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos
cambiar el entorno, existen cierto tipo de requerimientos que se
clasifican en esta categoría porque:
El sistema usa el entorno y lo necesita como una fuente de los
servicios necesarios para que funcione. Ejemplos del entorno
podemos mencionar: sistemas operativos, sistema de archivos, bases
de datos.

El sistema debe de ser robusto y tolerar los errores que puedan


ocurrir en el entorno, tales como congestión en los dispositivos y
errores de entrada de datos, por lo tanto el entorno se debe de
considerar dentro de los requerimientos.
• Requerimientos "ergonómicos"
El más conocido de los requerimientos ergonómicos es la interface
con el usuario o GUI (Graphic User Interface). En otras palabras, los
requerimientos ergonómicos son la forma en que el ser humano
interactúa con el ser sistema.
• Requerimientos de Interface
La interface es como interactúa el sistema con el ser humano o con
otros sistemas (el enfoque es prácticamente el opuesto a los
requerimientos ergonómicos), La interface es la especificación formal
de los datos que el sistema recibe o manda al exterior. Usualmente se
especifica el protocolo, el tipo de información, el medio para
comunicarse y el formato de los datos que se van a comunicar.
• Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es
importante que se describa el ¿Qué? Y no el ¿Cómo? Estos
requerimientos al tiempo que avanza el proyecto de software se
convierten en los algoritmos, la lógica y gran parte del código del
sistema.
• Requerimientos de desempeño
Estos requerimientos nos informan las características de desempeño
que deben de tener el sistema. ¿Qué tan rápido?, ¿Que tan seguido?,
¿Cuantos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los
sistemas de tiempo real en donde el desempeño de un sistema es tan
crítico como su funcionamiento.
• Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradación,
potabilidad, flexibilidad, contabilidad y capacidad de actualización.
Este tipo de requerimientos es también muy importante en sistemas
de tiempo real puesto que estos sistemas manejan aplicaciones
críticas que no deben de estar fuera de servicio por periodos
prolongados de tiempo.
• Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el
sistema. ¿Qué tipo de usuarios son?, ¿Qué tipo de operadores?,
¿Que manuales se entregarán y en qué idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un
pedazo de código dentro del sistema, son muy importantes en el
proceso de diseño ya que facilitan la introducción y aceptación del
sistema en donde será implementado.
• Restricciones de diseño
Muchas veces las soluciones de un sistema de software son
normadas por leyes o estándares, este tipo de normas caen como
"restricciones de diseño".
• Materiales
Aquí se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de
industrialización del sistema.

También podría gustarte