Proyectos y tipos de requisitos,

FUNCIONAL

Un requisito funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para cada requerimiento funcional se muestran en los casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.

Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema.
Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.
Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto.
El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

NO FUNCIONAL

Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.
Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
rendimiento
disponibilidad
seguridad
accesibilidad
usabilidad
estabilidad
portabilidad
costo
operatividad
interoperabilidad
escalabilidad
concurrencia
mantenibilidad
interfaz

EL ALCANCE DEL PROYECTO

Parte de nuestra labor como profesionales es brindar un buen servicio al cliente. Para ello, necesitamos saber, principalmente, qué debemos hacer cuando tenemos una tarea asignada. Si fuésemos a construir una silla, tendríamos que definir sus características: si esta será reclinable, si tendrá ruedas o si será giratoria. A este conjunto de características del producto, entre otras consideraciones propias del servicio, se le denomina “alcance”.
Tener claro el alcance de un proyecto nos permite saber los recursos que requerimos, así como el tiempo y dinero a invertir en implementar la solución. Pero, ¿cuándo debemos definir este alcance? ¿Antes de iniciar el proyecto o luego de iniciado el mismo?
Sería ideal tener todo definido desde el principio; sin embargo, las condiciones no siempre son óptimas. Propuestas rápidas, cotizaciones de último momento, poca información por parte del cliente, etc. Teniendo en cuenta esto, definimos los siguientes puntos imprescindibles antes de iniciar un proyecto:
-Detalles y razones de la actividad a realizar.
-Niveles de confidencialidad de la información.
-Especificar los entregables con fechas programadas de entrega.
-Saber las fechas críticas y los hitos.
-Conocer las penalidades, si aplica, de no entregar en las fechas pactadas.
-Responsabilidad y compromiso, tanto del cliente, como de la contraparte.
-Garantías requeridas.

Ejemplo

Cuando el proyecto se encuentra en marcha y durante las reuniones de levantamiento de información, los analistas deberán especificar al detalle cada uno de los entregables. De esta manera será necesario obtener del cliente dos tipos de información: qué se incluirá en el proyecto y qué se descartará.
Con estos dos puntos se procede a elaborar la documentación, que nos asegure que todo lo acordado verbalmente con el cliente quede tipificado en un documento formal, con la aprobación del cliente. Y si durante el ciclo de vida del proyecto nos encontramos con cambios, es recomendable identificar primero el impacto en nuestras actividades e informar a los responsables para que se evalúe y tome la mejor decisión.
Por todo lo expuesto, cada vez que seamos parte de un proyecto, debemos iniciarlo teniendo en claro qué tenemos que hacer, esto nos evitará retrasos y reprocesos, y nos permitirá trabajar con la tranquilidad y seguridad.

Módulo

En programación un módulo es una porción de un programa de computadora. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará, comúnmente, una de dichas tareas (o varias, en algún caso).
En general (no necesariamente relacionado con la programación), un módulo recibe como entrada la salida que haya proporcionado otro módulo o los datos de entrada al sistema (programa) si se trata del módulo principal de éste; y proporcionará una salida que, a su vez, podrá ser utilizada como entrada de otro un módulo o bien contribuirá directamente a la salida final del sistema (programa), si se retorna al módulo principal.
Particularmente, en el caso de la programación, los módulos suelen estar (no necesariamente) organizados jerárquicamente en niveles, de forma que hay un módulo principal que realiza las llamadas oportunas a los módulos de nivel inferior.

Cuando un módulo es convocado, recibe como entrada los datos proporcionados por otro del mismo o superior nivel, el que ha hecho la llamada; luego realiza su tarea. A su vez este módulo convocado puede llamar a otro u otros módulos de nivel inferior si fuera necesario; cuando ellos finalizan su tareas, devuelven la salida pertinente al módulo inmediato llamador, en secuencia reversa, finalmente se continúa con la ejecución del módulo principal.