1.1 Análisis del problema 4 1.1.1 Necesidades 4 1.1.2 Características 5 1.1.3 Requerimientos 7 1.2 Análisis para definir la VISION del proyecto (Levantamiento de requisitos) 9 1.3 Técnicas de recopilación de necesidades del usuario 9 1.3.1 Introducción 9 1.3.2 Lluvia de ideas 9 1.3.3 Entrevista 10 1.3.4 Presentaciones (storyboards) 10 1.3.5 Cuestionarios 10 1.3.6 Encuestas 11 1.3.7 Intercambio de roles 11 1.3.8 Otras técnicas 11 1. Observación y análisis social 11 2. Prototipos 11 3. Modelos 12 4. Administración de requerimientos 12 5. Talleres 13

1. UNIVERSIDAD TECNOLÓGICA DE PANAMÁ
DEPARTAMENTO DE INGENIERÍA DE SOFTWARE
LICENCIATURA DE DESARROLLO DE SOFTWARE
INGENIERÍA DE SOFTWARE I
Tema:
CONCEPCIÓN DEL SISTEMA
Profesor: MC LEAN, JOSE
Integrantes:
Alvarado, Kelvin 10-709-814
Rubio, Ricardo 4-759-908
Grupo:
1LS222
Fecha
30 de Septiembre de 2014
FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES

2. 2
INDICE
INTRODUCCION ...................................................................................................... 3
CONTENIDO
1.1 Análisis del problema ......................................................................................... 4
1.1.1 Necesidades ............................................................................................. 4
1.1.2 Características ......................................................................................... 5
1.1.3 Requerimientos ........................................................................................ 7
1.2 Análisis para definir la VISION del proyecto
(Levantamiento de requisitos) .......................................................................... 9
1.3 Técnicas de recopilación de necesidades del usuario ................................... 9
1.3.1 Introducción ............................................................................................. 9
1.3.2 Lluvia de ideas ......................................................................................... 9
1.3.3 Entrevista ................................................................................................ 10
1.3.4 Presentaciones (storyboards) .............................................................. 10
1.3.5 Cuestionarios ......................................................................................... 10
1.3.6 Encuestas ............................................................................................... 11
1.3.7 Intercambio de roles .............................................................................. 11
1.3.8 Otras técnicas ........................................................................................ 11
1. Observación y análisis social ........................................................ 11
2. Prototipos ........................................................................................ 11
3. Modelos ............................................................................................ 12
4. Administración de requerimientos ................................................ 12
5. Talleres ............................................................................................. 13
CONCLUSION ......................................................................................................... 14
BIBLIOGRAFIA ....................................................................................................... 15

3. 3
INTRODUCCIÓN
En 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.
En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseño del sistema/software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

4. 4
Concepción del Sistema
1.4 Análisis del problema
En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.
El análisis del problema es un paso fundamental en el desarrollo de software. Frecuentemente este paso es obviado y se pasa a la etapa de programación lo que genera numerosos problemas tales como los aumentos de los costos de producción el fracaso del proyecto por no saber exactamente qué se debe hacer, el aumento de los costos de los cambios necesarios a partir del refinamiento del conocimiento del problema, etcétera, etcétera
1.4.1 Necesidades
Reconocer los elementos básicos del problema tal y como los perciben los usuarios finales.
Aquí se determina que se quiere hacer, Cual son las necesidades del usuario o cliente.
Se debe además establecer contacto con el equipo del cliente para reconocer el problema tal como lo percibe el cliente.
El cliente especifica las necesidades para el software.
 Para que quiere?
 Como quiere?
 Quienes lo van a usar?
 ¿Que debe hacer el software?
 ¿Qué hará el sistema?
 ¿Cuándo lo hará?
 ¿Existen varios modos de operación?
 ¿Cómo y cuando puede cambiarse o mejorarse un sistema?
 ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?
 ¿Que debe hacer el software?
 ¿Es posible hacer lo que quiero hacer con la cantidad de conocimiento y mano de obra Disponible?
 ¿Cómo lograr la mayor calidad posible con el menor costo posible?
 ¿Cuál es la combinación de tecnologías que me permite lidiar mejor con la escasez de dinero y mano de obra?
 ¿Cómo manejar el grupo humano?
 ¿Cómo mantener la moral del equipo alta?
 ¿Como lograr que se cambien los requerimientos lo menos posible, sobre todo en cuanto a la forma de interacción con el sistema?
 ¿Cómo lograr que el usuario aprenda a usar el software lo mas rápido posible?

5. 5
 ¿Qué actividades se pueden realizar en paralelo y cuales no?
 ¿Qué actividades necesitan que haya otras actividades terminadas para poder arrancar?
 ¿Cuál es el mensaje que hay que transmitir al equipo?
 ¿Cuál es el mensaje que no debe ser transmitido al equipo nunca?
 ¿Cómo amplificar las pequeñas victorias y minimizar las pequeñas derrotas?
 ¿Cómo lograr que las personas encargadas de la tarea tengan claro lo que tienen que hacer, para de esa forma reducir el número de errores en el desarrollo del sistema?
 ¿Cuál es el momento de dejar de agregar funcionalidades?
 ¿Cómo planificar los ciclos de descanso del equipo sabiendo que su energía y motivación es limitada y directamente proporcional a los beneficios monetarios?
 ¿Cuáles son los gustos del equipo como consumidores además del dinero?
 ¿Qué otros beneficios además del dinero se le puede brindar al equipo de trabajo?
 ¿Cómo evitar los celos y competencias internas entre los miembros?
 ¿Por qué parece que nunca se va a terminar el software?
 ¿Cómo lograr la menor interdependencia entre módulos?
 ¿Qué fue lo que no permitió en otras ocasiones hacer el producto que uno quería hacer?
 ¿Cómo se hizo el software exitoso?
 Una vez delimitado el dominio del problema, es decir la cantidad de software que se va hacer, ¿cómo estimar que porcentaje fue realizado y a partir de esa métrica analizar los progresos en porcentajes realizados, y por consiguiente los porcentajes no realizados del proyecto?
1.4.2 Características
Los Características permiten que los desarrolladores expliquen cómo han entendido lo que el cliente pretende del sistema. También, indican a los diseñadores qué funcionalidad y que características va a tener el sistema resultante. Y además, indican al equipo de pruebas qué demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es lo que solicitó.
1. Correcta
Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.
2. No ambigua
Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.
3. Completa
Una SRS es completa, sí y solo sí, incluye los siguientes elementos:
a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado.

6. 6
b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos.
c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.
4. Consistente
Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradice o entran en conflicto.
5. Jerarquizada de acuerdo a la importancia y/o estabilidad
Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.
6. Verificable
Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo- efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.
7. Modificable
Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS:
a) Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.
b) No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).
c) Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.
8. Rastreable
Una SRS es rastreable si el origen de cada uno de sus requisitos es clara y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación.
Se recomiendan los siguientes dos tipos de rastreabilidad:
a) Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores.
b) Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único

7. 7
o número de referencia. Es particularmente importante cuando el software entra en operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.
1.4.3 Requerimientos
Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.
La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto la preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado con el desarrollo.
Tipos de Requerimientos:
Requerimientos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.
Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para cada requerimiento funcional se muestran en los casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.
Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema.
Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.
Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto.
El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

8. 8
Requerimientos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)
Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
rendimiento
disponibilidad
seguridad
accesibilidad
usabilidad
estabilidad
portabilidad
costo
operatividad
interoperabilidad
escalabilidad
concurrencia
mantenibilidad
interfaz
Se debe identificar sobre que se está trabajando es decir, el tema principal que motiva el inicio del estudio y creación del nuevo software o modificación de uno ya existente. A su vez identificar los recursos que se tienen, en esto entra el conocer los recursos humanos y materiales que participan en el desarrollo de las actividades.
Se tienen que tener dominio de información de un problema lo cual incluye los datos fuera del software (usuarios finales, otros sistemas o dispositivos externos), los datos salen del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y organizan objetos persistentes de datos (por ejemplo, aquellos que se conservan de manera permanente).
También hay que ver los puntos críticos lo que significa tener de una manera clara los aspectos que entorpecen y limitan el buen funcionamiento de los procedimientos actuales, los problemas más comunes y relevantes que se presentan, los motivos que crean insatisfacción y aquellos que deben ser cubiertos a plenitud. Por ejemplo: ¿El contenido de los reportes generados, satisface realmente las necesidades del usuario? ¿Los tiempos de respuesta ofrecidos, son oportunos?, etc.
Hay que definir las funciones que realizara el software ya que estas ayudan al usuario final y al funcionamiento del mismo programa.

9. 9
Se tiene que tener en cuenta cómo será el comportamiento del software antes situaciones inesperadas como lo son por ejemplo una cantidad de usuarios enormes usando el software o una gran cantidad de datos entre otros.
1.5 Análisis para definir la VISION del proyecto (levantamiento de requisitos)
La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, debido a que se enfoca en un área determinante para el éxito de un proyecto: la definición de lo que se desea producir y el cumplimiento con lo que realmente se debía producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente, clara y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados con su desarrollo.
Para el levantamiento se pueden utilizar dos conceptos:
Escenarios: Describen un ejemplo del uso del sistema en términos de una serie de interacciones entre el usuario y el sistema
Casos de uso: Es una abstracción que describe una clase de escenarios. Ambos deben ser escritos en lenguaje natural para que sean entendidos por el usuario.
1.6 Técnicas de recopilación de necesidades del usuario 1.6.1 Introducción
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.
1.6.2 Lluvia de ideas
La lluvia de ideas, también denominada tormenta de ideas, es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado. La lluvia de ideas es una técnica de grupo para generar ideas originales en un ambiente relajado.
Esta herramienta fue ideada en el año 1938 por Alex Faickney Osborn (fue denominada brainstorming), cuando su búsqueda de ideas creativas resultó en un proceso interactivo de grupo no estructurado que generaba más y mejores ideas que las que los individuos podían producir trabajando de forma independiente; dando oportunidad de hacer sugerencias sobre un determinado asunto y aprovechando la capacidad creativa de los participantes.
Numerosos estudios recientes demuestran justamente lo contrario, que individualmente se generan más ideas que en grupo, por lo que la utilidad de esta

10. 10
técnica está en entredicho. Las conclusiones fueron obtenidas de 22 estudios de los cuales 18 corroboraron sus hipótesis.
1.6.3 Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.
1.6.4 Presentaciones (storyboards)
El Storyboard, es un conjunto de dibujos o bocetos que se muestran en secuencia y orden correcto respecto de las ideas que queremos transmitir en una presentación.
1.6.5 Cuestionarios
El cuestionario es un conjunto de preguntas sobre los hechos o aspectos que interesan en una investigación y son contestados por los encuestados. Se trata de un instrumento fundamental para la obtención de datos.
El cuestionario se debe redactar una vez que se ha determinado el objetivo de la encuesta se han desarrollado los objetivos específicos, de tal modo que las

11. 11
preguntas que se hagan respondan a la información que se desea obtener. No debe precipitarse el investigador en la confección del cuestionario porque es la pieza esencial en la obtención de los fines propuestos.
El cuestionario hace que todos los encuestados se encuentren en la misma situación psicológica, y además, que sus respuestas pueden ser comparadas. Para hacer un buen cuestionario la experiencia juega un gran papel ya que se ha considerado como un “arte” la confección de un cuestionario.
1.6.6 Encuestas
Una encuesta es un estudio en el cual el investigador obtiene los datos a partir de realizar un conjunto de preguntas normalizadas dirigidas a una muestra representativa o al conjunto total de la población estadística en estudio, formada a menudo por personas, empresas o entes institucionales, con el fin de conocer estados de opinión, características o hechos específicos.
Las encuestas se pueden realizar sobre el total de la población o sobre una parte representativa de la misma que llamaremos muestra.
1.6.7 Intercambio de roles
Es una técnica grupal a través de la cual se simula e interpreta el rol de la otra persona en disputa para comprender otros puntos vista y así reducir o abortar posibles malos entendidos o conflictos. Es una de las modalidades más trabajadas en el área educativa de la resolución de conflictos.
1.6.8 Otras técnicas
1. Observación y análisis social: La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto. Esto permite superar problemas con los participantes del proyecto que realizan descripciones idealizadas o demasiado simplificadas de los procesos que se llevan a cabo en sus trabajos.
2. Prototipos: Es programa de computador que implementa algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar con la definición de los requerimientos, o para facilitar la evaluación de alternativas de implementación de un sistema.
Existen dos grandes tipos de prototipos. Los prototipos no funcionales o desechables (Throw away), que sirven para entender la dificultad y aclarar los requerimientos; y los prototipos funcionales o evolutivos (Evolutionary) que permiten construir una aproximación del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo. Análisis: Es el proceso de analizar las

12. 12
necesidades de los clientes y los usuarios para llegar a una definición de los requerimientos de software.
Dentro de las prácticas principales se encuentra: JAD (Joint Application Development): Esta práctica se basa en la creación de espacios que permitan celebrar sesiones o reuniones en donde los participantes y directos interesados dentro del desarrollo del proyecto buscan obtener o generar conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas sesiones se trabaja bajo un enfoque común que permite el fácil entendimiento de los temas expuestos por parte de los invitados a la sesión
3. Modelos: Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. Existen dos tipos de modelos. - Modelo conceptual: Es el utilizado en la especificación del sistema, representa los conceptos más significativos en el dominio del problema…. Nos describe la parte estática del problema, es una fotografía del mundo real. - Modelo de Comportamiento: Utilizado en la parte de diseño del sistema, define la parte dinámica, es decir, cuál debe ser el comportamiento en cada situación y la forma de proceder.
Los diagramas de secuencia y de estados son parte de este modelo. Especificación: Consiste en el desarrollo de un documento que de manera clara y precisa contenga y especifique cada uno de los requerimientos del sistema de software. Verificación: Es el proceso de asegurar que la especificación de requerimientos de software sea acorde con los requerimientos del sistema, conforme a los estándares de documentación de la fase de requerimientos, y que a su vez este documento sea una base sólida para la arquitectura y el diseño.
Esta actividad representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.
4. Administración de requerimientos: Es un proceso que tiene por objetivo comprender y controlar los requerimientos. Como todo proceso de administración, inicia con la planeación a la par de la identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del proceso de desarrollo de software que se esté empleando, independientemente de esto se deben considerar las siguientes etapas:
a. Requerimientos duraderos y volátiles.
b. Planeación de la administración de requerimientos.
c. Administración del cambio de los requerimientos.

13. 13
5. Talleres:
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.
Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual ó coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.
Durante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.
En el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todas los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.
Analizar bien es una virtud. No programar hasta que tengas completamente desarrollado el análisis es un grado superior de virtuosismo.

14. 14
CONCLUSIÓN
Con este documento dejamos claro la importancia que tiene el conocimiento de la Ingeniería de Software y con ella la Gestión de Requisitos .Sin dejar de mencionar que el resultado satisfactorio depende de una intensa comunicación entre clientes y analistas de requerimientos. La Ingeniería se encarga de establecer y mantener un acuerdo en qué el sistema debe hacer, demás proporciona al equipo de desarrollo un entendimiento de los requisitos, hasta definir los límites del sistema.
A pesar de la importancia que tiene los Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras.
Cada actividad y técnica de los requerimientos utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, consideramos que no existe un modelo de proceso ideal para los requerimientos; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.
En esta investigación se presentaron una serie de actividades y técnicas, que no pertenecen a un modelo de proceso en sí, sino, que son una alternativa al material publicado por diferentes autores y que, desde mi punto de vista, son las más importantes.
Debemos recordar que los requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.

15. 15
BIBLIOGRAFIA
[BRUEGGE, 2002]
Ingeniería de Software Orientado a Objetos
Bruegge, Bernd y Dutoit, Allen
Prentice-Hall, 2002
ISBN: 970-26-0010-3
[IEEE Std 830-1998]
IEEE Recommended Practice for Software Requirements Specifications
Software Engineering Standards Committee of the IEEE Computer Society
ISBN 0-7381-0332-2
[PRESSMAN, 2002]
Ingeniería del Software. Un enfoque práctico. 5ta. Edición
Pressman, Roger
McGraw-Hill, 2002
ISBN 84-481-3214-9
[SOMMERVILLE, 2002]
Ingeniería de Software. 6ta. Edición
Sommerville, Ian
Prentice-Hall, 2002
ISBN 970-26-0206-8
[ISURJC]
Curso de Ingeniería del Software I
Universidad Rey Juan Carlos
http://kybele.escet.urjc.es/asignatura.asp?Nombre1=ISI