2.1. Tipos de requisitos. 2.2. Fuentes de datos para el anlisis del sistema. 2.3.

Seleccin y diseo de instrumentos para la recopilacin de Informacin. 2.4. Captura de requisitos candidatos. 2.5. Seleccin de metodologa de desarrollo. 2.6. Modelo del negocio. 2.7. Modelo del dominio. 2.8. Validacin de requerimientos. 2.9. Definicin de propuesta de solucin.

Recopilado por: M.I Norma H. Jimnez Alor

COMPETENCIA ESPECFICA:
o Identificar reas de oportunidad en una organizacin, para la propuesta y diseo de sistemas de informacin. o Analizar diversas alternativas de solucin a partir de la identificacin y definicin de requerimientos especificados por el cliente.

Recopilado por: M.I Norma H. Jimnez Alor

o Definicin de requisito: Caractersticas que deben incluirse en un sistema o aplicacin o Lista de caractersticas del sistema que sirven para realizar la planificacin del proyecto o No todas las caractersticas del sistema tienen por qu ser desarrolladas en una misma versin. o Cada caracterstica puede tener asociada una prioridad, riesgo, coste, etc.
Recopilado por: M.I Norma H. Jimnez Alor

Requisitos de usuario
o Declaraciones en lenguaje natural y en diversos diagramas de los servicios del sistema y de las restricciones bajo las que debe operar.

Requisitos del sistema

o Un documento estructurado que determina las descripciones detalladas de los servicios de sistema. o Escrito como contrato entre el cliente y el desarrollador o Deben ser una especificacin completa y consistente del sistema o Especificacin del software: descripcin detallada del software que sirve de base a los desarrolladores para disear el sistema.

Recopilado por: M.I Norma H. Jimnez Alor

Ejemplo de requisito de usuario

1.- El sistema debe permitir representar y acceder a archivos externos creados por otras herramientas.

Ejemplo de requisito del sistema

El usuario deber poder definir el tipo de un nuevo archivo externo. 2.- Cada tipo de archivo tendr una herramienta asociada, que se aplicar al archivo. 3.- Cada tipo de archivo se representar con un icono especfico.
Recopilado por: M.I Norma H. Jimnez Alor

Requisitos funcionales (RF)

o Describen el funcionamiento del sistema o Los RF del usuario pueden ser frases muy generales sobre lo que el sistema debera hacer. Se suelen expresar como objetivos del sistema. o Los RF del sistema deben describir los servicios que hay que proporcionar con todo detalle: los casos de uso

Recopilado por: M.I Norma H. Jimnez Alor

Ejemplo de requisitos funcionales

Se deben poder realizar bsquedas en base a diferentes criterios. 2. Se deben proporcionar diferentes visores para que el usuario lea los documentos recuperados. 3. Cada factura tendr un nmero nico y correlativo y la fecha

Recopilado por: M.I Norma H. Jimnez Alor

Requisitos no funcionales (RNF)

o Definen propiedades emergentes del sistema, tales como el tiempo de respuesta, las necesidades de almacenamiento, la fiabilidad, o Pueden especificar tambin la utilizacin de una herramienta CASE en particular, un lenguaje de programacin o un mtodo del desarrollo. o Pueden ser ms crticos que los funcionales. o Si un R. funcional no se cumple, el sistema se degrada o Si un R. no funcional no se cumple, el sistema puede inutilizarse

Recopilado por: M.I Norma H. Jimnez Alor

Mtricas para especificar requerimientos no funcionales

Recopilado por: M.I Norma H. Jimnez Alor

Clasificacin de los requisitos no funcionales

Requisitos del producto o Especifican el comportamiento del producto obtenido: velocidad de ejecucin, memoria requerida, porcentaje de fallos aceptables,

Requisitos organizacionales o Son una consecuencia de las polticas y procedimientos existentes en la organizacin: procesos estndar utilizados, de fechas de entrega, documentacin a entregar,
Requisitos externos o Presentan factores externos al sistema y a su proceso de desarrollo: interoperabilidad del sistema con otros, requisitos legales, ticos, Recopilado por: M.I Norma H. Jimnez Alor

Clasificacin de los funcionalesejemplos

requisitos

no

Requisito del producto Se utilizar en todas las comunicaciones el conjunto de caracteres estndar X. Requisito organizacional El sistema se debe desarrollar de acuerdo con el proceso estndar XYZCoSP-STAN-95.

Requisito externo El sistema no divulgar a los operadores ninguna informacin personal sobre los clientes aparte de su nombre y su nmero de referencia.
Recopilado por: M.I Norma H. Jimnez Alor

Clasificacin de los requisitos no funcionales

Requisitos verificables o Los requisitos no funcionales pueden ser muy difciles de expresar con exactitud. o Los requisitos imprecisos pueden ser difciles de verificar. o Un deseo general del usuario es, por ejemplo, la facilidad de uso Requisito no funcional verificable o Una frase que incluye alguna medida que puede ser objetivamente probada.
Recopilado por: M.I Norma H. Jimnez Alor

Clasificacin de los funcionalesejemplos

requisitos

no

Requisito RNF verificable RNF imprecisos (una primera versin) - Los usuarios especializados debern utilizar el sistema fcilmente. - El sistema deber estar organizado para minimizar los errores del usuario. RNF verificables (detallados) - Los usuarios experimentados debern poder utilizar todas las funciones del sistema despus de un total de dos horas de entrenamiento. - Despus de este entrenamiento, el nmero medio de errores cometidos por los usuarios experimentados no exceder de dos por da.
Recopilado por: M.I Norma H. Jimnez Alor

Clasificacin de los requisitos no funcionalesejemplos

Facilidad de uso (usability) o Se debe ver el texto fcilmente a una distancia de 1metro Fiabilidad ( reliability) o Si se produce algn fallo al usar un servicio externo (autorizacin de pago) solucionarlo localmente Rendimiento (performance) o Conseguir la autorizacin de pago en menos de 1 minuto, el 90% de las veces

Soporte (supportability) o El sistema debe ser instalable por los usuarios.

Recopilado por: M.I Norma H. Jimnez Alor

Funcionales
o Especifican qu debe hacer el producto. o Describen las acciones que el producto debe llevar a cabo. o Hay que pensar en estos requisitos como aquello que el producto debe hacer desde el punto de vista del negocio. o Pueden verse como requisitos independientes a cualquier tecnologa. o Son aquellos que hacen que el producto realice el trabajo o Son la esencia del trabajo.

No funcionales
o son las cualidades que debe tener el producto. Estos requisitos hacen que el producto sea atractivo, til, rpido, fiable o seguro. o Propiedades no requeridas porque no son actividades funcionales del producto, pero son deseables, ya que el cliente espera que las actividades sean ejecutadas de cierta manera y con un especfico grado de calidad. o Son aquellos que hacen que el producto d cierto carcter al trabajo.

Recopilado por: M.I Norma H. Jimnez Alor

Un buen proceso de obtencin de requisitos soporta el desarrollo de la especificacin de los requisitos, de tal forma que tengan los siguientes atributos:
o Los requisitos han de ser completos, consistentes y han de estar dentro del alcance del proyecto o Los requisitos son identificados de forma nica y han de priorizarse o Cumplen con los objetivos de los clientes o Son viables y apropiados para el desarrollo o Estn indicados de forma clara y no ambigua o Los requisitos han de ser testeables, es decir, es necesario que sean comprobables para poder validarlos y verificarlos en etapas posteriores. Deben tener capacidad de prueba.
Recopilado por: M.I Norma H. Jimnez Alor

Existen bsicamente tres fuentes de hechos dentro y alrededor de la organizacin: 1. El sistema actual. Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de informacin en donde anteriormente no haya existido ninguno. Con frecuencia se dedica una gran cantidad de tiempo investigando y documentando el sistema anterior, pero un anlisis de ventajas y desventajas puede ayudar a determinar cundo y qu tan extensamente debe estudiarse el sistema anterior. Las principales ventajas de analizar el sistema anterior: o o o o o Eficacia del sistema actual. Ideas de diseo. Reconocimiento de recursos. Conocimiento de conversin. Punto de partida comn.
Recopilado por: M.I Norma H. Jimnez Alor

Las principales desventajas de analizar el sistema anterior: o Gastos o Barreras Innecesarias. 2. Fuentes internas. Las fuentes ms importante de hechos de estudio a disposicin del analista es la gente. Los requerimientos de informacin puede ser planteado mejor por los usuarios de la informacin. El papeleo describe la forma en que una organizacin esta estructurada. 3. Fuentes externas. La exploracin de otros subsistemas de informacin dentro de la organizacin puede ser una fuente til de recopilacin de datos, procesamiento de datos o de ideas y tcnicas para el reporte de la informacin.

Recopilado por: M.I Norma H. Jimnez Alor

Existen mltiples tcnicas que pueden ayudar a la hora de recoger los requisitos de un producto. Entrevistas Esta es una tcnica simple y directa. Preguntas libres de contexto pueden ayudar a conseguir entrevistas libres. El objetivo es condicionar la respuesta del usuario a las preguntas. Entonces, puede ser apropiado buscar requisitos no descubiertos explorando soluciones.

Recopilado por: M.I Norma H. Jimnez Alor

Se puede usar esta tcnica para: o Reunir informacin sobre un sistema existente o Determinar requisitos de un sistema nuevo o Clarificar especificaciones funcionales o Obtener informacin de entorno sobre la organizacin del cliente. o Obtener realimentacin respecto a la usabilidad

Recopilado por: M.I Norma H. Jimnez Alor

Reunin Las reuniones se usan para comunicar y promover la solucin de un problema en grupo. Esta tcnica se puede usar para cualquier tipo de reunin, desde reuniones pequeas de dos o tres participantes hasta reuniones a gran escala. Cuanto ms grande sea mayor deber ser el nivel de formalidad. La efectividad de la reunin se puede evaluar mediante una encuesta a los participantes.

Recopilado por: M.I Norma H. Jimnez Alor

Formulario de recogida de observaciones El formulario de recogida de observaciones puede usarse para empezar a analizar un proceso de negocio reuniendo hechos que prueben una teora u opinin y para empezar a detectar patrones en un proceso. El formulario de recogida de observaciones ms efectivo: o Contiene informacin homognea o Muestra datos de forma visual en un formato que revela patrones subyacentes o Es fcil de entender y de usar
Recopilado por: M.I Norma H. Jimnez Alor

Cuestionarios y Encuestas Esta tcnica se usa cuando la informacin proviene directamente de la gente, como actitudes, valores, hbitos o preferencias personales: o Para determinar la funcionalidad de una aplicacin existente o Para determinar el uso de una tecnologa existente Usar cuestionarios por mail, de administracin personal cuando: o La gente est alejada geogrficamente o Haya mucha gente para entrevistar o La informacin a reunir sea simple o El anonimato es importante
Recopilado por: M.I Norma H. Jimnez Alor

Usar cuestionarios en entrevista cuando: o Se requiera informacin en profundidad o Se quiere comprobar los distintos puntos de vista de las personas o Se requiere una tasa de respuesta mayor que la generada por cuestionarios va mail.

Recopilado por: M.I Norma H. Jimnez Alor

Brainstorming El brainstorming o lluvia de ideas implica tanto la generacin como la reduccin de ideas. Las ideas ms creativas e innovadoras resultan con frecuencia de la combinacin de ideas aparentemente sin relacin. Se pueden utilizar algunas tcnicas de votacin para priorizar las ideas creadas. Aunque se prefieren los brainstorming en vivo, en algunas situaciones puede ser viable el brainstorming basado en web.

Recopilado por: M.I Norma H. Jimnez Alor

En forma tpica, el flujo de trabajo de requisitos incluye los siguientes pasos: o Enumerar los requisitos candidatos. o Comprender el contexto del sistema. o Capturar requisitos funcionales. o Capturar requisitos no funcionales. Durante la vida del sistema los clientes, usuarios, analistas y desarrolladores, aparecen con ideas que podrn convertirse en verdaderos requisitos, mantener una lista de estas ideas, las cuales sern un conjunto de requisitos candidatos. Esta lista se usa para planificar el trabajo.
Recopilado por: M.I Norma H. Jimnez Alor

La lista de caractersticas deseadas del sistema constituyen los requisitos candidatos .De cada caracterstica se registra: - Nombre corto
- Descripcin - Estado (propuesto, aprobado, incluido, o validado) - Coste estimado de implementacin (en trmino de tipos de recursos y horashombre) - Prioridad (crtico, importante, o secundario) - Nivel de riesgo asociado a la implementacin de la caracterstica (crtico,significativo, ordinario).

Estos valores se utilizan para estimar el tamao del proyecto y decidir cmo dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en que iteracin se implementar la caracterstica.
Recopilado por: M.I Norma H. Jimnez Alor

Criterio de seleccin por presencia o La metodologa con mayor presencia en Internet. o La metodologa mejor documentada. o Metodologas certificadas y con training. o Metodologas con comunidades. o Metodologa ms utilizada por empresas. empresarial.

Presencia

Recopilado por: M.I Norma H. Jimnez Alor

Criterio de seleccin por presencia

Recopilado por: M.I Norma H. Jimnez Alor

Criterio de seleccin por conocimiento o Grado de conocimiento o Soporte orientado a objetos o Adaptable a cambios o Basado en casos de uso o Posee documentacin adecuada o Facilita la integracin entre las etapas de desarrollo o Relacin con UML o Permite desarrollo software sobre cualquier tecnologa

Recopilado por: M.I Norma H. Jimnez Alor

Criterio de seleccin por conocimiento

Recopilado por: M.I Norma H. Jimnez Alor

Qu es un modelo? o Representacin simplificada de la realidad

o Recoge solo aspectos de inters o Promueve entendimiento

o til para:
o Comprender o Describir o Predecir o Responder preguntas

o Software: es disear aplicaciones de sw antes de codificarlas

Recopilado por: M.I Norma H. Jimnez Alor

o El modelo de negocio describe los procesos asociados al negocio con el objetivo de comprenderlos. o Especifica que procesos de negocios soportar el sistema. Este modelo establece las competencias requeridas en cada proceso; sus trabajadores, sus responsabilidades y las operaciones que llevan a cabo. o A medida que los analistas modelan el negocio aprenden mucho sobre el contexto del sistema y lo describen en un modelo de negocio.

Recopilado por: M.I Norma H. Jimnez Alor

Es decir:
o Determina qu procesos formarn parte del sistema.

o Para cada operaciones

proceso:

Trabajadores,

responsabilidades,

o Se representa mediante un diagrama de casos de uso, donde cada trabajador se representa como un actor y cada proceso o necesidad como un caso de uso o Tambin se utilizan los diagramas de actividad, que permiten reflejar la secuencia concreta en que han de ocurrir los procesos.
Recopilado por: M.I Norma H. Jimnez Alor

o Glosario de trminos para el equipo. o Sirven para identificar clases en el anlisis y diseo. o Se representa mediante un diagrama de clases, donde cada clase representa un objeto relevante del contexto o El glosario de trminos recoge el resto de objetos menos relevantes. Proyectos grandes: o Considerar en el modelo, slo aquellos objetos verdaderamente relevantes (10-50 objetos) o El resto recogerlos en el glosario Proyectos pequeos: o Directamente al glosario de trminos
Recopilado por: M.I Norma H. Jimnez Alor

o Modelo de dominio: Diagrama de clases (simplificado)

o Modelo de negocio: Diagramas de casos de uso

Recopilado por: M.I Norma H. Jimnez Alor

o El proceso de validacin de requisitos comprende actividades que generalmente se realizan una vez obtenida una primera versin de la documentacin de requisitos.

Recopilado por: M.I Norma H. Jimnez Alor

o Este proceso tiene por finalidad comprobar que los requisitos del software poseen todos los atributos de calidad enunciados en breve: son consistentes, completos, precisos, realistas, verificables y definen lo que el usuario desea del producto final. La realizacin de estas actividades en este momento pretende evitar los altos costos que significara el tener que corregir una vez avanzado el desarrollo.
o La actividad de validacin tiene como entrada el documento de requisitos, los estndares relacionados y el conocimiento de la organizacin, y como salida se obtiene una lista de problemas y una lista de acciones recomendadas
Recopilado por: M.I Norma H. Jimnez Alor

La validacin se realiza a travs de diversos mtodos. Los tres mtodos ms habituales son: o Revisin de requisitos. Las revisiones de requisitos consisten en reuniones donde un equipo de analistas intenta localizar errores en el documento de especificacin.
Recopilado por: M.I Norma H. Jimnez Alor

o Prototipado. El mtodo del prototipado consiste en construir una maqueta del fututo sistema software a partir de los requisitos recogidos en la especificacin. Esta maqueta ser evaluada por el cliente y usuarios para comprobar su correccin y completitud.
o Generacin de casos de prueba (test de requisitos). Este mtodo tiene como objetivo comprobar la verificabilidad de los requisitos. Consiste en la definicin de casos de prueba que permitan verificar el cumplimiento de los requisitos funcionales.

Recopilado por: M.I Norma H. Jimnez Alor

Generalmente la solucin a los problemas de ingeniera no es nica, existiendo un abanico de soluciones posibles que satisfacen en mayor o menor medida las restricciones impuestas al problema. Asimismo, la eleccin de la solucin ms adecuada no suele ser evidente ya que, si una solucin satisface correctamente uno de los objetivos, puede que no cumpla otros completamente. Para evitar los inconvenientes derivados de una mala seleccin de soluciones, es necesario que el nmero de posibles alternativas de diseo sea lo ms grande posible y realizar una evaluacin que contemple las soluciones adoptadas desde varios aspectos, de tal manera que se tenga en cuenta, no slo que lo diseado satisfaga las necesidades fundamentales del cliente, sino tambin la economa, la ergonoma, la esttica, la flexibilidad o adaptabilidad, la optimizacin en el uso de los recursos, etc.
Recopilado por: M.I Norma H. Jimnez Alor

Recopilado por: M.I Norma H. Jimnez Alor

 http://es.scribd.com/doc/21296187/39/Captura-deRequisitos http://www.slideshare.net/juliopari/10-clase-captura-de-losrequisitos-cap16 http://www.google.com.mx/url?sa=t&rct=j&q=tipos%20de%2 0requisitos&source=web&cd=16&ved=0CFoQFjAFOAo&url=ht tp%3A%2F%2Fwww.inteco.es%2Ffile%2FTnOIvX7kM5rlBIiD4w nTxQ&ei=Y0EpUL3WJ5T5qAGa54DYCQ&usg=AFQjCNGgXV aqu147qm8qljMZhav2OXajoA&cad=rja http://kuainasi.ciens.ucv.ve/ideas07/documentos/conferencias/ conferenciajonasmontilva.pdf http://is.ls.fi.upm.es/docencia/masterTI/ARS/docs/Manual_M2 C1U11.pdf http://www.info.univangers.fr/pub/maturana/files/Modelamiento_de_Software_y_ Recopilado por: M.I Norma H. Jimnez Alor Negocios.pdf