Cómo realizar un análisis de las necesidades de los usuarios
La definición de requisitos incluye explicar los requisitos desde la perspectiva del usuario (comportamiento externo del sistema) y desde la perspectiva del desarrollador (algunas características internas).
La cuestión clave es redactar los documentos de requisitos. He sido testigo del reemplazo de todos los desarrolladores durante un proyecto y el cliente se vio obligado a sentarse con un nuevo analista de requisitos. El analista de sistemas dijo: "Queremos hablar con usted sobre sus necesidades". La primera reacción del cliente fue: "Le he dicho a su predecesor todos mis requisitos y ahora lo único que quiero es programar un sistema para mí".
Personas que dicen saberlo todo
De hecho, los requisitos para las UGG no están documentados, por lo que los nuevos analistas tienen que empezar desde cero. Entonces, si solo tiene un montón de correos electrónicos, notas de reuniones o algunas conversaciones fragmentadas, está seguro de haber comprendido las necesidades de sus usuarios. Esto es un completo engaño.
Otra definición de requisitos es que un requisito es "una descripción de lo que un usuario necesita y puede desencadenar el desarrollo de un programa o sistema". Algunos expertos en análisis de requisitos han ampliado este concepto: "Las características, funciones y atributos con los que un sistema satisface a los usuarios se pueden encontrar fuera del sistema". Estas definiciones enfatizan cómo es un producto más que cómo está diseñado y construido. Las siguientes definiciones van más allá de los requisitos del usuario a las características del sistema:
Los requisitos son especificaciones que especifican lo que se debe implementar. Describe el comportamiento, características o propiedades del sistema y es una restricción del sistema durante el proceso de desarrollo.
A partir de estas diferentes definiciones, no es difícil descubrir que no existe un término claro y ambiguo "demanda". Las "necesidades" reales existen realmente en la mente de las personas. Esta persona se refiere principalmente al cliente, pero en circunstancias normales, los usuarios no pueden describir sus propias necesidades. Solo necesitan que los analistas del sistema clasifiquen las necesidades relevantes en función de sus propias descripciones de idioma y luego consulten con los clientes. Los analistas de sistemas y los clientes deben asegurarse de que todas las partes interesadas del proyecto describan los requisitos en esos términos.
Cualquier requisito documentado (como la especificación de requisitos que se describe a continuación) es solo un modelo y una descripción.
2. La tarea del análisis de requisitos
La parte más difícil del desarrollo de un sistema de software es explicar exactamente qué se va a desarrollar. El trabajo conceptual más difícil es escribir los requisitos técnicos detallados, incluidas todas las interfaces para usuarios, máquinas y otros sistemas de software. Al mismo tiempo, esta es también la parte que eventualmente causará un daño enorme al sistema si se hace mal, y será extremadamente difícil de modificar más adelante.
En la actualidad, existen muchos productos nacionales y una empresa puede tener varios sistemas funcionando en paralelo. La interfaz entre ellos es el mayor dolor de cabeza para los desarrolladores de sistemas.
Para las aplicaciones empresariales de usuario final, los sistemas de información y el software empresarial son claramente productos que forman parte de un sistema más grande. Pero para nosotros, los desarrolladores, no hemos escrito un documento de requisitos que sea reconocido por los clientes. ¿Cómo sabemos cuando un proyecto ha terminado? Si no sabemos qué es importante para nuestros clientes, ¿cómo podemos satisfacerlos?
Sin embargo, incluso los requisitos de software para fines no comerciales son necesarios. Por ejemplo, el equipo de desarrollo utiliza internamente bibliotecas, componentes y herramientas. Por supuesto, en ausencia de documentación, es posible que ocasionalmente esté de acuerdo con el punto de vista de otra persona, pero la mayoría de las veces es la consecuencia inevitable de reelaboraciones repetidas, y el costo de reprogramar el código excede con creces el costo de reescribir un documento de requisitos. . Estas sangrientas lecciones les están sucediendo a los desarrolladores de software nacionales.
Recientemente, conocí a un equipo de desarrolladores que habían desarrollado un conjunto de software asistido por computadora para uso interno que incluía un editor de código. Desafortunadamente, cuando terminaron de desarrollar la herramienta, descubrieron que no podía imprimir archivos de código fuente y los usuarios ciertamente querían esta característica. Como resultado, los equipos tuvieron que copiar manualmente los documentos del código fuente para revisar el código. Esto demuestra que incluso si los requisitos son claros y precisos, si no escribimos documentación, el software sólo puede culparse a sí mismo por no lograr los objetivos esperados.
En cambio, veo una interfaz simple integrada en el "sistema de seguimiento de errores" para escribir una solicitud de una página. Sin embargo, los administradores de sistemas operativos encuentran muy útil una lista simple de requisitos cuando trabajan con scripts. Cuando probaron el sistema según sus requisitos, no sólo implementó claramente todas las funciones necesarias, sino que tampoco encontró errores.
De hecho, los documentos de requisitos siempre han jugado un papel guía en el proceso de desarrollo.
3. Proceso de análisis de requisitos
Es más apropiado dividir todo el campo de investigación de la ingeniería de requisitos de software en desarrollo de requisitos y gestión de requisitos, como se muestra en la Figura 4-1:
p>
Figura 4-1 Diagrama de descomposición jerárquica del campo de la ingeniería de requisitos
El desarrollo de requisitos se puede dividir en cuatro etapas: adquisición del problema, análisis, redacción de especificaciones y verificación. Estos subelementos incluyen todas las actividades, como la recopilación de requisitos, la evaluación y la redacción de documentación en un producto de software. Las actividades de desarrollo de requisitos incluyen los siguientes aspectos:
Determinar las categorías de usuarios esperadas del producto.
Obtén los requisitos de cada clase de usuario.
Comprenda las tareas y objetivos reales de los usuarios y los requisitos comerciales que respaldan estas tareas.
Analice la información de los usuarios para diferenciar entre los requisitos de las tareas del usuario, los requisitos funcionales, las reglas comerciales, los atributos de calidad, las soluciones recomendadas y la información adicional.
Los requisitos a nivel de sistema se dividen en subsistemas y algunos requisitos se asignan a componentes de software.
Comprender la importancia de los atributos de calidad relevantes.
Discutir la priorización de la implementación.
Compile los requisitos de usuario recopilados en documentos y modelos.
Revisar la especificación de requisitos para garantizar que las necesidades del usuario se comprendan y reconozcan de la misma manera, y para aclarar todas las cuestiones antes de que todo el equipo de desarrollo acepte la especificación.
La gestión de requisitos requiere "establecer y mantener contratos con clientes en ingeniería de software". Dichos contratos están contenidos en documentos y modelos de requisitos. La aceptación del cliente es sólo la mitad del éxito de los requisitos; los desarrolladores deben poder aceptar los requisitos y realmente aplicarlos en el producto. Las actividades habituales de gestión de requisitos incluyen:
Definir la línea base de requisitos (el cuerpo principal del desarrollo rápido de documentos de requisitos).
Revisar los cambios de requisitos propuestos y evaluar el impacto probable de cada cambio para decidir si implementarlo.
Incorporar los cambios de requisitos al proyecto de forma controlada.
Ajustar los planes actuales del proyecto según las necesidades.
Estimar el impacto de los cambios en los requisitos y negociar nuevos compromisos en base a ello, que se reflejen en la solución del proyecto.
Vincula cada requisito con su correspondiente diseño, código fuente y casos de prueba para lograr el seguimiento.
Seguimiento del estado de los requisitos y sus cambios a lo largo del proyecto.
La explicación anterior se basa en mi experiencia como analista de sistemas después de la implementación exitosa del proyecto, y también se basa en la experiencia exitosa de otras implementaciones de sistemas en el país y en el extranjero.
4. Tipos de requisitos
Las siguientes definiciones son definiciones de términos comúnmente utilizados en ingeniería de requisitos.
Los requisitos de software incluyen tres niveles diferentes: requisitos comerciales, requisitos de usuario y requisitos funcionales (incluidos los requisitos no funcionales).
1. Los requisitos comerciales reflejan los requisitos objetivo de alto nivel de la organización o del cliente para sistemas y productos, y estos requisitos se describen en los documentos de vista y alcance del proyecto.
2. El documento de requisitos del usuario describe las tareas que los usuarios deben completar al utilizar el producto, que se explican en el documento del caso de uso o en la descripción del script de la solución.
3. Los requisitos funcionales definen las funciones de software que los desarrolladores deben implementar para que los usuarios puedan completar tareas y así satisfacer las necesidades del negocio.
Los requisitos funcionales descritos en la Especificación de Requisitos de Software (SRS) describen completamente el comportamiento externo que debe tener el sistema de software. Las especificaciones de requisitos de software juegan un papel importante en el desarrollo, las pruebas, el control de calidad, la gestión de proyectos y las funciones relacionadas del proyecto. Para sistemas grandes, los requisitos funcionales del software pueden ser sólo un subconjunto de los requisitos del sistema, ya que otros requisitos pueden pertenecer a subsistemas (o componentes de software).
Como complemento a los requisitos funcionales, la especificación de requisitos de software también debe incluir requisitos no funcionales. Los requisitos no funcionales describen los comportamientos y operaciones que el sistema presenta a los usuarios, incluidos los estándares, especificaciones y contratos que. los productos deben cumplir. Detalles específicos de la interfaz externa; requisitos de desempeño; restricciones de diseño o implementación y atributos de calidad. Las llamadas restricciones se refieren a las limitaciones impuestas por los desarrolladores al diseño y construcción de productos de software. Los atributos de calidad describen las características del producto desde múltiples perspectivas, reflejando así la funcionalidad del producto. Es extremadamente importante que los usuarios y desarrolladores describan el producto desde todas las perspectivas.
Utilicemos un procesador de textos como ejemplo para ilustrar los diferentes tipos de necesidades. El requisito comercial podría ser: "Los usuarios pueden corregir eficazmente los errores ortográficos en los documentos". La portada de la caja del producto podría indicar que se trata de un corrector ortográfico que cumple con el requisito comercial.
Un requisito correspondiente del usuario podría ser "encontrar errores ortográficos en un documento y elegir reemplazar la palabra mal escrita a través de la lista alternativa proporcionada". Al mismo tiempo, existen muchos requisitos funcionales para los correctores ortográficos, como encontrar y resaltar palabras mal escritas. Muestra un cuadro de diálogo que proporciona palabras de reemplazo, lo que permite el reemplazo en todo el documento.
Como se puede ver en la definición anterior, los requisitos no incluyen detalles de diseño, detalles de implementación, información de planificación del proyecto o información de prueba. Los requisitos no tienen nada que ver con estos, el punto es describir completamente lo que realmente quieres desarrollar. Los proyectos tienen otras necesidades, como un entorno de desarrollo o la necesidad de lanzar un producto y trasladarlo a un entorno de soporte. Aunque estos requisitos también son críticos para el éxito del proyecto, no se analizan en este libro.
5. Principios del análisis de requisitos
Los equipos de proyecto que no presten atención al proceso de requisitos sufrirán las consecuencias. Los defectos en la ingeniería de requisitos pueden plantear riesgos importantes para el éxito del proyecto. "Éxito" aquí significa que los productos lanzados pueden satisfacer plenamente las expectativas del usuario en términos de funcionalidad y calidad a un precio razonable y en el momento oportuno. Algunos riesgos de requisitos se analizan a continuación.
Algunos riesgos causados por un proceso de requisitos inadecuado:
1. No hay suficiente participación de los usuarios.
Los clientes a menudo no entienden por qué se necesita tanto esfuerzo para recopilar requisitos y garantizar su calidad, y es posible que los desarrolladores no presten atención a la participación de los usuarios. Las razones son las siguientes: primero, los desarrolladores sienten que trabajar con los usuarios no es tan interesante como escribir código; segundo, porque los desarrolladores sienten que ya comprenden las necesidades de los usuarios; En algunos casos, es difícil contactar directamente con los usuarios que realmente están utilizando el producto y los clientes no saben mucho sobre sus verdaderas necesidades. Sin embargo, los usuarios representativos deben participar directamente en el equipo de desarrollo en las primeras etapas del proyecto y experimentar todo el proceso de desarrollo juntos.
En el proceso de práctica, el personal del sistema también tiene algunos sentimientos. Si la implementación de un proyecto de la empresa no involucra a suficientes usuarios, los requisitos obtenidos por el personal del sistema serán unilaterales e incompletos, por lo que el personal del sistema también tendrá algunos sentimientos. El sistema no cumplirá con los requisitos. Los riesgos se plantean desde el principio.
2. Las crecientes necesidades de los usuarios
Si se agregan necesidades constantemente durante el proceso de desarrollo, el proyecto será cada vez más grande, excediendo el alcance de su plan y presupuesto. Los planes no siempre se alinean con el tamaño y la complejidad de los requisitos del proyecto, los riesgos, la productividad del desarrollo y la realidad de los requisitos cambiantes, lo que hace que los problemas sean más difíciles de resolver. De hecho, la raíz del problema radica en los cambios en las necesidades de los usuarios y las modificaciones de los desarrolladores a las nuevas necesidades.
Para minimizar el alcance de los cambios en los requisitos, la vista del proyecto, el alcance, los objetivos, las limitaciones y los criterios de éxito deben explicarse claramente desde el principio, y esta descripción debe usarse como marco de referencia para evaluar los requisitos. cambios y nuevas características. Describir el proceso de control de cambios, incluido el análisis de los factores de impacto de cada cambio, ayuda a todas las partes interesadas a comprender el fundamento de las decisiones comerciales, es decir, por qué se realizan ciertos cambios y las correspondientes compensaciones en tiempo, recursos o características.
Los cambios continuos en el desarrollo del producto harán que su estructura general sea cada vez más confusa, y el código de parche hará que todo el programa sea difícil de entender y mantener. La inserción de código de parche hará que el módulo viole los principios de diseño de cohesión fuerte y acoplamiento flojo, especialmente cuando la gestión de la configuración del proyecto es imperfecta, causará problemas al deshacer cambios y eliminar funciones. Si identifica estas características que pueden generar cambios desde el principio, podrá desarrollar una estructura más sólida que pueda adaptarse mejor a ellos. De esta manera, los cambios en los requisitos durante la fase de diseño no conducirán directamente a un código parcheado. Al mismo tiempo,
3. La falta de claridad es el problema más aterrador en los requisitos. presupuesto. Su primer significado es que muchos lectores tienen diferentes interpretaciones de la especificación de requisitos; el otro significado es que un lector puede interpretar una declaración de requisitos de múltiples maneras.
Los requisitos vagos harán que las diferentes partes interesadas tengan expectativas diferentes, harán que los desarrolladores pierdan el tiempo en temas equivocados y harán que los evaluadores y desarrolladores tengan expectativas inconsistentes. Un evaluador de sistemas me dijo una vez que su equipo de pruebas a menudo no entendía bien los requisitos y tenía que reescribir muchos casos de prueba y volver a ejecutar muchas pruebas.
Una forma de abordar los requisitos ambiguos es organizar un equipo responsable de revisar los requisitos desde diferentes perspectivas. Simplemente hojear el documento de requisitos no resolverá la ambigüedad. Si diferentes revisores interpretan los requisitos desde diferentes perspectivas, pero cada revisor realmente comprende el documento de requisitos, la ambigüedad no se descubrirá hasta más adelante en el proyecto y será costoso corregirla.
4. Funciones innecesarias
"Superfluas" se refiere a los desarrolladores que intentan agregar algunas funciones nuevas que son "apreciadas por los usuarios" pero que no están cubiertas en la especificación de requisitos. A menudo sucede que los usuarios sienten que estas funciones no son muy útiles, por lo que los esfuerzos invertidos en ellas son "en vano". Los desarrolladores deben concebir soluciones para los clientes y proporcionarles algunas ideas innovadoras. Las funciones específicas que se proporcionarán deben estar dentro del límite de tiempo permitido, equilibrando las necesidades del cliente y la viabilidad técnica de los desarrolladores. Los desarrolladores deben esforzarse por hacer que las funciones sean simples y fáciles de usar.
De manera similar, los clientes a veces pueden solicitar funciones que parecen "interesantes" pero que carecen de valor práctico, y la implementación de estas funciones sólo puede llevar mucho tiempo y ser costosa. Para minimizar el daño de lo "superfluo", debe asegurarse de comprender por qué se incluyen estas funciones y los "pros y contras" de estas funciones, de modo que el proceso de análisis de requisitos siempre se centre en aquellas funciones principales que permiten a los usuarios completar las tareas comerciales. .
5. Especificaciones demasiado concisas
A veces los clientes no entienden la importancia del análisis de la demanda y solo hacen una breve especificación que sólo involucra el contenido conceptual del producto, para luego dejarlo en manos de los desarrolladores. El personal se perfecciona a medida que avanza el proyecto. Es probable que el resultado sea que los desarrolladores primero establezcan la estructura del producto y luego completen la descripción de los requisitos. Este enfoque puede ser adecuado para productos de investigación de vanguardia o cuando los requisitos en sí son muy flexibles. Pero en la mayoría de los casos, causa frustración a los desarrolladores (dejándolos en suposiciones incorrectas y en un estado extremadamente limitado)
6. Ignorar la clasificación de los usuarios
Gran La mayoría de los productos son utilizados por diferentes grupos de usuarios. personas, con diferentes características de uso, frecuencia de uso y niveles de educación y experiencia de los usuarios. Si estos usuarios principales no pueden clasificarse en las primeras etapas del proyecto, algunos usuarios quedarán decepcionados con el producto. Por ejemplo, las operaciones basadas en menús son demasiado ineficientes para los usuarios avanzados, pero los comandos vagos y las teclas de acceso directo pueden dificultar la operación para los usuarios no calificados.
7. Planificación inexacta
Según las estadísticas, existen cinco razones principales para una estimación inexacta del coste del software durante el proceso de demanda: cambios frecuentes en la demanda, falta de demanda y comunicación con los usuarios. No es suficiente, las especificaciones de requisitos son de baja calidad y el análisis de requisitos está incompleto.
Para preguntas sobre requisitos inexactos, la respuesta correcta es "Te lo diré cuando realmente comprenda tus requisitos". Las estimaciones prematuras de la demanda basadas en información insuficiente y en necesidades mal consideradas son susceptibles a una serie de factores. Al hacer estimaciones, es mejor dar un rango. A menudo se dan estimaciones no preparadas como conjeturas, pero el oyente las toma como una promesa. Así que trate de fijarse objetivos alcanzables y cúmplalos.
6. Cooperación entre analistas de requisitos y usuarios
Los productos de software excelentes se basan en requisitos excelentes, y los requisitos de alta calidad provienen de una comunicación y cooperación efectivas entre clientes y desarrolladores. A menudo, la relación entre desarrolladores y clientes o agentes de clientes, como los especialistas en marketing, se vuelve de naturaleza conflictiva. Las fricciones surgirán cuando los directivos de ambas partes sólo quieran sus propios intereses y dejen de lado los requisitos de los usuarios. En este caso ninguna de las partes ganará nada.
Una asociación sólo se puede establecer cuando ambos participantes entienden lo que necesitan para tener éxito, y también deben saber lo que su socio necesita para tener éxito. A medida que aumenta la presión del proyecto, es fácil olvidar que todas las partes interesadas tienen los mismos objetivos. De hecho, todo el mundo quiere desarrollar un producto de software excelente que pueda alcanzar valor comercial, satisfacer las necesidades de los usuarios y satisfacer a los desarrolladores.
La Declaración de requisitos del cliente de software enumera diez requisitos legales para que los clientes se comuniquen con analistas y desarrolladores durante la implementación del proyecto de requisitos del proyecto. Cada uno de estos derechos corresponde a obligaciones de los desarrolladores y analistas de software. La declaración de requisitos del cliente de software también enumera diez obligaciones que el cliente debe asumir durante el proceso de requisitos. Como declaración de derechos del desarrollador, si lo desea.
Los clientes tienen los siguientes derechos:
1: Exigir a los analistas que utilicen expresiones que se ajusten a los hábitos lingüísticos del cliente.
Las discusiones sobre requisitos deben centrarse en las necesidades y tareas comerciales, por lo que se deben utilizar términos comerciales. Es necesario enseñar a los analistas y no es necesario comprender la terminología de la industria informática.
2. Los analistas deben comprender el negocio y los objetivos del cliente.
Al comunicarse con los usuarios para obtener sus necesidades, los analistas pueden comprender mejor sus tareas comerciales y cómo hacer que los productos satisfagan mejor sus necesidades.
Esto ayudará a los desarrolladores a diseñar un excelente software que realmente satisfaga sus necesidades y expectativas. Para ayudar a los desarrolladores y analistas, podría considerar invitarlos a observarlo a usted o a sus colegas en el trabajo. Si se utiliza un nuevo sistema de desarrollo para reemplazar un sistema existente, los desarrolladores deben usar el sistema actual, lo que les ayudará a comprender cómo funciona el sistema actual.
3. Solicitar a los analistas que escriban especificaciones de requisitos de software.
El analista debe recopilar toda la información obtenida de usted y de otros clientes. Distinguir entre requisitos y especificaciones comerciales, requisitos funcionales, objetivos de calidad, soluciones y otra información. A través de estos análisis, se pueden obtener especificaciones de requisitos de software. Esta especificación de requisitos de software permite a los desarrolladores y clientes ponerse de acuerdo sobre el contenido del producto a desarrollar. Las especificaciones de requisitos de software se pueden organizar y escribir de una manera que le resulte fácil de leer y comprender. Revise las especificaciones preparadas para asegurarse de que expresen de manera precisa y completa sus necesidades. Una especificación de requisitos de software de alta calidad puede ayudar al desarrollo.
4. Solicitar una explicación de los resultados del trabajo requerido.
Los analistas pueden utilizar varios diagramas para complementar las especificaciones textuales de requisitos de software. Debido a que diagramas como los diagramas de flujo de trabajo pueden describir claramente ciertos aspectos del comportamiento de un sistema, los diagramas en las especificaciones de requisitos son de gran valor. Aunque no son demasiado difíciles de entender, es posible que no estés familiarizado con ellos. Por lo tanto, se puede pedir a los analistas que expliquen la funcionalidad de cada diagrama o el significado de otros símbolos y resultados del desarrollo de requisitos, y cómo verificar los diagramas en busca de errores o inconsistencias.
5. Por favor, los desarrolladores respeten sus opiniones.
Si los usuarios y los desarrolladores no pueden entenderse entre sí, habrá obstáculos en la discusión de los requisitos. Sólo trabajando juntos todos podrán "entenderse". Los clientes involucrados en el proceso de desarrollo de requisitos tienen derecho a exigir que los desarrolladores los respeten y valoren el tiempo que dedican al éxito del proyecto. Asimismo, el cliente debe mostrar respeto y gratitud por los esfuerzos del desarrollador para que el proyecto sea un éxito.
6. Solicite a los desarrolladores que brinden sugerencias e ideas sobre los requisitos y la implementación del producto.
Normalmente, lo que el cliente llama "necesidad" es una solución de implementación práctica. Los analistas intentan comprender el negocio real y sus necesidades a partir de estas soluciones, al mismo tiempo que identifican deficiencias en los sistemas existentes para garantizar que el producto no sea ineficaz o ineficiente. Después de comprender a fondo algo en el ámbito empresarial, los analistas a veces pueden encontrar formas bastante buenas de mejorarlo. Los analistas experimentados y creativos también pueden proponer agregar funciones al sistema que los usuarios tal vez no encuentren valiosas.
7. Describe las características de facilidad de uso del producto.
Puede pedir a los analistas que presten atención a la usabilidad del software mientras implementan los requisitos funcionales, porque estas características o atributos de calidad fáciles de usar pueden permitirle completar tareas de manera más precisa y eficiente. Por ejemplo, los clientes a veces exigen que los productos sean "fáciles de usar", "robustos" o "eficientes", pero esto es demasiado subjetivo para que los desarrolladores tengan valor práctico. Con razón, los analistas utilizan consultas y encuestas para comprender qué quieren los clientes para que sean amigables, sólidos y eficientes.
8. Alinear los requisitos y permitir la reutilización de componentes de software existentes.
Los requisitos suelen ser flexibles. Los analistas pueden encontrar que los componentes de software existentes están estrechamente alineados con las necesidades que usted describe. En este caso, el analista debería proporcionar algunas opciones para modificar los requisitos para que los desarrolladores puedan reutilizar parte del software existente en el desarrollo del nuevo sistema. Si existe la oportunidad de reutilizar y puede ajustar sus propias necesidades al mismo tiempo, entonces se reduce el costo, se ahorra tiempo y no es necesario seguir estrictamente las necesidades originales. Por lo tanto, si desea utilizar algunos componentes comerciales existentes en su producto y no se ajustan exactamente a las características que necesita, un cierto grado de flexibilidad de requisitos es extremadamente importante.
9. Obtener un sistema que cumpla con los requisitos funcionales y de calidad del cliente.
Todo el mundo quiere que este proyecto tenga éxito. Pero esto requiere no sólo que usted les diga claramente a los desarrolladores todo lo que "hace" el sistema, sino también que los desarrolladores comprendan claramente las compensaciones y limitaciones a través de la comunicación. Debe expresar claramente sus suposiciones y expectativas subyacentes. De lo contrario, es posible que el producto desarrollado por el desarrollador no le satisfaga.
Los clientes tienen las siguientes obligaciones:
1: Explicar su negocio a los analistas.
Los analistas confían en usted para que les explique los conceptos y la terminología empresarial. Pero no puedes esperar que los analistas sean expertos en esto, sólo puedes hacer que comprendan verdaderamente tus problemas y objetivos. No espere que los analistas capten las sutilezas y el potencial de su negocio.
Lo más probable es que no conozcan el “conocimiento común” que usted y sus colegas dan por sentado.
2. Tómese el tiempo para explicar claramente y perfeccionar los requisitos.
Los clientes están muy ocupados y, a menudo, tienen que participar en el desarrollo de la demanda durante las horas de mayor actividad. Sin embargo, está obligado a tomarse el tiempo para participar en sesiones de lluvia de ideas, entrevistas u otras actividades para obtener requisitos. A veces los analistas pueden pensar que entienden su punto primero, sólo para luego descubrir que necesitan su explicación. En este momento, espere pacientemente la repetición y el refinamiento de los requisitos, porque este es un fenómeno natural en la comunicación humana y es extremadamente importante para el éxito de los productos de software.
3. Explicar los requisitos con precisión y detalle
Escribir un documento de requisitos claro y preciso es muy difícil. Debido a que ocuparse de los detalles no sólo es molesto sino que requiere mucho tiempo, es fácil quedarse con requisitos vagos. Sin embargo, durante el desarrollo se debe abordar esta ambigüedad e inexactitud. Y usted es la mejor persona para tomar las decisiones para resolver estos problemas. De lo contrario, tendrás que confiar en las conjeturas del desarrollador. Es una buena idea agregar temporalmente un signo de pendiente a la especificación de requisitos. TBD (también puede abreviarse en pinyin chino como "DQD: por determinar"). Puede indicar qué necesita mayor discusión, análisis o información adicional. A veces, sin embargo, un requisito particular puede marcarse como TBD porque es difícil de resolver o porque nadie quiere trabajar en él. Explique el contenido de cada requisito lo más claramente posible para que los analistas puedan escribirlo con precisión en la especificación de requisitos de software. Si no se puede expresar con precisión en este momento, permita el proceso de obtención de la información precisa necesaria. A menudo se utilizan las llamadas técnicas de creación de prototipos. A través del prototipo desarrollado, podrá modificarlo repetidamente con los desarrolladores para mejorar continuamente la definición de requisitos.
4. Toma decisiones oportunas
Al igual que un arquitecto que construye una casa para ti, los analistas te pedirán que tomes algunas decisiones. Estas decisiones incluyen manejar múltiples métodos propuestos por usuarios o elegir un compromiso entre características de calidad en conflicto y precisión de la información. Los clientes que tienen poder de decisión deben tomar una actitud positiva ante todo esto y tomar decisiones lo antes posible, porque los desarrolladores normalmente tienen que esperar a que usted tome una decisión antes de poder actuar, y esta espera retrasará el avance del proyecto. .
5. Respetar las necesidades, la viabilidad y la evaluación de costos de los desarrolladores.
Todas las funciones del software tienen sus propios precios de costo, y los desarrolladores son los más adecuados para presupuestar estos costos (aunque muchos desarrolladores no lo hacen). en evaluación y predicción). Es posible que algunas de las características del producto que desea no sean técnicamente viables o su implementación resulte prohibitivamente costosa. Los desarrolladores evaluarán los requisitos negativamente si intentan exigir un rendimiento que es imposible en el entorno operativo u obtener datos que simplemente no están disponibles. Debes respetar sus opiniones. A veces, se puede llegar a un requisito que sea técnicamente factible y barato de implementar. Por ejemplo, no es factible exigir que un determinado comportamiento ocurra "instantáneamente", pero se puede lograr cambiándolo a una declaración de requisitos de tiempo más específica ("dentro de 50 ms", pero no se pueden sacar conclusiones fácilmente sin un análisis técnico preciso). ).
6. Priorizar los requisitos
La mayoría de los proyectos no tienen suficiente tiempo ni recursos para implementar cada detalle de la característica. Decidir qué características son necesarias, cuáles son importantes y cuáles es bueno tener es una parte importante del desarrollo de requisitos. Usted solo puede ser responsable de establecer las prioridades de los requisitos porque los desarrolladores no pueden decidir las prioridades de los requisitos en función de su perspectiva. Los desarrolladores le brindarán información sobre los costos y riesgos de cada requisito. Cuando estableces prioridades, ayudas a los desarrolladores a garantizar los mejores resultados en el tiempo adecuado con el mínimo esfuerzo. Se debe respetar la opinión del desarrollador en cuanto a si, o en qué medida, la funcionalidad requerida se puede lograr dentro de las limitaciones de tiempo y recursos. Aunque nadie quiere ver que los requisitos deseados no se cumplan en el proyecto, al fin y al cabo tienen que afrontar esta realidad. Las decisiones comerciales a veces tienen que reducir el alcance del proyecto o extender el período de construcción, agregar recursos o encontrar un compromiso en la calidad basado en prioridades.
7: Revisar los documentos de requisitos y los prototipos
Como veremos en el Capítulo 14, revisar los documentos de requisitos, ya sean formales o informales, ayudará a mejorar la calidad del software. Sólo involucrando al cliente en la revisión se puede identificar realmente si el documento de requisitos está completo e interpreta correctamente las características necesarias esperadas. Las revisiones también brindan una oportunidad para que los representantes de cuentas brinden comentarios a los analistas de requisitos para mejorar su trabajo. Si cree que el documento de requisitos que redactó no es lo suficientemente preciso, tiene la obligación de comunicárselo al analista lo antes posible y darle sugerencias para mejorar. Es difícil imaginar cómo será el software real leyendo la especificación de requisitos.
Un mejor enfoque es desarrollar primero un prototipo de su producto, de modo que pueda brindar comentarios más valiosos a los desarrolladores y ayudarlos a comprender mejor sus necesidades. Es importante darse cuenta de que un prototipo no es un producto real, pero un desarrollador puede convertirlo y ampliarlo hasta convertirlo en un sistema completo.
8. Si sus necesidades cambian, contáctenos de inmediato.
Los continuos cambios en la demanda tendrán un grave impacto negativo en la finalización de los productos de alta calidad planificados. El cambio es inevitable, pero cuanto más tarde en el ciclo de desarrollo se produzca, mayor será su impacto. Los cambios no sólo pueden dar lugar a costosas repeticiones de trabajo, sino que también pueden forzar retrasos en la programación, especialmente si es necesario agregar nuevas funciones una vez completada la estructura general. Entonces, tan pronto como vea la necesidad de cambiar los requisitos, notifique a sus analistas de inmediato.
9. Se debe seguir el proceso de la organización de desarrollo para manejar los cambios de requisitos.
Para minimizar el impacto negativo de los cambios, todos los participantes deben seguir el proceso de control de cambios del proyecto. Esto requiere no abandonar todos los cambios propuestos, analizar y considerar exhaustivamente cada cambio requerido y, finalmente, tomar decisiones apropiadas para garantizar que se introduzcan algunos cambios en el proyecto.
10: Respetar el proceso de ingeniería de requisitos utilizado por los desarrolladores.
Lo más desafiante en el desarrollo de software es recopilar requisitos y determinar su exactitud. El enfoque adoptado por los analistas es acertado. Puede pensar que el proceso de requisitos no es rentable, pero crea que el tiempo dedicado al desarrollo de requisitos es "valioso". Todo el proceso será más fluido si comprende y respalda las técnicas utilizadas por los analistas para recopilar y compilar documentos de requisitos y garantizar su calidad. Simplemente pregúntele al analista por qué quiere recopilar cierta información o participar en actividades relacionadas con los requisitos.
Los analistas de sistemas pueden encontrar los siguientes problemas durante el proceso de desarrollo. Es posible que algunos clientes ocupados no estén dispuestos a participar activamente en el proceso de requisitos, y la falta de participación del cliente probablemente dé como resultado productos insatisfactorios. Por lo tanto, es necesario garantizar que todos los actores clave en el desarrollo de requisitos comprendan y acepten sus obligaciones. Si surgen desacuerdos, se puede llegar a un entendimiento mutuo de las obligaciones respectivas mediante la negociación, lo que puede reducir fricciones futuras.
7. Documento de requisitos
El resultado final del desarrollo de requisitos es que el cliente y el equipo de desarrollo se ponen de acuerdo sobre el producto a desarrollar. Este protocolo integra requisitos comerciales, requisitos de usuario y requisitos funcionales de software. Como vimos anteriormente, los documentos de vista y alcance del proyecto contienen requisitos comerciales, mientras que los documentos de casos de uso contienen requisitos de usuario. Debe escribir el documento de requisitos funcionales a partir de los casos de uso del producto y los documentos de requisitos no funcionales. Incluye atributos de calidad y requisitos de interfaz externa. Sólo cuando estos documentos estén escritos de manera estructurada y legible, y sean revisados y aprobados por las partes interesadas del proyecto, las personas de todos los ámbitos de la vida podrán estar seguros de que los requisitos que acuerdan son sólidos.
Puede utilizar los siguientes tres métodos para escribir especificaciones de requisitos de software:
Escribir documentos de texto con buena estructura y lenguaje natural.
Establecer un modelo gráfico que pueda describir el proceso de conversión, el estado del sistema y sus cambios, las relaciones de datos, los flujos lógicos o las clases de objetos y sus relaciones.
Escribir especificaciones formales que definan requisitos utilizando un lenguaje lógico formal matemáticamente preciso.
Debido al rigor y precisión de las especificaciones formales, sólo unos pocos desarrolladores de software están familiarizados con el lenguaje formal utilizado, y mucho menos los clientes. Aunque el lenguaje natural estructurado tiene muchas desventajas, sigue siendo el método más realista para escribir documentos de requisitos en la mayoría de los proyectos de software. La mayoría de los proyectos han aceptado las especificaciones de requisitos de software basadas en texto, incluidos los requisitos funcionales y no funcionales. Los modelos de análisis gráfico mejoran la especificación de los requisitos de software al proporcionar otra vista de los requisitos.