¿Por qué son importantes los requisitos en la ingeniería de software?

En este artículo, repasaremos la importancia de los requisitos en el desarrollo de software y las razones por las que descuidar la etapa de requisitos no es una buena idea al crear una aplicación.

" Software de trabajo sobre documentación completa " . Esto es parte del Manifiesto Ágil.

En la superficie, esta afirmación puede parecer implicar que los requisitos son intrascendentes y no dignos del momento. Algunos desarrolladores y sus clientes renuncian a la documentación adecuada. Pero eso es un error.

Comencemos con una pequeña explicación de los requisitos en términos de desarrollo de software.

¿Cuáles son los requisitos en el desarrollo de aplicaciones?

No es que la definición de requisitos cambie significativamente cuando se aplica al desarrollo de software. Los requisitos simplemente especifican qué características debe incluir un producto y cómo deben funcionar esas características. Cómo te acercas a ellos es lo importante.

La recopilación y el análisis de los requisitos es una de las etapas iniciales del proceso de desarrollo de software tanto en las metodologías Agile como en Waterfall. Durante la fase de requisitos de la etapa de validación de la idea, se debe llegar a un acuerdo entre el cliente y el desarrollador sobre qué debe hacer exactamente el producto final y cómo. Los requisitos en el desarrollo de aplicaciones suelen ser bastante detallados.

Cómo definir los requisitos de software

Puede haber varios tipos de requisitos en el desarrollo de software.

Requisitos comerciales

¿Por qué el cliente necesita la aplicación? De un vistazo, esta información puede parecer innecesaria o incluso redundante. Después de todo, tienes un cliente que quiere pagarte para crear una aplicación. ¿Por qué debería preocuparte por sus razones?

Bueno, si se enorgullece de lo que hace y se esfuerza por crear productos de calidad, debe preocuparse tanto por los porqués como por los qué y los cómo.

La importancia de los requisitos comerciales es que brindan una visión del objetivo final. Con el objetivo a la vista, los desarrolladores pueden establecer prioridades. También pueden aplicar su experiencia para ofrecer mejores soluciones para alcanzar estos objetivos. Existe una razón por la que el análisis empresarial se incluye en el proceso de desarrollo en la mayoría de las empresas.

Sin requisitos comerciales claros, se pueden tomar malas decisiones. Decisiones que retrasarán el desarrollo, interrumpirán los plazos y darán lugar a etapas de desarrollo adicionales.

Requisitos de Software

Hay dos tipos de requisitos: funcionales y no funcionales. En términos simples, la distinción es la siguiente:

Los requisitos funcionales son los requisitos: ¿para qué está diseñado este sistema? Como sugiere su nombre, describen la funcionalidad del software.

Los requisitos no funcionales son los requisitos de cómo: ¿cómo hará este sistema para lo que está diseñado? Estos requisitos describen cómo debe comportarse cada característica en qué condiciones, qué limitaciones debe haber, etc.

Los dos van de la mano. Los requisitos no funcionales complementan y definen los requisitos funcionales. Por ejemplo, imaginemos que estamos creando una aplicación de mensajería.

Los principales requisitos funcionales, en este caso, serían:

1. La aplicación debe poder enviar mensajes.
2. La aplicación debe admitir la transferencia de archivos y medios.
3. Etc.

Estos son bastante sencillos y es fácil entender por qué los requisitos funcionales son importantes: describen la funcionalidad. En este ejemplo, el Los requisitos no funcionales pueden ser los siguientes :

1. El servicio debe ofrecer una funcionalidad completa en todos los navegadores principales: Microsoft Edge, Google Chrome (las dos últimas versiones), Mozilla Firefox (las dos últimas versiones), Opera, Safari (la última versión).
2. Los diseños móviles deben ser compatibles.
3. Etc.

Como se puede ver, Los requisitos funcionales son básicamente una lista de funciones que deben incluirse en el sistema. . Por otro lado, los requisitos no funcionales son específicos. Son necesarios para definir las condiciones de desarrollo y prueba.

Es cierto que el proceso ágil iterativo conlleva la posibilidad de introducir cambios en cualquier etapa del desarrollo , pero eso no implica requisitos previos por completo. Solo necesitas hacerlos flexibles.

Sin parámetros precisos especificados, es imposible comprender si una función está diseñada exactamente como debería.

Los requisitos deben analizarse y documentarse minuciosamente. ¿Por qué? Porque muchas cosas pueden salir mal si no es así.

La espada de los Damocles de requisitos indocumentados

Los especialistas en garantía de calidad comprenden mejor la importancia de los requisitos de software. Cuando los requisitos del proyecto no se establecen correctamente, los controles de calidad reciben el mayor golpe. Imagínese tratando de determinar si el software se implementa correctamente sin pautas claras sobre lo que debe hacer y cómo debe hacerlo. Es una locura total.

Sin embargo, este problema no solo afecta a los evaluadores. No tener especificaciones oficiales significa lo siguiente:

• No existe una comprensión clara de lo que constituye un producto terminado o incluso una característica.
• El cliente no sabe qué esperar al final del desarrollo y por qué está pagando.
• Los desarrolladores se quedan colgando, teniendo que averiguar los detalles de las características en función de lo que se dijo y cómo lo entendieron ellos mismos.
• Insectos. Están por todas partes.

Los requisitos indocumentados conducen a una falta de comunicación en todos los lados. No es nada raro que un cliente y un desarrollador entiendan los mismos términos de manera diferente. Especialmente si hablamos de una empresa de desarrollo de subcontratación que no está íntimamente familiarizada con el negocio del cliente.

La falta de comunicación, a su vez, abre un camino directo hacia la repetición constante, los cambios y la corrección de errores. Existe la posibilidad de que todo salga según lo planeado sin requisitos documentados, pero es escaso. Por lo general, esta cadena termina con plazos interrumpidos y costos que se disparan.

Para garantizar un desarrollo fluido del proyecto, todos los miembros del equipo deben comprender todas las partes del producto y el proceso de su desarrollo de la misma manera. Para garantizar que los desarrolladores vean cada característica del producto exactamente como lo hace el cliente, se realiza una especificación de requisitos de software (SRS).

El diablo está en los detalles: ¿Qué hace que una buena especificación de requisitos de software?

Ahora, las especificaciones de los requisitos de software reales pueden ser excepcionalmente detalladas o pueden ser solo un resumen de las características. El nivel de detalle depende de varios factores.

Todos los involucrados en el proyecto comprenden fácilmente los requisitos de alta calidad . Esto incluye al cliente, que puede o no estar bien versado en aspectos técnicos. Algunas empresas exigen una lista de requisitos excepcionalmente técnica y con muchos detalles, mientras que otras prefieren los requisitos en términos sencillos.

Independientemente de cuán llena de tecnología esté su documentación, existen reglas generales para administrar los requisitos de software. Incluso existe un estándar oficial: IEEE Std 830-1998, "Práctica recomendada para especificaciones de requisitos de software". Esto es lo que debería ser un buen SRS, según el estándar:

• Correcto . Este es fácil. El cliente y el desarrollador verifican la exactitud del SRS según el acuerdo que tienen. El SRS debe cumplir con las especificaciones técnicas y toda la demás documentación del proyecto que rige.

• Inequívoco . Uno de los propósitos principales de un SRS es eliminar la falta de comunicación. Es por eso que cada especificación de requisitos debe escribirse para tener solo una interpretación posible. No es inusual que un SRS incluya un glosario.

• Completa . Cuanto más compleja sea la aplicación, más detallado debe ser el SRS. Un SRS completo cubre todos los aspectos, desde los requisitos de rendimiento hasta la funcionalidad. También establece ciertos límites al diseño. Sin embargo, nunca especifica un diseño exacto. Solo ofrece parámetros.

• Consistente . La coherencia interna significa que ninguna declaración en un SRS contradice otras declaraciones en el mismo SRS. Esta es otra razón para incluir un glosario, de modo que cualquier objeto, proceso y especificación dentro del documento se designe con un término preciso.

• Clasificado por importancia y / o estabilidad . En la mayoría de los casos, existen requisitos obligatorios y requisitos potenciales. Es importante que las especificaciones de requisitos de software etiqueten claramente ambos tipos. Esto ayudará a los desarrolladores y gerentes de proyecto cuando creen un plan paso a paso para el proyecto.

• Verificable . Debe haber una forma de probar cada requisito que incluya en el SRS. Para ser considerados verificables, los requisitos deben contener conceptos medibles y concretos.

• Modificable . Esto se refiere a la estructura SRS. Para no interrumpir el flujo de trabajo del proyecto cuando necesite implementar cambios, el SRS debe ser claro y fácil de cambiar, y los requisitos no deben repetirse.

• Rastreable . Debería ser fácil identificar la fuente de cada requisito establecido en el SRS.

Estas son recomendaciones . En realidad, las empresas pueden prescindir de algunos de estos puntos en función del proyecto, el cliente y el equipo. Pero siempre es bueno tener alguna orientación.

Los requisitos son útiles si se especializa en el desarrollo de aplicaciones para iOS y Android o en el desarrollo web. Son documentación de propósito general. Y su apariencia generalmente depende de los desarrolladores y sus clientes.

Dado que un SRS debe ser fácil de entender para todas las partes involucradas, la mejor manera de diseñarlos también es discutible. Algunos prefieren tablas, otros prefieren listas. Hay desarrolladores que prefieren sus especificaciones en forma visual como diagramas de flujo de datos y gráficos. No existe una única forma correcta de elaborar un documento de especificación de requisitos.

Conclusión

Estos son los puntos más comunes cuando los requisitos de software son útiles:

• Entendiendo el objetivo
• Estimación de los costos de desarrollo
• Creando un horario completo
• Estableciendo prioridades

Si documentar los requisitos es algo que cada desarrollador decide por sí mismo. Y el valor de los requisitos varía según la escala del proyecto. En Mind Studios, preferimos tener las cosas en orden, por lo que documentamos todos los requisitos . Si está interesado en cómo lo hacemos o tiene preguntas sobre el valor de los requisitos en general, contáctenos a través de nuestro formulario de contacto .