• Author / Uploaded
• Pavel Daniel Meza Alonso

• Categories
• Proceso de desarrollo de software
• Software
• Ingeniería de software
• Planificación
• Ingeniería

Citation preview

La importancia de Requisitos El propósito de este libro es ayudar a mejorar la práctica de la ingeniería de requisitos. Requisitos de ingeniería es difícil. No es sólo una simple cuestión de escribir lo que el cliente dice que quiere. Un problema fundamental en los negocios es que los requisitos son inherentemente dinámico; van a cambiar con el tiempo ya que nuestra comprensión del problema que estamos tratando de resolver los cambios. La importancia de los buenos requisitos y la naturaleza dinámica subyacente del proceso significa que debemos ser tan precisa tasa posible, y sin embargo, ser flexibles. Flexible no significa "débil", 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 prácticas 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 más disciplinado para el desarrollo y gestión de requisitos con el fin de mejorar las tasas de éxito de los proyectos. Un alarmante 53% de la inversión de la industria en proyectos de desarrollo técnico es una víctima de los excesos de costes y proyectos fallidos. En este capítulo se define el término "prescripción", explica por qué requisitos son importantes, y los defensores de la planificación para definir la estrategia y las actividades requisitos. Se sugiere el uso de un proceso de requisitos definidos y documentados, que invertir más en el proceso de requisitos tendrá un gran retorno de la inversión, 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 tamaños.

¿Cuáles son los requisitos y por qué son importantes? Un requisito es un atributo necesario en un sistema, una declaración que identifica una capacidad, característica, 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 técnico: diseño de sistemas, desarrollo, pruebas, implementación y operación. Con demasiada frecuencia, hay una tendencia a querer comenzar lo que se refiere a menudo como "el verdadero trabajo" (en desarrollo, o

de programación, el software) demasiado rápido. Clientes y directores de proyectos (PMS) Muchos parecen creer que el trabajo de programación actual ("codificación") 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

más tiempo en la recopilación de requisitos, análisis y gestión. La razón es que, por lo general, el trabajo de codificación se inicia mucho antes de lo que debería ser porque se necesita más tiempo para identificar las necesidades "reales" y planificar actividades requisitos relacionados (descritas a continuación). 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 información, propuesta o cotización o en una declaración 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 análisis 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 clarificación de su ING media y la identificación de otros aspectos que deben tenerse en cuenta. Para citar un ejemplo sencillo, requisitos analistas (RA) están más 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 comprensión y la comunicación 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 través del mecanismo de un cliente / usuario y el esfuerzo conjunto de la RA. Los clientes y los usuarios necesitan el apoyo de técnicamente capacitados y experimentados profesionales, y viceversa, para garantizar una comunicación eficaz. Desarrolladores necesitan tener ese mismo entendimiento para que la solución 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 identificación de las necesidades reales requiere un proceso de requisitos interactivos e iterativos, apoyados por efectivos prácticas, procesos, mecanismos, métodos, técnicas y herramientas. Este libro proporciona una descripción de cómo la RA puede utilizarlas en la realización de los trabajos necesarios. En un anterior libro, Prácticas 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 guía de referencia turística para la AR o ingeniero y gerente de requisitos en

la ingeniería y la informática. También 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 tamaño. Es más importante que un proyecto u organización tienen un proceso de requisitos definidos y documentados. La naturaleza de los componentes específicos de la definida proceso puede ser mejorado basado en la experiencia. ¿Por qué plan? Es bien sabido y entendido por la mayoría de la gente que un poco de planificación va un largo camino. Por ejemplo, antes de partir en un viaje en automóvil, la comprobación de un mapa para localizar el destino y, tal vez, incluso la planificación de una ruta puede ser un tiempo bien empleado. Sin embargo, con frecuencia cobramos adelante con el hacer con poca o ninguna planificación, ¿no? Es la naturaleza humana querer seguir adelante con el trabajo necesario sin hacer mucha planificación. Sistemas de desarrollo de software y administradores de desarrollo y los profesionales están familiarizados con varios tipos de planes: el plan del proyecto, los sistemas de planes de gestión de la ingeniería (SEMP), la garantía de calidad (QA) plan, gestión de la configuración (CM) plan, plan de desarrollo de software (SDP), plan de pruebas , etcétera. 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 cómo los requerimientos reales evolucionarán y cómo se abordarán las actividades requisitos.

Escribir un plan de requisitos (RP) facilita la comprensión de las actividades y esfuerzos que deben llevarse a cabo para poner en práctica un proceso de requisitos eficaz para un esfuerzo de desarrollo en particular. Los detalles adicionales referentes al plan de necesidades se proporcionan a continuación. Una estrategia sugerida Yo sugiero una estrategia que incluye (1) escribir un plan de necesidades, (2) el diseño o la adaptación de un proceso de requisitos para su proyecto, (3) la inversión en las actividades relacionadas con los requisitos en el ciclo de vida del sistema, y (4) la utilización de los requisitos eficaces prácticas, mecanismos, métodos, técnicas, herramientas y capacitación que se describen en este libro. Requisitos Las actividades en el ciclo de vida del sistema Los administradores a menudo piensan de los requisitos de las actividades relacionadas como que consiste principalmente de los requisitos de recopilación y gestión 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 identificación de los grupos de interés: Esto incluye cualquier persona que tenga un interés 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 obtención de requisitos. Tenga en cuenta que los requisitos pueden incluir varios tipos. Tipos de requisitos se discuten en el Capítulo 4. Requisitos reuniendo técnicas se discuten en el Capítulo 5. Identificación de requisitos: Se trata de afirmar requisitos en oraciones simples y proporcionándoles 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 técnica para la comprensión 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 organización en el logro de ellos. Clarificar y reafirmar los requisitos: Esto se hace para garantizar que se describen las necesidades reales del cliente y están en una forma que pueda ser entendida y utilizada por los desarrolladores del sistema.

















El análisis de los requisitos: Esto se hace para asegurarse de que están bien definidos y que se ajusten a los criterios de una buena requisito (siempre más adelante). La definición de los requisitos de forma que significa lo mismo para todos los grupos de interés: Tenga en cuenta que cada grupo de interés 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 léxico proyecto. A menudo se requiere gastar mucho tiempo y esfuerzo para lograr un entendimiento común. Especificar los requisitos: Esto requiere incluidos todos los detalles precisos de cada requisito de modo que se puede incluir en un documento de especificación u otra documentación, en función del tamaño del proyecto. Priorizar los requisitos: Todos requisitos no son de igual importancia para los clientes y usuarios del sistema de planificación. Algunos son críticos, 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 gustaría hacer en nuestros sistemas desarrollados. Dar prioridad a los requisitos proporciona la oportunidad de abordar la prioridad más alta primero y posiblemente lanzar una versión de un producto después de que las direcciones

necesidades de menor prioridad. Priorizar ayuda a asegurar que una cantidad adecuada de la inversión que se haga en el cumplimiento de diversos necesidades.1 cliente Derivado requisitos: Hay algunos requisitos que se producen debido al diseño de un sistema, pero no proporcionan un beneficio directo para el usuario final. Un requisito para el almacenamiento de disco podría 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, capacitación y documentación, por ejemplo. A menudo, este proceso resulta ser más compleja de lo que anticipamos cuando algunos requerimientos son satisfechos por más de una categoría. Asignación 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 más a menudo lleva a cabo a través del uso de una herramienta de requisitos automatizado. requisitos Gestión: Tenemos que ser capaces de añadir, eliminar y modificar los requisitos durante todas las fases de diseño de sistemas, desarrollo, integración, pruebas, despliegue y operación. El repositorio requisitos consiste en un conjunto de artefactos y bases de datos. Se describe en el capítulo 5. Prueba y requisitos que verifican: Este es el proceso de comprobación de los requisitos, diseños, códigos, planes de prueba y productos de sistemas para asegurar que se cumplen los requisitos. Validación de requisitos: Este es el proceso para confirmar que los requisitos reales se implementan en el sistema entregado. El orden de validación de requisitos debe priorizar ya que hay una cantidad limitada de fondos disponibles.

La inversión en el Proceso de Requisitos La inversión promedio de la industria en el proceso de los requisitos para un sistema típico es del 2% al 3% del costo total del proyecto. Debería ser evidente a partir de la información ya presentada que esta cantidad de inversión es inadecuada y de hecho es la causa fundamental del fracaso de muchos proyectos. Los datos de la Aeronáutica 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 ejecución excesivo, mientras que los proyectos que invirtieron 8% al 14% del total del proyecto de coste / esfuerzo en el proceso de requisitos tenían 0% a 50% excesos [2, p. 9]. (Obviamente, nuestra meta no es tener excesos en absoluto, sin embargo, una saturación del pequeño es preferible a uno más grande!) Este libro describe cómo lograr un nivel adecuado de inversión en el proceso de los requisitos y los beneficios asociados.

Un Enfoque basado en procesos En las últimas dos décadas, 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 descripción, un diagrama de flujo proceso documentado y una descripción del proceso que lo acompaña (PD) de un conjunto de actividades que se traduce en la realización de una tarea o logro de un resultado. Basado en mi experiencia, hay un gran valor a la utilización 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 común de lo que se trata.  El proceso documentado puede ser entendido por todos los que están involucrados.  los involucrados, que tiene un entendimiento común, puede sugerir mejoras en el proceso (que permitan la mejora continua y el empoderamiento de los que están 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 estándar de la industria para evaluar la madurez / capacidad de un proceso de desarrollo. La versión 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 más 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 desvía 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 inversión (ROI) del proceso mejora. 2 Otros datos de la industria informan constantemente del 40% al 50% de la reanudación de los proyectos de desarrollo. La reducción de la reanudación es un objetivo lucrativo para los esfuerzos de mejora de procesos. La reducción de re trabajo puede proporcionar los recursos para las iniciativas de mejora de procesos toma insuficientemente. Además, los modelos de procesos requisitos están disponibles; por ejemplo, uno está dentro de mi libro anterior y disponible en mi sitio Web (www ralphyoung.net.); el modelo espiral de la ingeniería de requisitos; y un modelo se proporciona en Dominar el Proceso Requisitos [5]. El Plan de Requisitos Un plan de necesidades debe ser desarrollado por la AR temprana, ya sea durante la fase de preparación de la propuesta o poco después de que se tomó la decisión de seguir adelante con un proyecto de desarrollo o tarea. El propósito del plan de necesidades es determinar y documentar cómo se desarrollaron las necesidades reales y cómo se abordarán las actividades relacionadas con los requisitos en el ciclo de vida del sistema (enumerados y descritos anteriormente). A continuación se presenta una lista de temas sugeridos para este plan y una descripción de cada tema



Propósito (del plan de requisitos): Esto se define en el párrafo anterior.









Resumen del contrato / proyecto: Un resumen de alto nivel de los objetivos del sistema o software debe ser proporcionada. Esta sección puede ser extraído de otros documentos como un documento de visión y alcance que pueden haber sido escrito anteriormente para describir la intención general. Antecedentes: En esta sección se debe describir la situación que llevó a la decisión de desarrollar el sistema o software. Debe identificar los principales grupos de interesados, aquellas que tienen un interés en el sistema, como el cliente (la persona u organización que proporciona los fondos para pagar por el proyecto o sus productos finales), diversas categorías de usuarios, desarrolladores y proveedores principales. Evolución 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 cuántos proyectos han fallado y cuántos más han sido seriamente y negativamente afectados por una falta de inversión en este paso crítico [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 número similar de desarrolladores técnicamente 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. También la justificación 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 pequeño proyecto, es probable que más 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 capacitación requisitos (el contenido de este entrenamiento se describe en el capítulo 5). Otra persona será responsable de la herramienta requisitos automatizado. Sin embargo, otra persona puede tener la responsabilidad de los procesos clave que se utilizarán en el proyecto, INCLUYENDO ing el proceso de requisitos. Otra puede ser el responsable de diseñar la arquitectura (la estructura subyacente del sistema o software). Dado que los requisitos y el impacto arquitectura entre sí, una práctica recomendada es de requisitos para recorrer los requisitos y la arquitectura en varias ocasiones, esto se traduce en

requisitos más fuertes y una arquitectura más robusta [1, pp. 131158].

Tabla 1.1 Criterios de un buen Requisito Cada individuo debe ser Requisito

Necesario: 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 técnicamente y jurídicamente posible. Conciso: El requisito se afirma con sencillez. Inequívoca: 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 declaración. Consistente: No está en conflicto con otros requisitos. Verificable: Implementación de la exigencia en el sistema se puede probar. Trazabilidad: La fuente de la obligación se puede remontar, y puede ser seguido en todo el sistema (por ejemplo, para el dise Numerado: El requisito es asignado a un componente del sistema diseñado. Diseño independiente: No plantean una solución específica aplicación. No redundante: No es un requisito duplicado. Escrito utilizando la construcción estándar: El requisito se afirma como un imperativo el uso de "deberá". Asignado un identificador único: Cada requisito deberá tener un número de identificación único. Desprovisto de cláusulas de escape: El lenguaje no debe incluir frases como "si", "cuándo", "pero", "excepto" "A menos", y "si bien". El lenguaje no debe ser especulativo o general (es decir, evitar expresiones como "por lo general", "ge











 

Definición del proceso de requisitos que se utilizará: Como se señaló 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 organización que lleva a cabo cada paso) acompañado 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 organización de realizar cada tarea, y algunas medidas (métricas) 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 práctica de involucrar a los principales actores de un proceso en su construcción. Este enfoque fomenta la comprensión, la integridad y bluyín al proceso definido, así como el compromiso de usarlo. Los mecanismos, métodos, técnicas y herramientas para ser utilizadas: Varios ejemplos de cada categoría se describen en este libro. Obviamente, algunos son más adecuados en algunos casos que en otros, y algunos son particularmente útiles en situaciones específicas. Los específicos mecanismos, métodos, técnicas y herramientas deben ser determinados y documentados, y el equipo del proyecto deben estar familiarizados con los seleccionados y las razones para su selección. Integración de probadas prácticas eficaces requisitos: La experiencia ha demostrado que el uso de un conjunto de prácticas probadas requisitos eficaces pueden hacer una gran diferencia en un proyecto [1]. Por ejemplo, la práctica de tiempo y esfuerzo para definir las necesidades reales de los clientes invertir ya ha sido recomendado. Se describirán recomendados "mejores" prácticas requisitos largos de este libro y se resumen en el Capítulo 6. Seleccionar y documentar un conjunto de requisitos de las prácticas que servirán 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 políticas que se aplican, y así sucesivamente. Estas referencias deben enumerarse, y la localización en donde cada uno puede acceder deben indicarse. estrategia recomendada: Basado en el análisis de la información 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 podría incluir lo siguiente: La estrategia de asociación; 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 especificación del sistema); La determinación de lo que impulsa a los requisitos (reglamentos, especificaciones de mayor nivel; normas, políticas, sistemas y procesos existentes; limitaciones, tales como el costo, el calendario, la viabilidad técnica, las necesidades de los clientes y de los usuarios y expectativas); Definición de una política de los requisitos del proyecto; Definición 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 diseñar 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); Capacitación sobre los requisitos para el equipo del proyecto (incluido el cliente); Selección de una herramienta apropiada requisitos automatizada y cómo se va a utilizar; Definición 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 comprensión de los riesgos inherentes a los requisitos, ya que es probable que la falta de plena comprensión de algunos requisitos crea principales riesgos del proyecto; Definición de lineamientos para el desarrollo de sistemas basados en consideraciones requisitos.

Factores que afectan sus decisiones de carrera Recomiendo que se reúna con su PM muy temprano, tal vez incluso antes de finalizar su asignación al proyecto. Hable con él o sus perspectivas sobre los requisitos. Después de digerir este libro y mi anterior uno, usted debe tener un conocimiento suficiente de las prácticas de los requisitos para que pueda concluir si puede ser eficaz en su papel. 

 



¿Considera la PM que los requisitos, exigencias prácticas, 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 capítulo 2)? ¿Él o ella parecen preocupados por la gente, sobre la motivación de las personas, el reconocimiento de sus esfuerzos, dándoles el poder, y el apoyo a ellos? ¿Él o ella tiene una buena reputación en la organización 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. Tómese el tiempo y esfuerzo para satisfacer a ti mismo de que su tiempo será bien gastado. Usted debe darse cuenta de que una nueva posición le proporcionará experiencias de aprendizaje, oportunidades para dar a valoradas y necesarias aportaciones, para trabajar con sus compañeros quienes usted respeta, para derivar satisfacción de uno mismo y el cumplimiento, y para divertirse en el trabajo.

Resumen En este capítulo se ha centrado en la importancia de los requisitos y proporcionado una introducción a la función crítica de la RA (las funciones de la RA se exponen más detalladamente en el capítulo siguiente, y las habilidades y características de un RA efectiva se describen en el capítulo 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 ingeniería y la informática. Un alarmante 53% de la inversión de la industria en proyectos de desarrollo técnico es una víctima 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 gestión de proyectos no se dan cuenta del valor de la inversión 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 prácticas requisitos eficaces. RA, ingenieros y gerentes están en una posición estratégica para mejorar el desempeño de la industria. Este libro proporciona pro enfocado y orientación específica 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 organización.