Por qué necesita comprender los requisitos de software como ingeniero de software

En este artículo, aprenderá todo sobre los requisitos de software. Obtendrá un resumen del área temática, el proceso y, lo más importante, cuáles son sus responsabilidades en esta área como ingeniero de software.

Debería conocer mejor su función y sus actividades con los requisitos de software. En todo caso, ¿tendrá algo que discutir con sus colegas después de su próxima reunión?

Este artículo se basa en gran medida en el tomo que es la guía IEEE SWEBOK. Intenta destilar algo de ese conocimiento, reorientando su propósito de manera más concisa. En caso de que se lo pregunte, SWEBOK es un acrónimo de Software Engineering Body of Knowledge que mantiene la IEEE Computer Society.

Por adelantado, ¿por qué es esto importante?

Los que no están en ingeniería de software tienen la idea errónea de que el papel de un ingeniero de software es simplemente "escribir código".

Sí, somos tecnólogos a los que generalmente les encanta aprender a programar. En realidad, esta es una visión simplista que subestima lo que un ingeniero de software profesional realmente hace en su trabajo y carrera cotidianos. Se centra solo en una parte de sus responsabilidades generales.

La función de un ingeniero de software es crear soluciones comerciales a escala empresarial. Esto incluye una gran cantidad de responsabilidades que no están relacionadas con el código que crean.

Un área de responsabilidad que tiene como ingeniero de software profesional es el área de requisitos de software.

¿Cuáles son los requisitos de software?

Los requisitos de software en la superficie parecen simples. El software debe hacer X por Y para que Z. Piense en ello durante el tiempo suficiente en cualquier problema que el software pueda resolver (o en el software existente que ya está resolviendo un problema) y probablemente podría pensar en una gran cantidad de requisitos. Fácil ¿verdad?

Bueno, no, de hecho, para la mayoría del software empresarial.

¿Cómo está reuniendo sus requisitos? ¿Está considerando las necesidades y prioridades de las partes interesadas? ¿Es esto realmente un requisito para los usuarios del software? ¿Existen limitaciones técnicas de consideraciones? ¿Cómo sabes cuando está hecho? ¿La implementación de requisitos satisface un criterio establecido? Y así...

Cuando comienza a profundizar en la idea de requisitos de software, descubre que ocultan un área de conocimiento grande y más profunda.

¿Qué tan profunda y amplia es un área de conocimiento? SWEBOK define el área de Requisitos de software como " relacionada con la obtención, análisis, especificación y validación de los requisitos de software, así como con la gestión de los requisitos durante todo el ciclo de vida del producto de software " .

El tamaño de esta área, como la cantidad de actividades y el grado de participación de cada una de ellas, dio suficiente crédito para dedicar una rama de la ingeniería conocida como " ingeniería de requisitos " centrada únicamente en el proceso de requisitos.

Algunas organizaciones pueden contratar específicamente para el rol de un ingeniero de requisitos. Puede ver esto con más frecuencia en organizaciones realmente grandes que brindan soluciones a nivel de sistema, por ejemplo, donde las soluciones propuestas a los problemas del cliente abarcan una solución total de la cual el software es solo un componente.

Más típicamente, las organizaciones tienden a compartir la responsabilidad de la ingeniería de requisitos a través de actividades asignadas entre los otros roles del proyecto, como diseñadores, analistas comerciales, propietarios de productos, gestión de ofertas o clientes, redactores técnicos, arquitectos / ingenieros de software, etc.

En general, es difícil implementar el proceso de requisitos en un proceso lineal en la práctica, como una metodología en cascada. Eso requeriría obtener los requisitos de software de las partes interesadas, clasificarlos, asignarlos y, finalmente, entregarlos para su implementación por parte del equipo de desarrollo de software. A menudo, esto no es factible para soluciones exitosas a escala a largo plazo.

Los requisitos para esos grandes proyectos de software nunca se comprenden ni se especifican perfectamente. En cambio, generalmente iteran hasta el nivel de calidad y detalle suficiente que permite tomar decisiones de diseño y adquisición.

La ingeniería de requisitos es distinta de la ingeniería de software en el tipo de trabajo en el que se enfoca.

Es importante que comprenda su conexión con el proceso de requisitos, ya que es probable que en algún momento participe en alguna actividad de requisitos.

¿Qué implican los requisitos de software para el ingeniero de software?

Dependiendo del proceso de requisitos de su organización y / o de las actividades de requisitos de las que es responsable el ingeniero de software, usted puede estar involucrado en cualquiera o en todas las etapas. Esto podría ser desde la recopilación de requisitos hasta la verificación de su implementación.

Áreas en las que puede participar:

  • Elicitación: la recopilación de requisitos para el software.
  • Clasificación: categorizar el requisito
  • Validación: confirmación del requisito con las partes interesadas
  • Desarrollo e implementación: creación del software para cumplir con los requisitos
  • Negociación: abordar los conflictos de intereses de las partes interesadas
  • Verificación: la evaluación de la función del software satisface el requisito

Vale la pena señalar que esto no es un duplicado del proceso de ingeniería de requisitos. Requieren un nivel más profundo de implicación y tipos de actividad con determinadas áreas, como la gestión y documentación de requisitos.

La gestión y documentación de los requisitos no suele ser su responsabilidad. Probablemente será uno de los otros roles que comparten la responsabilidad de los requisitos.

Es importante que sepa cómo acceder y utilizar el sistema de gestión de requisitos para evaluar los cambios de requisitos y el análisis de impacto.

Um, no hay un sistema de gestión de requisitos ...

En algunos casos, el registro y la gestión de los requisitos pueden no estar en un sistema especializado. Podrían grabarse en otros tipos de sistemas de grabación, como el software de seguimiento de problemas, las herramientas de gestión de proyectos o incluso el sistema de control de versiones.

En otros casos, las organizaciones o los equipos de proyectos no desarrollan un medio para documentar y gestionar los requisitos. En su lugar, podrían confiar en la visión del liderazgo (un individuo o equipo con el ejemplo común de ser el fundador de la empresa) y / o tener recursos limitados. Pueden argumentar en contra de que no es necesario registrar o administrar los requisitos.

No registrar ni administrar los requisitos puede representar un riesgo grave para una organización y el proceso de solución de software.

Por ejemplo, su organización, que desarrolla soluciones para las necesidades del cliente, deberá cumplir con ciertas obligaciones legales. Indicarán que su componente de software está diseñado para proporcionar cierta funcionalidad y puede brindar un nivel de servicio específico (SLA).

Pero si surgiera un conflicto (legal o de otro tipo), tal vez una pieza faltante de funcionalidad, un requisito no funcional que no funcionaba como se esperaba, o incluso el tiempo / presupuesto invertido en características no deseadas, ¿cómo muestra qué se implementó fue qué? ¿Fue acordado por las partes interesadas como requerido y necesario?

Su organización debe poder demostrar el mapeo entre los requisitos de la solución de alto nivel (lo que el cliente necesita como solución) y los requisitos de software validado (lo que las partes interesadas acordaron como satisfacer las necesidades funcionales de la solución, no necesariamente de 1 a 1). 1) hasta la implementación de documentación y registro de pruebas de nivel de servicio o aceptación que demuestren la funcionalidad proporcionada.

Otro ejemplo más común (y menos elaborado) es la evaluación del impacto. A medida que su organización o equipo de proyecto crece y evoluciona, también lo hace el software que crea. A menos que el software esté destinado a ser prescindible, debe preverse que funcione durante un período de tiempo y, por lo tanto, estará sujeto a actualizaciones, nuevas funciones y mantenimiento.

Este nuevo trabajo puede negar, impactar o cambiar la funcionalidad existente diseñada para cumplir con un requisito histórico de varias formas (como cambiar la arquitectura del software o el diseño de un componente).

Si es así, deberá revisar los requisitos anteriores para comprender mejor las motivaciones que los sustentan. Por ejemplo, ¿por qué se implementó de esa manera? ¿Es necesario cambiar el trabajo actual? ¿Sigue siendo relevante el antiguo requisito? etc.

Obtención de requisitos de software

La obtención de requisitos se refiere a la actividad que describe cómo se recopilan o recopilan los requisitos. No todos los requisitos se "recopilan" de un cliente y pueden derivarse del sistema o dominio en el que opera el software (como la operabilidad y confiabilidad para sistemas críticos).

Desde una perspectiva de gestión de proyectos, la obtención es fundamental para derivar el alcance del proyecto y los entregables importantes para las necesidades del cliente o usuario, priorizando primero las necesidades más importantes.

¿Qué implica obtener los requisitos de software?

Dependiendo del nivel de participación de su rol en el proceso de requisitos, es posible que deba tomar los requisitos de la fuente.

La obtención de requisitos ayuda a informar el diseño y la arquitectura de la solución general. Es importante que comprenda de dónde provienen los requisitos y qué técnicas se utilizan.

¿De dónde provienen los requisitos de software?

Hay muchas fuentes de requisitos, como:

  • Metas (también conocidas como preocupación comercial, factor crítico de éxito, etc.)
  • Conocimiento del dominio
  • Interesados
  • Reglas del negocio
  • Entorno operativo

Si está involucrado en la obtención de fuentes, deberá:

  • Preste especial atención a los objetivos.
    • Suelen ser vagas, como "El software debe implementarse utilizando las mejores prácticas" o "El software debe ser fácil de usar".
    • Evalúe el valor relativo a la prioridad de la solución. Estudie formas de lograr resultados relativamente económicos.
  • Adquirir o tener conocimientos disponibles sobre el dominio de la aplicación
    • Esto le proporciona la información básica que le permite comprender las razones detrás de los requisitos.
    • El desarrollo de modelos del problema del mundo real, como los modelos de relación entre entidades, es clave para un buen análisis de requisitos de software. Intente pensar con un enfoque ontológico.
  • Identificar, representar y gestionar los puntos de vista de muchos tipos diferentes de partes interesadas.
    • Los requisitos pueden ser contradictorios, superpuestos o requerir diferentes motivaciones en parte de las necesidades de diferentes partes interesadas.
    • Es importante que reconozca las diferentes necesidades, especialmente en la planificación previa de la implementación, donde las necesidades se incorporan en el diseño.
  • Mostrar sensibilidad al entorno operativo de la solución
    • El entorno operativo estará sujeto a la estructura, cultura y política interna de una organización.
    • Un principio general por el que debe esforzarse su software es no introducir cambios no planificados o forzados en el proceso empresarial de la organización.

¿Cómo obtengo los requisitos de software?

Algunas de las principales técnicas en las que puede estar involucrado (proporcionando experiencia técnica) podrían ser:

  • realizar entrevistas con las partes interesadas
  • delineando escenarios
  • prototipos de construccion
  • observación en el área del problema
  • historias del usuario

Al construir prototipos, un principio general que debe intentar seguir es utilizar prototipos de baja fidelidad con más frecuencia en estas etapas iniciales.

Se prefieren para evitar la fijación de las partes interesadas en características menores o incidentales. Un prototipo de mayor calidad puede limitar la flexibilidad del diseño de formas no deseadas.

Clasificación de requisitos de software

Cuando se han obtenido los requisitos de software, el equipo del proyecto puede clasificarlos en varias categorías.

Esto ayuda de diversas formas, como la estimación del esfuerzo del proyecto, la identificación de componentes para el diseño de la solución o incluso simples consideraciones de implementación.

Los tipos de clasificación pueden incluir:

  • Funcional / No funcional
    • Los requisitos funcionales describen las funciones que debe ejecutar el software. Por ejemplo, proporcionar un canal de comunicación para un usuario o transferir datos de un formato a otro. También se pueden conocer como características o capacidades del producto.
    • Los requisitos no funcionales actúan para imponer ciertas limitaciones a la solución, a menudo en términos de calidad. Estos pueden clasificarse además en los muchos tipos de " características " como disponibilidad, confiabilidad, capacidad de recuperación, mantenibilidad, escalabilidad, rendimiento, seguridad, etc.
  • Derivado / Impuesto / Emergente
    • ¿El requisito se deriva de otros requisitos?
    • ¿El requisito lo impone explícitamente una parte interesada?
    • ¿Es el requisito una propiedad emergente? En otras palabras, no puede ser abordado por un solo componente sino que depende de cómo interoperan todos los componentes de software.
  • Proceso / Producto
    • ¿El requisito está relacionado con el producto? (un ejemplo, " El software debe verificar la elegibilidad de una persona ")
    • ¿El requisito está relacionado con el proceso? (un ejemplo, " El software debe desarrollarse gradualmente y utilizar flujos de trabajo de implementación e integración continuos )
  • Prioridad
    • Equilibrar el costo de desarrollo y la implementación frente a la necesidad de entrega.
    • Puede usar una escala de etiqueta fija como obligatoria, altamente deseable, deseable y opcional.
  • Alcance
    • Se utiliza para considerar el impacto en la arquitectura del software y los diseños de componentes.
    • Los no funcionales suelen tener un alcance global.
  • Volatilidad / estabilidad
    • El potencial del requisito cambiará durante el ciclo de vida del software.
    • Esto ayudará a implementar diseños que sean tolerantes a los cambios.

Validación de requisitos de software

Una vez que se han obtenido y clasificado los requisitos de software, es necesario validarlos con las partes interesadas para verificar su precisión y si realmente satisfacen o no sus necesidades. Los requisitos que no se pueden validar son en realidad sólo "deseos" de las partes interesadas.

Si sigue un método de desarrollo iterativo, la validación de los requisitos puede realizarse con regularidad, separarse por alcance en áreas específicas de la solución, o emprenderse por partes, o algún otro tipo de separación que tenga sentido lógico.

La validación de requisitos generalmente implica que el equipo de la solución vuelva a transmitir su comprensión del requisito a las partes interesadas. También puede involucrar un diseño inicial (comercial o técnico, o ambos) que muestre cómo se implementarán cada una de las necesidades de las partes interesadas.

Estos conocimientos se crean de manera iterativa a través de las etapas de planificación y normalmente consisten en las opiniones de un equipo multifuncional (diseñadores, analistas de negocios, expertos técnicos).

En algunos casos, el diseño puede necesitar algún trabajo previo a la implementación para demostrar mejor la comprensión del equipo, generalmente en forma de un prototipo funcional.

Durante la validación, es posible que su equipo no pueda satisfacer perfectamente los requisitos de todas las partes interesadas. Será su responsabilidad como experto técnico demostrar y negociar las compensaciones que se ajusten a las limitaciones. Deberá ser aceptable para las principales partes interesadas, al mismo tiempo que se incluye en las medidas presupuestarias, técnicas, reglamentarias y de otro tipo.

Usando prototipos funcionales

Los prototipos funcionales son útiles ya que permiten:

  • validar que se entienden los requisitos
  • interpretación más sencilla de los supuestos del ingeniero
  • retroalimentación que puede proporcionar nuevos requisitos

Debe tener en cuenta que los interesados ​​pueden distraerse con problemas estéticos o de calidad. Puede mitigar esto comunicando de manera coherente la importancia real de la demostración: la funcionalidad básica subyacente.

El equipo de proyecto determina cómo se construye el prototipo. Algunos defensores prefieren prototipos que eviten el software por completo (similares a los que se crean cuando se solicitan requisitos). Otros prefieren algún tipo de visualización de software a través de kits de herramientas de diseño o una iteración de borrador construida rápidamente del software detrás de un control de funciones.

Cualquiera que sea la elección que decida su equipo, debe considerar la velocidad de construcción del prototipo versus la efectividad de demostrar la funcionalidad principal.

Desarrollo e implementación de requisitos de software

Cuando el requisito se ha validado con las partes interesadas, puede comenzar el desarrollo / implementación del requisito.

En muchos casos, actuarás como arquitecto de software porque el proceso de análisis y elaboración de los requisitos exige que se identifiquen los componentes de arquitectura / diseño que serán los responsables de satisfacer los requisitos.

Un interés clave para su organización es beneficiarse de la solución de software. Es su responsabilidad intentar utilizar métodos que reduzcan el costo de desarrollo y mantenimiento.

Puede hacer esto, por ejemplo, mediante la reutilización de componentes (internamente o de otros productos), utilizando patrones bien definidos y trabajando con herramientas / marcos bien probados y bien documentados.

Los requisitos específicos, en particular las restricciones, pueden tener un gran impacto en el costo del software. Por ejemplo, si su conjunto de habilidades en la implementación es deficiente o quizás el requisito sea contrario o no se ajuste a la arquitectura actual. El equipo del proyecto debe identificar importantes compensaciones entre dichos requisitos.

A lo largo del proceso de requisitos, un punto importante que debe comprender es la expectativa de que cambie una proporción significativa de los requisitos. Reconozca la inevitabilidad del cambio e intente tomar medidas en su diseño para permitirlo.

La historia del usuario

Un ingeniero de software a menudo trabaja en el contexto de una historia de usuario entregada. La historia del usuario es una representación en palabras naturales de la interacción de un tipo de usuario particular con el software y la funcionalidad que debería proporcionarle. Suele seguir el formato de:

Como, quiero, para que

Un ejemplo:

Como administrador del curso, quiero ver la cantidad de personas inscritas en un curso, para poder ver la capacidad actual del curso.

En algunos casos, la historia del usuario vendrá con un diseño o prototipo si estos fueron requeridos en la etapa de validación.

Es posible que la historia del usuario no esté centrada en el usuario y, en cambio, se derive de una propiedad emergente o un requisito no funcional. En estos casos, puede recibir el requisito en un contexto de entrega diferente (como una especificación o un conjunto de escenarios).

Una historia de usuario está destinada a contener la información suficiente para que su equipo de ingenieros pueda producir una estimación razonable del esfuerzo para implementarla. Si su equipo no puede producir una estimación razonable, podría ser un signo de una mala correspondencia en conocimientos / habilidades, niveles de confianza individual, limitaciones de adaptación o dependencia, o de manera crucial, que la historia del usuario carece de calidad.

Los ingenieros de software están (necesariamente) limitados por los planes de gestión de proyectos, por lo que debe intentar tomar medidas para comprobar que la calidad de los requisitos sea lo más alta posible, dados los recursos disponibles.

Antes de implementar una historia de usuario, verifique:

  • para un criterio de aceptación apropiado, escrito o acordado con las partes interesadas, que determina cómo se pueden cumplir los objetivos de la historia del usuario con la implementación.
    • Esto formará la base para las pruebas de aceptación de la función (en otras palabras, las pruebas que demuestran que se cumple el requisito).
    • Esto también puede formar parte de la definición de equipo de "hecho" o completo.
  • el diseño del prototipo (si se hace) es factible y puede ajustarse a la arquitectura actual, las habilidades de ingeniería y las herramientas aprobadas para su uso en el proyecto.
  • cualquier supuesto que respalde el requisito.
    • Esto puede resaltar brechas en el conocimiento, problemas potenciales u otros escenarios / casos extremos que no se consideran y que requieren una mayor aclaración por parte de las partes interesadas.

Negociación de requisitos de software

Al implementar un requisito, es posible que no todos los intereses de las partes interesadas se satisfagan perfectamente. Esto puede suceder, por ejemplo, entre requisitos funcionales y no funcionales, o cuando la implementación de un requisito impacta en el interés de otra parte interesada.

En la mayoría de los casos, no es aconsejable que tome una decisión unilateral.

En cambio, usted es responsable de evaluar el problema, comunicarse de manera simple y negociar compensaciones que sean aceptables para las principales partes interesadas, sin dejar de cumplir con las limitaciones presupuestarias, técnicas, reglamentarias y de otro tipo.

Verificación de requisitos de software

Todos los requisitos de software exigen la necesidad de ser verificables, como característica o requisito funcional, o a nivel global como requisito no funcional. Los requisitos deben verificarse con el producto terminado.

Una tarea importante para usted es planificar cómo verificar cada requisito.

Un ingeniero de software verifica un requisito mediante una prueba de aceptación. La prueba de aceptación demuestra cómo se ha completado el requisito (cumpliendo los criterios de aceptación) al mostrar el comportamiento del usuario final al realizar negocios con el software según lo definido por el requisito.

En requisitos donde es más difícil demostrar la verificación, como requisitos no funcionales, puede ser necesaria una simulación construida. Por ejemplo, para probar la carga de rendimiento del software que implementa un proceso de admisión, se puede crear un software de prueba para simular cientos o miles de aplicaciones en el sistema en una prueba de aceptación de caja negra.

A medida que el software evoluciona con el tiempo, la implementación de un nuevo requisito puede afectar inadvertidamente el cumplimiento de un requisito implementado previamente. Esta regresión se puede evitar automatizando las pruebas de aceptación. Puede encontrar muchas herramientas y bibliotecas disponibles para lenguajes de programación de uso general por empresas que permiten automatizar las pruebas de aceptación.

No confunda la prueba de aceptación como su única responsabilidad de prueba. Intente cubrir adecuadamente la implementación con otras pruebas además de la aceptación, como pruebas unitarias o de integración.

Las pruebas de aceptación varían en el nivel de complejidad según los criterios de aceptación. Las diferentes organizaciones también pueden usar terminología y prácticas diferentes, lo que significa que puede confundirse con otros tipos de pruebas o denominarse con diferentes nombres, como pruebas de extremo a extremo, pruebas funcionales o pruebas de escenarios. Su organización también puede tener criterios o formatos estrictos en los que se demuestren las pruebas de aceptación.

Recuerde que el núcleo de cada prueba de aceptación es simplemente una verificación formal de que una solución implementada satisface el requisito de software al replicar los comportamientos del usuario al ejecutar la aplicación en el producto final.

Eso es todo en pocas palabras

Usted lo ha hecho. ¡Felicitaciones a usted!

Espero que este artículo haya proporcionado algún beneficio al reconocer su papel como ingeniero de software con Requisitos de software.

Puedes leer más de mis artículos en mi blog.

Este artículo se comparte libremente y el autor no recibió ninguna contribución o beneficio como lo exigen los permisos de reimpresión y derechos de autor de SWEBOK. Cualquier punto de vista u opinión expresada no refleja los de IEEE o cualquier organismo / organización al que esté afiliado, no está respaldado por el IEEE y representa el mío únicamente mi propio punto de vista y opiniones.