CAPTULO 6

Las mejores prcticas para Requisitos Desarrollo y Gestin

En 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
organizacin

Algunas 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 importante
Dadas 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 mnimo

Estas 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 Estudio
Hace 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