Cómo documentar los requisitos de soluciones funcionales en su informe de análisis de negocio

Sección de requisitos funcionales del análisis de negocio responde a la " cómo " preguntas, tales como " Cómo vamos a cambiar el proceso? Para responder a este tipo de preguntas, sus requisitos funcionales deben incluir la siguiente información:

• Área de Diseño alcance: El alcance de lo que va a ser incluido en el diseño. Diseño de la solución puede tardar en ambas soluciones no automatizados (como agregar más personas a la zona de negocios o rediseñar el proceso manual) o soluciones automatizadas (creando una aplicación móvil para permitir a la gente a pedir comida para llevar de un restaurante, por ejemplo). Una técnica que puede utilizar para crear el alcance el área de diseño es un diagrama de casos de uso.

  El alcance el área de diseño puede diferir del alcance del proyecto, porque no todos los aspectos del alcance del proyecto se efectuará directamente en el mismo tiempo. La solución puede ser dividido en diferentes fases, cada una con su propio ámbito de diseño.

• La funcionalidad del sistema: Cómo el usuario interactúa con el software. Piense acerca de las acciones que se realizan y las reacciones (o respuestas) que proporciona el sistema de nuevo a usted - esta es la funcionalidad esperada del sistema. A menudo documentar estos elementos con los casos de uso y la interfaz de usuario (UI) documentos de especificaciones.

• Las definiciones de datos: Lo que los datos de negocio se parece, como los valores permisibles, los valores por defecto, y longitudes de campo. Por ejemplo, puede definir que los incumplimientos del estado del envío de un cliente a usar el código del estado en su dirección de facturación, de manera que los valores permitidos son AL, AZ, AK, y así sucesivamente.

• Clases de usuarios: Los grupos de personas que van a utilizar el nuevo software de aplicación o proceso (interno o externo). Algunos ejemplos incluyen clientes, clientes potenciales, clientes, empleados, la alta dirección, la gente de línea, y representantes de centros de llamadas.

• Interfaces de usuario: Descripción de los diseños de pantalla, diseños de informes y procedimientos. Recuerde que debe seguir cualquier fotografías con explicaciones de cómo funciona la pantalla. Por ejemplo, la imagen de abajo es un ejemplo de un prototipo de interfaz de usuario de un sistema de reserva de vuelo.

  Al describir este prototipo de interfaz, que te explique que la " Encuentra Vuelos " botón permanece inactivo hasta que los usuarios elegir un origen, de destino y de salida y retorno fechas. Esta secuencia es el comportamiento que rodea la pantalla.

  

Cuando la documentación de requisitos funcionales, tenga en cuenta lo siguiente:

• Documentar cómo desea que la funcionalidad para trabajar en lugar de qué herramienta específica que va a utilizar. Por ejemplo, asegurándose de que el sistema de reservas de vuelo muestra sólo regresan fechas que ocurren después de la fecha de salida es una descripción de funcionalidad- el hecho de que vamos a usar, por ejemplo, un applet de Java de código calendario para calcular Hoy 1 es una descripción de un herramienta para su ejecución.

• Se adhieren a las interacciones entre el sistema informático y el agente externo (el usuario).

• Dirección de la apariencia (las conductas observables) en lugar de centrarse en el diseño y la ejecución de código.

Tienes que andar con una línea muy fina cuando se está documentando requisitos funcionales. El lenguaje tiene que ser lo suficientemente no técnico para comunicar a los expertos en la materia objeto de negocio para que entiendan cómo la solución se va a operar. Sin embargo, todavía tiene que ser lo suficientemente detallada para que el equipo técnico sabe cómo crear la solución, incluyendo todas las excepciones / formas alternativas para crear la solución.