Fundamentos de la POO con C# [2/10]: Los requerimientos funcionales y no funcionales
Aprende a definir los requerimientos de tu software como un crack 😉

Hola estimados lectores, continuamos con la serie y en esta ocasión hablaremos de algo que pudiese resultar básico para muchos desarrolladores, sin embargo no son muchos los que conocen en realidad lo que son los requerimientos en Software.

De forma que mejor es asegurarse de comprender el concepto para aplicarlos en la vida real y así tener un buen fundamento, como ya he mencionado antes, dominar estos conceptos y saber aplicarlos en Software real es lo que te diferenciará entre amateur e ingeniero de software. Así que aquí vamos...

Contenido de la Serie de artículos

Estos son todos los temas de la serie:

  1. 1. La Programacion orientada a objetos (POO) y el diseño orientado a objetos (DOO)
  2. 2. Los requerimientos: funcionales y no funcionales
  3. 3. Objetos y clases
  4. 4. Tipos de datos en C#: Por valor y por referencia
  5. 5. Constructores
  6. 6. Signaturas e Interfaces
  7. 7. Clases especiales: estáticas y abstractas
  8. 8. Modificadores de acceso
  9. 9. Los 4 Pilares de la POO: Herencia, abstracción, encapsulamiento y polimorfismo
  10. 10. Los Principios SOLID
Foto de Chivalry Creative en Unsplash

Requerimientos de software

Son las necesidades que poseen los stakeholders y que deben ser satisfechas mediante el Software.

Para definir los requerimientos del Software se puede tomar como referencia la especificación IEEE Std 830(1998) la cual menciona algunos aspectos a considerar cuando se definen los requisitos o requerimientos del Software.

La definición de requerimientos de software es parte de la disciplina "Análisis y requerimientos de Software" de forma que podríamos ponernos muy técnicos en este apartado, sin embargo lo que recomiendo es mantener un equilibrio entre los estándares de documentación y la practicidad que requieren hoy en día los proyectos. Más aún tratándose de un entorno ágil como scrum.

Sin embargo no por practicidad se va a dejar de definir los requerimientos y agruparlos correctamente, veamos justamente eso, los dos tipos que existen.

Requerimientos funcionales

Son aquellos que describen lo que el software debe hacer en términos prácticos. Son los comportamientos específicos que tendrá nuestro software.

No se centra en el cómo sino en el qué es capaz de hacer nuestro software y podríamos tener como resultado de este análisis y definición a la siguiente lista:

  • El sistema de planillas deberá hacer un cálculo mensual del sueldo de los empleados basado en la fórmula planteada en el manual de operaciones de la empresa "Leonardo Sánchez y asociados SA" página 23.
  • El sistema deberá calcular la nota de los alumnos utilizando un promedio simple de la suma de sus exámenes parciales del colegio "Pablo Arias".
  • La calificación aprobatoria para todos los cursos del Instituto "José Siles" será de 11 en una escala del 0 al 20.
  • Cada fin de mes el sistema de ventas "El cuervito SA" deberá generar un kardex valorizado, almacenarlo en el histórico de ventas y enviar un resumen a gerencia general y jefatura de ventas.

Con ejemplos todo se entiende mejor 😁

Requerimientos no funcionales

Son las condiciones relacionadas con las características generales de la operación de nuestro software.

Estos requerimientos están basados en los siguientes aspectos:

  • Mantenibilidad: Uno de los principales a día de hoy, ya que establece qué tan fácil será el software de mantener o agregar funcionalidades.
  • Reusabilidad: Es la capacidad que tiene nuestro software de reutilizar características y funcionalidades ya existentes.
  • Flexibilidad: Es la virtud de nuestro software que permite intercambiar funcionalidad
  • Rendimiento: Es el correcto uso de recursos por parte de nuestro software, lo cual debería resultar en un software razonablemente rápido y eficiente.
  • Integridad de la data: Nos habla sobre la correcta gestión de la información en el sistema y la reducción máxima de errores de coherencia entre los datos.
  • Seguridad: Se refiere a la seguridad de nuestro software en términos de gestión de accesos, seguridad de la información y reducción de brechas de seguridad.

Ahora crack ya no te van a asustar estos términos, entonces podrás hacer una correcta definición de requisitos o requerimientos en tu próximo proyecto de software.

Si este artículo te ha gustado, y espero que así sea 😄 compártelo crack

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *