Analisi de sistemas

ANALISIS DE REQUERIMIETO

El proceso de análisis de requerimientos refina, modela, especifica y verifica las solicitudes de usuario, y

con ello genera documentos base para la ejecución de los procesos siguientes.

La base para la definición del proceso de administración de requerimientos es el área de

procesos Requirements Development (RD) del modelo CMMI Development versión 1.3 (Capability

Maturity Model Integration), que reúne un conjunto de prácticas que orientan y garantizan el correcto

análisis de los requerimientos de un sistema, en un proyecto de desarrollo de software.

El diagrama muestra el flujo de información entre las actividades del proceso de análisis de

requerimientos, incluyendo los productos de trabajo generados durante el proceso.

https://www.icesi.edu.co/i2t/driso/process/proceso_desarrollo_sw/index.php/procesos-de-
desarrollo/ra
……………………………………..
EL ANÁLISIS DEL REQUERIMIENTO
El análisis de requerimientos permite al ingeniero de sistemas especificar las características op
datos y rendimientos), indica la interfaz del software con otros elementos del sistema y estable
cumplir el software.

La función principal de un analista del software (o ingeniero de requisitos es llevar a ca

cumplir con las cinco áreas de esfuerzo descritas en la sección anterior. Para lo cual hace uso
1. Entrevistas
2. Talleres
3. Observación
4. Encuestas
5. Revisión documental
6. Uso de especificaciones formales para requerimientos (formatos estándar de do

El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:

1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión
https://sites.google.com/site/ingrequerimientosm/el-analisis-del-requerimiento

INGENIERIA DE REQUERIMIENTOS
…………………………

7 Técnicas de levantamiento de requerimientos software

Esta página incluye parte del contenido del Curso Online de Ingeniería de requisitos. Identifica y
analiza requisitos de software de manera integrada, para elaborar especificaciones de calidad.
Para mayor información visita la página del curso.

Diseñado por Freepik

Una etapa fundamental en proyectos de ingeniería de software, es la identificación y

documentación de los requerimientos del futuro sistema al comienzo del proyecto, pues en
numerosas ocasiones se ha demostrado que es cuando pueden prevenirse errores que puedan
significar el fracaso del proyecto.

En la Ingeniería de requisitos, el levantamiento de requerimientos se refiere a la identificación

y documentación de los requerimientos de un sistema, a partir de los usuarios, clientes o
interesados (Stakeholders). A la práctica también se le conoce como Recopilación de
requerimientos.

En este artículo te compartimos 7 técnicas para realizar el levantamiento de requerimientos de

software, entre ellas las de Análisis de documentación, observación, entrevistas, cuestionarios,
mesas de trabajo, tormentas de ideas e historias de usuario.

PMOInformatica, La oficina de proyectos de informática presenta: 7 Técnicas para obtener

requerimientos en proyectos de ingeniería de software.

7 Técnicas para obtener requerimientos de

software
1. - Análisis de documentación
 Consiste en obtener la información sobre los requerimientos
funcionales y requerimientos no funcionales de software a partir de documentos que ya están
elaborados.
 Es útil cuando los expertos en la materia no están disponibles para ser entrevistados o ya
no forman parte de la organización.
 Utiliza la documentación que sea relevante al requerimiento que se está levantando.
 Ejemplos de documentación: Planes de negocio, actas de constitución de proyecto,
reglas de negocio, contratos, definiciones de alcance, memorándums, correos electrónicos,
documentos de entrenamiento, entre otros.

2.- Observación
 Consiste en estudiar el entorno de trabajo de los usuarios, clientes e interesados de
proyecto (Stakeholders).
 Es una técnica útil cuando se está documentando la situación actual de procesos de
negocio.
 Puede ser de dos tipos, pasiva o activa.
 En observación pasiva, el observador no hace preguntas, limitándose solo a tomar notas y
a no interferir en el desempeño normal de las operaciones.
 En observación activa, el observador puede conversar con el usuario.

¿Buscas formación en técnicas para definir los

requerimientos de software?

Inscríbete en el curso de Ingeniería de requisitos

Métodos probados para la elicitación y análisis para elaborar especificaciones de calidad. Gestión
efectiva de los requerimientos

Preinscríbeme gratis
3.- Entrevistas
 Se realizan con los usuarios o interesados clave.
 Direccionan al usuario hacia aspectos específicos del requerimiento a levantar.
 Son útiles para obtener y documentar información detallada sobre los requerimientos y
sus niveles de granularidad.
 Pueden ser entrevistas formales o informales.
 Una clave es mantenerse enfocado en los objetivos de la entrevista.
 Las preguntas abiertas son útiles para identificar información faltante.
 Las preguntas cerradas son útiles para confirmar y validar información.
 El éxito de las entrevistas depende del grado de conocimiento del entrevistador y
entrevistado, disposición del entrevistado de suministrar información, buena documentación de la
discusión y en definitiva de una buena relación entre las partes.

4.- Encuestas o cuestionarios

Diseñado por Freepik

 Es una técnica útil para recopilar eficientemente los requerimientos de muchas personas.
 La clave para el éxito es que tengan un propósito y audiencia claramente definida,
establecer fechas topes para llenar la encuesta, con preguntas claras y concisas.
 Deben enfocarse en los objetivos de negocio que se necesitan identificar.
 Pueden apoyarse con entrevistas de seguimiento con usuarios individuales.
 Pueden contener tanto preguntas cerradas como preguntas abiertas.
5.- Mesas de trabajo (Workshops)
 Es una técnica efectiva para obtener información rápidamente de varias personas.
 Es recomendable tener una agenda predefinida y preseleccionar a los participantes,
siguiendo buenas prácticas para reuniones efectivas.
 Se puede utilizar un facilitador neutral y un transcriptor (que no sea el mismo facilitador).
 Se puede utilizar un material común sobre el cual enfocar la atención y conversar, por
ejemplo una presentación con un desglose del proceso que se está estudiando o un flujograma.
 Se pueden combinar con otras técnicas como pueden ser las entrevistas y cuestionarios.

Lectura recomendada

Ingeniería de requisitos: Software orientado al

negocio

Autor: Guilherme Siqueira Simões, Carlos Eduardo Vazquez

Con el libro Ingeniería de requisitos: Software orientado al negocio aprenderás el conjunto de

técnicas, actividades y prácticas que componen el análisis funcional y análisis de negocio, que al
aplicarlo a tus proyectos te ayudará a asegurar su éxito.
 Comprar en Amazon España

Comprar en Amazon (Latinoamérica)

6.- Tormenta de ideas

Diseñado por Freepik

 Es una sesión de trabajo estructurada orientada para obtener la mayor cantidad de ideas
posibles.
 Es recomendable limitarlas en el tiempo, utilizar ayudas visuales y designar un facilitador.
 Las reglas son importantes, por ejemplo los criterios para evaluar ideas y asignarles un
puntaje, no permitir las críticas a las ideas y limitar el tiempo de discusión.
 En una primera fase, se deben identificar la mayor cantidad de ideas, para luego
evaluarlas. Todas las ideas deben ser consideradas y deben limitarse que una idea se le ahogue o
critique antes de tener tiempo de desarrollarla.

7.- Historia del usuario

 Las historias de usuario, son una aproximación simple al levantamiento de
requerimientos de software, en la cual la conversación pasa a ser más importante que la
formalización de requerimientos escritos.
  Es recomendable que sean escritas por el mismo cliente o interesado (con apoyo del
facilitador si es necesario), con énfasis en las funcionalidades que el sistema deberá realizar.
 Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la
funcionalidad y el resultado esperado de la aplicación en una frase corta.
 Las historias de usuario son una de las técnicas más difundidas para levantar
requerimientos de software en metodologías ágiles.

Que le sigue al levantamiento de requerimientos

Toda la información obtenida durante el levantamiento de requerimientos puede ser incluída en
una matriz de trazabilidad de requerimientos y en una especificación de requerimientos de
software.

Al levantamiento de requerimientos le sigue el análisis de los mismos, por medio de técnicas como
la descomposición funcional, modelado de procesos, casos de uso, inspecciones y prototipos.
Estas técnicas serán sujeto de un próximo artículo.

¿Buscas formación en Ingeniería de requisitos y análisis de negocio? visita la página del Curso
Online de Ingeniería de requisitos. Identifica y analiza requisitos de software de manera
integrada, para elaborar especificaciones de calidad.

¿Y qué opinas tú?

¿Cuáles técnicas para el levantamiento de requerimientos de software has utilizado? ¿Cuáles
buenas prácticas recomendarías? ¿Qué errores cometiste y que aprendiste de ellos?

>> Siguiente artículo: 8 Técnicas de análisis de requerimientos de software

¿Buscas más información de

gerencia informática?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos
y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

http://www.pmoinformatica.com/2016/08/tecnicas-levantamiento-requerimientos.html

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.

 Principal
 Sobre el blog
 Plantillas
 Gerencia de proyectos
 Agile / Scrum
  Desarrollo y tecnología
 Cursos
 Productos Amazon
 Contacto
miércoles, 3 de agosto de 2016

………………………

Técnicas de Levantamiento
de Requerimientos
Existen diversas técnicas para realizar el Levantamiento de los requerimientos a
continuación mencionaremos algunas:

1. AHP (PROCESO DE ANÁLISIS JERÁRQUICO)

Fue desarrollado a finales de los 60 por Thomas Saaty, quien a partir de sus
investigaciones en el campo militar y su experiencia docente formuló una herramienta
sencilla para ayudar a las personas responsables de la toma de decisiones.
Su simplicidad y su poder han sido evidenciados en las cientos de aplicaciones en las
cuales se han obtenido importantes resultados y en la actualidad, es la base de
muchos paquetes de software diseñados para los procesos de tomas de decisiones
complejas. Además, ha sido adoptado por numerosas compañías para el soporte de
los procesos de toma de decisiones complejas e importantes.
El AHP es una metodología para estructurar, medir y sintetizar. Ha sido aplicado
ampliamente en la solución de una gran variedad de problemas. Es un método
matemático creado para evaluar alternativas cuando se tienen en consideración varios
criterios y está basado en el principio que la experiencia y el conocimiento de los
actores son tan importantes como los datos utilizados en el proceso.
Los primeros usos del AHP fueron dados en la solución de problemas de decisión en
ambientes multicriterio.

Elementos de complejidad en los procesos de

decisión multicriterio.

Entre sus principales ventajas se pueden comentar:

• Se puede analizar el efecto de los cambios en un nivel superior sobre el nivel
inferior.
• Da información sobre el sistema y permite una vista panorámica de los actores, sus
objetivos y propósitos.
• Permite flexibilidad para encarar cambios en los elementos de manera que no
afecten la estructura total.

El AHP utiliza comparaciones entre pares de elementos, construyendo matrices a

partir de estas comparaciones, y usando elementos del álgebra matricial para
establecer
prioridades entre los elementos de un nivel, con respecto a un elemento del nivel
inmediatamente superior.

2. CASOS DE USO
Los casos de uso se han convertido en la técnica más utilizada a nivel mundial para
el levantamiento y la comunicación clara y eficiente de los requisitos (mejor conocidos
como “requerimientos”) para el desarrollo de sistemas.

Los casos de uso son parte del Lenguaje Unificado de Modelado (UML®), que es el
estándar más importante y más ampliamente reconocido para la especificación,
diagramación y documentación de software de calidad. El UML es un estándar abierto
(es decir, que no es propiedad de una empresa en particular), y es administrado por el
Object Management Group (OMG®) con el acuerdo y participación de prácticamente
todas las principales organizaciones dedicadas al desarrollo de software.

3. ENTREVISTAS
Según [Pressman , 2006], las entrevistas que se realizan al inicio del proyecto deben
contener preguntas “libres de contexto” divididas en tres conjuntos de preguntas.
Estas preguntas ayudan a iniciar la conversación esencial para la obtención exitosa.
Sin embargo, la sesión de preguntas y respuestas se debe usar sólo para los
primeros encuentros.
El primer conjunto de preguntas se enfoca en los usuarios, otros interesados, metas
generales y en los beneficios medibles de una implementación exitosa.

Algunos ejemplos de estas preguntas son: [Pressman , 2006]

• ¿Quién usará el sistema?
• ¿Cuál será el beneficio de la solución propuesta?
• ¿Hay otra solución posible (que no sea automatizar?

El segundo conjunto de preguntas permite comprender mejor el problema y que los

usuarios expresen sus percepciones sobre una solución. Algunos ejemplos de estas
preguntas son: [Pressman , 2006]

• ¿Cómo sería un buen resultado generado por una solución exitosa?

• ¿Cuáles problemas podrían surgir con la solución propuesta?
• ¿Puede describir el ambiente en el que se usará la solución?
• ¿Qué aspectos especiales de desempeño o restricciones afectarán la forma en que
se busque la solución?

El tercer conjunto de preguntas se enfoca en la efectividad de la entrevista en sí.

Algunos ejemplos de estas preguntas son: [Pressman , 2006]
• ¿Es Usted la persona adecuada para contestar las preguntas?
• ¿Alguien más puede proporcionar información adicional?
• ¿Existe información adicional que desee aportar?

4. JAD
JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario,
basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha
reunión los temas a tratar se centran más en el negocio que en el asunto técnico.
Lógicamente está más orientado a proyectos de cliente (o bien sistemas a medida,
como también se los conoce), y permite recolectar requisitos eficientemente.

Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una
falsa realidad en cuanto al progreso del proyecto o la productividad. Además, hay que
prestar especial cuidado con las estimaciones tempranas, aquellas que entrañan un
mayor riesgo por el mayor desconocimiento del sistema y que deben ofrecer una
amplitud de rango mayor entre mejor estimación y estimación pesimista.

*Para reducir tanto el tiempo como el costo de las entrevistas personales, tal vez los
analistas quieran considerar el diseño de aplicaciones conjuntas (JAD) como
alternativa. Mediante el uso de JAD los analistas pueden analizar los requerimientos
humanos de información y diseñar una interfaz de usuario con los usuarios en un
ambiente de grupo. Una evaluación cuidadosa de la cultura específica de la
organización ayudará al analista a juzgar si es adecuado usar JAD.

*El uso de JAD fue más efectivo en pequeños y claramente enfocados proyectos y
menos efectivo en proyectos largos y complejos.

*Al final, este proceso resultará en un nuevo Sistema de Información viable y

orientado tanto a diseñadores como a usuarios.

Actividades realizadas en JAD

Aquí se encuentran algunos tips para que una sesión JAD sea exitosa:

5. PROTOTIPOS
Los prototipos y los modelos son mecanismos excelentes para presentar ideas a los
usuarios porque ellos pueden ver inmediatamente algunos aspectos claves del
sistema. Mostrar los Prototipos puede provocar que el usuario brinde un mayor
número de requerimientos o cambie de idea acerca de los
requerimientos existentes depurándolos.

Los prototipos también pueden ilustrar como la solución podría funcionar o dar
a los usuarios un vistazo de lo que podrían hacer con el sistema. Muchos más
requerimientos salen a la vista cuando el usuario puede comprobar los que están
proponiendo.

Una presentación puede incluir un grupo de diapositivas, un concepto elaborado por

un artista o un
diseñador, una representación o una animación que brinde a los usuarios
una visión de las posibilidades del
sistema. Cuando se creen prototipos de software se puede hacer una m
aqueta compuesta por pantallazos enfatizando que no existe código asociado y que el
sistema aún no ha sido especificado, diseñado o desarrollado.

Advertencia: Una maqueta puede crear un conjunto de expectativas difíciles de ser

cubiertas.
Estos prototipos tienen como objetivo fomentar que los usuarios mencione
n requerimientos que faltan, no se supone que se está vendiendo una idea o un
producto. Es decir, se debe centrar la
presentación en determinar lo que realmente se requiere del sistema. Ver
un prototipo que,
invariablemente tiene problemas, en algún sentido puede ser un estímulo
para que los usuarios comiencen a decir lo que necesitan. Si ellos expresan
demasiados problemas con el prototipo es
señal de que se está logrando el cometido ya que cada problema puede
conducir a un nuevo requerimiento.

6. LLUVIA O TORMENTAS DE IDEAS

Una tormenta de ideas es una sesión de trabajo en la que un pequeño grupo de

personas proponen ideas acerca de lo que consideren importante en el
área o tópico de interés.

Inicialmente las ideas se

recogen pero no se discuten. Después de esto un facilitador guía
al grupo para que los resultados de la sesión sean organizados y priorizados.
Las siguientes reglas básicas pueden asegurar unos mejores resultados:

 Comenzar declarando claramente el objetivo de la sesión de tormenta de ideas.

 Generar el mayor número de ideas posible.
 Permitir que la imaginación vuele.
 Evitar y disuadir cualquier forma de crítica o de debate mientras se están capturando las i
deas
 Después de que se hayan capturado las ideas reformularlas y combinarlas
7. ESCENARIOS
Son descripciones de ejemplos de las sesiones de interacción con el sistema. Inicia
con un bosquejo y durante la obtención de agregan detalles. Un escenario incluye:

 Una descripción del estado del sistema al inicio del escenario

 Una descripción del flujo normal de eventos en el escenario
 Una descripción de lo que puede ir mal y cómo manejarlo
 Información de otras actividades que se podrían llevar al mismo tiempo
 Una descripción del estado del sistema después de completar el escenario
8. CUESTIONARIOS
El cuestionario es una técnica de recolección de datos y está conformado por un
conjunto de preguntas escritas que el investigador administra o aplica a las personas
o unidades de análisis, a fin de obtener la información empírica necesaria para
determinar los valores o respuestas de las variables es motivo de estudio.

Planeamiento
El cuestionario, tanto para su elaboración como aplicación, debe considerar las
siguientes fases:

 Determinación de los objetivos del cuestionario, que están referidos a obtener

información para analizar el problema motivo de la investigación.
 Identificación de los variables a investigar, que orientan el tipo e información que debe
ser recolectado.
 Delimitación del universo o población bajo estudio, donde será aplicado el cuestionario;
las unidades de análisis o personas que deben responder al cuestionario; y el tamaño y
tipo de muestra de unidades de análisis que permita identificar a los informantes y al
número de ellos.
 Selección del tipo de cuestionario y forma de administración.
 Elaboración del cuestionario como instrumento de recolección de datos.
 El pre- test o prueba piloto.
 Aplicación del cuestionario o trabajo de campo para la recolección de los datos.
 Crítica y codificación de la información recolectada.
 Plan de procesamiento y análisis estadística de la información recolectada.
 Estructura o partes del cuestionario
El cuestionario, por lo general, tiene la siguiente estructura:
 Título específica a quien va dirigido el cuestionario.
  Introducción o presentación; resume los objetivos del cuestionario, la población bajo
estudio, la institución que lleva a cabo la investigación y el carácter anónimo y científico
de la información requerida para motivar la colaboración del informante.
 Identificación del cuestionario; específica un número para cada cuestionario aplicado,
lugar y fecha de aplicación, dirección y teléfono del informante.
 Estos datos son necesarios para cuando se realice el proceso de control de calidad de la
información recolectada.
 Una última parte, donde se debe especificar el nombre, la dirección y el teléfono del que
aplicó el cuestionario (cuando no es auto-administrado); así como las observaciones que
este desee hacer.
 En algunos estudios, en esta parte del cuestionario, también se incluyen preguntas que
deben ser respondidas por el entrevistador, cuando no ha sido posible ubicar al
informante. Estas preguntas, incluso, pueden ser respondidas con la colaboración de
terceras personas.
Tipos de cuestionario
El tipo de preguntas determina el tipo de cuestionarios.

Así, estos pueden ser:

 Cuestionarios con preguntas cerradas.

 Cuestionarios con preguntas abiertos.
 Cuestionarios mixtos, que combinan preguntas cerradas con preguntas abiertas. Este tipo
de cuestionario es el más usual en la investigación social para la recolección de datos.
Sin embargo, otros tipos de clasificación de cuestionarios estarían en función de la
forma de administrarlo (auto-administrado y administrado por terceras personas); así
mismo, los cuestionarios pueden ser simples o pre – codificados

Referencias:

1. Articulo: El proceso de análisis jerárquico (AHP) y la toma de decisiones

multicriterio. Ejemplo de
Aplicación. http://revistas.utp.edu.co/index.php/revistaciencia/article/view/3217/1849
2. Administración de requerimientos con Casos
de Uso. http://www.abiztar.com.mx/cursos/curso_administracion_levantamiento_de_requeri
mientos_con_casos_de_uso.html29 de Septiembre de 2014
3. Recolección de requerimientos utilizando la técnica de
Entrevista. http://www.ministeriodesalud.go.cr/sobre_ministerio/do/productos/. 29 de
septiembre de 2014
4. Subprocesos gestion de requerimientos y
requisitos. http://www.udistrital.edu.co:8080/documents/276352/356568/Cap6GestionRequeri
mientosRequisitos.pdf
5. Procesos de la ingenieria de
requerimientos. http://mena.com.mx/gonzalo/maestria/ingreq/presenta/procesos_ir/
6. Conceptos y técnicas de recolección de datos en la investigación jurídico
social https://www.unifr.ch/ddp1/derechopenal/articulos/a_20080521_56.pdf
 https://monivela.wordpress.com/requerimientos/tecnicas-de-levantamiento-de-requerimientos/

Modelado y Gestión de
la Información


Universidad Distrital Francisco José de Caldas |Especialización en Proyectos Informáticos|Modelado y Gestión de la
información| Docente Ing. Alexandra Abuchar Porras|2014

SIGUE EL B

………………………………………………………………..

3. Técnicas para Identificar Requisitos

Funcionales y No Funcionales
Contenidos

1. 1 Identificación de Requerimientos funcionales

2. 2 Identificación de Requerimientos no funcionales

3. 3 Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales

4. 4 Identificación de elementos
5. 5 Preguntas generales:
Ya que los requerimientos de sistemas de software se clasifican en funcionales y no funcionale
correcta.

Identificación de Requerimientos funcionales

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que éste r
los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimiento

ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen qu
entrega de éste e incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La c
consistencia significa que los requerimientos no tienen definiciones contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleció
parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias c
después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases p

Identificación de Requerimientos no funcionales

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a
capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dis
sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a la
software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeño en
fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del client
requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerim

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los re
los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema ope
para asegurar que será aceptado por el usuario.

En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir sus me
no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cua

En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la p

los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es
requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del tipo de
propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una sección aparte o diferencián
Aspectos a tener en cuenta en la identificación de requerimientos funcionales y

Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:

• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?

Siempre se debe comenzar con lo básico. Cuando se hacen preguntas y se reciben respuestas, se proporcionan antec
describirlo.

Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:

• ¿Cuál es la finalidad de la actividad dentro de la empresa?

• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?

Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:
• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos
• Bases de datos
• Datos de las bases de datos

Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el sistema; o sea, cuánto
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño documentados oficial o no oficialmente
respetan dichos procedimientos?
• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
• ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?

https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-
funcionales-y-no-funcionales
Metodología Gestión de
Requerimientos
………………………………

Requerimientos Funcionales y
No Funcionales

Fecha: 20 enero, 2017Autor/a: rvillarroel160 Comentarios

Los analistas de sistemas pueden clasificar los requerimientos identificados en dos

grandes grupos: los requerimientos funcionales y los requerimientos no funcionales.
A menudo, los requerimientos de sistemas software se clasifican en funcionales y no
funcionales, o como requerimientos del dominio
Requerimientos funcionales

“Los requerimientos funcionales hacen referencia a la descripción de las actividades

y servicios que un sistema debe proveer. Normalmente este tipo de requerimientos
están vinculados con las entradas, las salidas de los procesos y los datos a almacenar
en el sistema.”

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en

que este debe reaccionar a entradas particulares y de cómo se debe comportar en
situaciones particulares. En algunos casos, los requerimientos funcionales de los
sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.”

Los requerimientos funcionales de un sistema describen lo que el sistema debe

hacer. Los cuales dependen del software a desarrollar, los cuales en su mayor parte
se los redactan de una forma abstracta. Pero estos describen con detalle la función de
este, sus entradas y salidas, excepciones, etcétera.

Como ejemplo le presentamos los requerimientos funcionales de una cafetería:

 El cliente vera los productos que están disponibles

 Los precios de los alimentos serán visibles

 Se pedirá los alimentos en un lugar específico (tanto empaquetados como por

preparar) y pagaran en el mismo lugar (caja)

 Los alimentos empaquetados se entregaran en la caja

 Los alimentos a preparar se pedirán en su lugar asignado

o Fruta, gelatinas,etc.

o Tortas, hamburguesas, etc.

 Los clientes recibirán sus productos una vez terminado el proceso

 Se podrá pedir el servicio de calentamiento para alimentos

 El administrador podrá ver las ganancias

 Los vendedores entregaran los alimentos empaquetados

 Los ayudantes de los cocineros entregaran los alimentos para preparar

 El administrador se encargara de los proveedores

Requerimientos no funcionales
“Por otra parte los requerimientos no funcionales describen otras prestaciones,
características y limitaciones que debe tener el sistema para alcanzar el éxito. Los
requerimientos no funcionales engloban características como rendimiento, facilidad
de uso, presupuestos, tiempo de entrega, documentación, seguridad y auditorías
internas”

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen

restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los
requerimientos no funcionales a menudo se aplican al sistema en su totalidad.
Normalmente apenas se aplican a características o servicios individuales del sistema.

La clasificación de requerimientos no
funcionales de Somerville

La figura presenta la clasificación de requerimientos no funcionales definida por

Somerville.
Somerville divide los requerimientos no funcionales en tres grandes tipos:
Requerimientos de producto, requerimientos organizacionales y requerimientos
externos.

Requerimientos no funcionales de producto

Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo

cual establece límites y restricciones sobre lo que los diseñadores (arquitectos de
software) e ingenieros de software pueden hacer.

Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el

desempeño y la confiabilidad, pero otros son más difíciles como por ejemplo
usabilidad y adaptabilidad.

Los requerimientos de producto pueden clasificarse en (Sommerville):

 Requerimientos de usabilidad: La usabilidad se define como el esfuerzo que

necesita hacer un usuario para aprender, usar, ingresar datos e interpretar los
resultados obtenidos de un software de aplicación. En tiempos recientes, la
usabilidad ha adquirido mucha importancia, en especial ante la demanda de
desarrollo de software para móviles y tabletas.

 Requerimientos de eficiencia: Relacionado con desempeño en cuanto a tiempo

de respuesta, número de operaciones por segundo, entre otras mediciones, así
como consumo de recursos de memoria, procesador, espacio en disco o red.

 Requerimientos de dependibilidad: Engloba varios atributos

o Disponibilidad: Disposición del sistema para prestar servicio correctamente.

o Confiabilidad: Continuidad del servicio prestado por el sistema.

o Seguridad industrial: Ausencia de consecuencias catastróficas para el

usuario o el ambiente.
 o Integridad: Ausencia de alteraciones inadecuadas al sistema.

o Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones a un

proceso sin afectar la continuidad del servicio.
 Requerimientos de seguridad: Capacidades funcionales o no funcionales que
debe tener un sistema para cumplir atributos en el área de seguridad de
tecnología de información, seguridad de datos, seguridad lógica, control de
acceso a información (restricciones de acceso), autenticidad de la información,
privacidad, entre otros aspectos.
Considerar los requerimientos de producto es vital para lograr la integración
continua de aplicaciones y el desarrollo de cambios que sean rápidos pero
sostenibles en el tiempo.

Este nuevo paradigma es necesario para implementar las nuevas tecnología de

información y aplicaciones de software como la movilidad, internet de las cosas,
analítica avanzada de datos (Big Data), evolución de los sistemas a la nube y
tecnología de información escalable.

 Requerimientos no funcionales organizacionales

Se derivan de las políticas y procedimientos de la organización como por
ejemplo estándares de procesos o requerimientos de implementación.

Pueden incluir metodologías de desarrollo de software, estándares de

programación (codificación) y herramientas de soporte al desarrollo de software
(por ej. Herramientas CASE) que deben usarse (siguiendo las políticas de la
organización), también reportes a la gerencia que deben proveerse, entre otros.

Las herramientas para la gestión de desarrollo de software que conocemos,

se definen como requerimientos no funcionales organizacionales.

Los requerimientos organizacionales pueden clasificarse en (Sommerville):

 o Requerimientos de entorno: Describen el ambiente operativo en el que se
debe desenvolver el sistema.

o Requerimientos operacionales: Procedimientos operativos que describen

como será usado el sistema dentro del contexto de la organización.

o Requerimientos de desarrollo: Lenguaje de programación a usar, estándares

de codificación, patrones (y antipatrones) de diseño y programación,
herramientas para gestionar el desarrollo de software, entorno de desarrollo
de software (ambiente de desarrollo), entorno de pruebas de software
(ambiente de pruebas), entre otros aspectos.
Uno de los aspectos que se documentan como requerimientos funcionales
organizacionales son los entorno, específicamente los procedimientos de
mantenimiento y administración del ambiente de desarrollo de software.

Esta administración también incluye los procedimientos para gestionar los

ambientes de pruebas integrales.

 Requerimientos no funcionales externos

Estos derivan del entorno organizacional (no entorno técnico) en el cual se
desarrolla el sistema y pueden hacerse tanto sobre el producto (el software
desarrollado) o también sobre el proceso de desarrollo de software.

Este tipo de requerimientos incluyen limitaciones de índole económica, como

por ejemplo el presupuesto del proyecto de software, interacción o necesidad
del sistema de inter-operar con otros sistemas, requerimientos regulatorios en el
área de salud, seguridad industrial o protección de datos, requerimientos legales
concernientes con licencias, regulaciones o certificaciones que necesita el
producto según la industria en el que se desempeñe, entre otros.

Somerville a su vez clasifica estos requerimientos en:

 o Requerimientos regulatorios: Leyes y reglamentos que establecen que debe
hacer el sistema y como debe hacerlo para cumplirlas. El foco de un sistema
o nueva funcionalidad puede ser exclusivamente para cumplir una regulación.

o Requerimientos éticos: Requerimientos que aseguran que el sistema será

aceptable para el usuario, público en general y se adapta a las costumbres de
la sociedad en la que se desenvuelve o a la que presta servicios.

o Requerimientos legislativos: Características que debe cumplir el sistema

para cumplir con la ley, por ejemplo en el área de contabilidad (normas
contables y estándares financieros), requerimientos de seguridad industrial
(para sistemas críticos), entre otros aspectos.
Anuncios
REPORT THIS AD

Comparte esto:

 Twitter

 Facebook

Publicado por rvillarroel16

Ver todas las entradas de rvillarroel16
https://ingenieriadesoftwareutmachala.wordpress.com/2017/01/20/requerimientos-funcionales-
y-no-funcionales/

http://www.espacios.media/que-es-un-analisis-de-requerimientos/