El papel de la RACaptulo 1 hizo hincapi en la importancia de los requisitos. Fuesealaron que los clientes, gerentes y desarrolladores subestimaningeniera de requisitos. La AR se encuentra en una posicin estratgica paramejorar las prcticas en uso en los proyectos y en la organizacin.El analista puede tener un impacto positivo en el xito del proyectoy tambin facilitar los resultados de mejora de la organizacin poractuando en varios papeles. Haciendo rol contribuye explcitas de la RAa un proceso suave. El papel de la RA puede vincularsefcilmente a los objetivos de negocio, tales como el aumento de la satisfaccin del clientecon los productos de trabajo entregados; reducir el tiempo demercado de los productos; cumplimiento de los objetivos de costos, cronograma y calidad;y la utilizacin de los recursos humanos de la empresa mseficazmente. El papel de la RA necesita ser entendida y valorada enla mente de los PMs y las comunidades tcnicas (tanto la computacine ingeniera). Tabla 2.1 resume los roles deRA, tomando nota de las fases del ciclo de vida en la que cada funcin esrealizado.Roles sugeridos de la RA1. Trabajar en colaboracin con los clientes, usuarios y arquitectos de sistemasy los diseadores para identificar las necesidades reales de un sistema planificadoo esfuerzo de desarrollo de software para definir el problema que necesita serresuelto.El concepto de las necesidades reales se explic enCaptulo 1. La experiencia ha demostrado que el problema nmero unoen la ingeniera de requisitos es la falta de identificacin de lanecesidades reales antes de iniciar el desarrollo del sistemaactividades. Cualquiera que haya tenido alguna experiencia en el desarrollo desistemas o software de acuerdo en que la identificacin de las necesidades realeses un problema significativo. Con respecto a este papel, la RAdebe crear una conciencia del problema y tambin proporcionar una estrategia sugerida para superar el problema. Este es un ejemplo concreto de unasituacin que sabemos que se puede mejorar, pero ms a menudo que no actan eneste conocimiento. Estamos impacientes por empezar a trabajar en el llamado verdadero trabajo deprogramacin. Nos contentamos para permitir que el esfuerzo de desarrollo para procedersin tomar el esfuerzo adicional para evolucionar las necesidades reales. Tenga en cuenta que yohan utilizado la palabra "evolucionar". Este trabajo implica ms que la identificacinrequisitos. La tarea esencial es el uso de los requisitos indicados articuladospor los clientes y usuarios como una base, unimos esto con un conocimiento profundode los objetivos de negocio, y reiterar evolucione requisitos que cumplenlos criterios para una buena requisito y direccin priorizan las necesidades reales de lasistema o software. Actividades que participan en la realizacin de este trabajo incluyen elsiguiente:. La identificacin de las necesidades expresadas por los clientes y usuarios. esto implicala revisin de las cosas previamente escrito sobre el sistema propuesto, entrevistandoclientes y usuarios, que estudian la legislacin pertinente, y assucesivamente. El estudio de los objetivos de negocio para el esfuerzo propuesto. La colaboracin con clientes y usuarios en un entorno conjunta o cooperativapara analizar los requisitos indicados, evolucionan mejor los requisitos,y dar prioridad a ellos (ver las tcnicas sugeridas que siguen). La participacin de arquitectos de sistemas en el desarrollo de los requisitos. Iteracin laproyectos o propuestas requisitos se traducir en una arquitectura candidatocon mejores requisitos y una arquitectura ms robusta. Por ejemplo,Los sistemas deben ser capaces de acomodar las cambiantes necesidades empresariales. lala arquitectura debe ser diseado y desarrollado en consecuencia, o bien elsistema entregado pronto ser obsoleta. Utilizando una herramienta requisitos de la industria fuerza automatizado para apoyareste trabajo.La RA debe trabajar dentro de la organizacin del proyecto para ganar el apoyode la PM en la obtencin de compromiso de invertir tiempo y esfuerzo aadido aevolucionando las necesidades reales. Aqu hay una gran oportunidad para la RA para tomarresponsabilidad y, basndose en la experiencia de la industria, convencer proyectogestin y desarrolladores a invertir ms tiempo y esfuerzo en los requisitosproceso. Afortunadamente, los datos estn disponibles para ayudarnos a manejar por hechoms que por la intuicin o la forma en la que siempre hemos hecho las cosas. Referirse aRequisitos eficaces Prcticas [1, p. 62] para estos datos.Considere el uso de los requisitos de colaboracin tcnicas de obtencin de quetrabajar bien en sesiones de grupo. Ejemplos de buenas obtencin de requisitostcnicas son talleres requisitos, groupware basada en electrnica oherramientas de desarrollo de colaboracin electrnicos, diagramas de flujo de datos de alto nivel,alto nivel diagramas IDEF0 (especialmente para el modelado de negocios), y de alto niveldiagramas de casos de uso (especialmente para distinguir los requisitos que sonRoles sugeridos de la RA 17fuera del sistema en comparacin con el comportamiento esperado del sistema). Todos estostrabajar bien en una pizarra, son fciles de entender, y permitir a todospresentes a participar. Ver Dean Leffingwell y Software Gestin de Don WidrigRequisitos: Un enfoque unificado [2] para buenas discusiones de estos yotras tcnicas y la forma de utilizarlos. David Hay proporciona una comparacin tilde las tcnicas que se pueden utilizar en Anlisis Requisitos: De NegocioVistas a la arquitectura (ver [3, p. 194] y la discusin anterior).2. Trabajar de manera efectiva con los clientes y los usuarios gestionar los requisitos nuevos y modificadospara que el proyecto se mantiene bajo control. Instalar un mecanismo de controlcambios.El siguiente problema ms grave de la ingeniera de requisitos (despus del fracasopara identificar las necesidades reales) es la falta de control requisitos queson identificados despus del desarrollo del sistema (programacin) comienza, tanto nuevosrequisitos y modificacin de los existentes. Aqu distinguimosentre los requisitos crticos (los que tendra un impacto en el precio,horario, o el esfuerzo de desarrollo si cambi) y los requisitos no crticos,tal como un requisito derivado que define an ms el sistema siendoconstruido, sino que sirve para aclarar un requisito de nivel superior y no afectacosto, horario, o la funcionalidad. Todos los interesados deberan recibir un "noimpact"requisito de que aclara an ms el sistema.Una vez ms, tenemos los datos de experiencia en la industria para guiar nuestras acciones:un cambio en los requisitos de 20% dar lugar a una duplicacin de proyectoDesarrollocostes [4]. Por lo tanto, es fundamental que un mecanismo puede poner enlugar para evaluar y adjudicar cambios en los requisitos. Sin una efectivamecanismo para el control de cambios en los requisitos, el proyecto estar prontofuera de control en cuanto a horario y costo. Hay varias cosas que se deben hacer: La importancia de los cambios que controlan a los requisitos debe serexplic a los clientes, usuarios y desarrolladores para que la asociacinse mantiene compromiso con el xito del proyecto. Los desarrolladores deben ser entrenados para no aceptar los requisitos no autorizadascambios. Todas las solicitudes de cambios, no importa lo trivial, deben ser canalizadosa travs del mecanismo de control de cambio. El mecanismo de control de cambios debe ser un equipo conjunto que incluyetomadores de decisiones empoderadas que representan el cliente y el desarrollador.El equipo conjunto debe cumplir con la frecuencia suficiente para tener una razonablenmero de solicitudes de cambio a tener en cuenta. Una mtrica objetivo del 0,5%Se recomienda requisitos volatilidad para guiar las decisiones tomadas por elequipo conjunto una vez que se ha establecido una lnea de base de los requisitos validados.1 "Whoa," usted dice, "que no es mucho!" Muy bien! Este es otro El mecanismo de control de cambios debe ser un equipo conjunto que incluyetomadores de decisiones empoderadas que representan el cliente y el desarrollador.El equipo conjunto debe cumplir con la frecuencia suficiente para tener una razonablenmero de solicitudes de cambio a tener en cuenta. Una mtrica objetivo del 0,5%Se recomienda requisitos volatilidad para guiar las decisiones tomadas por elequipo conjunto una vez que se ha establecido una lnea de base de los requisitos validados.1 "Whoa," usted dice, "que no es mucho!" Muy bien! Esto se another.reason invertir el tiempo necesario para desarrollar las necesidades reales antesde iniciar las actividades de desarrollo. La asociacin con su cliente, evolucionando formas de lidiar con el cambio. Nosotrosconocer el mundo est cambiando mientras estamos desarrollando el sistema. Quson algunas maneras de lidiar con este sin poner en peligro el xito del proyecto?Considere el uso de versiones, versiones y actualizaciones. Incrementos del paquete deRequisitos actualizaciones y cambios en las emisiones o el sistema posterioresactualizaciones. Asegrese de que el contrato prev el tiempo y el presupuesto adicionalpara todos los cambios. Este es un mecanismo para mantener buenas relacionesa lo largo del contrato de trabajo a asociarse para el xito. Costo Cambiostiempo y dinero. Esto debe ser reconocido en la delantera y se refleja enel contrato.3. Est alerta a las nuevas tecnologas que pueden ayudar.Un papel que a menudo infrautilizada est asesorando a nuestros clientes en relacin conLa tecnologa evoluciona. Si bien esto no es responsabilidad exclusiva de laRequisitos de los analistas o ingenieros, muchos involucrados en el desarrollo de sistemaspara los clientes haran bien para pasar el tiempo y el esfuerzo adicionalaprender sobre nuevas tecnologas y la forma en que se pueden aplicar a nuestro trabajo.Los clientes se centran normalmente en lo que el sistema debe hacer. Podemosservirles mejor por estar familiarizados con las tecnologas en evolucin que mejorancmo el sistema est diseado necesaria. Esto sugiere que los RA se beneficiar deque tienen los diseadores de sistemas revisen sus productos de trabajo. Simultneamente conrequisitos de elaboracin, implica un pequeo equipo de diseadores para revisar lanecesidades reales de los impactos de costos, calendario, tecnologa y riesgo. Uso comercialproceso de los estudios de la Resolucin de Anlisis de Decisiones (DAR) en CMMI terminologa-evolucionando alternativas. Mantenga el cliente involucrado en estas actividades,de manera que cuando se presente la oportunidad, el cliente est ah para asociarse conque en la formulacin de recomendaciones para las decisiones. Una excelente referencia quedescribe el proceso de utilizacin de las nuevas tecnologas es la difusin de Everett M. Rogersde Innovaciones (4 ed.) [5].4. Facilitar la reutilizacin del proyecto de artefactos y repetibilidad lograr.Ha habido mucha discusin en la literatura de la industria acerca de la reutilizacin.Reciclar tiene dos significados: (1) para tomar objeto X (por ejemplo, un objeto, subrutina, oSoftware COTS) que fue hecho por Y y usarlo directamente en otro proyecto,y (2) para tailor2 un producto de trabajo desarrollado (una especificacin, un plan, oproceso, por ejemplo). Muchas organizaciones han invertido en las estrategias de reutilizacinslo para concluir que no son viables o prctico. Otros se resisten a la reutilizacin porque creen que se opone a las soluciones sin precedentes e incorporalos errores de los productos de trabajo reutilizados.Podemos considerar mismos requisitos que los artefactos reutilizables. Los libros quediscutir patrones de requisitos reutilizables incluyen Patrones Modelo de datos: Conveniosdel pensamiento [6] (para un punto de vista relacional) por David C. Hay, Patrones de Anlisis(Para un punto de vista orientado a objetos) de Martin Fowler [7], y patrones de diseopor Eric Gamma, et al. [8]. Marcos de problemas de Michael Jackson (descritos en sulibro del mismo nombre [9]) son en esencia muy abstractos requisitos patronesque se puede conectar, jerarquizado, y construyeron en los modelos del mundo real. Lael punto es que muchos de los requisitos no son nicos; que ya han sidoidentificado en el medio ambiente y el problema de espacio de otra persona.He encontrado en mis actividades de escritura que comienzan con una obra de ejemploproducto me da ideas sobre el formato, la estructura, el contenido y los recursos areferencia o contacto. Un producto de ejemplo el trabajo es posible que desee considerares un plan de necesidades. Como se destaca en el captulo 1, yo abogo por el desarrollode un plan de necesidades para cualquier esfuerzo de desarrollo del sistema o software.Esta idea puede ser nuevo para usted, y sera muy til e instructivoopinin desarrollada previamente con el fin de tener en cuenta su valor potencial paratu trabajo. Otro ejemplo de mi experiencia est documentada la reutilizacinprocesos. Si la organizacin u otro proyecto tiene un proceso documentadopor hacer algo, por qu no adaptar segn sea necesario y luego volver a utilizarlo, en lugarde crear el propio proceso? Otros que han realizado el proceso dela prctica han incorporado su experiencia y las lecciones que tienenaprendido a usarlo. Relacionado con esto est el valor de los exmenes por homlogos. Abogo por unarevisin por pares de cada producto de trabajo. (La extensin de la revisin por pares, lanmero de personas que solicit revisar el producto del trabajo y el tiempoinvertido para realizar la revisin por pares e informar sobre los defectos y hacer sugerencias-es una funcin de la importancia del producto de trabajo). Si uno puede reutilizarel proceso de revisin por pares y listas de control de otra organizacin, esto proporcionaun salto de inicio en conseguir el proceso diseado, aceptado, desplegado, implementado,e institucionalizado.Un ejemplo de reutilizacin de procesosAl ensear requisitos cursos y tutoriales, siempre estoy interesado enConoce cmo muchos de los participantes estn utilizando un requisitos documentadosproceso en su proyecto o en su organizacin. Por lo general, esto resultaser 15% a 20% de los participantes. Se proporciona un procedimiento requisitos de la muestraRequisitos en Prcticas Efectivas [1, pp. 110-118]. Este proceso tieneha adaptado, desplegado, e implementado en ms de 50 proyectos. Suintegracin con el proceso de la arquitectura del sistema se describe ms adelante en ellibro [1, pp. 136-146].Sugerencia: Sastre este proceso requerimientos de la muestra para su proyecto oorganizacin. Involucrar a las partes interesadas a hacer los cambios que mejor sirvensus necesidades. Proporcionar ambos diagramas de flujo y PD narrativas como se describe en EfectivoRequisitos Prcticas. Actualizar peridicamente el proceso documentado conideas de mejora continua y sugerencias.5. Ayudar al proyecto y sus clientes en la aspiracin a un camino de crecimiento desde el primer lanzamientoo la versin de un producto a travs de una serie de lanzamientos en escena al sistema finalo producto.Esta funcin est relacionada con la funcin 3. La AR puede servir a una importante y valiosapapel en ayudar a los clientes a imaginar y desarrollar una serie de lanzamientos o versionesde productos. Este enfoque es particularmente apropiado en la situacinen la que los requisitos no se entienden bien desde el principio o los requisitosestn cambiando rpidamente. Esto sugiere que un "desarrollo incrementalenfoque "se debe utilizar, en que el sistema completo se implementa a travs de unaperodo de tiempo a travs de incrementos de funcionalidad entregada. En un sentido, sinsistema est hecho nunca, as que tenemos que ayudar a todos a ver el desarrollo del sistemacomo un viaje. Independientemente de la metodologa de desarrollo de sistema utilizado(Cascada, incremental espiral, evolutivo, etc.), no tiene que ser una previamente convenidasproceso para gestionar los cambios y determinar el alcance de individuoproyectos. No importa lo mucho debate y prueba que se hace, hayalgunos requisitos faltantes que no se descubrieron hasta que el sistema se encuentra enproduccin.6. Asesorar al proyecto (y cliente) de mtodos, tcnicas y herramientas automatizadasque estn disponibles para los mejores requisitos-relacionados de apoyo de trabajo y actividades del proyecto.Este es un papel importante. La experiencia ha demostrado que los mtodos y tcnicasvaran en su aplicabilidad y eficacia y que a menudo automatizadosherramientas adquiridas por los proyectos y las organizaciones no son utilizados o estn subutilizados.Captulo 11 de las Prcticas Requisitos eficaces [1] informa sobre la industriaexperiencia y ofrece una serie de recomendaciones. Captulo 8 de EfectivoPrcticas Requisitos [1] recomienda que los mtodos y tcnicas queson utilizados por un proyecto sea familiar para los participantes del proyecto y comprobada ensu respectiva industria. No es aconsejable llevar a cabo un proyecto con, mtodos inhabituales no probadas y tcnicas. El trabajo de desarrollo eslo suficientemente difcil sin introducir la complejidad de los mtodos otcnicas que no son familiares y no han sido utilizados con xito en anterioresproyectos de la organizacin. A nivel de proyecto, el equipo debe pegarsecon las herramientas, los procesos y las tcnicas con las que sus miembros estn familiarizados.A nivel organizativo, el proyecto debe tratar de usar las herramientas,procesos y tcnicas que son conocidos y probados en la organizacin.Cuando los contratistas se ponen en un esfuerzo existente, deben adaptarse alas herramientas que el cliente ya tiene en su lugar (suponiendo que estn trabajandoefectivamente). Si se realizaron los ltimos cinco proyectos con la herramienta X, y todo el mundo essatisfecho con la utilidad de la herramienta, y luego cuando llegas, haybuenas razones para usarlo. Tenga en cuenta que un problema de recursos pueden estar involucrados. Idealmente,un RA sera un recurso apalancada, al pasar de un proyecto a otro ytomando su experiencia con ella. Sin embargo, a menudo en la prctica, un equipo de proyecto esconstruido (o ya existe) y alguien del equipo actual con el dominioel conocimiento tiene la tarea de ser el RA. Mientras que las tcnicas probados y verdaderosy existen herramientas, que pueden no estar familiarizados con esta persona, lo que requiere un largoy, a veces curva de aprendizaje doloroso, con desventajas significativas al proyecto. Esto aboga por la organizacin para proporcionar un conjunto de asociaciones regionales con experienciaque proporcionar un alto retorno de la inversin realizada para identificarlos,entrenarlos y darles experiencia.Tambin recomiendo las direcciones de los clientes difciles de utilizar mtodos especficoso tcnicas que no estn familiarizados con el equipo del proyecto o no previamentedemostrado en la prctica. Por ejemplo, un cliente puede ordenar que una a objetosSer empleado (OO) enfoque de desarrollo (ver [10] para pensativadirectrices sobre este tema) o que una herramienta o instrumento privado automatizado particular, seautilizado. Es valioso para estar en condiciones de poder asesorar a su proyecto ysu cliente de los mtodos, tcnicas y herramientas automatizadas que lo harmejor soportan la situacin especfica de desarrollo. Dibuje en la experiencia de la industriay no pretender que "todo saldr bien."7. Utilice las mtricas para medir, rastrear y relacionados requisitos de control de las actividades de trabajo del proyectoy resultados.La literatura de la industria en relacin con las mtricas es enorme. Yo estimara que tal vez20% de los que proporciona consejo til. Es fcil entrar en una situacin de llevar a caboactividades de medicin para su propio bien, en lugar de ayudar aevaluar el trabajo del proyecto y tomar las acciones correctivas. Recomiendo el uso de unos pocosmtricas tiles. He desarrollado el siguiente axioma en mi trabajo sobre elao:Las cosas que se miden y rastreado y que la administracin presta atencinque son los que mejoran.Esto sugiere que no es suficiente para tener unos pocos tiles mtricas quedeben ser seguidos, y deben ser utilizados por la direccin para guiar proyectodecisiones.Hay un conjunto de medidas o indicadores que deben ser utilizados por todos los proyectos.Ver Requisitos Prcticas Efectivas [1, pp. 255-261] para sugerencias especficas.Hay otro nivel de sofisticacin que se debe utilizar por maduraproyectos y organizaciones. Tal como se utiliza aqu, "maduro" significa que los procesosse han definido, documentado, implementado, usado, institucionalizada, ymejorado continuamente durante un perodo de al menos dos a cuatro aos. Esteimplica la gestin cuantitativa (QM) de costos, plazos, calidad ymtricas de procesos y lneas de base en apoyo de los objetivos de negocio especficos. Escumpliendo para ver los proyectos y las organizaciones pasar de la situacin en la queQM no se entiende bien a uno en el que QM se utiliza efectivamente para lograrobjetivos de negocios. Esto es especialmente satisfactorio para procesar los ingenieros, porquelos ejecutivos pueden conocer de primera mano el valor de la mejora de procesos en la reuninlas necesidades del negocio.8. Ser capaz de facilitar el debate y para mediar en los conflictos.Este papel subraya los "don de gentes" de la RA. Hemos aprendido que estar biencualificado tcnicamente es importante, pero que tambin es necesario tener fuertes as refinados habilidades, gente. La experiencia ha demostrado que dos cabezas piensan mejorde uno-cuando nos tomamos el tiempo para explorar ideas y enfoques conotros, consiguen incluso mejores ideas y enfoques! Ergo, podemos caer elpunto de vista que "sabe mejor". Y podemos hacer un gran uso de este principioal convertirse en buenos facilitadores y mediadores. Hay cursos disponiblespara ayudar (por ejemplo, la negociacin de habilidades, formacin de equipos, comunicaciones,relaciones y liderazgo). Mucho se puede ganar mediante la prctica de estas habilidades ennuestro trabajo diario. Tener una perspectiva de "ganar-ganar" es til, de hecho, BarryBoehm et al. han desarrollado un desarrollo requisitos de ganar-ganarenfoque en el trabajo realizado en la Universidad del Sur de California. Verhttp://sunset.usc.edu/research/WINWIN/winwin_main.html.9. Estudiar el dominio de la zona en la que se est utilizando el sistema o software.Ser capaz de comprender, abstracto, y expresar ideas de forma rpida en el idioma de los usuarios. Sila RA no entiende el dominio de usuario casi tan bien como los que hacen los usuarios,corre el riesgo de limitar su papel al de un tomador de pedidos. He visto diferentesgrupos van y vienen cuya especialidad era la comunicacin, la creacin de consenso,etcetera. Poblar esos grupos fue un conjunto de personas que se encontrabanfacilitadores capacitados, pero que no eran tcnicamente competente. Se movieronde proyecto a proyecto con tanta frecuencia que nunca lograron ningn profundacomprensin dominio. Por ejemplo, qu pasara si, en una red de comunicacionesproyecto, la nica manera de un RA puede explicar cualquier concepto a los usuarios es pordando analogas con la construccin de aviones militares? Respuesta: reduccin de la eficaciay credibilidad.ResumenLa RA realiza varias funciones importantes en un proyecto y en una organizacin.Nueve papeles importantes fueron identificados y descritos en este captulo. Lados primeros son de suma importancia y esencial para el xito del proyecto. Por consiguiente, el estudioestos, se vuelven competentes en ellos, y ayudar a su proyecto y la organizacin enla adopcin, implementacin e institucionalizacin de las prcticas relacionadas. Organizacionesdebera considerar la adopcin de medidas concretas para desarrollar y aprovechar sus asociaciones regionales,tales como (1) la garanta de que los RA experimentados son asignados a cada proyecto; (2)impartir formacin adecuada a las asociaciones regionales; (3) la asignacin de los RA experimentados amentor de los nuevos empleados, RA junior, y pasantes; y (4) que tiene una organizacinrequisitos de grupo de trabajo para compartir conocimientos y proporcionar unrecursos a la organizacin. La RA debe ser un capacitado, con experiencia, ybuen desempeo. Por desgracia, he visto muchos casos en que la nuevaempleado o el pasante de verano se despachan "para obtener los requisitos." Elpapel de la RA necesita ser entendida y valorada en la mente de los PM yla comunidad tcnica. En este punto, usted puede sentirse abrumado consus responsabilidades, como sugiere la Figura 2.1. Tenga la seguridad de que con el estudio yexperiencia, le proporcionar una contribucin muy positiva a los esfuerzos queApoya usted!