Pagina 50 Storyboarding

Storyboard es otra tcnica que puede ser til para conseguir que la gente hable sobre sus deseos y expectativas. Esto implica tener uno de los miembros del equipo de crear un conjunto de escenarios o guiones grficos , que describe las posibles formas en que la informacin de gestin de configuracin se podra recopilar , utilizar , inform , o algn otro aspecto . Por ejemplo , es posible preparar un guin grfico que describe un caso tpico cambio en su organizacin. El esquema general del guin grfico podra tener este aspecto : 1 . Un cambio es propuesto por el administrador del servidor para agregar memoria a la CashFlow servidor. 2 . El cambio se enva al equipo de arquitectura , que se evala contra las normas que se encuentran en la CMDB . 3 . El equipo de arquitectura aprueba la tecnologa detrs de los cambios y reenva el registrar a la aprobacin del Directorio Cambio ( CAB ) para la direccin del negocio . 4 . El CAB comprueba en la CMDB para otros servidores que ya tienen capacidad adicional. Encontrar uno , se preguntan si CashPro podra ser trasladado a un servidor diferente . 5 . El administrador del servidor verifica la configuracin del otro servidor y detecta que ste no tiene suficiente memoria . 6 . El CAB aprueba el cambio propuesto. Storyboards no tienen que describir en detalle los procedimientos existentes e ncluso los nuevos procedimientos. Simplemente tienen que cubrir lo suficientemente baja para que puedan generar una conversacin acerca de los requisitos . Este tipo de enfoque de " hombre de paja ", a menudo ayuda a las personas explican sus propias expectativas con ms claridad que una simple discusin. La experiencia demuestra que la gente critica ms fcilmente un concepto existente que crear un concepto totalmente nuevo. Despus de los guiones grficos estn en su lugar , puede enviarlos alrededor de email para la discusin o se utilicen como base para las sesiones de tipo

seminario . Independientemente del formato , es importante que todos sepan que su propsito no es hacer que el guin perfecto, sino generar debate y capturar los requisitos para el proyecto de gestin de la configuracin . Puede utilizar la tendencia a querer mejorar los guiones grficos , sin embargo , por la evolucin natural de los storyboards primas al formato ms refinada de casos de uso.

Entrevistas En algunos casos, uno o ms de los principales lderes de la organizacin podran intimidar a los dems en un formato de taller. En lugar de recurrir a un taller en una entrevista con un orador principal y muchos espectadores, a veces es mejor programar entrevistas individuales a personas cuya situacin y personalidad hacen de este un mejor enfoque. Entrevistas directas tambin pueden ser tiles cuando las principales partes interesadas estn demasiado ocupados para asistir a un taller o comentario sobre un paquete de storyboards. La entrevista tiene no menos preparacin que el taller y debe cubrir muchos de los mismos temas. Al utilizar las entrevistas junto con talleres , siempre incluya los resultados del taller como parte de la agenda de las entrevistas. Las ideas generadas por los muchos podran provocar los pensamientos de la persona entrevistada y dar lugar a discusiones ms productivas. Desafortunadamente , debido a que la entrevista tiene slo una persona la generacin de ideas , es probable que proporcione menos cantidad de requisitos de un taller . Por otro lado , porque es probable que sea en una posicin de liderazgo ms alto es el entrevistado , los requisitos probablemente sern ms importantes que los generados en un taller de grupo. La desventaja de las entrevistas es que la comunicacin de los resultados no es tan fcil como aquellos para los talleres . Despus de un taller, todos los participantes conozcan los resultados mmediately y muy probablemente comenzarn a hablar de ellos con sus compaeros y su equipo de direccin. Despus de una entrevista , slo tiene un conjunto de notas y la necesidad de trabajar duro para conseguir las ideas generadas a otros. Es muy posible que una sola idea oye slo en una entrevista que no representa los deseos de la organizacin en absoluto. De hecho, muchas veces he tenido ideas de una entrevista directa contradiccin con las ideas de otra entrevista . En este caso, es an ms importante para conseguir los billetes para su revisin para determinar qu ideas deben convertirse en necesidades legtimas . Si usted utiliza un taller, una exposicin itinerante , storyboards o entrevistas individuales , una de las tcnicas ms importantes en los requisitos solicitando es para recorrer de nuevo y asegrese de que ha capturado con precisin y

completamente lo que has odo . Ciertamente, se trata de la documentacin de los requisitos ( ms sobre esto en un momento) , pero lo ms importante consiste en la revisin de los documentos con las fuentes originales. No hay nada tan gratificante como ser comprendido. Con precisin la captura y reproduccin de los requisitos que oyes que recorrer un largo camino hacia la construccin de su base de apoyo entre las partes interesadas. Por otro lado , no hay nada tan alienante como siendo malinterpretado y se fue sintiendo mal entendido . Siempre tome tiempo para poner los requisitos por escrito y validar que los captur con precisin. Como documento de requisitos A primera vista, podra parecer de la discusin anterior que los requisitos son simplemente notas de reuniones. He dejado la impresin de que al escuchar a un montn de conversaciones y mantener notas detalladas, se ha creado un conjunto viable de requisitos. Ahora es el momento de corregir esa idea errnea. Para ser realmente til y servicial, los requisitos deben ser documentados con ms cuidado que al igual que un conjunto de notas. En esta seccin se describen algunas de las mejores prcticas en los requisitos de documentacin y le ayuda a pasar de notas a una serie de requisitos especficos en los que se puede construir un proyecto. Niveles y Categoras Una simple lista de requisitos, empezando por el primero que se escucha y terminando con el ltimo que alguien pide, es probablemente la forma ms eficiente para documentar sus requisitos. Usted necesita una manera de organizar la informacin que ser til en la gestin de los requisitos ms tarde. La mayora de los sistemas de Requisitos de la caracterstica, al menos, una idea de los niveles y una idea de categoras. Los niveles indican el grado de especificidad de un requisito , y las categoras se utilizan para requisitos del grupo a lo largo de lneas arquitectnicas . Las siguientes secciones tratan con los niveles de exigencia y categoras. Nivel indica el grado de generalidad o especificidad de un requisito . Los requisitos de negocio normalmente se encuentran en el nivel ms alto y necesita expresar general acerca de cules son las funciones de la empresa de gestin de la configuracin ser. A requerimiento de negocio podra decir " Cada actualizacin de la CMDB debe realizarse de conformidad con una solicitud especfica de cambio. " Esto es en general de varias maneras : define una declaracin de poltica , deja el concepto de " trazabilidad " abiertos a una definicin ms precisa , y permite muchas implementaciones diferentes a travs de cualquiera de los procesos o herramientas . Este concepto de los requisitos de nivel de negocio genera mucha confusin porque parece violar la regla anterior

que los requisitos deben ser claros . En realidad, sin embargo , hay una diferencia entre un requisito de que es general y uno que es ambigua . Un requisito ambiguo puede ser interpretado de diferentes maneras especficas , mientras que un requisito general no da detalles , pero tampoco sugiere mltiples interpretaciones. La distincin no es tan importante en la prctica debido a los requisitos de negocio siempre se hacen ms especfica por los requisitos de los niveles inferiores . El siguiente nivel de necesidades es normalmente el nivel "sistema" , donde la mayora de la general detalles de la totalidad del proyecto de gestin de configuracin se definen . Estos requisitos deben ser ms especficos que los requisitos de negocio y necesariamente sern ms numerosos. Requisitos del sistema normalmente se definen a un nivel de detalle que permite al equipo de implementacin para cumplir con ellos de alguna manera verificable . Agregando al ejemplo anterior , esto es un requisito del sistema que estar a un nivel ms bajo que el requisito de negocio : "Cuando un usuario intenta actualizar un elemento de configuracin desde la pantalla de actualizacin , el sistema leer el valor del campo de RFC . Si el valor no es vlido en la tabla systemRFC , el sistema responder con un mensaje que indica que las actualizaciones no estn permitidos sin RFC vlido. " Este requisito es claramente en un nivel inferior de detalle que el requisito de negocio que dio lugar a ella, sino que tambin es un resultado directo de algo que el requisito de negocio pide . Es importante que los requisitos en un nivel ms bajo sea directamente atribuible a los requisitos de nivel superior. En la documentacin de los requisitos del sistema , puede decidir que una o ms piezas del deben definirse en un nivel an ms bajo de detalle de la arquitectura en general. Esto puede llevar a un tercer nivel de exigencias , a menudo llamados requisitos de los componentes . No todos los proyectos tendr requisitos de los componentes , e incluso cuando usted elige utilizar requisitos de los componentes , no todos los componentes se requieran. Requisitos de los componentes son a menudo tiles para los componentes que debe interactuar con la gente o herramientas externas de su equipo de gestin de la configuracin . Las interfaces de usuario y puntos de integracin de herramientas externas son ejemplos de situaciones que con frecuencia requieren requisitos de nivel de componentes. Ahora que entendemos los niveles de exigencia , las categoras son mucho ms simples . Cuando se habla de las necesidades , la mejor prctica es dividir las categoras a lo largo de lneas arquitectnicas . Si su proyecto implica la construccin de una solucin completa de gestin de la configuracin de la nada, sus categoras arquitectnicos podran incluir los requisitos del proceso , los requisitos de la herramienta , los requisitos de la organizacin y las necesidades

de datos . Si , por el contrario , su trabajo es el desarrollo de la prxima versin de un herramienta de gestin de la configuracin, las categoras podra ser la interfaz de usuario, bases de datos, interfaces externas e informes. Lo esencial es que se define un conjunto de categoras que tengan sentido para todos los que trabajan en el proyecto. Despus de que los requisitos estn organizados por categoras, el plan de ejecucin del proyecto, el ciclo de prueba, e incluso el despliegue se pueden organizar en la misma lnea. Este tipo de proyecto de arquitectura orientada ayuda a garantizar que no se pierdan las tareas y todos los requisitos se cumplan plenamente, probar y desplegar.

Tcnicas de Documentacin Hay un par de requisitos de uso de tcnicas especiales de documentacin, que merecen una atencin especial. El primero se llama casos de uso. Los casos de uso son esencialmente descripciones secuenciales de cmo se supone que algo funcione. Describen cmo una persona o una herramienta (llamada actor) se refiere a lo que se est construyendo. Los casos de uso son especialmente buenos para la descripcin de los requisitos de transaccin, o workfloworiented porque ayudan a todos a entender el flujo y la secuencia ms que una simple lista de requisitos del sistema o componente. Muchos volmenes se han escrito sobre el uso de la tcnica de casos de uso en los requisitos de documentacin, pero los pasos bsicos son bastante simples: 1. Documento que el actor es. 2. Describir el conjunto normal o tpica de pasos que ocurren en orden. 3. Piense en cualquier desviacin de los pasos normales, y documentar esos caminos. 4. Volver atrs y profundizar en el caso de uso con el texto suficiente para que sea un conjunto requisito de utilidad. La otra tcnica especial que se puede utilizar para los requisitos de documentos es un prototipo. Especialmente en el caso de la definicin de las pginas web u otros elementos de la interfaz de usuario de las herramientas de configuracin, a menudo se puede comenzar con un prototipo de "baja fidelidad", que no es ms que unas pocas diapositivas poner juntos en una presentacin. Cuando el equipo del proyecto cuenta con las habilidades, se puede ir ms all de un prototipo de "alta fidelidad", de hecho el uso de herramientas de prototipado rpido. El proceso de construccin de un prototipo, obtener retroalimentacin, modificar el prototipo, y repetir hasta que se cumplan todas las partes interesadas es una gran manera de

documentar exactamente lo que se supone que la interfaz para que parezca. En este caso, lo que realmente es cierto que la imagen vale ms que mil palabras. Al detener la recopilacin de requisitos Todo esto se centran en la recopilacin de requisitos puede hacer que parezca que nunca se va a aplicar en la prctica la gestin de configuracin. En realidad, el proceso requisito puede tomar varias semanas a varios meses, dependiendo de la madurez de pensamiento en torno a la gestin de configuracin en su empresa. Si los interesados sepan de gestin de la configuracin y entender lo que el proyecto debe cumplir, en principio, se llega a la final de los requisitos de forma relativamente rpida. Probablemente ya saben lo que quieren, y tu misin ser simplemente para capturar en papel y pasar a la fase de anlisis. En algunos casos, sin embargo, el proceso de recopilacin de requisitos debe ser combinado con un proceso de educacin. En esta situacin, la mejor cosa que puedes hacer es reunir expertos lo tienes que ayudar a preparar todo. Talleres, sesiones de storyboard, y entrevistas que lleve a cabo tendr que ser mucho ms bsico para empezar. En algunos casos puede que tenga que tener una sesin inicial para establecer el tema en la mente de la gente, y luego una sesin de seguimiento donde se puede reunir los requisitos . En las preguntas que usted y las categoras que usted elija, usted le est enseando a la organizacin a tener un vocabulario comn y una idea coherente de lo que la gestin de configuracin es y hace . Si ese es tu caso, no tenga miedo de dejar que los requisitos de recopilacin de fase se prolongan durante varios meses. Pero , cmo saber cuando haya terminado con los requisitos ? Esto es en realidad un lugar difcil cuestin . La respuesta ms simple es que cuando se ha preguntado a todos los que se pueda imaginar , y ninguno de ellos tiene nuevas ideas , que haya terminado de conseguir los requisitos . Pero todos sabemos que alguien que se qued sin ideas de ayer podra pensar en algo nuevo maana . Los requisitos no puede ser un proceso sin lmites. Si los requisitos de recopilacin de fase dura demasiado tiempo, los interesados tendrn la impresin de que su proyecto va a tomar mucho tiempo para devolver un valor significativo , e incluso pueden decidir que hay mayor prioridad que la recogida de requisitos sin fin. Por otro lado, si usted corta los requisitos de recoleccin antes de tiempo , se corre el riesgo de que las partes interesadas importantes sentir su voz no fue escuchada y retener as el apoyo del proyecto . Un delicado equilibrio est claramente necesario. La mejor prctica es reunir los requisitos por nivel , y cada nivel de madurez adecuado .

Esto significa que por primera vez se renen los requisitos de negocio y firmemente se niega a hablar de los detalles de bajo nivel hasta que todo el mundo cree que se han agotado todos los requisitos generales. Asegrese de incluir el informe, la administracin de las herramientas , fuentes de datos , los procedimientos , los roles organizacionales , y todo lo que se menciona en este libro para cubrir toda la costa. Cuando ests convencido de que usted ha alcanzado la amplitud de la cobertura y ha documentado los requerimientos del negocio, va a travs de algunos comentarios . En primer lugar, revisar con el equipo del proyecto y ver si algn surgen nuevas ideas . A continuacin, revise con sus patrocinadores - los proyectos de las personas que financian el proyecto y la toma de decisiones clave sobre si se debe seguir adelante. Por ltimo , revise la lista ms amplia posible de partes interesadas y afectadas . En cada etapa de la revisin, buscar nuevos requisitos. Este no es el momento de cambiar la redaccin o la redefinicin de la actual los requisitos - que viene en la fase de anlisis . En el momento en que haya concluido esos tres exmenes , usted debe tener un conjunto bastante madura de los requerimientos del negocio y todo el mundo estar ms que listo para cavar en un nivel inferior . A continuacin, defina la categora de requisitos del sistema por categoras. Decida en este momento si usted necesita requisitos de los componentes o no, pero no empezar a definir ellos hasta que haya terminado con todos los requisitos que se aplican a nivel de sistema . Una vez ms, ir a travs de una serie de revisiones , aunque las opiniones que tenga que ser dividido en varias reuniones para dar cabida al mayor nmero de requisitos previstos en este nivel. Los requisitos de nivel inferior dictarn que ms personas de los equipos de implementacin estn involucrados para entender realmente si los requisitos son lo suficientemente ambigua para ser implementada directamente . El proceso de revisin permite que los requisitos del sistema madura , y al hacerlo , las personas deciden que no tienen requisitos adicionales a nivel de sistema que desea aadir. Repita el proceso para cada nuevo conjunto de requisitos de los componentes que desea definir . Con el tiempo te da la sensacin de un slido conjunto completo de requisitos. Admito que es ms arte que ciencia , pero lo hace ms fcil con la prctica. La recopilacin y documentacin de requisitos es muy parecido a hacer palomitas en el microondas. Usted comienza simplemente con la creacin de las cosas. Muy pronto, las cosas estn apareciendo a lo largo muy bien, y antes de que te des cuenta requisitos estn surgiendo en todas partes. Pero despus de un poco, el ritmo se ralentiza y no muchos de los nuevos requisitos estn apareciendo. Con suficiente experiencia, usted aprender a dejar las ltimas ideas de madurez sin tener que esperar demasiado tiempo y quemar las palomitas de maz.

Analizando Enhorabuena! Por ahora usted es el orgulloso propietario de al menos un par articulados, documentos de requisitos bien escritos. Eso es un gran trabajo. El siguiente paso es convertir esos requisitos documentados en una organizacin de gestin de configuracin en ejecucin un proceso de gestin de la configuracin para recoger y gestionar los datos de gestin de configuracin. La mejor manera de hacerlo es pasar algn tiempo en el anlisis de requisitos. El anlisis puede evocar una imagen de interminables estudios llevados a cabo por un sinnmero de comisiones. Eso no es en absoluto lo que se pretende aqu. El anlisis de requerimientos es simplemente el acto de decidir el orden correcto de las cosas de aproximacin y romper grandes esfuerzos en proyectos ms pequeos para demostrar pequeos pasos hacia el objetivo general. Esta seccin describe varias tcnicas que le permitirn entender con claridad cmo construir un servicio de gestin de configuracin que funcione correctamente, ya sea en un solo proyecto o como parte de un programa de varios aos. Requisitos Priorizacin Cuando los requisitos de documentacin, tienden a terminar con las listas de funciones individuales que tienen diferentes grados de importancia para la organizacin. Lo primero que quiero hacer es organizar a los requisitos de importancia. Esto se conoce como requerimientos de prioridades, y es la primera etapa del anlisis. Para asignar diferentes prioridades a los requisitos, es necesario definir lo que los valores pueden ser diferentes. A algunos les gusta usar ", bajo", "medio" y "alto". Otros optan por "aplazado", "opcional" y "necesaria", o quizs "posible", "importante", "crtico" y "vital. "las etiquetas que usted elija para su uso no son tan importantes como las polticas que sustentan el uso de esas etiquetas. Si se trata de un nuevo paso para usted, y usted no puede encontrar los requisitos que se han priorizado en su organizacin antes, hacer un favor a todos y tener tiempo para documentar la poltica en torno a la eleccin de las diferentes prioridades. Suena trivial, pero tener una forma coherente de decidir entre una alta prioridad y una prioridad media, guardar su proyecto y los proyectos futuros horas de tiempo en el regateo y el debate. Si las polticas claras ya existen para su organizacin, entonces simplemente revisar la poltica para asegurarse de que se ajusta al contexto de sus necesidades. La siguiente cuestin es decidir quin va a precisar las prioridades. A veces, una "una persona, un voto" funciona bien. Si usted siente que puede haber conflictos significativos en las prioridades de los diferentes grupos, es posible que desee establecer un sistema de ponderacin ms sofisticado permitiendo que los grupos ms poderosos una voz ms fuerte en la priorizacin. El equipo que no necesita

un voto es el equipo que la aplicacin tendrn algo que decir en la siguiente fase de anlisis cuando se especifique lo difcil sern los requisitos para aplicar. Los requisitos deben ser priorizados por los niveles , comenzando con los requerimientos del negocio . Despus se han priorizado las necesidades de negocio , junto priorizar todos los requisitos del sistema que se relacionan con cada requisito del negocio. Por ejemplo , suponga que tiene los requerimientos del negocio A, B, y C. requisito Negocios A tiene requisitos de sistema A y B; requisito B tiene requisitos de sistema c , d, ye , y el requisito de C tiene requisitos de sistema f , g , h, i , y j . Una vez que haya determinado que A y C son de alta prioridad y B es de prioridad media , y luego determinar cul de a y b es la mxima prioridad y que a travs de f j es ms alta prioridad. Esto parece obvio, pero es sorprendente la frecuencia con la gente pasa el tiempo priorizando docenas o incluso cientos de requisitos detallados del sistema sin tener que darse cuenta de que el requerimiento del negocio es baja prioridad y probablemente no se implementan en el prximo proyecto. Un problema comn es que todo lo que parece una alta prioridad . Usted puede terminar con 5 por ciento de las necesidades de baja prioridad , el 15 por ciento de prioridad media y 80 por ciento de alta prioridad. Esto puede suceder si usted tiene polticas dbiles o inexistentes para la eleccin de las prioridades . Si encuentra que su anlisis de los requerimientos de tomar esta direccin , slo tiene que insistir en que en lugar de varias categoras de prioridad , se utiliza una estricta clasificacin numrica . Tome toda la categora ms alta prioridad y clasificarlos desde el ms urgente de los menos urgentes. Esto refuerza la idea de que algunos de los requisitos tienen una prioridad ms alta que los dems. Un segundo problema que puede surgir es que la gente sea reacia a utilizar la categora de menor prioridad , ya que creen que esto es equivalente a tomar una decisin que no se cumpla el requisito. Esto no es as , porque la priorizacin es slo la primera parte de la fase de anlisis . Muchas veces los requisitos ms pequeos en una prioridad ms baja se consiguen implementado antes exigencias ms grandes en una prioridad ms alta. El hecho de que un requisito es asignado a una prioridad ms baja no significa que no quede incorporado en el proyecto de gestin de la configuracin. Acerca de los requisitos Conocer la prioridad de los requisitos que vale la mitad de la informacin que usted necesita para el alcance adecuadamente su proyecto de gestin de configuracin. La otra mitad de la ecuacin es una estimacin de cunto tiempo tomar para cumplir con cada requisito. Esta estimacin se conoce como el tamao de un requisito. Cuando se conoce el tamao y la prioridad de cada requisito, usted puede montar estas piezas juntas en un plan coherente para

cumplir los requisitos ms importantes en el menor tiempo posible, mientras que gastar la menor cantidad de recursos posible. Para asignar el tamao correcto para cada necesidad, tiene que entregar a los requisitos sobre el equipo responsable de su ejecucin. Para los requisitos de herramientas, esto podra ser un desarrollo o equipo de personalizacin. Para los requerimientos del proceso, lo ms probable es ingeniero de procesos. Para los requisitos de la organizacin, es posible que un especialista en recursos humanos que pueden calcular cunto tiempo se tardar en encontrar gente para llenar las funciones indicadas en los requisitos. En esta primera etapa, estas estimaciones no son compromisos a das especficos en un programa del proyecto, pero los indicadores del nivel de esfuerzo que se necesita para cada requisito. Pida a los equipos que hacen estas estimaciones slo proporcionan un orden aproximado de magnitud en este punto. Recuerde que algunos de los requisitos que se estima que no se llevar a cabo en el primera versin, o posiblemente no del todo, por lo que no quieren que alguien pasar horas para llegar a una estimacin muy precisa de cunto tiempo va a tomar para poner en prctica. Una estimacin aproximada es todo lo que quieras durante la fase de anlisis de requisitos, y una estimacin ms detallada vendr durante la planificacin del proyecto. Asegrese de obtener las estimaciones de vuelta en unidades coherentes. Muy a menudo esto significa pidiendo a todos que calcular el nmero de das necesarios para cumplir con los requisitos que son de tamao. Para proporcionar estimaciones como un nmero de horas es probablemente demasiado grano fino, pero va a semanas o meses va a llegar a tener demasiados requisitos con exactamente el mismo tamao. Si los das de esfuerzo, ser difcil o costoso para estimar, tambin puede optar por iniciar categorizando los requisitos en pequeo, pequeo, mediano, grande y extra grande. En caso de demasiados requisitos caer en la misma categora de tamao (como la totalidad de ellos son medianos), que puede hacer de tamao ms especfica en slo esos requisitos. Si su organizacin no est acostumbrada a ofrecer estimaciones, sera mejor para documentar algunas de las polticas en esta rea tambin. Por ejemplo, si un desarrollador est proporcionando una estimacin para escribir un poco de cdigo, deben tambin incluir horas para probar que el cdigo? O vas a obtener una estimacin de las pruebas por separado de otra persona? En caso de horas se incluyen en las estimaciones para las revisiones de los productos del trabajo, tales como revisiones de cdigo y revisiones de documentos? Hacer las suposiciones errneas sobre lo que debe incluirse en el tamao de un requisito resultar en un tamao de inflado o desinflado en comparacin con otras estimaciones. Declaraciones de poltica simples ayudan a evitar este tipo de inconsistencias y errores en los requisitos de tamao. Esos errores se encuentran ocultos hasta que la ejecucin real del proyecto que descubre y paga por ellos, darse cuenta de que

el programa le resbale o ms de trabajo se podra haber hecho en el tiempo asignado. Derivado Requisitos adicionales Muchas veces en el curso de anlisis de las necesidades, los expertos descubrirn que algo no est claro o perdidas por completo. Esto ocurre con mayor frecuencia en la fase de estimacin, donde expertos en la materia profundas estn estudiando los requisitos ms crticos. Esto no es un problema, pero sin duda debe abordarse cuando se encuentran. Cuando algo parece claro, o detalles adicionales tienen que ser decidido, la mejor manera de manejar esto es mediante la adicin de ms requisitos, llamados requerimientos derivados. Ms que surge de talleres o entrevistas, vienen de el equipo de implementacin y sirven para llenar los vacos en los documentos de requerimientos originales. En lugar de simplemente deslizarse en, estos requisitos deben integrarse en los requisitos de los documentos a travs de un proceso de cambio controlado. Los actores que ayudaron a definir y priorizar los requisitos deben tener la oportunidad de revisar los nuevos requisitos propuestos antes de ser adoptados oficialmente en los documentos. Esto evita que un equipo de implementacin de "chapado en oro", los requisitos y entregar as la capacidad que realmente no son necesarios. El cambio puede ser propuesto por el experto en la bsqueda de la omisin, y un pequeo grupo central de las partes interesadas puede revisar y determinar si desea aadir ms detalle rpidamente. Muy a menudo estos requisitos que se derivan ms adelante tendrn la misma prioridad y categora que el requisito originalmente siendo examinado. A modo de ejemplo, supongamos que usted encuentra un sistema requisito que indica " La CMDB debe almacenar un nombre para cada elemento de configuracin . " Nuestro equipo de personalizacin es la estimacin de la cantidad de tiempo que se necesita para hacer que nuestra herramienta de satisfacer este requisito cuando se dan cuenta que se necesita saber el nmero de caracteres de un nombre puede ser , si el nombre debe permitir maysculas y minsculas , y si todos los caracteres especiales como guiones bajos y guiones pueden ser parte de un nombre. El lder del equipo propone un requisito adicional que dice " El nombre de un elemento de configuracin debe ser no ms de 40 caracteres de longitud, y se har de letras y nmeros en maysculas y minsculas , pero no otros personajes . " La prioridad y categora de la nuevo requisito sera el mismo que el requisito original , y los dos se vincule a indicar que uno no se puede hacer sin la otra . Una alternativa consiste en modificar la redaccin del requisito original, en esencia, lo que es ms especfico y medible. El proceso de derivacin de requisitos adicionales puede ocurrir durante todo el ciclo de anlisis .

Cuantos ms ojos que tienes en los requisitos, la mayor probabilidad de que este tipo de inserciones ocurrir - esto es una buena cosa. Recuerde que el propsito de analizar las necesidades es decidir lo que eventualmente conseguir construido por el proyecto de gestin de configuracin . Una mayor claridad en el anlisis ahora siempre conduce a un menor costo en la ejecucin posterior. Las lagunas se encuentran de vez en cuando , incluso despus de la fase de anlisis se ha completado y los requisitos que se acuerden . Cuando requisitos adicionales son necesarios despus del inicio del proyecto , deben ser introducidos a travs de un proceso de cambio cuidadosamente controlada que se asegura de que todos estn informados del cambio. Los grandes cambios , como aadir requisitos adicionales de negocios , deben ser revisadas con el promotor del proyecto , ya que es muy probable que el impacto de la programacin del proyecto y el presupuesto , mientras que los pequeos cambios en el contenido del sistema o requisitos de los componentes por lo general pueden ser manejados por el equipo de proyecto directamente durante la ejecucin. De cualquier manera, las partes interesadas deben ser conscientes de los cambios, no importa cun sutil. Obtener la aprobacin del proyecto El objetivo central del anlisis de los requisitos es producir un alcance exacto del proyecto que pueden obtener financiacin para que pueda seguir adelante. Mirando hacia atrs en este captulo, se dar cuenta de que tiene una buena cantidad de informacin que puede ayudar a preparar un alcance recomendado. Tiene notas de talleres y entrevistas, muchas de las cuales pondrn contexto alrededor de lo que los actores se sienten son los grupos importantes de requisitos. Usted tiene los documentos de requisitos revisados, que consta de un conjunto completo de todo lo que posiblemente podra hacer por su proyecto. Lo ms importante es que ha asignado una prioridad y un tamao para cada necesidad, ya travs de la serie de crticas que tener confianza que no se ha perdido nada. Con la informacin que ha reunido, ahora emprende el ejercicio creativo de encontrar el alcance del proyecto derecha. Te han dado lineamientos generales de su patrocinador, pero ahora se van a poner preciso sobre el cual las empresas, el sistema y requisitos de los componentes que implementar exactamente. Ms importante an, usted va a decidir qu requisitos no ser de aplicacin en el primer proyecto de gestin de la configuracin. Ya sea que usted est desarrollando una herramienta o aplicacin de un servicio completo, siempre se debe comenzar con la idea de que habr una segunda versin. Es decir, siempre se asume que no se puede poner en prctica todos los requisitos de un proyecto nico, monoltico y que sern necesarios proyectos de seguimiento para llenar completamente todas las necesidades de la organizacin.

Muchas personas como para establecer el mbito en base a un conjunto determinado de recursos a lo largo de un perodo de tiempo especificado. En otras palabras , cunto puede el equipo de implementacin de seis personas lograr dado una vida de un proyecto de cuatro meses ? Con ese esquema , slo tiene que mirar hacia abajo en la lista de los requisitos de prioridad , poniendo en las ms altas prioridades que caben en el nmero de das de esfuerzo asignados. Cuando tenga todos los requisitos de ms alta prioridad en que se ajuste , observe el siguiente grupo de prioridad ms alto y ver si son lo suficientemente pequeas para seguir encajando dentro de la caja . Siguiendo este mtodo para poder llegar a un proyecto que se ajuste a sus criterios predeterminados. Otras organizaciones prefieren trabajar a lo largo de lneas funcionales . Aqu nos fijamos en las listas de requisitos por categora y cuya funcin arquitectnica se ha determinado como la ms alta prioridad en general. Despus de usted, AOVE identifica el conjunto funcional de mayor prioridad , entonces incluya todos los requisitos necesarios para aplicar plenamente esa funcin. A menudo, usted , ll encontrar que tiene que incluir los requisitos de otras categoras para implementar realmente la funcin de alta prioridad. Sea cual sea el mtodo que elija para montar un good , proyecto AU, es probable que tenga algn malabarismo que hacer . Cuanto ms familiarizado est con el conjunto de requisitos , mejor , ll ser capaz de hacer esto malabares. A modo de ejemplo , es posible que haya documentado un requisito para la visualizacin grfica de las relaciones entre los elementos de configuracin . En los requisitos del sistema , usted explor exactamente lo que se necesitaba y se encontr que se necesita la capacidad de buscar un solo CI y , a continuacin, mostrar que CI en el centro de un diagrama radial con las distintas relaciones en un crculo alrededor de la nica CI . Este es un requisito comn , y uno que se puede lograr por varias de las herramientas principales . En su organizacin, este requisito se ha priorizado con una prioridad media , y la estimacin para cumplir con el requisito de volver a los 22 das de esfuerzo . Al mismo tiempo, usted tiene la obligacin de producir esencialmente la misma informacin en formato de lista , que se ha vuelto como una alta prioridad, pero tendr 30 das de esfuerzo. Usted puede optar por incluir ninguno de estos requerimientos en el mbito de aplicacin propuesto , que sera claramente hacer para un proyecto de costo ms bajo con un tiempo de aplicacin ms corto , pero esto reducira la funcin global proporcionado a un nivel que podra no ser aceptable . Usted puede optar por hacer ambos requisitos, pero a un

alto costo en trminos de recursos y / o horario. O puede elegir slo uno o los otros formatos de presentacin , citando las razones que realmente proporcionan la misma informacin. El uso de un proceso de toma de decisiones de este tipo, el equipo debe reunir un alcance general del proyecto, determinar exactamente qu requisitos celebrarn juntos para producir el equilibrio adecuado de la uncin frente a los costos . Mientras que el alcance propuesto est siendo ensamblado , don , AOT olvide documentar la justificacin utilizada para poner juntos . Ese razonamiento le ayudar en la venta de la propuesta a todos sus grupos de inters. Muchas de las preguntas que los interesados tendrn que quedar cubierta porque el equipo ha considerado y respondido a ellas en el montaje de la propuesta de proyecto . Si ha montado el proyecto con tiempo y de recursos , asegrese de decirle a todos lo que esas restricciones son . Si ha seleccionado un conjunto de funcionalidades como la ms alta prioridad , documentar por qu se eligieron estas funciones y cmo cada requisito contribuye a esas funciones. Lgico y bien documentado justificacin har la propuesta ms fuerte que una simple lista de requisitos.