Capítulo 2 Marco Teórico.

2.1. Antecedentes de la arquitectura de 4+1 vistas.

2.1.1 Estándares de arquitectura de 4+1 vista IEEE 1471-2000.
2.2. Estado del arte.
2.2.1 Ingeniería de Requerimientos.
2.2.1.1 Requerimientos de proceso IEEE 830.
2.2.1.2 Requerimientos de los usuarios (actores involucrados).
2.2.1.3 Para la gestión, negociación y análisis.
2.2.2 ESTÁNDARES EN LA GESTIÓN DE PROYECTOS.
2.2.2.1 Calidad en la Gestión de Proyectos ISO 100006
2.2.2.2 PMBOK del PMI
2.2.2.3 Directrices para la Gestión de Proyectos ISO 21500.
2.2.2.4 Asociación Internacional IPMA
2.1. Antecedentes de la arquitectura 4 +1 vistas

La arquitectura de software constituye un diseño de alto

nivel sistema y forma de representarla es mediante el
modelo de vistas 4 +1, el cual se ha perfilado como
referente a este ámbito fue desarrollado por Philippe
Kruchten para organizar el software en el entorno de
desarrollo.

En el modelo se proponen 4 vistas (lógica, desarrollo, procesos y física) y una vista

adicional (escenario) utilizada para vincular a las demás. La representación de la
arquitectura bajo este modelo considera, además de las vistas descritas, hacía que
tipo de usuario va dirigido el diseño o que funcionalidad es la que proporcionara a
desarrolladores, soporte técnico, usuario final, etc.

Integrando, además, para su representación, diagramas UML.

2.1.1 Estándares de arquitectura de 4+1 vista IEEE 1471-2000

El modelo 4 +1 Kruchten, estándar “IEEE 1471-2000” (Recommended Practice for

Architecture Description of Software-Intensive Systems) es un modelo de vistas
diseñado por el profesor Philippe Kruchten y presentado en 1995 en cual es
utilizado para describir la arquitectura de un sistema software basado en el uso de
múltiples puntos de vistas, una vista es una representación de todo el sistema desde
una determinada perspectiva y un punto de vista puede definirse como un conjunto
de reglas (con normas) utilizadas para llevar a cabo y entender las vistas.

Existen 4 vistas bien diferenciadas y relacionadas entre sí.

 Vista lógica (Logical view), Se encarga en el modelo de objetos, clases,

entidad-relación.
 Vista de procesos (process view), lleva a cabo el modelo concurrencia,
sincronización.
  Vista de despliegue o desarrollo(development view), se encarga de la
organización estática del software en su entorno de desarrollo(librerías,
componentes, etc).
 Vista física(phisical view), lo cual es el modelo de correspondencia software-
hardware, aspectos de distribución en máquinas, más la denominada vista
“+1” que tiene la función de relacionar las demás vistas, está formada por las
necesidades funcionales que cubre el sistema, también se denomina como
vista de escenario o como vista de casos de uso.

A continuación se explica más a detalle que información ha de haber en la

documentación de cada una de estas vistas:

 Vista lógica: Representa la funcionalidad que el sistema proporcionara al o

usuarios finales, lo que el sistema debe hacer las funciones y los servicios
que debe ofrecer, la documentación asociada a estar vista uml incluye los
diagramas de clases, comunicación o de secuencia.
 Vista de despliegue: Muestra el sistema desde la perspectiva o visión del
programador se ocupa de la gestión del software; muestra como está dividido
el sistema, sus componentes y las dependencias entre estos, esta vista se
documenta en UML con los diagramas de componentes y de paquetes.

 Vista física: muestra la perspectiva del ingeniero de sistemas, incluye todos

los componentes físicos del sistema y las conexiones entre todos los
componentes que conforman la solución (Incluyendo los también los
servicios), se documenta en UML mediante el diagrama de despliegue.

 “+1” Vista de escenarios: Representa los casos de uso software y tiene la

función de unir y relacionar las otras vistas, desde esta vista tendremos la
trazabilidad de los componentes, las clases , los equipos, los paquetes, etc,
de cada caso de uso es documentación en UML con los diagramas de casos
de uso.
 Hay que dejar claro que Kruchten no dice de qué manera se ha documentar
cada vista; si no que hay que documentar en cada vista, es decir que cuando
se diga que la vista lógica se puede documentar de forma gráfica con un
diagrama de clases UML, no quiere decir que esa vista se tenga que
documentar con ese diagrama, si no que ese diagrama (por sus
características) puede documentar esa vista.

2.2. Estado del arte.

Es una de las primeras etapas que debe desarrollarse dentro de una investigación,
puesto que su elaboración, que consiste en “ir tras las huellas” del tema que se
pretende investigar, permite determinar cómo ha sido tratado el tema, cómo se
encuentra en el momento de realizar la propuesta de investigación y cuáles son las
tendencias. Para su elaboración, es recomendable establecer un período de tiempo,
de acuerdo con los objetivos de la investigación describe las investigaciones más
recientes y actuales que sobre un tema en específico se han realizado.

El origen de la expresión, muy probablemente, se debe a Aristóteles en el libro

primero de Metafísica donde clasifica el conocimiento en Ciencia, Experiencia y
Arte. La ciencia busca el conocimiento por la mera curiosidad innata del ser humano.
De hecho el libro primero de Metafísica de Aristóteles comienza con su famosa frase
Todos los hombres tienen por naturaleza el deseo de saber (Elcho Pan, 1988:45).
La ciencia no busca ninguna utilidad en la búsqueda del conocimiento, sino
satisfacer la propia curiosidad innata del ser humano. Así pues son ciencias la
filosofía, las matemáticas, la física, la biología, la química, etc. El arte, a diferencia
de la ciencia, busca una utilidad a la búsqueda del nuevo conocimiento, cómo hacer
mejores puentes con un menor coste de materiales

Dentro del ambiente tecnológico industrial, se entiende como "estado del arte" o
"estado de la técnica" todos aquellos desarrollos de última tecnología realizados a
un producto, que han sido probados en la industria y han sido acogidos y aceptados
por diferentes fabricantes.
Se desarrolla en dos fases:

1. Fase heurística: se procede a la búsqueda y recopilación de las fuentes de

información, que pueden ser de muchas características y diferente naturaleza.

 Bibliografías, anuarios; monografías; artículos; trabajos especiales.

 Documentos oficiales o privados; testamentos; actas; cartas; diarios.
 Investigaciones aplicadas
 Filmaciones; audiovisuales; grabaciones, multimedios.

2. Fase Hermenéutica: Durante esta fase cada una de las fuentes investigadas
se leerá, se analizará, se interpretará y se clasificará de acuerdo con su importancia
dentro del trabajo de investigación. A partir de allí, se seleccionarán los puntos
fundamentales y se indicarán el o los instrumentos diseñados por el investigador
para sistematizar la información bibliográfica acopiada, por ejemplo, en una ficha de
contenido o una matriz para los conceptos.

¿Para qué se hace? ¿Cuál es la intención?

1) Es el primer acercamiento formal del sujeto que investiga a las producciones

intelectuales en el tema que le interesa. Si el investigador se hará experto del tema,
entonces esta actividad es una manera de iniciar el camino.

2) Conocer otras investigaciones le permite al investigador clarificar sus ideas

respecto a su tema de interés, y así podrá definirlo mejor, afinarlo, delimitarlo, y
enfocarlo desde la perspectiva que a él le interesa.

3) Saber qué es lo último que se ha producido respecto al tema y conocer a los

autores que están haciendo investigación sobre el tema. De esta manera iniciará un
intercambio de información, y podrá establecer una relación académica con otros
investigadores. Si se es un investigador audaz podrá en un futuro generar redes de
investigación sobre el campo que les interesa a varios que por causas de la
elaboración del estado del arte ha descubierto.
a) ¿Quién? El investigador que desarrolló estudio.

b) ¿Cuándo? El año en que se publicaron los resultados del estudio. Aunque

sabemos anticipadamente que el estudio debió de haber sido desarrollado con
anterioridad mínima a un año generalmente.

c) ¿Qué? El objeto de estudio. Es aquí en donde se hace énfasis en la descripción.

No solo se dice el objeto de estudio, sino el enfoque, los resultados de la
investigación.

d) ¿Dónde? El lugar en donde se realizó la investigación. Este es un dato de

referencia con varios propósitos: uno es para organizar la información de lo macro
a micro (de carácter internacional, nacional o local); otro propósito es para saber la
manera de establecer contacto con el autor de la investigación si así fuera el deseo
del investigador que realiza el estado del arte; por ejemplo si es de la localidad
puede contactarlo de manera directa y cara a cara, si no tendrá que establecer
contacto por otros medios, ahora tenemos al alcance los medios electrónicos para
ello que recortan el tiempo de la retroalimentación de un mensaje.

PASOS PARA INICIAR LA ELABORACION DEL ESTADO DEL ARTE

1er. PASO.- Saber sobre qué tema específico se elaborará el estado del arte.

2do. PASO.- Identificar DESCRIPTORES de búsqueda, que generalmente son los

conceptos clave de la investigación, aunque pueden evolucionar conforme se
avanza en el proceso de clarificación temática y del enfoque.

3er. PASO.- Buscar investigaciones. , la creatividad del investigador, y su habilidad

aguda para obtener información valiosa puede llevarlo a lugares insospechados.

A continuación se detallan las fuentes de investigación:

a) Memorias de Congresos.- Ponencias. Generalmente las ponencias son

resultadas de investigaciones terminadas o en proceso de donde se obtiene
información valiosa para iniciar con nuestro proceso de búsqueda, las memorias de
congresos pueden ser locales, nacionales e internacionales, y en su mayoría se
encuentran digitalizadas y disponibles en la red. Dependiendo de la habilidad del
investigador en el manejo de los medios y de la suerte que tenga podrá rescatar
mucha información valiosa. Además los Congresos, simposios, coloquios, están
organizados mediante MESAS TEMATICAS que facilitan la búsqueda al
investigador.
b) Revistas especializadas en el área de interés. En este caso concreto en
Educación. Las revistas serias publican resultados de investigaciones destacadas.

c) Las Bases de Datos Electrónicas ponen a disposición del investigador una gran
cantidad de información organizada con resúmenes analíticos. Para poder obtener
la información se debe suscribir, las bibliotecas grandes, o las instituciones
generalmente tienen la suscripción, es preciso solicitar el servicio para su acceso.

d) Las TESIS definitivamente reportan los resultados de investigaciones realizadas

para la obtención del grado. Estos documentos difícilmente se encuentran en
electrónicamente, por lo que es necesario realizar una indagación personal
Biblioteca por Biblioteca de cada una de las instituciones que en donde están a su
disposición las tesis de los estudiantes egresados.

4to. PASO.- La información disponible de estas cuatro fuentes puede ser mucha,
dificil de leer toda y de clasificar, por lo que se sugiere se tenga un criterio para
seleccionar la que verdaderamente sea más compatible, parecida al tema de
investigación de interés y de acuerdo a la importancia que tenga para el investigador
conforme sus propios criterios establecidos previamente. Una vez seleccionada la
información. Elaborar un listado con los documentos seleccionados para ser
incorporados al ESTADO DEL ARTE. Esta labor puede ser más fácil si se organiza
la información en una tabla con cuatro columnas: AÑO, LUGAR, AUTOR,
CONCEPTO CLAVE.

5to. PASO.- LECTURA de los textos seleccionados. Esto lleva tiempo, y es aquí en
donde puede iniciar el proceso de clarificación conceptual del tema de indagación,
o sucede que la confusión se apodere de nosotros porque algún autor nos haya
cautivado y desvié hacia otro lado la atención del investigador. Es por esto que la
lectura se debe realizar con distanciamiento crítico y objetividad. Es preciso
entender bien la literatura para tener una visión global y una perspectiva del avance
del conocimiento en el tema.

6to. PASO.- Descripción, en una redacción clara, que expone sistemáticamente los
avances existentes acerca del tema y es de carácter más cualitativo, en el que se
detallan los resultados y enfoques de las investigaciones en torno al tema que cada
investigación ha abonado al tema de estudio de interés del investigador que elabora
el estado del arte.. Es preciso recomendar que no se debe copiar el texto del artículo
o el resumen revisado de manera textual porque esto es plagio. Es preciso re-
escribirlo con nuestras propias palabras.
2.2.1 Ingeniería de Requerimientos.

Los requerimientos se deben descubrir antes de empezar a construir un producto,

y que puede ser algo que el producto debe hacer o una cualidad que el producto
debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda
ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea
parte del producto final. Así que si no se tienen los requerimientos correctos, no se
puede diseñar o construir el producto correcto y, consecuentemente, el producto no
permitirá a los usuarios finales realizar su trabajo. Y esto está confirmado por
estudios que demuestran que más del 60% de los errores de diseño se originan
durante las etapas de requerimientos y análisis.

La Ingeniería de Requerimientos se define como un "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)."

Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las

actividades involucradas en el descubrimiento, documentación y mantenimiento de
los requerimientos para un producto determinado.
El uso del término "ingeniería" implica que se deben utilizar técnicas sistemáticas y
repetibles para asegurar que los requerimientos del sistema estén completos y sean
consistentes y relevantes.

El proceso de recopilar, analizar y verificar las necesidades del cliente para un

sistema de software es llamado Ingeniería de Requerimientos. La meta de la
ingeniería de requerimientos es entregar una especificación de requerimientos de
software correcta y completa. La ingeniería de requerimientos apunta a mejorar la
forma en que comprendemos y definimos sistemas de software complejos.

Existen varias definiciones de requerimientos, algunas de las cuales son:

Los Requerimientos fueron definidos por la IEEE como [IEEE90]:

1. Condición o capacidad requerida por el usuario para resolver un problema o

alcanzar un objetivo.
2. Condición o capacidad que debe satisfacer o poseer un sistema o un componente
de un sistema para satisfacer un contrato, un estándar, una especificación u otro
documento formalmente impuesto.
3. Representación documentada de una condición o capacidad como en 1 ó 2.

El análisis de requerimientos establece el proceso de definición de requerimientos

como una serie de tareas o actividades mediante las cuales se busca ganar
conocimientos relevantes del problema, que se utilizarán para producir una
especificación formal del software necesario para resolverlo. En este proceso se
deben conciliar diferentes puntos de vista y utilizar una combinación de métodos,
personas y herramientas.

El resultado final constituye la documentación de los requerimientos. Éstos deben

expresarse de forma clara y estructurada de manera que puedan ser entendidos
tanto por expertos como por el usuario, quien deberá participar en la validación.
Como resultado del análisis se desarrolla la especificación de requerimientos del
software. La revisión es esencial para asegurar que el realizador del software y el
cliente tengan la misma percepción del sistema. Una vez finalizado nuestro proyecto
de desarrollo de sistemas, y contando con un buen análisis de requerimientos,
podremos evaluar la calidad del producto terminado.

Función de un proceso de ingeniería de requerimientos

El Proceso de ingeniería de requerimientos es un conjunto estructurado de

actividades, mediante las cuales obtenemos, validamos y mantenemos el
documento de especificación de requerimientos.

Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la

negociación y la validación. No existe un proceso único que sea válido de aplicar en
todas las organizaciones. Cada organización debe desarrollar su propio proceso de
acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional,
y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería
de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de
requerimientos y muchas veces tenemos también que recurrir a consultores, ya que
ellos tienen una perspectiva más objetiva que las personas involucradas en el
proceso.

Cualquier tarea en donde el resultado sea importante, se puede realizar de mejor

manera al utilizar algún tipo de proceso ordenado. Para obtener este orden,
diseñamos nuestros procesos basándonos en algún modelo que nos guíe a la hora
de diferenciar y secuenciar las actividades.

A continuación se muestran los modelos aplicables a la ingeniería de

requerimientos:

Un modelo es una simplificación de la realidad que incluye aquellos elementos que

tienen una gran influencia y omite aquellos elementos que no son relevantes para
el nivel de abstracción dado.

Sin embargo, en el caso del proceso de IR y desde una perspectiva "intelectual",

podemos decir que todos esos diversos modelos parten de una misma base, un
modelo "madre" que llamaremos "modelo-abstracto". Este tipo de modelo nos
brinda una vista preliminar del proceso, una secuenciación aproximada y general de
las actividades que luego deberemos realizar.
En el siguiente ejemplo se muestra cada uno de los compartimientos que cubre una
sección particular del proceso.

Esto nos llevaría a simplificar el proceso a tres etapas para obtener los
requerimientos del problema que estamos atacando, estas etapas son las
siguientes:

1. Elicitación de requerimientos
2. Especificación
3. Validación

Requerimientos del Sistema

Los requerimientos del sistema son versiones extendidas y detalladas de los

requerimientos del usuario que son utilizados por los ingenieros de requerimientos
como punto de partida para el diseño del sistema.

Clasificación de Requerimientos

Los requerimientos para fines prácticos pueden clasificarse en dos grandes grupos:
Requerimientos Funcionales y Requerimientos No Funcionales. En la siguiente
figura se puede apreciar una taxonomía completa:
Requerimientos Funcionales

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

hacer, desde un punto de vista de la organización (dominio del problema), pasando
por los usuarios y finalizando en los detalles propios del sistema de software.

En principio, la especificación de requerimientos funcionales de un sistema debe

estar completa y ser consistente. La completitud significa que todos los servicios
solicitados por el usuario deben estar definidos. La consistencia significa que los
requerimientos no deben tener definiciones contradictorias. En la práctica, para
sistemas grandes y complejos, es prácticamente imposible alcanzar los
requerimientos de consistencia y completitud.

Requerimientos No Funcionales

Los requerimientos no funcionales, como su nombre sugiere, son aquellos

requerimientos que no se refieren directamente a las funciones específicas que
proporciona el sistema, sino a las propiedades emergentes de éste como la
fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.
De forma alternativa, definen las restricciones del sistema como la capacidad de los
dispositivos de entrada/salida y las representaciones de datos que se utilizan en las
interfaces del sistema.

Sin embargo, el incumplimiento de un requerimiento no funcional puede significar

que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple
sus requerimientos de fiabilidad, no se certificará como seguro para el
funcionamiento; si un sistema de control de tiempo real no cumple sus
requerimientos de rendimiento, las funciones de control no funcionarán
correctamente.
Los requerimientos no funcionales surgen de las necesidades del usuario, debido a
las restricciones en el presupuesto, a las políticas de la organización, a la necesidad
de interoperabilidad con otros sistemas software o hardware, o a factores externos
como regulaciones de seguridad o legislaciones sobre privacidad.

Elicitación de Requerimientos de Negocio y de Usuario

Es el proceso de adquirir (“eliciting”) todo el conocimiento relevante necesario para

producir un modelo de los requerimientos de un dominio de problema, con el
objetivo de entender el dominio del problema en particular. Se trata de un proceso
“humano”.

Antes de mantener las reuniones con los clientes y usuarios e identificar los
requerimientos es fundamental conocer el dominio del problema.

Para conocer el dominio del problema se puede obtener información de fuentes

externas al negocio del cliente: folletos, informes sobre el sector, publicaciones,
consultas con expertos,
etc. En el caso de que se trate de un dominio muy específico puede ser necesario
recurrir a fuentes internas al propio negocio del cliente, en cuyo caso pueden
utilizarse las técnicas de elicitación de requerimientos como el estudio de
documentación, observación in situ, cuestionarios, etc.

Normalmente encontramos que los clientes y analistas se enfrascan en el proyecto

de forma unilateral y no en equipo. Cada parte define su propio “territorio” y se
comunica a través de una serie de notas, impresos formales, documentos y
sesiones de preguntas y respuestas.

Con estos problemas presentes, se desarrollaron numerosas técnicas para tratar de

superar este difícil momento, que es el inicio del proceso. Cada técnica puede
aplicarse en una o más actividades de la ingeniería de requerimientos; en la
práctica, la técnica más apropiada para cada actividad dependerá del proyecto que
esté desarrollándose.
Entrevistas

Las entrevistas son la técnica de elicitación más utilizada, y de hecho son

prácticamente inevitables en cualquier desarrollo.

Análisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a
limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de
información, etc. Una vez elaborada la información, se puede enviar al entrevistado
para confirmar los contenidos. También es importante evaluar la propia entrevista
para determinar los aspectos mejorables.
Brainstorming

El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo

objetivo es la generación de ideas en un ambiente libre de críticas o juicios.

Se busca que los involucrados en un proyecto desarrollen su creatividad,

promoviendo la introducción de los principios creativos. Las sesiones de
brainstorming suelen estar formadas por un número de cuatro a diez participantes,
uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que
de controlarla.

Consolidación: en esta fase se deben organizar y evaluar las ideas generadas

durante la fase anterior.

Documentación: después de la sesión, el jefe produce la documentación oportuna

conteniendo las ideas priorizadas y comentarios generados durante la
consolidación.

Diseño de Casos de Uso

Los casos de uso son una herramienta muy poderosa para representar
requerimientos de sistema.
Todo requerimiento de sistema es susceptible de ser representado gráficamente
mediante un caso de uso.

Los diagramas de casos de uso documentan el comportamiento de un sistema

desde el punto de vista del usuario. Por lo tanto, los casos de uso determinan los
requisitos funcionales del sistema, es decir, representan las funciones que un
sistema puede ejecutar. Su ventaja principal es la facilidad para interpretarlos, lo
que hace que sean especialmente útiles en la comunicación con el cliente.

Actores: Los actores representan un tipo de usuario del sistema. Se entiende como
usuario cualquier cosa externa que interactúa con el sistema. No tiene por qué ser
un ser humano, puede ser otro sistema informático o unidades organizativas o
empresas.
Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema
que se está desarrollando. Se representan mediante una elipse. Cada caso de uso
debe detallarse, habitualmente mediante una descripción textual.

Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor

interactúa con el sistema para llevar a cabo el caso de uso.

Tipos de asociaciones

Existen tres tipos de asociación o relaciones en los diagramas de casos de uso:

Include: Se puede incluir una relación entre dos casos de uso de tipo “include” si
se desea especificar comportamiento común en dos o más casos de uso.

Extend: Se puede incluir una relación entre dos casos de uso de tipo “include” si se
desea especificar diferentes variantes del mismo caso de uso. Es decir, esta
relación implica que el comportamiento de un caso de uso es diferente dependiendo
de ciertas circunstancias.

Generalizaciones: En un diagrama de casos de uso también pueden mostrarse

generalizaciones (relaciones de herencia) para mostrar que diferentes elementos
están relacionados como tipos de otros. Son aplicables a actores o casos de uso,
pero para estos últimos la semántica es muy similar a las relaciones “extend”.

Especificación de requerimientos

Una especificación de requerimientos es una descripción completa del

comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que
describen todas las interacciones que se prevén que los usuarios tendrán con el
software.
Las estrategias recomendadas para la especificación de los requisitos del software
están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles,
contenido deseable, y calidades de una especificación de requisitos del software.

Especificación de casos de uso

La especificación de los casos de uso se refiere a la descripción de cada una de las

partes definidas para lograr su descripción completa.

Ejemplo de una Tabla de Especificación

2.2.1.1 Requerimientos de proceso IEEE 830.

Estándar IEEE/ANSI 830

Contenido del Documento de Requerimientos

Varias organizaciones grandes, como el Departamento de Defensa de los Estados

Unidos y el IEEE, han definido estándares para los documentos de requerimientos.
Davis (Davis, 1993) analiza algunos de estos estándares y compara sus contenidos.
El estándar más ampliamente conocido es el IEEE/ANSÍ 830-1998 (IEEE, 1998).
Este estándar IEEE sugiere la siguiente estructura para los documentos de
requerimientos:

Aunque el estándar IEEE no es ideal, contiene muchos consejos sobre cómo

redactar los requerimientos y cómo evitar problemas. Es muy general para que
pueda ser un estándar de una organización. Es un marco general que se puede
transformar y adaptar para definir un estándar ajustado a las necesidades de una
organización en particular.

Por supuesto, la información que se incluya en un documento de requerimientos

debe depender del tipo de software a desarrollar y del enfoque de desarrollo que se
utilice. Si se adopta un enfoque evolutivo para un producto de software (por
ejemplo), el documento de requerimientos dejará fuera muchos de los temas
detallados sugeridos anteriormente. El interés estará en definir los requerimientos
del usuario y los requerimientos del sistema no funcionales de alto nivel.
En este caso, los diseñadores y programadores utilizan su juicio para decidir cómo
satisfacer el esquema de los requerimientos del usuario para el sistema.

El documento de requerimientos es fundamental cuando un contratista exterior está

desarrollando el sistema software. Sin embargo, los métodos de desarrollo ágiles
sostienen que los requerimientos cambian tan rápidamente que un documento de
requerimientos se queda desfasado en cuanto se redacta, por lo que el esfuerzo en
gran parte se malgasta. Más que un documento formal, enfoques como la
programación extrema (Beck, 1999) proponen que los requerimientos del usuario
deberían ser recogidos incrementalmente y escritos en tarjetas.
 El usuario entonces da prioridad a los requerimientos que se han de implementar
en el siguiente incremento del sistema.

Para sistemas de negocio donde los requerimientos son inestables, pienso que este
enfoque es bueno. Sin embargo, argumentaría que todavía es útil redactar un breve
documento de soporte que defina el negocio y los requerimientos de confiabilidad
del sistema. Es fácil olvidarse de los requerimientos que se aplican al sistema en su
totalidad al centrarse en los requerimientos funcionales para la siguiente entrega del
sistema.

2.2.1.2 Requerimientos de los usuarios (actores involucrados).

Stakeholders

“Stakeholder” es un término inglés utilizado por primera vez por R. E. Freeman en

su obra: “Strategic Management: A Stakeholder Approach” (Pitman, 1984), para
referirse a «quienes pueden afectar o son afectados por las actividades de una
empresa (o proyecto)».

Estos grupos o individuos son los públicos interesados o el entorno interesado

("stakeholders"), que según Freeman deben ser considerados como un elemento
esencial en la planificación estratégica de los negocios y en los proyectos.

Stakeholders en Sistemas

También son llamados interesados o involucrados en un problema determinado, y

que necesitan una solución.

Desde el punto de vista del desarrollo de sistemas, un "stakeholder" es aquella

persona o entidad que está interesada en la realización de un proyecto o tarea,
auspiciando el mismo ya sea mediante su poder de decisión o de financiamiento, o
a través de su propio esfuerzo.

Stakeholders en Gestión de Proyectos

En la gestión de proyectos, los involucrados o interesados ("stakeholders" en inglés)

son todas aquellas personas u organizaciones que afectan o son afectadas por el
proyecto, ya sea de forma positiva o negativa. Una buena planificación de proyectos
debe involucrar la identificación y clasificación de los interesados, así como el
estudio y la determinación de sus necesidades y expectativas.
Usuarios

En sentido general, un usuario es un conjunto de permisos y de recursos (o

dispositivos) a los cuales se tiene acceso. Es decir, un usuario puede ser tanto una
persona como una máquina, un programa,
etc.

Aunque las personas que tienen contacto directo con las computadoras pueden ser
definidas colectivamente como usuarios, de forma individual tienen numerosas
diferencias (edad, sexo, conocimientos previos, motivación, etc).
Sin embargo, hay situaciones en que es necesario clasificarlos en una sola
categoría; por ejemplo, para fines de evaluación. Una de las más utilizadas es la
que clasifica a los usuarios según su nivel de conocimiento (avanzado, principiante,
intermedio).

Usuarios y Requerimientos

En la Ingeniería de Requerimientos, se suele establecer una correspondencia entre

los niveles de los usuarios y los niveles de los requerimientos. La idea básica
consiste en que los usuarios de cada nivel tendrán necesidades y expectativas
diferentes con respecto a un mismo sistema. De esta correspondencia se puede
clasificar en sentido general a los requerimientos en los siguientes grupos:

Requerimientos de Negocio

Los requerimientos del negocio se derivan del dominio de aplicación del sistema
más que de las necesidades específicas de los usuarios. Normalmente incluyen
terminología especializada del dominio o referencias a conceptos del dominio.
Los requerimientos del negocio son importantes debido a que a menudo reflejan los
objetivos y estrategias que la organización cliente tiene para el nuevo sistema.
Si estos requerimientos no se satisfacen, puede ser imposible hacer que el sistema
funcione de forma satisfactoria.

Requerimientos del Usuario

Los requerimientos del usuario para un sistema deben describir las necesidades y
expectativas que tienen los usuarios desde el punto de vista humano para con el
nuevo sistema.

Bibliografías:

Articulo de Philippe Kruchtens “Architectual Blueprints – the “4+1” View Model of

Software Architecture”: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-
architecture.pdf

http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

“Software Engineering: Principles and Practice”, 3rd Edición de Hans van Vlient.
May 2008.
http://www.notei.com.mx/index.php?id=81
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
http://standards.ieee.org/findstds/standard/1471-2000.html

Bibliografía:

BOGDAN, S.J; TAYLOR, R. Introducción a los métodos cualitativos de in-

vestigación social. Barcelona, Paidós, 1992.

CIFUENTES ROCIO. Una perspectiva hermenéutica para la construcción

de estado del arte. Manizales, 1993

ERLANDSON, D.A; et al. Doing natulalistic inquary. London: Sage, 1993