En un modelo totalmente orientado a la re utilización de componentes, sin duda los requisitos también deben estar en consonancia. ¿ Qué significa esto ? Pues que habrá muchos requisitos generales para aplicaciones que ya vengan cubiertos por el sólo hecho de utilizar tal módulo o tal componente.

Por ejemplo requisitos de autenticación ya vienen solucionados al usar el core de Drupal. En este aspecto a su vez hay multitud de módulos relacionados que permiten satisfacer casi cualquier tipo de autenticación del mercado, desde contribuciones que atacan a productos propietarios hasta la implementación de cualquier estándar como puede ser OpenId.

Incluimos a continuación un posible listado de requisitos "auto" cubiertos. Los agruparemos por funcionalidades. Como ejemplo podemos tratar la funcionalidad de Autenticación al sistema.

Para los requisitos no cubiertos por la núcleo de requisitos "auto-cubiertos", indicaremos explícitamente las funcionalidades pedidas. El objetivo es que haya un documento de requisitos auto cubiertos para cualquier portal que respete la arquitectura y una pequeño subconjunto de requisitos específicos para cada Portal.

El objetivo es que el conjunto de requisitos que diferencien un portal de otro sea mínimo y se convierta en un documento manejable y ágil tanto para desarrollo como para el propio cliente.