CAPTULO 6Las mejores prcticas para Requisitos Desarrollo y GestinEn los captulos anteriores he sugerido que haces ciertas cosas y otras no. En este captulo, comparto un conjunto de mejores prcticas para el desarrollo de gestin. La frase " mejores prcticas " se utiliza con frecuencia en los sistemas y programas de ingeniera cermica (entre muchas otras profesiones). Sin embargo, en realidad no gastamos el tiempo y esfuerzo para evaluar, analizar, o implementar en prctica de institucionalizarlos. La razn de esto es bastante simple: es un montn de trabajo. Se requiere lo siguiente: El desarrollo de una comprensin profunda de la prctica Comunicar su valor para los compaeros de trabajo y directivos Ganando un compromiso de intentar la prctica (pilotaje ella) Ofrecer algn tipo de formacin sobre la prctica para que otros entenderlo y lo que estamos tratando de lograr a travs de su uso Implementacin de la nueva prctica, el cambio de lo que estamos haciendo ahora a hacer algo diferente La implementacin de la nueva prctica, asegurando que la nueva forma es utilizado El mantenimiento de la nueva prctica, incluyendo la obtencin de apoyo para su utilizar La evaluacin de su impacto La declaracin de la victoria, reconociendo que la nueva forma es mejor a la manera antigua, tal vez incluso de celebrar el xito Institucionalizar el uso de la nueva prctica en todo el proyecto u organizacinAlgunas de estas prcticas se han discutido con cierto detalle en el libro as que voy a limitar mis comentarios en este captulo. Mi objetivo es convencerte de que vale la pena el esfuerzo, al menos, para poner a prueba cada una de estas mejores prcticas sobre su proyecto y hacer un esfuerzo para evaluar los resultados de la utilizacin de cada uno las mejores prcticas. Tabla 6.1 ha sido cuidadosamente diseada, y me gustara explicar su estructura. En primer lugar, las necesidades de las actividades de una tarea o proyecto estn inextricablemente relacionados con las actividades de gestin de proyectos, as como con otras disciplinas como CM, ingeniera de sistemas y control de calidad. Los requisitos que se aproximan se utiliza en una tarea o proyecto no est desarrollado y puesto en prctica en el vaco por la RA. Se desarroll a travs de un conjunto de decisiones que necesariamente implica otras personas clave, incluyendo el cliente, PM, ingeniero de sistemas, y otros. Recomiendo que usted comparte la Tabla 6.1 con el equipo de trabajo o el liderazgo de proyectos (Incluido el cliente) y seleccione conjuntamente las mejores prcticas que usted determine como equipo se debe utilizar en su tarea o proyecto. Esta tabla est disponible para abajo cargar en mi sitio web (www.ralphyoung.net). En segundo lugar, las mejores prcticas recomendadas en la Tabla 6.1 se agrupan en tres categoras: 1. Requisitos desarrollo 2. La gestin de requisitos 3. Gestin de proyectos.Dentro de cada categora, se organizan aproximadamente y secuencial 1 primero, a continuacin, 2, y as sucesivamente. Sin embargo, tenga en cuenta que muchos del proyecto de las mejores prcticas relacionadas con la gestin son globales. Por ejemplo, las mejores 25 prcticas recomienda acordado una meta, propsito, o se establezca la misin para la tarea o proyecto. A falta de un acuerdo ponen un objetivo, propsito o misin para la tarea o proyecto har que sea difcil lograr cualquier cosa de valor. Todas las otras mejores prcticas en el proyecto de gestin de reas de direcciones que pueden estar ms all del alcance de la RA. Ellos han demostrado mejores prcticas de la industria que pueden tener una posicin significativa de impacto en los esfuerzos de desarrollo y gestin de requisitos. Usted ser necesario el compromiso del equipo de trabajo o de la direccin del proyecto para implementar efectivamente estas prcticas. No es suficiente para que la RA slo para permitir prcticas evolucionen queramos o no. Su responsabilidad es proporcionar esta lista a su seleccionarse tarea o equipo de liderazgo de proyectos con la peticin de que las prcticas que se utilizarn en colaboracin por el equipo. En tercer lugar, la columna ms a la derecha en la Tabla 6.1 proporciona una referencia al captulo en este libro donde se discute la mejor prctica para que usted pueda conseguir ms informacin, orientacin y referencias adicionales al respecto. Cada una de estas prcticas recomendadas se discutirn en el orden en que se enumeran en Tabla 6.1.Tabla 6.1 Mejores prcticas para Desarrollo y Gestin de Requisitos

1. Desarrollar un plan de necesidades. Las razones para la planificacin de la realizacin de actividades de relacin con los requisitos relacionados los lazos y los contenidos sugeridos de un plan de necesidades se discuten en Los captulos 1 y 5.

2. Escribe requisitos que cumplen los criterios de un buen requisito previsto en el Tabla 1.1. Si no se realiza este paso, detngase aqu. Tabla 1.1 proporciona una lista de sugerido tenia de un buen requisito. Hay una gran cantidad de informacin acerca de este tema disponibles y varios autores han proporcionado varias versiones con muy similares criterios. Sorprendentemente, los criterios se aplican con poca frecuencia en la prctica. Esto es un ejemplo flagrante de una situacin en la que sabemos hacer mejor, pero nosotros no debemos utilizar nuestro conocimiento y experiencia. Aqu es una oportunidad para a hacer una valiosa contribucin a los proyectos que apoya. Considerar incluyendo estos criterios como una lista de verificacin en su herramienta de requisitos automatizado. Usted encontrar que tanto tiempo y dinero se guardar como un resultado de la aplicacin los criterios.

3. Identificar e involucrar a todos los actores de la tarea o proyecto. Asegrese de que todas las partes estn identificadas e involucradas en los requisitos del proceso de desarrollo. Con demasiada frecuencia, no identificamos la totalidad de las partes interesadas que deberamos. La omisin de un grupo de interesados puede resultar en un ataque de asma ms tarde en el trabajo de desarrollo. Las partes interesadas incluyen el cliente, los usuarios, organizaciones de gestin y control del programa, el desarrollo y arquetipos, personal legal, grupos de prueba, los clientes de la interfaz, y as sucesivamente. Sugerencias y enfoques sobre cmo lograr esto se proporcionan en Captulo 5.4. Asegrese de que los objetivos de la tarea o proyecto se han identificado, documentado, y acordado por las partes interesadas. Esto debe hacerse antes y puede llevarse a cabo escribiendo una "visin y documento de alcance. La disponibilidad de estos, acordados en los objetivos del proyecto ayuda a que el equipo de desarrollo a mantener el enfoque y proporciona una base comn para la identificacin de las necesidades reales y la evaluacin de sus prioridades. Ayuda asegurar que todo el mundo est mirando el sistema necesitaba o capacidades de software lazos desde la misma perspectiva y tambin ayuda a los que estn proporcionando la financiacin entender lo que hay que hacer y cmo se apoya la organizacin. 5. Utilice talleres como un requisito para lograr una visin compartida, facilitar el compromiso, y todos los interesados. Un taller de requisitos es una reunin estructurada en la que un cuidado selecto de grupos de las partes interesadas y expertos en el tema trabaja en conjunto para definir, crear, refinar, y alcanzar el cierre de entregables (tales como modelos y documentos) que representan las necesidades del usuario. El beneficio del proceso del taller es que nutre la comunicacin del equipo, toma de decisiones, y entendimiento mutuo. Los talleres son tambin una forma eficaz de llevar junto clientes, usuarios y proveedores de software para mejorar la calidad de productos sin sacrificar tiempo de entrega. Estas sesiones suelen cometer los usuarios en el proceso de definicin de requerimientos y promover su sentido de propiedad de los entregables y, en definitiva, del sistema.6. Proporcionar los requisitos de formacin para las asociaciones regionales, para los miembros del personal del proyecto, y por grupos de inters. Debe ser evidente que a partir del material presentado hasta ahora que es ventajoso proporcionar la capacitacin para tres grupos distintos: RA, los miembros del personal del proyecto, y las partes interesadas. La razn es que experiencia en la industria tiene mucho que ofrecer a cada grupo para mejorar el enfoque. El objeto es diferente para cada uno de los grupos, como se indica en Captulo 5. De particular beneficio es la constatacin de que la comunicacin entre todos los grupos se mejora cuando todos comparten las mismas ideas y entendimiento.7. Identificar las necesidades reales. Colaborar con los clientes y usuarios en relacin con los requisitos establecidos para identificar las necesidades reales. Mirar el requisito desde mltiples puntos de vista. Confo en que a estas alturas puedas entender la diferencia entre la exigencia establecida y requisitos reales. Su responsabilidad principal es colaborar con clientes y usuarios acerca de los requisitos establecidos para identificar el verdadero requisito. Este es el papel 1 en el contexto de las funciones definidas en el Captulo 2racin como los requisitos facilitador para trabajar en colaboracin con los clientes, usuarios y arquitectos de sistemas y diseadores para identificar las necesidades reales.Su primer paso ser convencer a sus clientes y usuarios de que es esencial y que vale la pena invertir tiempo y esfuerzo aadido en el requisito proceso, en este caso, para revisar los requisitos establecidos y evolucionar los verdaderos requisitos utilizando un concepto equipo conjunto o mecanismo. No Pasar a que es el problema de la industria ms importante de los requerimientos de ingeniera y que casi siempre se presta suficiente atencin. Aplicar efectivas tcnicas de recopilacin de requisitos, tales como los descritos en el Captulo 5. En colaboracin con sus clientes y usuarios, adaptar la lista de comprobacin proporciona en Tabla 5.1 a las necesidades de su proyecto en su entorno. 8. Documentar la justificacin de cada requisito, es decir, por qu es necesario. Justificacin es un atributo que se debe incluir en su exigencia automatizado herramienta. Experiencia en el sector muestra que al tomar el paso del documento y la justificacin de cada requisito, hasta la mitad de los indicados requisitos pueden ser eliminados. El ahorro en trminos de no tener que hacer seguimiento de los trabajos tcnicos para cumplir los requisitos eliminados es obviamente enorme. Por otra parte, este esfuerzo de clarificar y endurecer los requisitos se debe mantener. La experiencia de Ivy Ganchos es que la grabacin de la lgica para cada requisito reduce el nmero total de los requisitos, expone malas suposiciones, elimina aplicacin no deseada, mejora la comunicacin entre los miembros del equipo, acorta el ciclo de revisin, mantiene correspondiente conocimientos y reduce el riesgo en la definicin de un producto derivado, y apoya los costos de mantenimiento y de operaciones.

9. Utilizar tcnicas eficaces de recoleccin de requisitos. Este fue el tema del captulo 5. Algunas tcnicas de recopilacin de requisitos son ms eficaces que otros. Asegrese de que alguien en su tarea o proyecto ha utilizado anteriormente las tcnicas seleccionadas con xito.

10. Involucrar a los clientes y usuarios de todo el esfuerzo de desarrollo. Reconocer que la experiencia de la industria demuestra que los proyectos que implican usuarios en todo el proceso de desarrollo son el diseo el uso de mecanismos para mantener a los clientes y usuarios del proyecto participan, tales como el equipo conjunto, los requisitos de colaboracin reuniendo tcnicas y un tablero de control de la configuracin conjunta (CCB) para administrar el proyecto.11. No haga decisiones requisitos. Por decisiones requisitos, me refiero a las decisiones sobre lo que es un requisito es o debera ser, incluyendo la forma en que est redactado. Una de las maneras que losRA crean problemas para nuestros proyectos es tomando decisiones requisitos. Establezca una persona poltica de no tomar decisiones requisitos. Decisiones Requisitos son responsabilidad del cliente y del usuario en el equipo conjunto uno mismo. Si bien puede ser ms rpido y ms fcil slo para decidir algo ms que para obtener una aclaracin, resistir esta tentacin porque es peligroso. Reflexionar sobre lo difcil que es para comunicarse efectivamente y lo diferente individuos interpretan las cosas que escuchan, leen y ven. Usted tiene un alto riesgo de tomar una decisin incorrecta. Por otra parte, su decisin podra tener un gran impacto negativo en el proyecto, sin embargo no intencionales. El enfoque de no tomar decisiones requisitos tiene que ser comun en todo el equipo de desarrollo, para asegurar que los desarrolladores no lo hacen tomar decisiones requisitos tampoco. Esto debe ser aclarado en el requisito formacin relacionados siempre al equipo del proyecto.

12. Haz placas no oro, es decir, aadir caractersticas o capacidades. No decidir que usted tiene una idea de que conoce el cliente y los usuarios le encanta.Ellos s pueden amarla, y puede agregar al costo y horario, as como para el trabajo tcnico que ya ha sido completado. Cumplir los requisitos mnimos reales. Haga placas no oro.

13. Uso de un glosario de proyectos y un proyecto acrnimos en una lista.He hecho previamente esta sugerencia y siempre que la razn fundamental para hacer este. Consulte el Captulo 5, el paso 8.

14. Iterar los requisitos y la arquitectura en varias ocasiones a evolucionar mejor requisito y una arquitectura ms robusta.El punto aqu es que los requisitos y el impacto de la arquitectura entre uno y otro. Como modificamos la arquitectura de lo real debemos aprender ms acerca de los requisitos y los cambios de arquitectura nos hacen quieren cambiar el requisito. Este trabajo se puede realizar en conexin con las tres o cuatro iteraciones del proceso de desarrollo de los requisitos anteriormente recomendada.

15. Utilizar los expertos de dominio / Pymes que tienen conocimiento y experiencia en el reas funcionales siendo abordados por el esfuerzo tcnico.He mencionado antes algunas ventajas tradas a un proyecto por una nuevo analista asignado, como tener una nueva perspectiva, y la historia del sistema y los procedimientos de herencia. El otro lado de este es el valor de las que involucran a personas que tienen una amplia experiencia y conocimientos en las reas funcionales siendo abordada por el sistema. Ellos tienen una profunda comprensin de por qu se hacen las cosas de cierta manera, y mira las necesidades del cliente con una perspectiva experimentado que puede incluir aspectos uniforme imaginable por los menos informados o menos experiencia. Involucrar a tales personas en la recopilacin de requisitos actividades, por ejemplo, los requisitos talleres, o los utilizan como asesores. 16. Cuantificar el ROI para seleccionar mecanismos requisitos, prcticas, mtodos, tcnicas y herramientas a utilizar.Proporciono informacin detallada sobre esta buena prctica en Efectivo Requisitos Prcticas. La toma de decisiones sobre la base de datos en lugar que por el asiento de nuestros pantalones o mediante la intuicin es una buena prctica en nuestra empresa, nos referimos a este hbito como "gestin por hecho." Su PM debe esperan que los datos que se facilitarn cuando se solicitan decisiones.

17. Identificar los requisitos mnimos que satisfagan las necesidades reales.Algunas personas tienen dificultad con el concepto de identificacin mnima de requisitos. Ellos interpretan esto como no hacer todo lo posible para satisfacer clientes. Cualquier requisito y caractersticas adicionales que van ms all de bienes necesidades complican el proceso de desarrollo, hacen que sea ms caro, toman tiempo adicional, ponga en peligro la calidad del producto de trabajo, y, potencialmente, poner en peligro el xito del proyecto. El proceso de sistema y software de desarrollo es complicado y difcil. Ambos socios deben esforzarse constantemente para satisfacer requisitos mnimos reales en el inters de xito del proyecto. Determinar cules son los requisitos mnimos adecuadamente priorizadas debe involucrar a los miembros del equipo de desarrollo, la comunidad de usuarios.

18. Priorizar requisitos temprano ya menudo. Es igualmente importante dar prioridad a las necesidades reales temprano y con frecuencia. Utilice su equipo en conjunto o un mecanismo similar a un acuerdo conjuntamente sobre requisitos prioridades. Hay artculos y herramientas disponibles para Ayudar. Tmese el tiempo para leerlos y utilizarlos. Una vez que las necesidades reales se identifican y priorizan el desarrollo equipo pueden estimar el esfuerzo requerido para proporcionar caractersticas adicionales, y el cliente puede evaluar el costo de la prestacin y decidir si vale la pena el dinero y el tiempo adicional. La clave es asegurar que la produccin de trabajo desarrollado sern aceptables para el cliente y los usuarios y para obtener el acuerdo de todas las partes interesadas en la delantera. 19. Proporcionar inspecciones de todos los documentos de requerimientos relacionados. La justificacin para proporcionar inspecciones de todos los requisitos relacionando documentos se proporciona en el captulo 7, tema 11.

20. Lmite cambia a las necesidades y la adicin de nuevos requisitos consistentemente con presupuesto adicional y el horario puestos a disposicin por el cliente para completar la tarea, proyecto o sistema. Esta es la segunda cosa ms importante que un RA puede hacer para apoyar un proyecto (despus de establecer un mecanismo de colaboracin conjunta y enfoque para identificar el verdadero requisito). Requisitos de los cambios y los nuevos requisitos son la segunda razn principal que se proyecta fuera de control. Su responsabilidad en esta rea es familiarizar a su equipo de proyecto, su cliente, y los usuarios con la industria tratar de ganar experiencia y compromiso con el control de cambios y nuevos requisitos. Por supuesto, usted tendr que satisfacerse a s mismo cuando cualquier solicitud de cambio representa una necesidad real y por lo tanto es un requisito real. Como antes, determinar la justificacin de la solicitud, por qu se necesita? La mayor importancia ante, el equipo de desarrollo tiene que aprender a decir que no. Es en ninguno el inters del cliente ni el desarrollador para permitir que el proyecto para llegar fuera de control. Establecer objetivos para diferentes situaciones, por ejemplo, los requisitos de 0.5% cambiar por mes para requisitos validados, y buscar la verificacin de la equipo tcnico de que cualquier cambio propuesto no pondr en peligro xito del proyecto ceso. Requisitos cambios despus de la lnea de base se establece requisitos poner en peligro los resultados del proyecto y el xito, a menos que sirvan para aclarar la intencin de un requisito en lugar de cambiar la funcionalidad. Algunos creen que un lmite de 0,5% requisitos volatilidad es demasiado estricto, realista, e inalcanzable. Sin embargo, proporciona una buena meta. Una directriz interesante de la industria experiencia es que un tercio de cambio en los requisitos (33% por ao o 2,75% por mes) dar lugar a una duplicacin de los costos del proyecto. El seguimiento de su mtrica requisitos volatilidad dentro del mecanismo de equipo conjunto. Asegurar que el cliente est dispuesto a ofrecer programacin y presupuesto adicional en proporcin al porcentaje de los requisitos de volatilidad de lo contrario, no lo hagas aceptar cambios en los requisitos o la adicin de nuevos requisitos. Aprender decir que no.

21. Use las versiones y lanzamientos de productos de trabajo para dar cabida a los nuevos requisitos, requisitos modificados, y los requisitos de menor prioridad. Se discute la importancia del uso de versiones y lanzamientos de productos de trabajo en el Captulo 5.

22. Uso de una herramienta de requisitos de potencia industrial automatizado. Proporcionar y utilizar atributos de requisitos. Seleccione su potencia industrial herramienta requisitos automatizado temprano y cuidadosamente plenamente. Asegrese de que la herramienta seleccionada apoya su proceso. Seleccin de la herramienta sin tener primero el proceso de requisitos en su lugar puede hacer que el proyecto para obligar a colocar su proceso para la herramienta de riesgo importanteDadas las herramientas comerciales que estn disponibles, no es eficaz para desarrollar sus propias capacidades automatizadas herramienta requisitos. Determinar mina de los atributos de los requisitos que se necesitan, ver la discusin de atributos en el captulo 5. Con demasiada frecuencia, la eleccin de la exigencia automatizado herramienta que se utilizarn en un proyecto es dictado por factores fuera del control del proyecto.

Por ejemplo, una experiencia de RA sobre la seleccin de la herramienta requisitos automatizado para apoyar cinco proyectos:

En un proyecto, hemos desarrollado nuestra base de datos de los requisitos propios utilizando Informix porque ya tenamos Informix y un montn de experiencia usndolo. En otra, propusimos un enfoque OO usando el Rational Unified Proceso (RUP) y la herramienta Rational SuiteRequisitePro que fue la herramienta predeterminada simplemente porque era parte de nuestro conjunto de herramientas en general. En un tercer proyecto, Rational fue seleccionado con base en el hecho de que la analista dio una clase de casos de uso en una universidad local y fue ya estn familiarizados con el Rational Suite. En otro proyecto, el cliente especifica RequisitePro Rational en el SOW. Y en otra, el proyecto utiliza PUERTAS porque el cliente utiliza DOOR.As, de cinco proyectos, la experiencia de este RA fue que el requisito automatizado herramienta fue seleccionado sobre la base de criterios arbitrarios en los cinco situaciones a las limitaciones presupuestarias, ya que estaba predestinado, o porque alguien tena una preferencia personal. No hubo ningn caso en el que un herramienta requisitos automatizado fue seleccionada porque era la mejor opcin para ese proyecto especfico. 23. Desarrollar o adaptar y utilizar los requisitos de organizacin y proyectos de polticas y proceso de requisitos que se mejora de forma continua en su tarea, proyecto u organizacin.Invertir 8% al 14% de los costos totales del proyecto en el (ciclo de vida del sistema) proceso de requisitos. Es til tener (y utilizar) un poltica de la organizacin en relacin con requisito. Todos estamos familiarizados con los proyectos y organizaciones que tienen las polticas, pero no utilizar en la prctica. Estoy hablando de una situacin diferente: me recomendamos que las organizaciones y los proyectos tienen polticas y los usan. Las polticas de la organizacin pueden ser tan simples como las sugeridas por los dos requisitos relacionados con las reas de proceso y RM:

En cuanto al desarrollo de requisitos: "Con el fin de identificar y satisfacer necesidades de los clientes, los proyectos debern: (a) Reunir las necesidades de las partes interesadas, (b) por producto y los requisitos de componente de producto, y (c) Analizar y validar estos requisitos. Respecto RM: "Con el fin de garantizar que las necesidades del cliente son satisfactorios cado, los proyectos ser: (a) Administrar los requisitos y exigencias cambios, y (b) Identificar inconsistencias entre el trabajo del proyecto y requisitos.24. Use probada y requisitos conocidos mecanismos, enfoques, mtodos, tecnologas y herramientas.Se comprometen a utilizar mecanismos, enfoques, mtodos probados y familiares, tcnicas y herramientas. Usted debe estar familiarizado con ejemplos de stos desde porciones anteriores del libro, pero voy a mencionar algunos ejemplos en cada categora de mantenerlos todo en su mente: Mecanismos: el equipo conjunto un conjunto de reglas de conducta en su tarea, proyecto. organizacin para describir cmo los miembros se traten unos a otros PDCA para determinar cmo fueron las reuniones o cmo lo estamos haciendo en un punto tiempo, por ejemplo, tras la finalizacin de un hito un Propsito, Agenda, y Lmite (PAL), siempre antes de las reuniones para que la gente pueda prepararse para la reunin y saber cunto tiempo para planificar para la reuniones Enfoques: asociacin uso de revisiones por pares y la prevencin de defectos (DP) tcnicas en toda la tarea o proyecto formacin CM QA utilizando tcnicas para facilitar la comunicacin proyecto catin medicin etctera Mtodos: recopilacin de requisitos mtodos como entrevistas, documentacin anlisis, talleres requisitos, prototipos y modelado Tcnicas: la gestin de los riesgos del proyecto, revisiones por pares, DP, "bolsas marrones" Herramientas: PUERTAS, otras herramientas automatizadas requisitos observ en Tabla 5.7 herramientas automatizadas de gestin de riesgos un proyecto cuaderno.Usted puede encontrar que vale la pena conocer y utilizar un nuevo mtodo o tcnica reconocer, sin embargo, ser necesario que el tiempo y esfuerzo para aprender nuevos mtodos y tcnicas para utilizar de manera efectiva y que hay un riesgo en el uso de un mtodo o tcnica que no est demostrado y familiar. Tomar decisiones relativas a usar nuevos mtodos y tcnicas con su los ojos bien abiertos. 25. Una tarea o visin del proyecto y documentar el alcance. Como se seal al comienzo de este captulo, a falta de un objetivo acordado en, propsito o misin para una tarea o proyecto hace que sea difcil de acompaar.

26. Desarrollar, implementar y hacer cumplir las reglas de reuniones que describen cmo el personal del proyecto miembros han de tratarse unos a otros. Esto implica dos elementos fundamentales: el establecimiento y siguiendo un orden del da (PAL) y siguiendo las reglas de conducta. Cada uno de estos elementos es un componente clave de reuniones diseadas para obtener y adoptar nuevos requisitos o cambios a requisitos existentes. La persona que solicita una reunin proporciona un PAL en antes de la reunin para que todo el mundo sabe lo que se va a debatir, cada persona puede preparar apropiadamente, y todos sabemos que la reunin ser fin.Ha sido mi experiencia que me gusta el trabajo y me siento ms eficaz cuando mis compaeros de trabajo aprecian y apoyan mi contribucin al esfuerzo general. YO han encontrado que tener un conjunto de reglas de conducta para los esfuerzos de trabajo que estoy involucrado en ha sido un medio eficaz para facilitar una actitud de apoyo unos a otros en nuestro entorno de trabajo. Ejemplos de reglas de conducta que yo valor son las siguientes: Respetar cada persona Comparte la responsabilidad Criticar las ideas, no las personas Manten una mente abierta Pregunta y participar Llegar a tiempo Mantenga las interrupciones a un mnimoEstas normas se publican en salas de conferencias en nuestra empresa. La gente es llamada a la tarea cuando violan una de estas reglas. S que mis compaeros de trabajo me van a respetar, incluso cuando mis ideas parecen inusual. Tratamos de apoyarnos mutuamente en todos los sentidos posible. Todo el mundo se presenta para las reuniones a tiempo, y empezamos a tiempo. No est permitido Sidetalk. Se espera Focus. Ahorramos cantidades increbles de tiempo. Pero lo ms importante, nos respetamos y estamos all para el uno al otro.27. Desarrollar y aplicar un conjunto de directrices para las reuniones y directrices eficaces para la efectividad.Pasamos mucho tiempo en reuniones y leer y escribir email. Es lgico que un conjunto de directrices para estos tiempos de comedores ahorrar tiempo y esfuerzo. He recomendado previamente un conjunto de directrices para cada uno. Las directrices especficas son menos importantes que (1) se ha comprometido a utilizando las directrices para estos fines, y (2) la gente en los proyectos y en organizaciones que toman el tiempo para desarrollar directrices que van a honrar y usar.

28. Llevar a cabo una evaluacin de riesgos de las necesidades nuevas y cambiantes. Orientacin para la forma de realizar las evaluaciones de riesgos requisitos relacionados es prevista en el Captulo 7, tema 18.

29. Aprenda a manejar equipos con eficacia.Hemos visto a lo largo del libro lo importante que es trabajar en colaboracin, para obtener el consenso, y lograrlo.

30. Establecer una mejora de la calidad y el clima mejora de procesos. Orientacin para la forma de lograr esto se proporciona en el captulo 8. Resumen Este captulo presenta 30 mejores prcticas para el desarrollo y requisitos gestin para su consideracin. Uno no puede hacer todo, al menos todo a la vez. Desempolvar su plan de necesidades. Desarrollar un enfoque razonable implementar, implementar e institucionalizar esas mejores prcticas que considere apropiado para su proyecto en su entorno a travs de una razonable perodo de tiempo. Colaborar con el equipo de tarea o proyecto para dar prioridad a la Valor de las mejores prcticas que usted decida implementar. Escribe una accin plan que permitir al proyecto para ponerlas en prctica. Para cada uno de mejores prcticas, definir las acciones y el calendario necesarios para ponerlo en prctica. Haced esto en colaboracin racin con el equipo del proyecto y su cliente. Involucre a su equipo de proyecto y el cliente en el proceso de toma de decisiones para obtener la aceptacin y el apoyo de otros. Lo ms importante es asegurarse de que el equipo del proyecto se est moviendo juntos en concierto con su cliente, no tener el mayor nmero de mejores prcticas. Recuerde, se necesita el compromiso de lograr cualquier cosa de valor.Caso De EstudioHace varios aos, se me pidi que ayudar a los abogados que trabajan en un caso legal entre un contratista de integracin de sistemas y el gobierno estadounidense. El gobierno haba resuelto el contrato por incumplimiento y luego el sistema de otro contratista. El sistema construido por el nuevo contratista explot cuando fue sometido a los volmenes de datos reales. Las pocas horas de asistencia consultora solicitada originalmente creci en aos de apoyo litigios puerto que el caso se desarroll, antes de que saliera a la solucin de cinco aos despus. Qu caus esta desconexin masiva? La respuesta corta es la falta de comprensin de los roles y responsabilidades para la gestin de requisitos. El gobierno reconoci que se necesita requisitos y tena contacto con el extrajeron anteriormente para un estudio de viabilidad que incluye requisitos de datos y los requisitos funcionales. Entonces, cuando estaba claro que era necesario avanzar con rapidez y ya no tena tiempo para completar el contrato para construir el sistema, se encarg al contratista de desarrollo a travs de una serie de rdenes de trabajo. Las dos primeras tareas fueron (1) "Evaluar el hardware y especificaciones de software y realizar un anlisis de los requisitos para las partes de la red de rea local (LAN), "y (2)" Revisar y validar el Estudio (antes), frente a las exigencias actuales. " La primera tarea, "evaluar las especificaciones de hardware y software y realizar un anlisis de los requisitos para la LAN de la Sede, "se tom como bajo riesgo tarea de recomendar las computadoras personales de automatizacin de oficinas (PC) hardware y software para estaciones de trabajo y servidores. Se llev a cabo rpidamente, usando fondos de fin de ao, y fue pensado para ofrecer equipos a los usuarios en el campo. El contratista consider esta tarea "alcanzable". La segunda tarea, "revisar y validar el trabajo anterior," dio lugar a un documento que describe las reas donde los requisitos funcionales actuales tenan reas cambiadas y que los requisitos identificados trabajo adicional. El contratista estaba ms preocupado acerca de ser capaz de lograr este trabajo con eficacia, debido a los problemas relacionados con los requisitos. Una tercera tarea fue emitida por el gobierno para disear una transmisin electrnica capacidad de la misin para el sistema. El SOW para esta tarea era extremadamente detallada y pidi el diseo de numerosas interfaces. Esto sugiri una un cambio importante en la arquitectura. El estudio original haba asumido que el sistema sera un sistema basado en computadora central centralizada. De repente, qued claro que el cliente tena un enfoque diferente en la mente de un cliente que de un servidor. Al expresar cmo los requisitos seran como el gobierno estaba imponiendo restricciones detalladas en la solucin. El contratista comenz a tener ansiedad porque haba muchas incgnitas, tales como el diseo del resto del sistema ms all de sus ciudades de transmisin. El trabajo continu sin una comunicacin efectiva entre el gobierno y el contratista. No se resolvieron las cuestiones pendientes. En una importante revisin de diseo, el contratista y cierto gobierno personal se reunieron por primera vez, y la luz empez a amanecer. El diseador jefe de la capacidad de transmisin electrnica declarado: "Ahora s lo que pedir! Todo el mundo declar la reunin sea un xito. Un elemento de accin era preparar un plan para cuando se complete la capacidad de transmisin. Cuando se entreg el plan, indic que el sistema proyectado con fecha de finalizacin sera un ao despus de la fecha deseada. Esto llev a la gobierno para rescindir el contrato. El Gobierno esper hasta que el otras prestaciones de diseo eran completos, los entregaron a un nuevo contacto, y consigui trabajar en marcha para construir rpidamente el sistema. En las pruebas de aceptacin del sistema, el sistema explot con correlacin de datos masivos corruptos, y estaba claro que no iba a funcionar. Cul fue el problema? Algunas de las cuestiones relacionadas con los requisitos son los siguientes:1. Las especificaciones de hardware y software evaluados bajo tarea 1 no se hace correctamente, porque los componentes seleccionados no poda acomodar el volumen de datos.Eran esas especificaciones simplemente requisitos del sistema para la compra de computadoras de las materias primas, o fueron los Ordenadores adquiridos con la intencin de que iban a ser parte de la solucin para el sistema global? Este matiz ms tarde resultar significativa, debido a que el gobierno afirm que la evaluacin de los ordenadores era por su idoneidad para apoyar el sistema. El desempeo no se haba definido requisitos ANCE para un sistema de este tipo, porque nadie en el lado del contratista se dio cuenta de que la arquitectura no era ya centralizada. 2. No en general, los requisitos unificados documento o repositorio fue desarrollada. Requisitos se encontraban en numerosas fuentes de variables edad y validez (por ejemplo, las notas escritas a mano por gobierno personal Ment en entregables revisaron). En algunos casos, requisitos eran contradictorios o no existen. reas identificadas en la revisin y validacin de documentos de requisitos previos como menor dominio Ing. mayor definicin requisitos quedaron de esa manera porque no tareas se recibi para explorarlos. No hubo CM de los requisitos. 3. La especificacin de requisitos detallados por el gobierno para el capacidad de Transmisiones, aunque no comunicar la tura general tura para el sistema o permitir que el contratista para disear el arquitectura, fue una sobrevaloracin de los requisitos de diseo.4. Los volmenes de datos identificados en los requisitos de datos efectuadas por el prior contratista creci en unos pocos lugares clave sin ninguna reevaluacin del impacto global sobre la arquitectura, hasta que el sistema entregado no iba a funcionar.5. El diseo del sistema por parte del contratista fue considerado por el gobierno sea tan pobre que el contrato se termin, sin embargo, la hecho de que el gobierno orden al contratista de seguimiento de usar esas mismas prestaciones de diseo para construir el sistema implica aceptacin del diseo. Eran, en realidad, un conjunto de requisitos del sistema para el nuevo contratista.La leccin importante que aprender de este estudio de caso se refiere a los roles y el liderazgo de las tareas requisitos. Debido a que el gobierno define a travs de su tarea que partes de los requisitos que requeriran la contratista que asuma la responsabilidad de las partes y que el gobierno sera especificar en detalle, no haba una estrategia global RM o proceso. Algunos de los resultados finales de este escenario fueron (1) las necesidades de los usuarios no estaban cumplido segn lo previsto por el gobierno y los contratistas, (2) el contrato final se termin, (3) el sistema desarrollado por el segundo contrato no funciona, (4) se desperdicia una gran cantidad de dinero y tiempo, (5) algunos personas perdieron sus puestos de trabajo debido a los problemas que se desarrollaron, (6) algunas familias se vieron afectados negativamente debido a varias cuestiones interpersonales que se dan, (7) aos los pas en un litigio costoso, (8) negativa significativa informacin relativa a los sistemas y la ingeniera de software y los problemas de ambas partes fue presentado en varias comunicaciones, incluido el peridicos, y (9) un montn de sealar con el dedo ocurri. En mi experiencia, esto escenario se escenarios no relacionados nicas se han repetido en varios maneras en los ltimos dos docenas de aos, y continan hasta hoy. Nombre retenido por la peticin, consultor requisitos de ingeniera