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.

Requisitos, cuando se identificó por primera vez, son realmente necesita, quiere, sugerencias o ideas - hasta que la persona adecuada decida otra cosa. Con frecuencia, las necesidades, los deseos, sugerencias e ideas son presentadas como declaraciones requisitos sin el pensamiento del proveedor acerca de las necesidades, limitaciones, o implicaciones de esa toma de decisiones a veces, él no es incluso 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 que alguien hace que las decisiones sobre los requisitos específicos y cuándo.

Como te habrás dado cuenta, la palabra requisito es un término muy vago en el mundo de análisis de negocio. Como resultado, la definición oficial de un requisito que aparece 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 que necesita un actor para resolver un problema o alcanzar un objetivo ". Este punto refleja la toma de decisiones fundamental necesaria en los negocios.

• " Una condición o capacidad que se debe cumplir o poseído por un componente de la solución o la solución para satisfacer un contrato, estándar, especificaciones, 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 sobre los requisitos también se conoce como un requisito. Eso es porque la documentación 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) a entender los requisitos para la solución junto con los componentes que 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 en sí se convierte en un requisito.

Requisitos caen en diferentes categorías, en capas. Las categorías principales incluyen los requerimientos del negocio, los requisitos de las partes interesadas, requisitos de la solución, los requisitos de transición, y los requisitos tecnológicos. Requisitos de la solución incluyen 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.

Yendo directamente de un requisito de negocio directamente a una exigencia técnica detallada no es posible. Usted debe conectar en cascada a través de cada capa o nivel de análisis en su caso, la catalogación y categorización sobre la marcha.

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 investigar lo suficiente como para obtener todos los REQUISITOS necesaria de lo contrario, se arriesga a que faltan algunos requisitos.

Puede volver a utilizar requisitos documentados (y necesidades, para el caso) a nivel de negocio y de los interesados ​​(y, a veces la solución)! Requisitos reutilizados pueden guardar 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 empresarial o centralizada lugar requisitos de referencia) en caso de que quiera hacer uso de ellos en otro proyecto.

Requisitos que alguna vez fueron 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 próximo 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 a la preocupación existente, sufren buggy o las interfaces en su defecto, poner sistemas de aguas abajo en peligro, y dar lugar a sistemas que son (más) difícil de apoyo, causando soluciones temporales o procesos adicionales manual.

Estos retos pueden herir de usuario y la satisfacción del cliente y los resultados del negocio, lo que puede dar lugar a una disminución de ventas y un impacto en los ingresos.