Cómo definir los requisitos a través de análisis de negocio

Necesidades y requisitos pueden parecer que significan la misma cosa, pero hay una diferencia cuando se trata de análisis de negocio: La necesidad es el objetivo, y el requisito es la decisión sobre si se debe hacer algo para alcanzar dicho objetivo. Una necesidad se convierte en un requisito cuando alguien reconoce que el tener la necesidad insatisfecha es inaceptable y decide que requiere la necesidad de que se cumplan.

Video: Diferencias entre idea de negocio y concepto de negocio

Requisitos, cuando se identificó por primera vez, son realmente necesita, quiere, sugerencias o ideas - hasta que la persona correcta decida otra cosa. Con frecuencia, necesidades, deseos, sugerencias e ideas se presentan como declaraciones requisitos sin el pensamiento del proveedor acerca de las necesidades, limitaciones, o implicaciones de ese decisiones a veces, ni siquiera está en la posición de decidir cómo o por qué el requisito es apropiado o necesario .

Las decisiones se toman por alguien por una razón. Captura y tenga en cuenta lo que alguien hace que las decisiones acerca de los requisitos específicos, y cuándo.

Como probablemente se dio cuenta, la palabra requisito es un término muy vago en el mundo análisis de negocio. Como resultado, la definición oficial de un requisito establecido en la Guía BABOK (según lo especificado por el IIBA - el Instituto Internacional de Análisis de Negocios) del siguiente modo:

• “Una condición o capacidad necesaria por una de las partes interesadas para resolver un problema o alcanzar un objetivo.” Este punto refleja la toma de decisiones necesarias en el negocio fundamental.

• “Una condición o capacidad que se debe cumplir o poseída por un componente de la solución o solución para satisfacer un contrato, estándar, especificación, u otros documentos impuestas formalmente.” Esta parte cambia el enfoque de la parte interesada a la solución.

• “Una representación documentada de una condición o capacidad como en 1 o 2.” Esta idea toma nota de que la documentación acerca de los requisitos también se conoce como un requisito. Esto se debe a la documentación de ayuda a los analistas, los diferentes grupos de interés, o consumidores de documentación (Las personas que están leyendo e interpretando la documentación) entienden los requisitos para la solución junto con los componentes son responsables de la creación.

  Debido a que los creadores de los componentes de la solución deben cumplir con los requisitos mientras que el desarrollo, la documentación se convierte en un requisito.

Requisitos se dividen en diferentes categorías, en capas. Las categorías principales incluyen los requisitos de negocio, requisitos de los interesados, los requisitos de soluciones, requerimientos de transición, y los requisitos de la tecnología. requisitos de la solución incluyen los requisitos funcionales y no funcionales creados ya sea a mano o con la tecnología (que tiene sus propios requisitos técnicos). Y cuando haya terminado, las soluciones se ponen en marcha a través de requerimientos de transición.

Ir directamente de un requisito de negocio directamente a un requisito técnico detallado no es posible. Debe conectar en cascada a través de cada capa o nivel de análisis en su caso, catalogación y categorización a medida que avanza.

Usted y su equipo no son sólo supone el diseño de cualquier solución al final de todo esto en cascada a través de la niveles- se supone que debes utilizar los requisitos para diseñar un éxito solución. Usted debe sondear la profundidad suficiente para obtener todos los REQUISITOS necesaria de lo contrario, se arriesga a que faltan algunos requisitos.

Video: Cómo definir un cuadro de mando integral para una empresa de Transporte y Logística

Puede volver a utilizar requisitos documentados (y necesidades, para el caso) a nivel de negocios y grupos de interés (y, a veces la solución)! requisitos reutilizados pueden ahorrar los equipos de proyecto y las partes interesadas tiempo y dinero. Usted debe organizar y guardar los requisitos de sus proyectos (tal vez en un repositorio centralizado empresa o lugar de Requisitos de referencia) en caso de que quiera hacer uso de ellos en otro proyecto.

Requisitos que antes eran ser (requisitos para el futuro entorno empresarial) puede convertirse en su como es (requisitos para el entorno empresarial actual) y proporcionan un nuevo punto de partida para el siguiente proyecto.

Sólo un requisito que falta puede causar problemas con las partes interesadas y los miembros del equipo y también puede afectar a la solución (s) a construir. La solución puede estar ausente o costoso, crear calidad o de apoyo preocupaciones en curso, sufren buggy o interfaces de defecto, poner los sistemas de aguas abajo en peligro, y el resultado en los sistemas que son (más) difícil de apoyo, causando manual de soluciones temporales o procesos adicionales.

Estos retos pueden herir la satisfacción del usuario y del cliente y los resultados del negocio, lo cual puede resultar en una disminución de las ventas y un impacto en los ingresos.