SlideShare una empresa de Scribd logo
1 de 15
Descargar para leer sin conexión
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 
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 
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 
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 
 ¿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 
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 
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 
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 
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 
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 
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 
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 
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 
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 
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

Más contenido relacionado

La actualidad más candente

Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1jmpov441
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de softwareGuillermo Lemus
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareJahiro Bojorquez
 
Requisitos funcionales del sistema
Requisitos funcionales del sistemaRequisitos funcionales del sistema
Requisitos funcionales del sistemafanyto
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAngel Reyes
 
Calidad de Software
Calidad de SoftwareCalidad de Software
Calidad de SoftwareAnaMelba MH
 
Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitosinmacu_
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesVictor Escamilla
 

La actualidad más candente (20)

Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Proyecto Final - Calidad de Software
Proyecto Final - Calidad de SoftwareProyecto Final - Calidad de Software
Proyecto Final - Calidad de Software
 
Guia iso 9126
Guia iso 9126Guia iso 9126
Guia iso 9126
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Formato ieee830(srs lleno)
Formato ieee830(srs lleno)Formato ieee830(srs lleno)
Formato ieee830(srs lleno)
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de software
 
Factores de calidad del software
Factores de calidad del softwareFactores de calidad del software
Factores de calidad del software
 
Requisitos funcionales del sistema
Requisitos funcionales del sistemaRequisitos funcionales del sistema
Requisitos funcionales del sistema
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de software
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Calidad de Software
Calidad de SoftwareCalidad de Software
Calidad de Software
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentes
 

Similar a Requerimientos en Ingenieria de Software

Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276marlev boadas
 
Planificación y Modelado
Planificación y ModeladoPlanificación y Modelado
Planificación y ModeladoDiaNa González
 
Unidad 1 requerimientos del software
Unidad 1 requerimientos del softwareUnidad 1 requerimientos del software
Unidad 1 requerimientos del softwareoemavarez
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosnenyta08
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosKleo Jorgee
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezkarolavergara
 
TAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSTAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSxinithazangels
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del softwareuniv of pamplona
 
Fundamentos del diseno software
Fundamentos del diseno softwareFundamentos del diseno software
Fundamentos del diseno softwareclaudiocaizales
 
presentacion_edisleynissilva
presentacion_edisleynissilvapresentacion_edisleynissilva
presentacion_edisleynissilvaeddysilva18
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)nenyta08
 
Ingeniería de requisitos
Ingeniería de requisitos Ingeniería de requisitos
Ingeniería de requisitos CHICATEC
 

Similar a Requerimientos en Ingenieria de Software (20)

Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Pym
PymPym
Pym
 
Pym
PymPym
Pym
 
Planificación y Modelado
Planificación y ModeladoPlanificación y Modelado
Planificación y Modelado
 
Ensayo ingenieria de requisitos
Ensayo ingenieria de requisitosEnsayo ingenieria de requisitos
Ensayo ingenieria de requisitos
 
Tipos de requerimeintos
Tipos de requerimeintosTipos de requerimeintos
Tipos de requerimeintos
 
Unidad 1 requerimientos del software
Unidad 1 requerimientos del softwareUnidad 1 requerimientos del software
Unidad 1 requerimientos del software
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
 
TAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSTAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOS
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Fundamentos del diseno software
Fundamentos del diseno softwareFundamentos del diseno software
Fundamentos del diseno software
 
presentacion_edisleynissilva
presentacion_edisleynissilvapresentacion_edisleynissilva
presentacion_edisleynissilva
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)
 
Ingeniería de requisitos
Ingeniería de requisitos Ingeniería de requisitos
Ingeniería de requisitos
 
Enrique Cabello
Enrique CabelloEnrique Cabello
Enrique Cabello
 
Tema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de RequisitosTema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de Requisitos
 

Requerimientos en Ingenieria de Software

  • 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