Cómo analizar sistemáticamente las necesidades de los usuarios

La definición de requisitos incluye tanto el punto de vista del usuario (el comportamiento externo del sistema) como el punto de vista del desarrollador (algunas funciones internas).

La cuestión clave es documentar los requisitos. Una vez vi un proyecto en el que todos los desarrolladores fueron reemplazados a mitad del proyecto y el cliente se vio obligado a sentarse con un nuevo analista de requisitos. El analista de sistemas dice: "Queremos hablar con usted sobre sus necesidades". La primera respuesta del cliente es: "Le dije a su ex todo lo que quería y ahora solo quiero diseñar un sistema para mí". Pepsi

De hecho, en UGG los requisitos no estaban documentados, por lo que el nuevo analista tuvo que empezar de cero si lo único que tiene es un montón de correos electrónicos, notas de reuniones o conversaciones dispersas, y cree. Si comprende las necesidades de sus usuarios, se está engañando.

Otra definición de requisitos es "necesidades del usuario". Una declaración que desencadena el desarrollo de un programa o sistema". Algunos expertos en análisis de requisitos han ampliado esto. concepto: "Las características, funciones y propiedades de un sistema. Estas características, características y propiedades se pueden encontrar "fuera del sistema para satisfacer las necesidades del usuario". Estas definiciones enfatizan qué es el producto en lugar de cómo está diseñado o construido. Las siguientes definiciones van más allá de las necesidades del usuario a las características del sistema:

Los requisitos son especificaciones de objetivos que deben alcanzarse. Describen el comportamiento, las características o los atributos del sistema y son una restricción del sistema durante el desarrollo. proceso.

A partir de estas diferentes formas de definición, no nos resulta difícil ver que "necesidad" no tiene un término claro y no binario. La verdadera "necesidad" está en realidad en la mente de las personas. Y esta persona es principalmente el cliente, pero en circunstancias normales, los usuarios no pueden describir sus propias necesidades, el analista del sistema solo necesita clasificar las necesidades relevantes en su propio idioma de acuerdo con la descripción del usuario y luego verificar más con el El analista del sistema y el cliente deben asegurarse de que el cliente pueda obtener toda la información. Los ingenieros y los clientes deben asegurarse de que todas las partes interesadas del proyecto tengan un conocimiento profundo de la terminología utilizada para describir los requisitos. Los requisitos documentados (como la especificación de requisitos que se describe a continuación) son solo un modelo, 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 describir lo que se va a desarrollar. La tarea conceptual más difícil es escribir requisitos técnicos detallados, que incluyen todas las interfaces con usuarios, máquinas y otros sistemas de software. Si esta parte del trabajo no se realiza correctamente, puede terminar. Causa un gran daño al sistema y será extremadamente difícil de modificar en el futuro. Los productos nacionales son muy complejos. Una empresa puede tener varios sistemas ejecutándose en paralelo y la interfaz entre ellos es el problema más problemático para los desarrolladores de sistemas.

Para aplicaciones empresariales de usuario final, sistemas de información empresarial y software, ser parte de un sistema de producto más grande es obvio, pero para nosotros, los desarrolladores, sin un documento de requisitos aprobado por el cliente, ¿cómo sabemos cuándo? ¿El proyecto termina si no sabemos qué es lo más importante para el cliente?

Sin embargo, incluso los requisitos de software no comerciales son necesarios, como bibliotecas, componentes y herramientas para uso interno del equipo de desarrollo. . Por supuesto, es posible que ocasionalmente esté de acuerdo con otros sin documentación, pero la mayoría de las veces, la reelaboración es una consecuencia inevitable y el costo de reescribir el código excede con creces el costo de reescribir los documentos de requisitos. Desarrollo de software en China. Esto es lo que le sucedió al personal. .

Recientemente, me encontré con un equipo de desarrollo que estaba desarrollando 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, que era lo que querían los usuarios. Como resultado, los equipos tuvieron que transcribir manualmente los archivos de código fuente para revisar el código.

Esto ilustra que incluso si los requisitos son claros y bien concebidos, si no documentamos el software, sólo seremos culpados si el software no logra los objetivos previstos.

Al contrario de esto, he visto una interfaz simple integrada en un "sistema de seguimiento de errores", pero solo se escribió una especificación de requisitos de una página. Los administradores de sistemas operativos encuentran útil una lista simple de requisitos cuando escriben scripts. Cuando probaron el sistema según los requisitos, no sólo implementó muy claramente toda la funcionalidad necesaria, sino que no se encontraron errores.

De hecho, el documento de requisitos les guía durante todo el proceso de desarrollo.

3. Proceso de análisis de requisitos

Todo el campo de investigación de la ingeniería de requisitos de software se puede dividir en dos campos más apropiados: desarrollo de la demanda y gestión de la demanda, como se muestra en la Figura 4-1:

Figura 4-1 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 segmentos incluyen todas las actividades de recopilación, evaluación y documentación de requisitos dentro del producto de software. Las actividades de desarrollo de requisitos incluyen lo siguiente:

Determinar las categorías de usuarios requeridas para el producto.

Obtén los requisitos de cada categoría de usuario.

Comprenda las tareas y objetivos reales de los usuarios y la empresa necesita soporte para estas tareas.

Analice la información derivada del usuario para distinguir los requisitos de las tareas del usuario, los requisitos funcionales, las reglas comerciales, los atributos de calidad, las soluciones recomendadas y otra información.

Dividir los requisitos a nivel de sistema en subsistemas y asignar algunos de los requisitos a componentes de software.

Comprender la importancia de los atributos de calidad relevantes.

Discutir las prioridades de implementación.

Documentar y modelar los requisitos de usuario recopilados.

Revisar las especificaciones de requisitos para garantizar una comprensión compartida de los requisitos del usuario y aclarar problemas antes de que todo el equipo de desarrollo los acepte.

La gestión de requisitos implica "establecer y mantener contratos con clientes en ingeniería de software". Este contrato está contenido en los documentos de requisitos y modelos que se redactan. La aceptación de los requisitos por parte del cliente es sólo la mitad de la batalla; los desarrolladores deben poder aceptar los requisitos e implementarlos en el producto. Las actividades típicas de gestión de requisitos incluyen:

Determinar la línea base de requisitos (el texto del documento de requisitos para un desarrollo rápido).

Revisar las modificaciones propuestas a los requisitos, evaluar el posible impacto de cada modificación y decidir si implementarla.

Integrar los cambios de requisitos en el 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 para las soluciones del proyecto.

Vincula cada requisito con el diseño, el código fuente y los casos de prueba correspondientes para facilitar el seguimiento.

Seguimiento del estado de los requisitos y sus cambios a lo largo del proyecto.

Los puntos anteriores se basan en mi experiencia como analista de sistemas después de un proyecto de implementación exitoso, y también se basan en otras experiencias exitosas relacionadas con la implementación de sistemas en el país y en el extranjero.

4. Tipos de requisitos

Las siguientes son definiciones de términos comúnmente utilizados en el campo de la ingeniería de requisitos.

Los requisitos de software incluyen tres niveles diferentes: requisitos de negocio, requisitos de usuario y requisitos funcionales (incluidos también los requisitos no funcionales).

1. Los requisitos comerciales reflejan los requisitos objetivos de alto nivel de la organización o del cliente para sistemas y productos, que se describen en los documentos de vista y alcance del proyecto.

2. El documento de requisitos del usuario describe el trabajo que los usuarios deben completar al utilizar el producto, que se explica en el documento del caso de uso o en la descripción del script del programa.

3. Los requisitos funcionales (requisito funcional) definen las funciones de software que los desarrolladores deben implementar para permitir a los usuarios completar tareas y satisfacer las necesidades comerciales.

En la Especificación de Requisitos de Software (SRS), la declaración de requisitos funcionales describe completamente el comportamiento externo que debe tener el sistema de software.

SRS juega un papel importante en el desarrollo, pruebas, control de calidad, gestión de proyectos y funciones relacionadas del proyecto. Para un sistema grande, los requisitos funcionales del software pueden ser un subconjunto de requisitos del sistema, ya que otros requisitos pueden ser subsistemas (o componentes de software).

Como complemento a los requisitos funcionales, las especificaciones de requisitos de software también deben incluir requisitos no funcionales, que describen los comportamientos y operaciones que el sistema presenta a los usuarios. Incluye estándares, especificaciones y contratos a los que debe ajustarse el producto; detalles específicos de los requisitos de desempeño externos; limitaciones de diseño o implementación y atributos de calidad; Las restricciones son limitaciones a las que se enfrentan los desarrolladores al diseñar y crear productos de software. Los atributos de calidad describen las características de un producto desde múltiples perspectivas para reflejar su funcionalidad. Describir un producto desde múltiples perspectivas es importante tanto para los usuarios como para los desarrolladores.

A continuación se muestra un ejemplo de diferentes tipos de requisitos para un programa de procesamiento de textos. La necesidad empresarial podría ser "Los usuarios pueden corregir eficazmente los errores ortográficos en los documentos", mientras que la cubierta de la caja del producto podría indicar que se trata de un corrector ortográfico que satisface la necesidad empresarial. Un requisito de usuario correspondiente podría ser "Buscar errores ortográficos en un archivo y reemplazar selectivamente las palabras mal escritas con una lista proporcionada de palabras de reemplazo". Al mismo tiempo, los correctores ortográficos deben cumplir una serie de requisitos funcionales, como buscar y resaltar palabras mal escritas, mostrar cuadros de diálogo que ofrezcan sustituciones y permitir sustituciones 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 del plan del proyecto o información de prueba. Los requisitos no tienen nada que ver con estos, se centran en describir exactamente lo que se quiere desarrollar. Además, existen otros aspectos del proyecto, como requisitos para un entorno de desarrollo o requisitos para lanzar el producto y trasladarlo a un entorno de soporte. Aunque estos requisitos son críticos para el éxito del proyecto, no son el tema de este libro.

5. Principios del análisis de requisitos

Los equipos de proyecto que no presten atención al proceso de requisitos cosecharán las consecuencias. Los defectos en la ingeniería de requisitos plantean riesgos importantes para el éxito del proyecto, que es la capacidad de entregar un producto que cumpla plenamente con las expectativas del usuario en términos de funcionalidad y calidad, a tiempo y a un precio razonable. Algunos riesgos de requisitos se analizan a continuación.

Algunos riesgos asociados con un proceso de requisitos inadecuado:

1. Participación insuficiente de los usuarios

Los clientes a menudo no entienden por qué se dedica tanto esfuerzo a recopilar requisitos y garantizar su calidad, mientras que es posible que los desarrolladores tampoco valoren la participación de los usuarios. Esto se debe a que los desarrolladores piensan que trabajar con los usuarios es menos divertido que escribir código, o porque creen que ya entienden lo que quieren los usuarios. En algunos casos, es difícil tener contacto directo con las personas que realmente utilizan el producto y los clientes no necesariamente saben lo que realmente quieren. Sin embargo, al principio del proyecto, el equipo de desarrollo debe involucrar directamente a una muestra representativa de usuarios y realizar juntos todo el proceso de desarrollo.

En el proceso de práctica, el personal del sistema también tiene algunos sentimientos. Durante la implementación del proyecto de una empresa, si no hay suficientes usuarios para participar, los requisitos obtenidos por el personal del sistema serán unilaterales e incompletos. Los riesgos se colocarán al comienzo de los requisitos del sistema.

2. Las demandas de los usuarios continúan aumentando

Durante el proceso de desarrollo, si las demandas continúan aumentando, el proyecto será cada vez más grande, superando el plan y el presupuesto. El hecho de que los planes no siempre coincidan con la escala y la complejidad de las necesidades, los riesgos, la productividad del desarrollo y los cambios en la demanda del proyecto hace que los problemas sean más difíciles de resolver. De hecho, la raíz del problema radica en las necesidades cambiantes de los usuarios y los cambios que realizan los desarrolladores para satisfacer los nuevos requisitos.

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 establecerse claramente desde el principio y utilizarse como marco de referencia para evaluar los cambios en los requisitos y la nueva funcionalidad. Esta descripción incluye un proceso de control de cambios que analiza el impacto de cada cambio y ayuda a todas las partes interesadas a comprender el fundamento de las decisiones comerciales, es decir, por qué se realizan ciertos cambios y el costo en términos de tiempo, consumo de recursos o funcionalidades pesa en consecuencia.

Los cambios continuos en el desarrollo de productos pueden hacer que su estructura general se vuelva cada vez más confusa, y el código de parche puede hacer que todo el programa sea difícil de entender y mantener.

Insertar código de parche puede hacer que un módulo viole los principios de diseño de cohesión fuerte y acoplamiento flojo, mientras que deshacer cambios y eliminar funcionalidad también puede causar problemas, especialmente si la gestión de la configuración del proyecto es imperfecta. Si puede distinguir estas características potencialmente modificables desde el principio, podrá desarrollar una arquitectura más sólida y adaptarse mejor a ella. De esta manera, los cambios en los requisitos durante la fase de diseño no conducirán directamente a la aplicación de parches en el código y podrá minimizar la pérdida de calidad causada por los cambios.

3. Requisitos ambiguos

La ambigüedad es el problema más aterrador en las especificaciones de requisitos. En un nivel, significa que muchos lectores pueden interpretar la especificación de requisitos de manera diferente; en otro nivel, significa que un solo lector puede interpretar la especificación de requisitos de múltiples maneras.

Los requisitos ambiguos pueden crear diferentes expectativas entre las diferentes partes interesadas, hacer que los desarrolladores pierdan tiempo en temas equivocados y hacer que los evaluadores no se alineen con las expectativas de los desarrolladores. 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 rehacer muchas pruebas.

Una forma de abordar los requisitos ambiguos es organizar equipos responsables de revisar los requisitos desde diferentes perspectivas. Simplemente hojear el documento de requisitos no resolverá las ambigüedades. Si diferentes revisores interpretan la especificación de requisitos desde diferentes perspectivas, pero cada revisor realmente comprende el documento de requisitos, las ambigüedades no se descubrirán hasta más adelante en el proyecto, cuando corregir las ambigüedades puede resultar costoso.

4. Funciones innecesarias

El término "funciones adicionales" se refiere a los desarrolladores que intentan agregar nuevas funciones que "gustan a los usuarios" pero que no están incluidas en la especificación de requisitos central. A menudo, los usuarios no encuentran útiles estas funciones, por lo que el esfuerzo invertido en ellas es "en vano". Los desarrolladores deben conceptualizar soluciones para los clientes y brindarles ideas innovadoras sobre qué funciones ofrecer, equilibrando las necesidades del cliente y la viabilidad técnica del desarrollador dentro del tiempo permitido, y deben esforzarse por hacer que las funciones sean fáciles de usar sin el permiso del cliente. los requisitos del cliente sin consentimiento.

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 solo consumirá mucho tiempo y costo. Para minimizar el daño de lo "superfluo", debe asegurarse de comprender por qué incluye estas funciones y los "pros y contras" de estas funciones, de modo que el proceso de análisis de requisitos permanezca centrado en la funcionalidad principal que permite a los usuarios completar sus tareas empresariales.

5. Especificaciones demasiado condensadas

A veces los clientes no comprenden la importancia del análisis de necesidades y, por lo tanto, compilan una especificación muy breve que solo cubre los aspectos conceptuales del producto y deja que los desarrolladores los refinen. a medida que avanza el proyecto y, como resultado, es probable que los desarrolladores construyan la estructura del producto antes de completar las especificaciones de requisitos. Este enfoque puede ser adecuado para productos de investigación de vanguardia o productos donde los requisitos son inherentemente flexibles. Sin embargo, en la mayoría de los casos, este enfoque frustra a los desarrolladores (que trabajan con suposiciones erróneas y una orientación muy limitada) y molesta a los clientes (que no obtienen el producto que imaginaron).

6. Ignora categorizar a los usuarios

La mayoría de los productos son utilizados por diferentes personas, que tienen diferentes características, diferente frecuencia de uso y diferentes niveles de educación y experiencia. Si no realiza una selección de todos estos usuarios clave al principio del proyecto, es probable que los usuarios finales se sientan decepcionados con el producto. Por ejemplo, las operaciones basadas en menús son demasiado ineficientes para los usuarios avanzados, pero los comandos y atajos poco claros las dificultan para los usuarios no cualificados.

7. Planificación inexacta

Según las estadísticas, hay cinco razones principales por las que las estimaciones de costos de software son muy inexactas en el proceso de demanda: cambios frecuentes en la demanda, falta de demanda y comunicación con usuarios Insuficiencia, mala calidad de las especificaciones de la demanda y análisis inadecuado de la demanda.

Para preguntas sobre requisitos inexactos, la respuesta correcta es "Volveré a usted cuando realmente comprenda sus necesidades". Las estimaciones inmaduras de la demanda basadas en información insuficiente y falta de pensamiento se ven fácilmente afectadas por una variedad de factores.

Al hacer estimaciones, es mejor dar un rango. Las estimaciones no preparadas suelen ser conjeturas y los oyentes las interpretarán como promesas. Por lo tanto, debemos intentar fijarnos un objetivo alcanzable y ceñirnos a él.

6. Asociación entre analistas de requisitos y usuarios

Los productos de software excelentes se construyen sobre la base de requisitos excelentes. Los requisitos de alta calidad provienen de una comunicación y colaboración efectivas entre clientes y desarrolladores. A menudo, la relación entre desarrolladores y clientes o agentes de clientes (como los especialistas en marketing) puede ser conflictiva. Si los administradores de ambas partes velan por sus propios intereses y dejan de lado los requisitos proporcionados por los usuarios, surgirán fricciones en ambas partes, en cuyo caso ninguna de las partes se beneficiará.

Una asociación sólo se puede establecer cuando ambas partes entienden lo que necesitan para tener éxito y lo que el socio necesita para tener éxito. A medida que aumentan las presiones del proyecto, es fácil olvidar que todas las partes interesadas tienen un objetivo común. Todo el mundo quiere desarrollar un producto de software excelente que ofrezca valor empresarial, satisfaga las necesidades de los usuarios y satisfaga a los desarrolladores.

La Declaración de derechos de requisitos del cliente de software enumera diez requisitos legales para que los clientes se comuniquen con analistas y desarrolladores durante la fase de ingeniería de requisitos de un proyecto. Cada derecho corresponde a una obligación para los desarrolladores y analistas de software. El documento de obligaciones de requisitos del cliente de software también enumera diez obligaciones del cliente durante el proceso de requisitos. Si lo desea, puede utilizar esto como una declaración de derechos de desarrollador.

Los clientes tienen los siguientes derechos:

1: Exigir a los analistas que utilicen expresiones coherentes con el idioma del cliente.

Las discusiones sobre requisitos deben centrarse en las necesidades y tareas del negocio, por lo que Se deben utilizar términos comerciales, debe enseñar estos términos a los analistas y no es necesario que conozca los términos de la industria informática.

2: Exija que los analistas comprendan 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 el producto sea más eficiente. satisfacer 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, considere invitarlos a observarlo a usted o a sus colegas en el trabajo. Si se está desarrollando un nuevo sistema para reemplazar un sistema existente, los desarrolladores deben utilizar el sistema existente, lo que les ayudará a comprender cómo funciona el sistema, su flujo de trabajo y qué se puede mejorar.

3: Pida a los analistas que escriban especificaciones de requisitos de software

Los analistas deben organizar toda la información que obtienen de usted y de otros clientes para distinguir entre requisitos y especificaciones comerciales, requisitos funcionales, objetivos de calidad, soluciones y otra información. El resultado del análisis es la especificación de requisitos del software. La especificación es un acuerdo entre el desarrollador y el cliente respecto del contenido del producto a desarrollar. Las especificaciones de requisitos de software se pueden organizar de una manera que sea fácil de leer y comprender. Revise la hoja de especificaciones para asegurarse de que exprese de manera precisa y completa sus necesidades. Las especificaciones de requisitos de software de alta calidad pueden ayudar a los desarrolladores a crear los productos que realmente necesitan.

4: Solicite explicar los resultados del trabajo de requisitos.

El analista puede utilizar varios diagramas para complementar el texto de especificación de requisitos de software. Esto se debe a que diagramas como los diagramas de flujo de trabajo pueden describir claramente ciertos aspectos del comportamiento de un sistema. Los diagramas de la especificación de requisitos son extremadamente valiosos. Aunque no son difíciles de entender, es posible que no te resulten familiares. Por lo tanto, pida al analista que explique el propósito y significado de los símbolos para cada diagrama u otro producto del esfuerzo de desarrollo de requisitos, y cómo verificar errores e inconsistencias en los diagramas.

5: Pida a los desarrolladores que respeten sus opiniones

Si hay una falta de entendimiento mutuo entre usuarios y desarrolladores, habrá obstáculos al discutir los requisitos y la cooperación hará que todos puedan. "escuchar y comprender". Los clientes involucrados en el proceso de desarrollo de requisitos tienen derecho a esperar que los desarrolladores respeten y valoren su tiempo y se comprometan con el éxito del proyecto. Asimismo, los clientes tienen derecho a respetar y apreciar los esfuerzos realizados por los desarrolladores para que el proyecto sea exitoso.

6: Pida a los desarrolladores que hagan sugerencias y sugerencias sobre los requisitos y la implementación del producto

Muchas veces, la llamada "demanda" de los clientes es en realidad un plan de implementación práctico, y los analistas Intentará comprender el negocio real y sus necesidades a partir de estas soluciones y, al mismo tiempo, descubrirá dónde el sistema existente no es adecuado para el negocio actual para garantizar que el producto no sea ineficaz o ineficiente. Con un conocimiento profundo del negocio, los analistas a veces pueden hacer buenas sugerencias para mejorar. Los analistas experimentados y creativos también pueden sugerir agregar funciones valiosas al sistema que los usuarios no descubren.

7: Describe las características de usabilidad del producto

Además de los requisitos funcionales, también puedes pedir a los analistas que se centren en la usabilidad del software. Esto se debe a que estas características de usabilidad, o atributos cualitativos, le permiten completar tareas de manera más precisa y eficiente. Por ejemplo, los clientes a veces piden que los productos sean "fáciles de usar", "robustos" o "eficientes", pero esto es demasiado subjetivo para que los desarrolladores tengan importancia práctica. Lo correcto es: los analistas deben preguntar e investigar para comprender las características específicas que los clientes desean en un producto que sea fácil de usar, sólido y eficiente.

8: Adaptar los requisitos para permitir la reutilización de componentes de software existentes

A menudo, los requisitos deben ser flexibles. Los analistas pueden encontrar componentes de software existentes que coincidan con las necesidades que usted describe. En este caso, el analista debe brindar la opción de modificar los requisitos para que los desarrolladores puedan reutilizar partes del software existente al desarrollar nuevos sistemas. Si surge una oportunidad de reutilización y puede ajustar sus especificaciones de requisitos, no tiene que seguir estrictamente las especificaciones de requisitos originales para desarrollar, lo que reduce costos y ahorra tiempo. Por lo tanto, si desea utilizar componentes disponibles comercialmente en su producto que no coinciden exactamente con la funcionalidad que necesita, es esencial cierto grado de flexibilidad en los requisitos.

9: Obtener un sistema que cumpla con los requisitos funcionales y de calidad del cliente

Todo el mundo quiere que el proyecto tenga éxito. Pero esto no solo requiere que usted comunique claramente a los desarrolladores todo lo que necesitan saber sobre "lo que hará el sistema", sino que también requiere que los desarrolladores comprendan las compensaciones y limitaciones a través de la comunicación. Asegúrese de expresar claramente sus suposiciones y expectativas básicas. De lo contrario, es probable que los desarrolladores creen un producto con el que no estará satisfecho.

Los clientes tienen las siguientes obligaciones:

1: Explicar su negocio a los analistas

Los analistas confían en usted para explicarles los conceptos y la terminología del negocio. Sin embargo, no se puede esperar que los analistas sean expertos en su campo, sólo que comprendan verdaderamente sus problemas y objetivos. No espere que los analistas comprendan los matices y el potencial de su negocio; es posible 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 ocupados y, a menudo, tienen que participar en el desarrollo de requisitos durante sus momentos de mayor actividad. Sin embargo, está obligado a dedicar tiempo a participar en sesiones de "lluvia de ideas", entrevistas u otras actividades de recopilación de requisitos. A veces el analista puede pensar que comprende su punto de vista y luego darse cuenta de que necesita escuchar lo que usted tiene que decir. En este momento, espere pacientemente la iteración de requisitos y el proceso de mejora de requisitos, porque este es el proceso natural de comunicación de las personas y es extremadamente importante para el éxito de los productos de software.

3: Requisitos precisos y detallados

Escribir un documento de requisitos claro y preciso es difícil. Dado que ocuparse de los detalles no sólo es tedioso sino que también requiere mucho tiempo, es fácil quedarse con requisitos vagos. Sin embargo, durante el desarrollo se deben abordar estas ambigüedades e inexactitudes. Usted está mejor calificado para tomar decisiones que aborden estos problemas. De lo contrario, tendrás que confiar en que los desarrolladores hagan buenas conjeturas. Es una buena idea agregar temporalmente un símbolo por determinar (TBD) en la especificación de requisitos. Utilice este símbolo para indicar la necesidad de una mayor exploración, análisis o información adicional. Sin embargo, en algunos casos, la bandera TBD puede usarse porque una necesidad es difícil de abordar o nadie quiere abordarla. Intente ser lo más claro posible sobre el contenido de cada requisito para que los analistas puedan incorporarlo con precisión en la especificación de requisitos de software. Si no puede hacerlo bien en este momento, deje de lado el proceso para obtener la información necesaria.

Esto a menudo requiere el uso de las llamadas técnicas de creación de prototipos. Al desarrollar un prototipo, puede iterar y perfeccionar la definición de requisitos junto con los desarrolladores.

4: Tome decisiones oportunas

Al igual que un arquitecto que construye su casa, los analistas le piden que tome decisiones. Estas decisiones pueden incluir enfoques de procesamiento propuestos por múltiples usuarios, o pueden incluir elegir un compromiso entre características de calidad en conflicto y precisión de la información. El cliente tiene el poder de decisión y debe ser proactivo y tomar decisiones lo más rápido posible. Porque los desarrolladores a menudo tienen que esperar a que usted tome una decisión antes de actuar, y esta espera puede retrasar el progreso del proyecto.

5. Respetar la viabilidad y la evaluación de costos de las necesidades 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). No es bueno para evaluar predicciones). Es posible que algunas de las funciones que necesita no sean técnicamente viables o que su implementación sea muy costosa. Debe respetar el hecho de que los desarrolladores evaluarán negativamente los requisitos que buscan lograr un rendimiento imposible en el entorno de ejecución o que intentan obtener datos que simplemente no están disponibles. A veces se puede volver a dar un requisito que es técnicamente factible y barato de implementar, por ejemplo, un requisito para lograr un determinado comportamiento "en un instante" no es factible, pero un requisito de tiempo más específico ("dentro de 50 ms", pero si no es preciso). el análisis técnico no puede sacar conclusiones fácilmente), esto se puede lograr.

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 sería bueno tener es una parte importante del desarrollo de requisitos. Usted es el único responsable de priorizar los requisitos porque los desarrolladores no pueden priorizar los requisitos desde su perspectiva. Los desarrolladores le proporcionarán información sobre costos y riesgos para cada requisito para determinar las prioridades. Cuando prioriza los requisitos, ayuda a los desarrolladores a garantizar los mejores resultados en el tiempo adecuado y al menor costo. Con tiempo y recursos limitados, se debe respetar la opinión del desarrollador en cuanto a si se puede lograr la funcionalidad requerida y en qué medida. Aunque nadie quiere ver que los requisitos esperados no se puedan cumplir en el proyecto, esto es un hecho indiscutible. A veces, las decisiones comerciales deben tomarse basándose en prioridades para reducir el alcance del proyecto, extender la duración, agregar recursos o comprometer la calidad.

7: Revisar los documentos de requisitos y los prototipos

Como veremos en el Capítulo 14, la revisión formal e informal de los documentos de requisitos puede ayudar a mejorar la calidad del software. Involucrar al cliente en la revisión es la única manera de determinar verdaderamente si el documento de requisitos está completo y describe correctamente la funcionalidad requerida y necesaria. Las revisiones también brindan al representante del cliente la oportunidad de brindar comentarios al analista de requisitos para mejorar el trabajo. Si cree que el documento de requisitos no está redactado con precisión, tiene la obligación de comunicárselo al analista lo antes posible y brindarle 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 producto. De esta manera, podrá proporcionar 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 los desarrolladores pueden transformarlo y ampliarlo hasta convertirlo en un sistema completamente funcional.

8: Los cambios en los requisitos de contacto son inmediatos

Los cambios continuos en los requisitos pueden tener un impacto negativo grave en la capacidad de entregar productos de alta calidad dentro de los plazos planificados. El cambio es inevitable, pero cuanto más tarde se produzca, mayor será el impacto. Los cambios no sólo pueden dar lugar a costosas repeticiones de trabajo, sino que también pueden retrasar el progreso, especialmente si es necesario agregar nuevas funciones una vez completada la estructura general. Por lo tanto, asegúrese de notificar a sus analistas tan pronto como se dé cuenta de que es necesario cambiar los requisitos.

9: 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 que no se abandonen todos los cambios propuestos, sino que se analice, sintetice cada cambio requerido y se tomen las decisiones apropiadas para determinar qué cambios introducir 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 corrección. Los métodos utilizados por los analistas son sólidos. Puede creer que el proceso de requisitos no es rentable, pero cree que el tiempo dedicado al desarrollo de requisitos "vale la pena". Este proceso será mucho más sencillo si puede comprender y respaldar las técnicas utilizadas por los analistas para recopilar, documentar y garantizar la calidad de los requisitos. No dude en preguntar a los analistas por qué recopilan cierta información o participan en actividades relacionadas con los requisitos.

Los analistas de sistemas pueden encontrar los siguientes problemas durante el proceso de desarrollo. Los clientes ocupados pueden no estar dispuestos a participar activamente en el proceso de requisitos y la falta de participación del cliente probablemente dé como resultado un producto insatisfactorio. Es importante garantizar que los participantes clave en el desarrollo de requisitos comprendan y acepten sus obligaciones. Si se encuentran desacuerdos, se debe negociar un entendimiento mutuo de las obligaciones respectivas para minimizar fricciones futuras.

7. Documento de requisitos

El resultado final del desarrollo de requisitos es que el cliente y el equipo de desarrollo lleguen a un acuerdo sobre el producto a desarrollar. El acuerdo combina las necesidades comerciales, las necesidades de los usuarios y los requisitos funcionales del software. Como se mencionó anteriormente, los documentos de vista y alcance del proyecto contienen requisitos comerciales, y los documentos de casos de uso contienen requisitos de usuario. Debe documentar los requisitos funcionales derivados de los casos de uso, así como los requisitos no funcionales del producto, incluidos los atributos de calidad y los requisitos de interfaz externa. Sólo si estos documentos están escritos de manera estructurada y legible, y son revisados ​​por las partes interesadas del proyecto, todas las partes pueden estar seguros de que los requisitos acordados son sólidos.

Hay tres formas de escribir especificaciones de requisitos de software:

Escribir documentos basados ​​en texto utilizando un lenguaje natural bien estructurado.

Construya modelos gráficos para describir transiciones, estados del sistema y cambios entre estados, relaciones de datos, flujos lógicos o 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 la precisión de las especificaciones formales, los lenguajes formales utilizados rara vez resultan familiares para los desarrolladores de software, y mucho menos para 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. Las especificaciones de requisitos de software basadas en texto incluyen requisitos funcionales y no funcionales y son aceptadas por la mayoría de los proyectos. Los modelos de análisis gráfico mejoran las especificaciones de requisitos de software al proporcionar una vista alternativa de los requisitos.

Si esto resuelve tu problema, ¡acéptalo!

Si esto no resuelve su problema, haga un seguimiento.