AO DE LA DIVERSIFICACIN, PRODUCTIVA Y FORTALECIMIENTO DE LA EDUCACIN

UNIVERSIDAD NACIONAL HERMILIO

VALDIZAN
FACULTAD DE INGENIERA INDUSTRIAL Y
DE SISTEMAS
E.A.P. INGENIERA DE SISTEMAS

TRADUCCION N6 CAPITULO 6
LAS MEJORES PRCTICAS PARA EL
DESARROLLO Y GESTION DE
REQUISITOS

DOCENTE:

ING. Sfora, Romn Snchez

CURSO:

INGENIERIA DE REQUISITOS

ALUMNO:
CAPCHA TRUJILLO , RAINER GIANCARLO
TUCTO GUERRA ,JULIO NILER

HUNUCO_ PER

2015

Contenido
AO DE LA DIVERSIFICACIN, PRODUCTIVA Y FORTALECIMIENTO DE LA EDUCACIN .................. 1
1.

Desarrollar un plan de necesidades. ........................................................................................... 8

2. Requisitos de escritura que cumplan los criterios de un buen requisito previsto en la Tabla
1.1. 8
3.

Identificar e involucrar a todos los actores de la tarea o proyecto. ........................................... 8

4. Asegrese de que se han identificado los objetivos de la tarea o proyecto, documentados, y

acordado por las partes interesadas. .................................................................................................. 9
5. Los talleres de requisitos de uso a lograr a una visin compartida, facilitan compromiso, y
ganan compra adentro de todos los tenedores de apuestas. ............................................................ 9
6. Proporcionar los requisitos de formacin para las asociaciones regionales, para los miembros
del personal del proyecto, y por grupos de inters. ........................................................................... 9
7. Identificar las necesidades reales. Colaborar con los clientes y usuarios en relacin con los
requisitos establecidos para identificar las necesidades reales. Mira los requisitos desde mltiples
puntos de vista [3]............................................................................................................................. 10
8.

Documento de la justificacin de cada requisito, que es, por qu es necesario. ..................... 10

9.

Utilizar tcnicas de relevamiento efectiva. ............................................................................... 10

10.

Involucrar a los clientes y usuarios de todo el esfuerzo de desarrollo. ................................ 11

11.

No haga decisiones requisitos. .............................................................................................. 11

12.

Placa no oro, es decir, aadir caractersticas o capacidades. ............................................... 11

13.

Uso de un glosario de proyectos y un proyecto acrnimos lista. ......................................... 11

14.
Iterar los requisitos y la arquitectura repetidamente para evolucionar mejores requisitos y
una arquitectura ms robusta........................................................................................................... 11
15.
Utilizar los expertos de dominio / Pymes que tienen conocimiento y experiencia en las
reas funcionales siendo abordados por el esfuerzo tcnico. .......................................................... 12
16.
Cuantificar el ROI para seleccionar los requisitos de mecanismos, prcticas, mtodos,
tcnicas,............................................................................................................................................. 12
17.

Identificar los requisitos mnimos que satisfagan las necesidades reales. ........................... 12

18.

Priorizar requisitos temprano y a menudo. .......................................................................... 13

19.

Proporcionar inspecciones de todos los documentos de requerimientos relacionados. ..... 13

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. ........................................................................................................................... 13
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. ......................................... 14

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

22.
Uso de una herramienta de requisitos de potencia industrial automatizada. Proporcionar y
utilizar atributos de requisitos. ......................................................................................................... 15
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 o empresa. Invertir
8% al 14% de los costos totales del proyecto en el (ciclo de vida del sistema) proceso de requisitos.
16
24.
Uso probada y mecanismos requerimientos familiares, enfoques, mtodos, tcnicas, y
herramientas. .................................................................................................................................... 17
25.
Establecer una meta acordada en, propsito o misin para la tarea o proyecto. Escribir (y
iterar) una tarea o visin del proyecto y documentar el alcance. .................................................... 18
26.
Desarrollar, implementar y hacer cumplir las reglas de reuniones que describen cmo el
personal del proyecto miembros han de tratarse unos a otros. ...................................................... 18
27.
Desarrollar y aplicar un conjunto de directrices para las reuniones y directrices eficaces
para la efectiva enviando por correo electrnico. ............................................................................ 19
28.

Lleve a cabo una evaluacin de riesgos de las necesidades nuevas y cambiantes............... 19

29.

Aprenda a manejar equipos con eficacia. ............................................................................. 19

30.

Establecer una mejora de la calidad y el clima mejora de procesos. .................................... 19

RESUMEN .............................................................................................................................................. 20
Caso De Estudio .................................................................................................................................... 20
Referencias ........................................................................................................................................... 24

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y

GESTION DE REQUISITOS
En los captulos anteriores he sugerido que lo haces ciertas cosas y no hacer otras cosas. En
este captulo, comparto un conjunto de mejores prcticas para el desarrollo y gestin de
requisitos. La frase "mejores prcticas" se utiliza con frecuencia en sistemas y software
ingeniera (entre muchas otras profesiones). Escuchamos y leer mucho sobre las mejores
prcticas. Sin embargo, en realidad no gastamos el tiempo y esfuerzo para evaluar, analizar,
piloto, implementar, ejecutar, e institucionalizar ellos. La razn de esto es bastante simple:
es un montn de trabajo. Se requiere lo siguiente:

Desarrollar un conocimiento profundo de la prctica;

Comunicar su valor para los compaeros de trabajo y directivos;
Lograr el 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;
La 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, tal vez incluso el diseo de una forma de medir los
resultados de su uso;
La declaracin de victoria, reconociendo que la nueva forma es mejor a la manera
antigua, tal vez incluso de celebrar el xito;
La institucionalizacin de uso de la nueva prctica en todo el proyecto u organizacin.

Visto desde esta perspectiva, es ms fcil de entender por qu las mejores prcticas no se
implementan e institucionalizado.
Tabla 6.1 proporciona una lista de las mejores prcticas para el desarrollo de los requisitos y
la gestin.
Algunas de estas prcticas se han discutido con cierto detalle en otra parte en este libro, as
que voy a limito mis comentarios acerca de ellos 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 serio 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 entrelazadas con actividades de gestin de proyectos, as como con otras
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

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 comparta la Tabla 6.1 con el equipo de trabajo o el liderazgo de
proyectos (Incluido el cliente) y seleccione conjuntamente las mejores prcticas que se
determinan en equipo se debe utilizar en su tarea o proyecto. Este artefacto est disponible
para su descarga 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 de desarrollo;
2. Requisitos de gestin;
3. La gestin de proyectos.
Dentro de cada categora, se organizan aproximadamente secuencialmente - uno hara 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 prcticas 25 recomienda acordado una meta, propsito, o se establezca la
misin para la tarea o proyecto. Careciendo de un cometido acordado, un propsito, o una
misin para la tarea o el proyecto dificultarn lograr cualquier cosa de valor. Todas las otras
mejores prcticas en la gestin de proyecto reas de direcciones categora que pueden estar
ms all del alcance de la RA. Estn probadas mejores prcticas de la industria que puede
tener un significativo positivo 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 estas prcticas con eficacia. 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 las mejores
prcticas recomendadas se discutirn en el orden en que se enumeran en Tabla 6.1.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

Tabla 6.1 Mejores prcticas para Desarrollo y Gestin de Requisitos.

Nmero

Mejores Prcticas

Desarrol
lo de
Requeri
mientos

RM

Administra
-cin de
Proyecto

Captulo
de
referencia

1,5

Desarrollar un plan de necesidades.

Escriba los requisitos que cumplen los

criterios de una buena requisito.

1,6

Identificar e involucrar a todas las partes

interesadas en la tarea o proyecto.
Asegrese de que los objetivos de la
tarea o proyecto se han identificado,
documentado, y acordado por las partes
interesadas.

1,5,6

Los talleres de requisitos de uso a lograr a

una visin compartida, facilitan
compromiso, y ganan la compra adentro
de todos los tenedores de apuestas.
Proporcionar los requisitos de formacin
para los RA, por miembros del personal
del proyecto, y por grupos de inters.
Identificar las necesidades reales.
Colaborar con los clientes y de los
usuarios en relacin con los requisitos
establecidos para identificar los
verdaderos requisitos. Mira los requisitos
desde mltiples puntos de vista.
Documento de la justificacin de cada
uno requisito, que es, por qu es
necesario).
Use requisitos eficaces recolecciones
tcnicas.
Involucrar a los clientes y usuarios en
todo el esfuerzo de desarrollo.
No tome decisiones requisitos.
Haz placa no el oro, es decir, aadir
caractersticas o capacidades).

5,6

9
10
11
12

13
14

15

2,5,6

X
X

X
X

X
X

6
6

Utilice un glosario de proyectos y un

proyecto acrnimos lista.
Iterar los requisitos y el
Arquitectura repetidamente para
evolucionar mejor requisitos y una ms
robusta arquitectura.

Utilizar los expertos de dominio / PYME

5,6

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

16

17
18
19

20

21

22

23

24

25

26

27

que son conocimientos y experiencia en

Las reas funcionales estn abordando
por la esfuerzo tcnico.
Cuantificar el retorno de la inversin para
seleccionar los requisitos mecanismos,
prcticas, mtodos, tcnicas y
herramientas que se utilizarn.
Identificar los requisitos mnimos que
satisfacer las necesidades reales.
Fije las prioridades de requisitos
tempraneros y a menudo.
Proporcionar inspecciones de todos
requisitos relacionados con los
documentos.
Lmite cambia a los requisitos y el
Adems de los nuevos requisitos
consistentemente, con presupuesto
adicional y el horario hecho disponible
por el cliente para completar la tarea,
proyecto o sistema.
Las versiones de uso y las liberaciones de
productos de trabajo a acomodar
requisitos nuevos, requisitos cambiados,
y requisitos de prioridad inferior.
Utilice una potencia industrial
automatizada herramienta requisitos.
Proporcionar y utilizar atributos de
requisitos.
Desarrollar o adaptar y utilizar
organizativa y polticas y requisitos del
proyecto proceso de requisitos que es
continuamente mejora en su tarea,
proyecto u organizacin. Invertir 8% a
14% del total los costos del proyecto en
el (ciclo de vida del sistema) proceso de
requisitos.
Requisitos Uso probadas y familiares
mecanismos, enfoques, prcticas,
mtodos, tcnicas y herramientas.

5,7

5,6

5,6

5,6

5,6

Establecer una meta acordada en,

propsito o misin para la tarea o
proyecto. Escribir (e iterar) una tarea o
visin del proyecto y el alcance
documento.
Desarrollar, implementar y hacer cumplir
reunin reglas que describen cmo el
personal del proyecto miembros han de
tratarse unos a otros.

Desarrllese y aplique un set de lneas

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

28
29
30

directivas para reuniones efectivas y las

lneas directivas para efectivo enviando
por correo electrnico.
Realizar una evaluacin del riesgo de
nuevos y cambios en los requisitos.
Aprender a manejar equipos con eficacia.
Establecer una mejora de la calidad y el
proceso de clima mejora.

3,7

X
X

X
X

X
X

7,9
8

1. Desarrollar un plan de necesidades.

Las razones para la planificacin de rendimiento con respecto a las actividades
relacionadas con los requisitos y los contenidos sugeridos de un plan de necesidades se
discuten en Los captulos 1 y 5.

2. Requisitos de escritura que cumplan los criterios de un buen

requisito previsto en la Tabla 1.1.
Si no realiza este paso, detngase aqu. Tabla 1.1 proporciona una lista de criterios
sugeridos de un buen requisito. Hay una gran cantidad de informacin acerca de este
tema disponibles-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 optar por no 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 identificados e involucrados en los requisitos
proceso de desarrollo. Con demasiada frecuencia, no nos identificamos todos los grupos
de inters 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 la
arquitectura equipos, 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.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

4. Asegrese de que se han identificado los objetivos de la tarea o

proyecto, documentados, y acordado por las partes interesadas.
Esto debe hacerse temprano y puede llevarse a cabo escribiendo una "visin y
documento de alcance "[1]. La disponibilidad de los definidos, 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 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. Los talleres de requisitos de uso a lograr a una visin compartida,

facilitan compromiso, y ganan compra adentro de todos los tenedores
de apuestas.
De todos los mtodos de recopilacin de requisitos y tcnicas, requisitos talleres parecen
ser los ms eficaces. Ellen Gottesdiener definicin de un taller requisitos proporciona
informacin detallada sobre por qu es tan [efectiva 2, p. 9]:
Un taller de requisitos es una reunin estructurada en la que un cuidado selecto grupo
de las partes interesadas y expertos en el tema trabaja en conjunto para definir, crear,
refinar, y alcanzar el cierre de las prestaciones (como los modelos y documentos) que
representan las necesidades del usuario. El beneficio del taller proceso 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 a partir del material presentado hasta ahora que es ventajoso
proporcionar capacitacin requisitos 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.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

7. Identificar las necesidades reales. Colaborar con los clientes y

usuarios en relacin con los requisitos establecidos para identificar
las necesidades reales. Mira los requisitos desde mltiples puntos de
vista [3].
Confo en que a estas alturas de entender la diferencia entre los requisitos establecidos y
requisitos reales. Su principal responsabilidad es colaborar con clientes y usuarios acerca
de los requisitos establecidos para identificar las necesidades reales.
Se trata de Papel 1 en el contexto de las funciones definidas en el Captulo 2 racin 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 PM, los clientes y usuarios de que es esencial y que
vale la pena invertir tiempo y esfuerzo aadido en los requisitos proceso, en este caso,
para revisar los requisitos establecidos y evolucionar el verdadero requisito utilizando un
concepto equipo conjunto o mecanismo. No se salte esta crtica paso a que es el
problema ms importante en la industria de la ingeniera de requisitos y que casi siempre
se presta suficiente atencin. Aplicar efectiva 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. Revise los
verdaderos requisitos de una variedad de perspectivas, a saber, los de todo el proyecto
grupos de inters.

8. Documento de la justificacin de cada requisito, que es, por qu es

necesario.
Justificacin es un atributo que se debe incluir en sus necesidades automatizados
herramienta. Experiencia en el sector muestra que al tomar el paso de la documentacin
la justificacin de cada requisito, hasta la mitad del indicado requisito pueden ser
eliminados. El ahorro en trminos de no tener que hacer seguimiento de los trabajos
tcnicos para cumplir los requisitos eliminados es, evidentemente, enorme. Por otra
parte, este esfuerzo de clarificar y endurecer los requisitos decide 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 corporativa conocimientos, reduce el riesgo en la definicin de un
producto derivado, y apoya los costos de mantenimiento y de operaciones [4].

9. Utilizar tcnicas de relevamiento efectiva.

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.
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

10

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 involucran
a clientes y los usuarios de todo el proceso de desarrollo son el diseo exitoso y 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
nosotros RA crean problemas para nuestros proyectos es tomando decisiones requisitos.
Establezca un personal poltico de no tomar decisiones requisitos. Decisiones Requisitos
son responsabilidad del cliente y usuario dentro del mecanismo de equipo conjunto.
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 acercamiento de no haciendo requisitos que las decisiones las necesidades a ser
comunicado completamente el equipo de desarrollo, para asegurar que reveladores no
hace decisiones de requisitos cualquier. Esto debera ser aclarado en el entrenamiento
relatado en requisitos provisto para el equipo de proyecto.

12.

Placa 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 (lase: causa re trabajo). Cumplir los requisitos
mnimos reales. Haga placa no oro.

13.

Uso de un glosario de proyectos y un proyecto acrnimos 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 repetidamente para
evolucionar mejores requisitos y una arquitectura ms robusta.
El punto aqu es que los requisitos y el impacto arquitectura el uno al otro. Como
modificamos la arquitectura de abordar el cumplimiento de lo real requisitos mejor,
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

11

aprender ms acerca de los requisitos y encontrar que los cambios de arquitectura nos
hacen quieren cambiar los requisitos, y alrededor vamos. Iteracin los requisitos y la
arquitectura resulta repetidamente en mejores requisitos reales y un ms robusto
arquitectura. 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 las reas funcionales siendo
abordados por el esfuerzo tcnico.
He mencionado antes algunas ventajas tradas a un proyecto por una nueva RA asignado,
como tener una nueva perspectiva, sin trabas por las restricciones y la historia del
sistema y los procedimientos legados. 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 el necesidades del cliente con una
perspectiva experimentado que puede incluir aspectos inimaginables 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 los requisitos de
mecanismos, prcticas, mtodos, tcnicas,
Proporciono informacin detallada sobre esta buena prctica en Efectivo Requisitos
Prcticas [5, pp. 50-52]. 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. Proporcionar datos
relativos al retorno de la inversin en la mejora de las prcticas de los requisitos es una
forma en que puede ganar apoyo a sus sugerencias y recomendaciones. En realidad no
es difcil para desarrollar la informacin ROI. Utilice la plantilla proporcionada en mi
anterior libro.

17.
Identificar los requisitos mnimos que satisfagan las
necesidades reales.
Algunas personas tienen dificultad con el concepto de mnimo identificacin requisitos.
Ellos interpretan esto como no hacer todo lo posible para satisfacer clientes. El punto es
que tenemos que estar en asociacin con nuestros clientes, comprometido con el xito
del proyecto, as como el desarrollo requisitos proceso debe dar lugar a un conjunto de
requisitos que son el mnimo necesario para satisfacer las necesidades reales. Todos los
requisitos 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 (que se define como un sistema eficaz, terminado en tiempo, dentro del
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

12

presupuesto, con una relacin de sociedad de ganar-ganar en todo el ciclo de vida del
sistema). 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. Si usted est teniendo dificultad para entender o aceptar
este concepto, lea "encuentre el requisito mnimo: Cualquier cosa ms es demasiado ",
por Neal Whitten [6]. Determinacin cules son los requisitos mnimos adecuadamente
priorizadas debe involucrar a los miembros del equipo de desarrollo, la comunidad de
usuarios, y el proyecto CCB-esta trada debe trabajar en conjunto para recomendar el
establecimiento de prioridades y la financiacin de las necesidades.

18.

Priorizar requisitos temprano y a menudo.

Es igualmente importante dar prioridad a las necesidades reales temprano y con

frecuencia. Darse Cuenta De (Y ayudar a sus clientes y usuarios a entender) que nunca
hay suficiente tiempo y dinero para hacer todo y que todos los requisitos no son de igual
prioridad. Utilice su equipo conjunto o un mecanismo similar a un acuerdo
conjuntamente sobre requisitos prioridades. Hay artculos y herramientas disponibles
para
ayuda.1 Tome el tiempo para leerlos y utilizarlos. No dejes para abogar y la aplicacin de
mecanismos, prcticas, mtodos, tcnicas y herramientas que mejorar las posibilidades
de que su proyecto tenga xito. Una vez que las necesidades reales se identifican y
priorizan el desarrollo equipo puede 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 productos de
trabajo desarrollados 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 documentos de
requerimientos relacionados est prevista 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 el enfoque para
identificar las necesidades reales).

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

13

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, el cliente, y los usuarios con la industria experimentar y adquirir el
compromiso de controlar los cambios y nuevos requisitos. Por ejemplo, considere el
enfoque de tener subsecuente versiones y lanzamientos de productos de trabajo, en
lugar de pretender que el proyecto puede acomodar cambios mientras est en
desarrollo.
Por supuesto, usted tendr que satisfacer a ti mismo que 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? Un anlisis cuidadoso
permitir la eliminacin de hasta la mitad de las solicitudes. Ms importante, 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. Crear y
mantener una asociacin con el objetivo principal de la finalizacin con xito del
proyecto. La asociacin es sobre el compromiso para el xito y ser flexible para lograr el
resultado deseado.
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 el xito del proyecto.
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.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

14

22.
Uso de una herramienta de requisitos de potencia industrial
automatizada. Proporcionar y utilizar atributos de requisitos.
Seleccione su herramienta requisitos de potencia industrial automatizada temprana y
cuidado.
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. La herramienta equivocada o una herramienta que es demasiado
complejo para el trabajo pueden retrasar los esfuerzos del proyecto. Asegrese de
que utilizan una probada requisitos automatizados herramienta que no puede
permitirse el lujo de invertir la tiempo y el esfuerzo requerido para escribir software
que realiza funciones tales como trazabilidad. Dadas las herramientas comerciales
que estn disponibles, no es rentable para desarrollar sus propias capacidades
automatizadas herramienta requisitos.
Proporcionar capacitacin formal para los que van a usar la herramienta ms
frecuentemente esta es una inversin valiosa y no debe ser pasado por alto.
Determinar los atributos de los requisitos que se necesitan, ver la discusin de
atributos en el captulo 5. Demasiado a menudo, la eleccin de los requisitos
automatizados herramienta para ser utilizada 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 diferentes
que apoyaba era la siguiente:
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, hemos propuesto un enfoque orientado a objetos utilizando el Rational
Unified Proceso (RUP) y la herramienta Rational Suite-RequisitePro 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
tcnica director dio una clase de casos de uso en una universidad local y fue ya
estn familiarizados con el Rational Suite.
Onstill otro proyecto, el cliente especifica Rational RequisitePro en el SOW.
Y en otra, el proyecto PUERTAS utiliza porque el cliente utiliza PUERTAS.
As, de cinco proyectos, la experiencia de este RA era que los requisitos automatizados
herramienta fue seleccionado en base a criterios arbitrarios en los cinco situacionesdebido 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!
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

15

El enfoque en la seleccin de los requisitos del proyecto herramienta fue en contraste

con eso aplica para CM y herramientas de prueba, donde ms
Se utilizaron procesos de pensamiento lgico y criterios especficos. La RA debe
recomendar que un estudio sobre el comercio requisitos herramientas [7] ser escrito
para asegurar que los criterios para la seleccin de la herramienta automatizada
requisitos son consistentes con las necesidades del proyecto.

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 o empresa. Invertir 8% al 14% de los
costos totales del proyecto en el (ciclo de vida del sistema) proceso de
requisitos.
Es til tener (y usar) una poltica organizacional en materia de requisitos. Todos estamos
familiarizados con los proyectos y organizaciones que tienen las polticas, pero no las
utilice en la prctica. Estoy hablando de una situacin diferente: Recomiendo que las
organizaciones y los proyectos tienen polticas y los usan! Desarrollo de la poltica de la
organizacin debe involucrar a la alta direccin e incluir su direccin en la que los
requisitos se utilizarn como base para actividades de ingeniera y de gestin. Las
polticas de la organizacin en relacin con requisitos pueden ser tan simples como los
sugeridos por los dos
el desarrollo de los requisitos y RM:
En cuanto al desarrollo requisitos: "Con el fin de identificar y satisfacer
necesidades de los clientes, los proyectos debern: (a) Reunir las necesidades de
las partes interesadas, (b) Formular producto y los requisitos de componente de
producto, y (c) Analizar y validar estos requisitos.
En cuanto RM: "Con el fin de garantizar que los clientes necesidades estn
satisfechas, proyectos sern: (a) Administrar los requisitos y exigencias cambios, y
(b) Identificar inconsistencias entre el trabajo del proyecto y requisitos.
Debido a los requisitos relacionados con las actividades que se realizan en los proyectos
son fundamentales para el xito de los proyectos, yo abogo por un proyecto ms
detallado poltica de requisitos, como el previsto en Prcticas Requisitos eficaces [5, pp.
119-122] y tambin est disponible en mi sitio web (www.ralphyoung.net).

Este artefacto sirve como una plantilla que debes adaptar (modificar) a las necesidades
de su proyecto en su entorno. Una alternativa a tener un proyecto poltico de los
requisitos es incorporar componentes necesarios en el proyecto de proceso de
requisitos.
Desarrollar o adaptar y utilizar un proceso de requisitos documentados. Ver
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

16

Captulo 8 de este libro para obtener orientacin sobre cmo disear un proceso. No es
difcil (O al menos, no tiene que ser difcil) para disear o adaptar un proceso. Si usted no
est familiarizado con el diseo y el uso de los procesos, es posible que desee involucrar
a la ayuda de alguien que conoce muy bien haciendo esto para servir un facilitador para
sus grupos de inters. Es importante que los miembros de la equipo del proyecto para
tener una buena comprensin de los procesos del equipo es utilizando. Tmese el
tiempo para informar a todo el mundo acerca de los procesos, y garantizar que hay
consenso y miembro aceptado que se enfoque basado en procesos del equipo puede ser
capaz de ofrecer mejoras, basado en sus experiencias.
Los datos proporcionados en la Figura 4.1 de Prcticas Requisitos eficaces [5]
proporcionan un caso convincente para invertir 8% al 14% de los costos del proyecto en
el proyecto de proceso de requisitos. Debera ser evidente a partir de la discusin hasta
ahora que la prestacin de mejores prcticas de requisitos es una buena inversin que
produce el apalancamiento en el control de costes, por ejemplo, de re trabajo (40% a
50% de los costos totales del proyecto promedio). Fomentar la inversin en el proyecto
de proceso de requisitos y el uso de requisitos eficaces prcticas proporcionan
oportunidades para la RA tengan un impacto positivo importante en el proyecto el xito.

24.
Uso probada y mecanismos requerimientos familiares,
enfoques, mtodos, tcnicas, 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
para mantenerlos todo en su mente:
Mecanismos: el equipo conjunto (o lo que decide llamar a esta colaboracin
mecanismo); un conjunto de reglas de conducta en su tarea, proyecto u
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; la planificacin de proyectos y el
seguimiento; formacin; CM; QA; el uso de tcnicas para facilitar la comunicacin
de proyectos; medicin; etcetera;
Mtodos: recopilacin de requisitos mtodos como entrevistas, documentos
anlisis, talleres requisitos, prototipos, guiones grficos, escenarios, y modelado;
Tcnicas: la gestin de riesgos del proyecto, revisiones por pares, DP, "bolsas
marrones";

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

17

 Herramientas: ReqPro, PUERTAS, otros requisitos automatizados herramientas

observaron en la Tabla 5.7; herramientas automatizadas de gestin de riesgos;
brickcharts; 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 las personas 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.
Establecer una meta acordada en, propsito o misin para la
tarea o proyecto. Escribir (y iterar) 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 lograr cualquier cosa
de valor. Uno tiene que ser capaz de articular la meta y para obtener el apoyo de las
partes interesadas para lograrlo. La escritura y la iteracin de un tarea o visin del
proyecto y documentar el alcance proporciona una base comn para identificacin y
priorizacin de objetivos ms especficos y la identificacin de la verdadera requisitos.

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;
Mantenga una mente abierta;
pregunta y participar;
Llegue a tiempo;
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

18

 Mantenga interrupciones al mnimo;

Administrar por hecho.
Estas normas se publican en salas de conferencias en nuestra empresa. La gente es
llamada a la tarea cuando violan una de estas reglas. Me siento facultado para contribuir
mis mejores esfuerzos. S que mis compaeros de trabajo me van a respetar, incluso
cuando mis ideas parecen inusuales. 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 permitida conversacin lateral. 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 efectiva enviando por correo
electrnico.
Pasamos mucho tiempo en reuniones y leer y escribir e-mail. 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: ver Efectiva
Requisitos Prcticas [5, pp. 165-167 y pp. 167-172, respectivamente].
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.
Lleve a cabo una evaluacin de riesgos de las necesidades
nuevas y cambiantes.
Se proporciona orientacin para la forma de realizar las evaluaciones de riesgos
requisitos relacionados 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, para obtener las compras de los interesados, y para lograr
resultados trabajando en equipo. La RA debe desarrollar la habilidad de gestionar
equipos eficazmente. Hay sesiones de capacitacin y talleres se puede asistir para
aprender y practicar las habilidades y tcnicas necesarias. Uno de los mejores los libros
correspondientes a los equipos de gestin es Scholtes et al. Es El Manual Equipo [9].

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.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

19

RESUMEN
Este captulo presenta 30 mejores prcticas para el desarrollo y requisitos gestin
para su consideracin. Uno no puede hacer todo, al menos no a una 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.
Para ello, en colaboracin con su equipo de proyecto y su cliente. Obtenga su compra
y apoyo a las mejores prcticas seleccionadas. Comunicar lo que est haciendo por
los medios de las reuniones del personal del proyecto o marrn-bags. 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 junto en concierto 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 reprocured 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 en litigios en su 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 necesitaba requisitos y haba contrado aos antes de un estudio
de viabilidad que incluyen 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 de la Sede
Red de rea local (LAN), "y (2)" Revisin y validar el Estudio (antes), frente a las exigencias
actuales. "
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

20

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 rea cambiada e
identificada donde era necesario requisitos adicionales de trabajo.
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 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
diferentemente en cliente servidor arquitectura.
Al expresar cmo se aplicaran los requisitos, 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 su capacidad de
transmisin.
El trabajo continu sin una comunicacin efectiva entre el gobierno y el contratista. No se
resolvieron las cuestiones pendientes. En una revisin del diseo principal, el contratista y
cierto personal del gobierno se reuni 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 la realizacin del sistema proyectado fecha 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 contratista, y consigui trabajar en marcha para construir rpidamente el sistema.
En las pruebas de aceptacin del sistema, el sistema explot con la corrupcin masiva de
datos, 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
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

21

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
agencywide. El desempeo no se haba definido los requisitos 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. Ningn general, se desarroll requisitos unificados documento o repositorio.
Requisitos se encontraban en numerosas fuentes de variables edad y validez (por
ejemplo, las notas escritas a mano por el gobierno personal de entregables
revisaron). En algunos casos, requisitos eran contradictorios o no existen. reas
identificadas en la revisin y validacin de documentos de requisitos previos que
necesitan otros requisitos definicin se 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 las
transmisiones, mientras que no se comunica la arquitectura general para el sistema o
permitir que el contratista para disear el arquitectura, fue una sobrevaloracin de
los requisitos de diseo y un restriccin en el sistema, uno que (como se vio despus)
no iba a funcionar.
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 la aceptacin de ese 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
original contrato fue terminado, (3) el sistema desarrollado por el segundo contratista no
funcion, (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
LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

22

se desarrollaron, (7) aos los pas en litigios costosos, (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

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

23

Referencias
[1] Wiegers, KE, Requisitos de software, 2 ed, Redmond, WA:. Microsoft Press,
2003, 77-93.
[2] Gottesdiener, E., Requisitos de Colaboracin: Talleres para definir las necesidades.
Boston, MA: Addison-Wesley, 2002.
[3] Sommerville, I., P. Sawyer, y S. Viller, "Puntos de vista de Requisitos
Elicitacin:. Un enfoque prctico "Actas de la Conferencia Internacional 1998
en Ingeniera de Requisitos (ICRE'98), 6 al 10 04 1998, Colorado Springs, CO,
Nueva York: IEEE Computer Society, 1998, 74-81. Ver http://computer.org/
procedimientos / ICRE / 8356 / 8356toc.htm. Vase tambin el Captulo 13 de I. Sommerville y
De P. Sawyer Ingeniera de Requisitos: Una gua de buenas prcticas, Nueva York: John Wiley
& Sons, 1997, y G. Kotonya y Ingeniera de Requisitos de I. Sommerville:
Procesos y Tcnicas, Chichester, UK: John Wiley & Sons, 1998.
[4] Los ganchos, SI, y KA Farry, los productos centrados en el cliente: Creacin de productos de xito
a travs de gestin de requisitos inteligente, Nueva York: AMACOM, 2001, 120-133.
[5] Young, RR, Prcticas Requisitos eficaces, Boston, MA: Addison-Wesley, 2001.
[6] Whitten, N., "Requisitos mnimos Meet: Algo ms es demasiado," PM
Network, septiembre de 1998, p. 19.
[7] jvenes, RR, "Requisitos de Herramientas para el Estudio del Comercio", en www.ralphyoung.net/
publicaciones / Requirements_Tools_Trade_Study1.doc.
[8] El sitio Web CMMI, en www.sei.cmu.edu/cmmi.
[9] Scholtes, PR, et al, El Manual del equipo, 2 ed, Madison, WI:.. Oriel, Inc., 2001.

LAS MEJORES PRCTICAS PARA EL DESARROLLO Y GESTION DE REQUISITOS

24