La importancia de RequisitosEl propsito de este libro es ayudar
a mejorar la prctica de la ingeniera de requisitos. Requisitos de
ingeniera es difcil. No es slo una simple cuestin de escribir lo
que el cliente dice que quiere. Un problema fundamental en los
negocios es que los requisitos son inherentemente dinmico; van a
cambiar con el tiempo ya que nuestra comprensin del problema que
estamos tratando de resolver los cambios. La importancia de los
buenos requisitos y la naturaleza dinmica subyacente del proceso
significa que debemos ser tan precisa tasa posible, y sin embargo,
ser flexibles. Flexible no significa "dbil", pero en lugar de que
tenemos un proceso para desarrollar los requisitos y servicial
requisitos cambiado como aclaramos las necesidades reales de los
clientes. Requisitos prcticas ineficaces son un problema de toda la
industria. Esta es un rea en la que se puede tener un impacto
positivo. Se necesita un enfoque ms disciplinado para el desarrollo
y gestin de requisitos con el fin de mejorar las tasas de xito de
los proyectos. Un alarmante 53% de la inversin de la industria en
proyectos de desarrollo tcnico es una vctima de los excesos de
costes y proyectos fallidos.En este captulo se define el trmino
"prescripcin", explica por qu requisitos son importantes, y los
defensores de la planificacin para definir la estrategia y las
actividades requisitos. Se sugiere el uso de un proceso de
requisitos definidos y documentados, que invertir ms en el proceso
de requisitos tendr un gran retorno de la inversin, y que los
requisitos de servir un papel crucial en los negocios en el riesgo
Ing. gerentes. Se recomienda que considere ciertos factores en la
toma de sus decisiones de carrera. Se sugiere que gran parte del
asesoramiento prestado en el libro es aplicable a los proyectos de
todos los tamaos.Cules son los requisitos y por qu son
importantes?Un requisito es un atributo necesario en un sistema,
una declaracin que identifica una capacidad, caracterstica, o
factor de calidad de un sistema en orden para que tenga valor y
utilidad a un cliente o usuario. Los requisitos son importantes
porque constituyen la base de todo el trabajo de desarrollo que
sigue. Una vez que se establecen los requisitos, los
desarrolladores de iniciar otro trabajo tcnico: diseo de sistemas,
desarrollo, pruebas, implementacin y operacin.Con demasiada
frecuencia, hay una tendencia a querer comenzar lo que se refiere a
menudo como "el verdadero trabajo" (en desarrollo, o de
programacin, el software) demasiado rpido. Clientes y directores de
proyectos (PMS) Muchos parecen creer que el trabajo de programacin
actual ("codificacin") indica que se est avanzando. De acuerdo a la
experiencia de la industria, el tiempo y el esfuerzo insuficiente
se gastan en las actividades relacionadas con los requisitos
relacionados con el desarrollo del sistema. Experiencia en el
sector confirma que un mejor enfoque consiste en invertir
ms tiempo en la recopilacin de requisitos, anlisis y gestin. La
razn es que, por lo general, el trabajo de codificacin se inicia
mucho antes de lo que debera ser porque se necesita ms tiempo para
identificar las necesidades "reales" y planificar actividades
requisitos relacionados (descritas a continuacin).Hay una
diferencia significativa entre los requisitos "establecidos" y
requerimientos "reales". Requisitos indicados son los
proporcionados por un cliente en el comienzo de un esfuerzo de
desarrollo de sistemas o software, por ejemplo, en una solicitud de
informacin, propuesta o cotizacin o en una declaracin de trabajo
(SOW). Requisitos reales son los que reflejan las necesidades
comprobadas de los usuarios de un sistema o capacidad particular. A
menudo hay una gran diferencia entre los requisitos establecidos y
los requisitos reales. Se requiere el anlisis de los requisitos
establecidos para determinar y refinar cliente real y las
necesidades del usuario y las expectativas del sistema entregado.
Los requisitos deben ser filtrados por un proceso de clarificacin
de su ING media y la identificacin de otros aspectos que deben
tenerse en cuenta. Para citar un ejemplo sencillo, requisitos
analistas (RA) estn ms familiarizados con la necesidad de los
requisitos del estado claramente (ver los criterios para un buen
requisito pro provisto abajo). Hay muchas maneras en las que la
capacidad, la comprensin y la comunicacin del significado de cada
uno y todos los requisitos pueden ser diferentes a un usuario que a
un desarrollador. Por lo tanto, es vital (y el ahorro de tiempo)
que se aclaren todos los requisitos a travs del mecanismo de un
cliente / usuario y el esfuerzo conjunto de la RA. Los clientes y
los usuarios necesitan el apoyo de tcnicamente capacitados y
experimentados profesionales, y viceversa, para garantizar una
comunicacin eficaz. Desarrolladores necesitan tener ese mismo
entendimiento para que la solucin se defina las direcciones de las
necesidades en la forma en que todos esperan. Los malentendidos de
requisitos resultan en un esfuerzo perdido y re trabajo. Otra idea
importante es que a veces los requisitos son incognoscibles al
comienzo de un esfuerzo de desarrollo, ya que se ven afectados por
las nuevas capacidades que debe proporcionarse en el nuevo sistema.
Esto sugiere la necesidad de planificar para las necesidades nuevas
y modificadas para proporcionar un grado de flexibilidad.La
identificacin de las necesidades reales requiere un proceso de
requisitos interactivos e iterativos, apoyados por efectivos
prcticas, procesos, mecanismos, mtodos, tcnicas y herramientas.
Este libro proporciona una descripcin de cmo la RA puede
utilizarlas en la realizacin de los trabajos necesarios. En un
anterior libro, Prcticas Requisitos eficaces [1], que describe lo
que debe hacerse y proporcionar un amplio conjunto de referencias a
muchas de las mejores publicaciones en la literatura de la
industria. Este libro est destinado a proporcionar un manual
conciso que sirve como una gua de referencia turstica para la AR o
ingeniero y gerente de requisitos en
la ingeniera y la informtica. Tambin proporciona referencias
actualizadas. El proceso de requisitos no tiene por qu ser
complicado o costoso. Sin embargo, se requiere un proceso de
requisitos para un proyecto de cualquier tamao. Es ms importante
que un proyecto u organizacin tienen un proceso de requisitos
definidos y documentados. La naturaleza de los componentes
especficos de la definida proceso puede ser mejorado basado en la
experiencia.Por qu plan?Es bien sabido y entendido por la mayora de
la gente que un poco de planificacin va un largo camino. Por
ejemplo, antes de partir en un viaje en automvil, la comprobacin de
un mapa para localizar el destino y, tal vez, incluso la
planificacin de una ruta puede ser un tiempo bien empleado. Sin
embargo, con frecuencia cobramos adelante con el hacer con poca o
ninguna planificacin, no? Es la naturaleza humana querer seguir
adelante con el trabajo necesario sin hacer mucha
planificacin.Sistemas de desarrollo de software y administradores
de desarrollo y los profesionales estn familiarizados con varios
tipos de planes: el plan del proyecto, los sistemas de planes de
gestin de la ingeniera (SEMP), la garanta de calidad (QA) plan,
gestin de la configuracin (CM) plan, plan de desarrollo de software
(SDP), plan de pruebas , etctera. Sin embargo, el concepto de un
plan de necesidades puede ser nuevo para usted. Aprovechando
requisitos relacionados actividades tiene un gran poder y efecto.
Escribir un plan de requisitos maximiza el valor. Un plan de
necesidades define cmo los requerimientos reales evolucionarn y cmo
se abordarn las actividades requisitos.Escribir un plan de
requisitos (RP) facilita la comprensin de las actividades y
esfuerzos que deben llevarse a cabo para poner en prctica un
proceso de requisitos eficaz para un esfuerzo de desarrollo en
particular. Los detalles adicionales referentes al plan de
necesidades se proporcionan a continuacin.Una estrategia sugeridaYo
sugiero una estrategia que incluye (1) escribir un plan de
necesidades, (2) el diseo o la adaptacin de un proceso de
requisitos para su proyecto, (3) la inversin en las actividades
relacionadas con los requisitos en el ciclo de vida del sistema, y
(4) la utilizacin de los requisitos eficaces prcticas, mecanismos,
mtodos, tcnicas, herramientas y capacitacin que se describen en
este libro.Requisitos Las actividades en el ciclo de vida del
sistemaLos administradores a menudo piensan de los requisitos de
las actividades relacionadas como que consiste principalmente de
los requisitos de recopilacin y gestin de los cambios en los
requisitos de todo el ciclo de vida. En realidad, hay varios otros
requisitos relacionados con las actividades que deben ser abordados
en el ciclo de vida del sistema:
La identificacin de los grupos de inters: Esto incluye cualquier
persona que tenga un inters en el sistema o en sus cualidades que
poseen que satisfagan las necesidades particulares. Profundizar en
el conocimiento de las necesidades de los clientes y usuarios para
el sistema planificado y sus expectativas de que: Esto se refiere a
menudo como la obtencin de requisitos. Tenga en cuenta que los
requisitos pueden incluir varios tipos. Tipos de requisitos se
discuten en el Captulo 4. Requisitos reuniendo tcnicas se discuten
en el Captulo 5. Identificacin de requisitos: Se trata de afirmar
requisitos en oraciones simples y proporcionndoles como un
conjunto. Necesidades o requerimientos de negocio son las
actividades esenciales de una empresa. Se derivan de las metas
empresarial (los objetivos de la empresa). Escenarios de negocios
pueden ser utilizados como una tcnica para la comprensin de los
requerimientos del negocio. Un factor clave en el xito de un
sistema es la medida en que es compatible con los requerimientos
del negocio y facilita una organizacin en el logro de ellos.
Clarificar y reafirmar los requisitos: Esto se hace para garantizar
que se describen las necesidades reales del cliente y estn en una
forma que pueda ser entendida y utilizada por los desarrolladores
del sistema. El anlisis de los requisitos: Esto se hace para
asegurarse de que estn bien definidos y que se ajusten a los
criterios de una buena requisito (siempre ms adelante). La
definicin de los requisitos de forma que significa lo mismo para
todos los grupos de inters: Tenga en cuenta que cada grupo de
inters puede tener una perspectiva muy diferente del sistema y los
requisitos del sistema. A veces esto requiere invertir tiempo
significativo el aprendizaje de un vocabulario especial o lxico
proyecto. A menudo se requiere gastar mucho tiempo y esfuerzo para
lograr un entendimiento comn. Especificar los requisitos: Esto
requiere incluidos todos los detalles precisos de cada requisito de
modo que se puede incluir en un documento de especificacin u otra
documentacin, en funcin del tamao del proyecto. Priorizar los
requisitos: Todos requisitos no son de igual importancia para los
clientes y usuarios del sistema de planificacin. Algunos son
crticos, algunos de prioridad relativamente alta, algunos de
prioridad normal o promedio, y algunos incluso de menor prioridad.
Es importante dar prioridad a todos los requisitos porque nunca hay
suficiente tiempo o dinero para hacer todo lo que nos gustara hacer
en nuestros sistemas desarrollados. Dar prioridad a los requisitos
proporciona la oportunidad de abordar la prioridad ms alta primero
y posiblemente lanzar una versin de un producto despus de que las
direcciones
necesidades de menor prioridad. Priorizar ayuda a asegurar que
una cantidad adecuada de la inversin que se haga en el cumplimiento
de diversos necesidades.1 cliente Derivado requisitos: Hay algunos
requisitos que se producen debido al diseo de un sistema, pero no
proporcionan un beneficio directo para el usuario final. Un
requisito para el almacenamiento de disco podra resultar de la
necesidad de almacenar una gran cantidad de datos, por ejemplo.
requisitos de particionalmente: Clasificamos requisitos que los que
pueden ser satisfechas por hardware, software, capacitacin y
documentacin, por ejemplo. A menudo, este proceso resulta ser ms
compleja de lo que anticipamos cuando algunos requerimientos son
satisfechos por ms de una categora. Asignacin de requisitos:
Asignamos requisitos a diferentes subsistemas y componentes del
sistema. Las asignaciones pueden no siempre ser satisfechas por un
solo subsistema o componente. requisitos de seguimiento:
Necesitamos la capacidad de rastrear o pista donde en el sistema se
satisface cada requisito, para que podamos verificar que se est
abordando cada requisito. Esto es ms a menudo lleva a cabo a travs
del uso de una herramienta de requisitos automatizado. requisitos
Gestin: Tenemos que ser capaces de aadir, eliminar y modificar los
requisitos durante todas las fases de diseo de sistemas,
desarrollo, integracin, pruebas, despliegue y operacin. El
repositorio requisitos consiste en un conjunto de artefactos y
bases de datos. Se describe en el captulo 5. Prueba y requisitos
que verifican: Este es el proceso de comprobacin de los requisitos,
diseos, cdigos, planes de prueba y productos de sistemas para
asegurar que se cumplen los requisitos. Validacin de requisitos:
Este es el proceso para confirmar que los requisitos reales se
implementan en el sistema entregado. El orden de validacin de
requisitos debe priorizar ya que hay una cantidad limitada de
fondos disponibles.La inversin en el Proceso de RequisitosLa
inversin promedio de la industria en el proceso de los requisitos
para un sistema tpico es del 2% al 3% del costo total del proyecto.
Debera ser evidente a partir de la informacin ya presentada que
esta cantidad de inversin es inadecuada y de hecho es la causa
fundamental del fracaso de muchos proyectos. Los datos de la
Aeronutica y del Espacio de los EEUU (NASA) que se describen en [2]
proporcionan un mensaje claro y poderoso: proyectos que gastan la
media del sector del 2% al 3% del total del proyecto de coste /
esfuerzo de los requisitos (ciclo de vida completo) proceso
experimentado un 80% a 200% costo de ejecucin excesivo, mientras
que los proyectos que invirtieron 8% al 14% del total del proyecto
de coste / esfuerzo en el proceso de requisitos tenan 0% a 50%
excesos [2, p. 9]. (Obviamente, nuestra meta no es tener excesos en
absoluto, sin embargo, una saturacin del pequeo es preferible a uno
ms grande!) Este libro describe cmo lograr un nivel adecuado de
inversin en el proceso de los requisitos y los beneficios
asociados.
Un Enfoque basado en procesosEn las ltimas dos dcadas, ha habido
un considerable debate sobre el valor de un "enfoque basado en
procesos." Por un enfoque basado en procesos, me refiero a
desarrollar y utilizar una descripcin, un diagrama de flujo proceso
documentado y una descripcin del proceso que lo acompaa (PD) de un
conjunto de actividades que se traduce en la realizacin de una
tarea o logro de un resultado. Basado en mi experiencia, hay un
gran valor a la utilizacin de un enfoque basado en procesos: Los
que apoyan el documento de actividad las acciones o actividades
involucradas en conseguir hacer algo. Una vez documentado, hay una
(compartido) entendimiento comn de lo que se trata. El proceso
documentado puede ser entendido por todos los que estn
involucrados. los involucrados, que tiene un entendimiento comn,
puede sugerir mejoras en el proceso (que permitan la mejora
continua y el empoderamiento de los que estn involucrados para
aportar ideas para hacer mejor el proceso).Se han desarrollado
varios modelos generales de proceso. Por ejemplo, el Modelo de
Madurez de Capacidades (CMM) [3] desarrollado por el ingeniero de
software ing Institute (SEI) de la Universidad Carnegie Mellon en
finales de 1980 proporciona un marco estndar de la industria para
evaluar la madurez / capacidad de un proceso de desarrollo. La
versin actual de este modelo se llama el Capability Maturity Model
Integration (CMMI) [4]. Su xito se debe a la capacidad del modelo
para discernir si el software se est desarrollando de manera ms
efectiva. Uno puede decir si el esfuerzo de desarrollo es "mejor" o
"peor" en el tiempo. Algunos PMs pueden cuestionar el valor de la
mejora de procesos, en la creencia de que desva recursos de su
principal responsabilidad de satisfacer las necesidades de los
clientes y que la mejora de procesos cuesta demasiado dinero.
Industria mantenidos por el SEI reflejan un 7: 1 retorno de la
inversin (ROI) del proceso mejora. 2 Otros datos de la industria
informan constantemente del 40% al 50% de la reanudacin de los
proyectos de desarrollo. La reduccin de la reanudacin es un
objetivo lucrativo para los esfuerzos de mejora de procesos. La
reduccin de re trabajo puede proporcionar los recursos para las
iniciativas de mejora de procesos toma insuficientemente.Adems, los
modelos de procesos requisitos estn disponibles; por ejemplo, uno
est dentro de mi libro anterior y disponible en mi sitio Web (www
ralphyoung.net.); el modelo espiral de la ingeniera de requisitos;
y un modelo se proporciona en Dominar el Proceso Requisitos [5].El
Plan de RequisitosUn plan de necesidades debe ser desarrollado por
la AR temprana, ya sea durante la fase de preparacin de la
propuesta o poco despus de que se tom la decisin de seguir adelante
con un proyecto de desarrollo o tarea. El propsito del plan de
necesidades es determinar y documentar cmo se desarrollaron las
necesidades reales y cmo se abordarn las actividades relacionadas
con los requisitos en el ciclo de vida del sistema (enumerados y
descritos anteriormente). A continuacin se presenta una lista de
temas sugeridos para este plan y una descripcin de cada tema
Propsito (del plan de requisitos): Esto se define en el prrafo
anterior. Resumen del contrato / proyecto: Un resumen de alto nivel
de los objetivos del sistema o software debe ser proporcionada.
Esta seccin puede ser extrado de otros documentos como un documento
de visin y alcance que pueden haber sido escrito anteriormente para
describir la intencin general. Antecedentes: En esta seccin se debe
describir la situacin que llev a la decisin de desarrollar el
sistema o software. Debe identificar los principales grupos de
interesados, aquellas que tienen un inters en el sistema, como el
cliente (la persona u organizacin que proporciona los fondos para
pagar por el proyecto o sus productos finales), diversas categoras
de usuarios, desarrolladores y proveedores principales. Evolucin de
los requisitos: Un mecanismo debe ser acordados entre los clientes
/ usuarios y el equipo de desarrollo para revisar los requisitos
establecidos y evolucionar las necesidades reales. Los clientes
pueden resistir este esfuerzo, en la creencia de que ya tienen un
"buen" conjunto de requisitos. La RA debe estar familiarizado con
experiencia en la industria Normas referentes a cuntos proyectos
han fallado y cuntos ms han sido seriamente y negativamente
afectados por una falta de inversin en este paso crtico [1, p. 48].
Un mecanismo es una manera de hacer algo o de alcanzar un
resultado. El mecanismo recomendado evolucionando las necesidades
reales es un equipo cooperativo o conjunto compuesto por uno o unos
pocos representantes de los usuarios y un nmero similar de
desarrolladores tcnicamente competentes. Los miembros del equipo
conjunto deben revisar los requisitos para garantizar que se
cumplen los criterios de un buen requisito previsto en la Tabla
1.1. Tambin la justificacin de cada requisito (por qu es necesario)
debe ser documentado. Experiencia en el sector es que al tomar un
paso, hasta la mitad de los requisitos puede ser eliminado. Los
roles y responsabilidades del personal del proyecto que participan
en actividades relacionadas con los requisitos de: Incluso en un
pequeo proyecto, es probable que ms de una persona se involucra con
las actividades relacionadas con los requisitos. Es til aclarar y
documentar estas funciones, por lo que todo el mundo entiende sus
responsabilidades nicas y comunes. Por ejemplo, alguien debe ser
designado para proporcionar capacitacin requisitos (el contenido de
este entrenamiento se describe en el captulo 5). Otra persona ser
responsable de la herramienta requisitos automatizado. Sin embargo,
otra persona puede tener la responsabilidad de los procesos clave
que se utilizarn en el proyecto, INCLUYENDO ing el proceso de
requisitos. Otra puede ser el responsable de disear la arquitectura
(la estructura subyacente del sistema o software). Dado que los
requisitos y el impacto arquitectura entre s, una prctica
recomendada es de requisitos para recorrer los requisitos y la
arquitectura en varias ocasiones, esto se traduce en requisitos ms
fuertes y una arquitectura ms robusta [1, pp. 131-158].
Tabla 1.1 Criterios de un buen RequisitoCada individuo debe ser
RequisitoNecesario: Si el sistema puede satisfacer las necesidades
reales priorizadas sin el requisito, no es necesario.Factible: El
requisito es factible y puede llevarse a cabo dentro del
presupuesto y el calendario.Correcto: Los hechos relacionados con
el requisito son exactos, y es tcnicamente y jurdicamente
posible.Conciso: El requisito se afirma con sencillez.Inequvoca: El
requisito se puede interpretar de una sola manera.Completo: Todas
las condiciones en las que se aplica el requisito se expresan, y se
expresa toda una idea o declaracin.Consistente: No est en conflicto
con otros requisitos.Verificable: Implementacin de la exigencia en
el sistema se puede probar.Trazabilidad: La fuente de la obligacin
se puede remontar, y puede ser seguido en todo el sistema (por
ejemplo, para el diseo, cdigo, prueba y documentacin).Numerado: El
requisito es asignado a un componente del sistema diseado.Diseo
independiente: No plantean una solucin especfica aplicacin.No
redundante: No es un requisito duplicado.Escrito utilizando la
construccin estndar: El requisito se afirma como un imperativo el
uso de "deber".Asignado un identificador nico: Cada requisito deber
tener un nmero de identificacin nico.Desprovisto de clusulas de
escape: El lenguaje no debe incluir frases como "si", "cundo",
"pero", "excepto""A menos", y "si bien". El lenguaje no debe ser
especulativo o general (es decir, evitar expresiones como "por lo
general", "general", "frecuencia", "normalmente", y
"normalmente").
Definicin del proceso de requisitos que se utilizar: Como se
seal anteriormente, un proceso documentado requisitos es esencial.
Un proceso puede ser pensado como un diagrama de flujo (que indica
los pasos que llevan a cabo y la persona o la organizacin que lleva
a cabo cada paso) acompaado de una PD narrativa que indica, por
ejemplo, el nombre del proceso, sus clientes, insumos para el
proceso , salidas del proceso, las tareas realizadas en el proceso,
la persona u organizacin de realizar cada tarea, y algunas medidas
(mtricas) que pueden ser utilizados para evaluar la calidad de los
productos producidos por el proceso y el rendimiento del proceso.
La experiencia demuestra que es una buena prctica de involucrar a
los principales actores de un proceso en su construccin. Este
enfoque fomenta la comprensin, la integridad y bluyn al proceso
definido, as como el compromiso de usarlo. Los mecanismos, mtodos,
tcnicas y herramientas para ser utilizadas: Varios ejemplos de cada
categora se describen en este libro. Obviamente, algunos son ms
adecuados en algunos casos que en otros, y algunos son
particularmente tiles en situaciones especficas. Los especficos
mecanismos, mtodos, tcnicas y herramientas deben ser determinados y
documentados, y el equipo del proyecto deben estar familiarizados
con los seleccionados y las razones para su seleccin. Integracin de
probadas prcticas eficaces requisitos: La experiencia ha demostrado
que el uso de un conjunto de prcticas probadas requisitos eficaces
pueden hacer una gran diferencia en un proyecto [1]. Por ejemplo,
la prctica de tiempo y esfuerzo para definir las necesidades reales
de los clientes invertir ya ha sido recomendado. Se describirn
recomendados "mejores" prcticas requisitos largos de este libro y
se resumen en el Captulo 6. Seleccionar y documentar un conjunto de
requisitos de las prcticas que servirn as su proyecto. Referencias:
Habr un conjunto de documentos que son referencias fundamentales
para el proceso de requisitos. Los ejemplos incluyen documentos que
describan los objetivos del sistema y objetivos, listas de
requisitos de los diferentes usuarios, normas que el cliente ha
especificado aplicarse, las polticas que se aplican, y as
sucesivamente. Estas referencias deben enumerarse, y la localizacin
en donde cada uno puede acceder deben indicarse. estrategia
recomendada: Basado en el anlisis de la informacin anterior, una
estrategia debe ser desarrollado y establecido para aprovechar de
manera ptima los requisitos de los aspectos del proyecto
relacionados. Elementos de la estrategia podra incluir lo
siguiente: La estrategia de asociacin; 3 El "proceso adelantado"
para ser utilizado (para comprender las necesidades reales de los
clientes y el medio ambiente, comprender y documentar el alcance
del proyecto, definir interfaces externas, definir los componentes
del sistema, y definir el contorno para la especificacin del
sistema); La determinacin de lo que impulsa a los requisitos
(reglamentos, especificaciones de mayor nivel; normas, polticas,
sistemas y procesos existentes; limitaciones, tales como el costo,
el calendario, la viabilidad tcnica, las necesidades de los
clientes y de los usuarios y expectativas);
Definicin de una poltica de los requisitos del proyecto;
Definicin del proceso de requisitos (diagrama de flujo y PD) (A
Simple proceso de requisitos se proporciona en [1] y en mi sitio
web (www.ralphyoung.net). Usted puede ser capaz de utilizarlo para
disear un proceso de requisitos para su entorno o proyecto).;
Mecanismos para ser utilizados (por ejemplo, el equipo de las
articulaciones y otros que se recomienda en este libro);
Capacitacin sobre los requisitos para el equipo del proyecto
(incluido el cliente); Seleccin de una herramienta apropiada
requisitos automatizada y cmo se va a utilizar; Definicin de la
arquitectura destino; planes para hacer frente a los requerimientos
nuevos y modificados (por ejemplo, el uso de un mecanismo para el
control de ellos, as como las versiones, lanzamientos, y
construye); La comprensin de los riesgos inherentes a los
requisitos, ya que es probable que la falta de plena comprensin de
algunos requisitos crea principales riesgos del proyecto; Definicin
de lineamientos para el desarrollo de sistemas basados en
consideraciones requisitos.Factores que afectan sus decisiones de
carreraRecomiendo que se rena con su PM muy temprano, tal vez
incluso antes de finalizar su asignacin al proyecto. Hable con l o
sus perspectivas sobre los requisitos. Despus de digerir este libro
y mi anterior uno, usted debe tener un conocimiento suficiente de
las prcticas de los requisitos para que pueda concluir si puede ser
eficaz en su papel. Considera la PM que los requisitos, exigencias
prcticas, que invierten en el proceso de requerimiento, que
controlan los requisitos de cambios y nuevas necesidades, y
minimizando re trabajo son importantes? Es usted siente que l o
Ella Te apoyar en los muchos roles en los que potencialmente puede
contribuir al proyecto (ver captulo 2)? l o ella parecen
preocupados por la gente, sobre la motivacin de las personas, el
reconocimiento de sus esfuerzos, dndoles el poder, y el apoyo a
ellos? l o ella tiene una buena reputacin en la organizacin como un
PM? Es l o ella preocupada por el crecimiento personal y
profesional? Es l o ella dispuesto a delegar la responsabilidad?El
punto es que usted est a punto de cometer una parte de su vida
profesional a un proyecto. Tmese el tiempo y esfuerzo para
satisfacer a ti mismo de que su tiempo ser bien gastado. Usted debe
darse cuenta de que una nueva posicin le proporcionar experiencias
de aprendizaje, oportunidades para dar a valoradas y necesarias
aportaciones, para trabajar con sus compaeros quienes usted
respeta, para derivar satisfaccin de uno mismo y el cumplimiento, y
para divertirse en el trabajo.
ResumenEn este captulo se ha centrado en la importancia de los
requisitos y proporcionado una introduccin a la funcin crtica de la
RA (las funciones de la RA se exponen ms detalladamente en el
captulo siguiente, y las habilidades y caractersticas de un RA
efectiva se describen en el captulo 3). Debe ser evidente a partir
del material ya se present que hay un gran poder y el efecto en el
aprovechamiento de los requisitos de las actividades relacionadas
con la ingeniera y la informtica. Un alarmante 53% de la inversin
de la industria en proyectos de desarrollo tcnico es una vctima de
sobrecostos y proyectos fallidos. Los principales factores que
contribuyen son la falta de entrada del usuario (13%), los
requisitos incompletos (12%), y los requisitos cambiantes (12%). 4
La comunidad de usuarios y en particular la gestin de proyectos no
se dan cuenta del valor de la inversin en el proceso de requisitos.
Le sugiero que no es "bien" para un RA sea consciente de esto y no
para discutir las implicaciones con su PM. Como profesional de que
se trate, usted tiene la responsabilidad de llevar estos hechos y
el enfoque recomendado para el PM y para pedirle a apoyar un
proceso de requisitos eficaz que incorpora prcticas requisitos
eficaces. RA, ingenieros y gerentes estn en una posicin estratgica
para mejorar el desempeo de la industria. Este libro proporciona
pro enfocado y orientacin especfica que puede tener una
rentabilidad enorme. Al aplicar el enfoque recomendado en este
libro, usted puede tener un impacto muy positivo en su proyecto y
organizacin.
