Para no olvidar decidir «en cuántos segundos debe responder para ser aceptable» — Cómo ordenar los requisitos no funcionales con la «Escala de requisitos no funcionales» del IPA
· Actualizado el: · Go Komura · Requisitos no funcionales, Definición de requisitos, Desarrollo por encargo, Desarrollo de sistemas, Escala de requisitos no funcionales, IPA, Diseño, Consultoría técnica, B2B
«Nos dijeron que la transición de pantallas era lenta, pero ni el contrato ni las especificaciones fijaban ningún acuerdo sobre el tiempo de respuesta.»
«El proceso por lotes nocturno dejó de terminar antes de la mañana, pero nadie había estimado cuánto crecerían los datos ni en cuántos años.»
«Solo tras medio día de detención por un fallo del servidor nos dimos cuenta de que, al momento de contratar, nadie había confirmado “en cuántas horas se podía restablecer la configuración”.»
Cuando se piensa en problemas del desarrollo de sistemas, lo primero que viene a la mente son los desajustes de percepción sobre las funciones. Sin embargo, no son pocos los casos en los que, una vez iniciada la operación, el conflicto surge por haber olvidado definir estos requisitos ajenos a las funciones, es decir, los llamados requisitos no funcionales.
La herramienta pública para evitar este olvido es la Escala de requisitos no funcionales del IPA (Agencia de Promoción de Tecnologías de la Información, por sus siglas en japonés: IPA). En este artículo explicamos su contenido y su uso práctico en los sistemas de negocio de pequeñas y medianas empresas, en un lenguaje que también resulte claro para el cliente.
1. En resumen
- Los requisitos no funcionales no definen «qué hace» el sistema, sino «con qué calidad y en qué condiciones funciona». En la clasificación del IPA se organizan en seis grandes apartados: disponibilidad, rendimiento y escalabilidad, operación y mantenimiento, migración, seguridad, y entorno del sistema y ecología
- La Escala de requisitos no funcionales es un conjunto de herramientas gratuitas del IPA que enumera de forma exhaustiva los elementos de estos 6 grandes apartados y permite al cliente y al equipo de desarrollo acordarlos mediante seis niveles, de 0 al máximo de 5. En el apartado 3.1 se reproduce un extracto real de esa definición de niveles
- No es necesario completar todos los elementos. El uso previsto consiste en elegir el «sistema modelo» más cercano a la propia empresa y ajustar, empezando por los elementos importantes, según la situación real de esta
- Cuanto más alto es el nivel no funcional exigido, mayor es el costo. En lugar de «pedir un nivel alto sin más», el nivel debe elegirse calculando hacia atrás desde el impacto en el negocio
- El resultado de esta definición debe quedar documentado en la definición de requisitos. Las premisas acordadas aquí ayudan a comparar presupuestos y a evitar disputas de «él dijo, ella dijo» tras iniciar la operación
2. Qué son los requisitos no funcionales — lo que hay entre «funcionar» y «ser útil»
Los requisitos funcionales son los que definen qué hace el sistema, como «poder registrar un pedido» o «poder imprimir un informe». Las reuniones de desarrollo tienden a concentrarse naturalmente en este tipo de cuestiones.
Por otro lado, las siguientes preguntas no aparecen en ningún listado de funciones.
- ¿Entre qué horas debe funcionar este sistema? ¿Y los fines de semana? ¿Y durante los procesos por lotes nocturnos?
- Si se detiene por un fallo, ¿en cuántas horas debe restablecerse para que el negocio pueda seguir operando? ¿Hasta qué punto en el tiempo es aceptable recuperar los datos?
- ¿Cuántas personas lo usan simultáneamente y cuántos casos se procesan al día? ¿Cuánto habrá crecido el volumen de datos dentro de cinco años?
- ¿Quién supervisa el sistema, quién realiza las copias de seguridad y quién recibe el primer aviso ante un fallo?
- ¿Hasta dónde se trasladan al nuevo sistema los datos del sistema anterior?
Todo esto son requisitos no funcionales. Lo complicado es que, incluso sin definirlos, el sistema «funciona» de alguna manera. El problema solo sale a la luz una vez que empieza la operación, aumenta la carga y ocurre un fallo. Y en ese momento, como está relacionado con la configuración del servidor y con la base del diseño, corregirlo resulta muy costoso.
3. Qué es la Escala de requisitos no funcionales
La Escala de requisitos no funcionales es un conjunto de herramientas que el IPA publica con el objetivo de evitar desajustes de percepción entre el cliente y el equipo de desarrollo en torno a los requisitos no funcionales. La primera versión se publicó en abril de 2010, y la versión más reciente actual es «Escala de requisitos no funcionales 2018» (publicada en abril de 2018), que refleja los cambios en torno a la seguridad y la virtualización (la nube). Actualmente se encuentra en una página tratada como archivo dentro del sitio del IPA, pero en la práctica sigue siendo un estándar habitual como criterio para verificar que no falte ningún requisito no funcional.
Su contenido se compone de las siguientes herramientas.
| Herramienta | Función |
|---|---|
| Tabla de niveles | Tabla que resume el nivel orientativo por sistema modelo para los elementos especialmente importantes. Es el punto de partida para acordar los requisitos |
| Listado de elementos | Lista completa con las 238 métricas (indicadores de medición y verificación) en total. Se usa para profundizar en el detalle |
| Diagrama de árbol | Diagrama jerárquico que muestra la clasificación desde los 6 grandes apartados hasta cada elemento. Se usa para captar la visión de conjunto |
| Hoja de trabajo | Hoja de trabajo para ir anotando los elementos y niveles en un proyecto real |
| Guía de uso | Manual explicativo compuesto de tres partes: explicativa, de uso y de aplicación práctica |
Cada métrica tiene definidas opciones de nivel escalonadas, de modo que el requisito se puede expresar como una elección de nivel en lugar de con términos ambiguos como «alto» o «bajo».
3.1. Qué es un nivel — un vistazo a la tabla de niveles real
Como cuesta imaginar qué significa «nivel escalonado» solo con la descripción, veamos un ejemplo real. Los niveles van de 0 a un máximo de 5, en seis escalones: cuanto más alto es el número, mayor es la dificultad de implementación y, por lo general, mayor también el costo de desarrollo y operación. Sin embargo, no todas las métricas tienen seis escalones; algunos elementos solo tienen tres opciones (de 0 a 2).
Por ejemplo, el primer elemento de disponibilidad, «horario de operación (normal)» (número A.1.1.1), se define de la siguiente manera. Las horas entre paréntesis son solo un ejemplo, no la condición misma para elegir el nivel.
| Nivel | Definición del horario de operación (normal) |
|---|---|
| 0 | Sin especificar |
| 1 | Dentro del horario laboral (9:00 a 17:00) |
| 2 | Solo se detiene por la noche (9:00 a 21:00) |
| 3 | Se detiene alrededor de 1 hora (9:00 a las 8:00 de la mañana siguiente) |
| 4 | Se detiene un poco (9:00 a las 8:55 de la mañana siguiente) |
| 5 | Sin interrupciones, 24 horas |
El deseo vago de «que nuestro sistema funcione las 24 horas» se convierte, en esta tabla, en la decisión concreta de «elegir el nivel 5». Y en el momento en que se elige, también se hace visible que eso conlleva costos de personal de turno para la operación y de una configuración redundante.
Veamos también otro ejemplo con el que al cliente le resulta fácil hablar en números: la «tasa de disponibilidad» (número A.1.5.1). En las notas de la tabla de niveles se indica, además, el tiempo de interrupción anual orientativo para cada nivel.
| Nivel | Tasa de disponibilidad | Tiempo total de interrupción del negocio en un año, con operación de 24 horas los 365 días |
|---|---|---|
| 0 | 95% o menos | ─ |
| 1 | 95% | 18.3 días |
| 2 | 99% | 87.6 horas |
| 3 | 99.9% | 8.76 horas |
| 4 | 99.99% | 52.6 minutos |
| 5 | 99.999% | 5.26 minutos |
Puede parecer que «99% y 99.9% son casi lo mismo», pero en tiempo de interrupción anual la diferencia es de 87.6 horas frente a 8.76 horas: un día entero frente a poco menos de medio día. El verdadero valor de la Escala de requisitos no funcionales está en mostrar, con números uno al lado del otro, que aunque las palabras suenen parecidas, el impacto en el negocio puede ser 10 veces distinto.
Además, la tabla de niveles ya incluye rellenados los niveles orientativos por sistema modelo. Para los dos elementos anteriores, por ejemplo, quedan así.
| Elemento | Impacto social casi nulo | Impacto social limitado | Impacto social extremadamente grande |
|---|---|---|---|
| Horario de operación (normal) | Nivel 2: solo se detiene por la noche (9:00 a 21:00) | Nivel 4: se detiene un poco (9:00 a las 8:55 de la mañana siguiente) | Nivel 5: sin interrupciones, 24 horas |
| Tasa de disponibilidad | Nivel 2: 99% | Nivel 4: 99.99% | Nivel 5: 99.999% |
Tomando como punto de partida la columna del modelo más cercano a la propia empresa, se va subiendo o bajando: «como tenemos un proceso por lotes nocturno, subimos un nivel más», «en cambio, no necesitamos tanta tasa de disponibilidad». Así es como se usa la tabla de niveles.
3.2. Los tres sistemas modelo
Otra característica son los tres sistemas modelo, definidos según la magnitud del impacto social que tendría la detención del sistema.
- Sistemas con impacto social casi nulo
- Sistemas con impacto social limitado (como los sistemas centrales de una empresa)
- Sistemas con impacto social extremadamente grande (como infraestructuras sociales)
La tabla de niveles ya trae rellenados los niveles orientativos para cada modelo. Es decir, en lugar de empezar la discusión desde cero, se puede hacer una primera aproximación con «nuestra empresa se parece a este modelo» y luego ajustar hacia arriba o hacia abajo según la situación real.
4. Los seis grandes apartados — traducidos al lenguaje del cliente
Si traducimos los 6 grandes apartados de la Escala de requisitos no funcionales a preguntas que el cliente puede responder, quedan así.
| Gran apartado | Ejemplos de preguntas que responde el cliente |
|---|---|
| Disponibilidad | ¿Cuándo debe estar disponible? (¿solo en horario laboral o las 24 horas?). Si se detiene, ¿en cuántas horas debe restablecerse? ¿Hasta qué punto en el tiempo es aceptable recuperar los datos? |
| Rendimiento y escalabilidad | ¿Cuántas personas lo usan simultáneamente? ¿Cuántos casos se procesan al día o en el pico de fin de mes? ¿Cuánto crecerán los datos en cuántos años? ¿Cuál es el tiempo objetivo de respuesta de pantalla o de proceso por lotes? |
| Operación y mantenimiento | ¿Quién supervisa, hace copias de seguridad y realiza la recuperación? ¿Hay franjas horarias en las que se puede detener el sistema para mantenimiento? ¿Cuál es la ventanilla de contacto y su horario de atención? |
| Migración | ¿Qué datos del sistema anterior se traspasan y hasta qué punto? ¿Se establece un período de operación en paralelo? ¿Cuánto tiempo de detención se puede usar para el cambio? |
| Seguridad | ¿Quién puede acceder a qué, y desde dónde? ¿Hasta qué punto se conservan los registros de operación (logs)? ¿Qué leyes o requisitos de las contrapartes se deben cumplir? |
| Entorno del sistema y ecología | ¿Dónde se ubica el servidor? (¿en las instalaciones propias o en la nube?). ¿Qué restricciones existen en el lugar de instalación, como suministro eléctrico o temperatura? |
Visto así, queda claro que la mayoría de los 6 grandes apartados no son preguntas técnicas, sino preguntas sobre el negocio. Quien puede responder «¿qué pasaría si el procesamiento de facturación de fin de mes se retrasa medio día?» no es la empresa de desarrollo, sino el cliente. En realidad, la iniciativa sobre los requisitos no funcionales está en manos del cliente.
5. Un uso realista — no intentar completar los 238 elementos
El listado de elementos tiene 238 métricas, pero discutirlas todas una por una no es realista en un proyecto de una pequeña o mediana empresa, y tampoco es el uso que contempla la guía. El flujo previsto es el siguiente.
1. Elegir el sistema modelo
(¿a qué grado de impacto se parece el sistema propio?)
↓
2. Para los elementos importantes de la tabla de niveles,
ajustar según la situación real de la empresa a partir del nivel orientativo del modelo
↓
3. Profundizar solo en la parte necesaria con el listado de elementos
Para una aplicación de negocio de una pequeña o mediana empresa, con solo el paso 2 — «acordar los elementos importantes» — ya se obtiene un efecto suficiente. Por experiencia, recomendamos documentar en la definición de requisitos al menos los siguientes puntos. Observe que los tres casos mencionados al principio ocurrieron, en cada caso, por saltarse alguna parte de esta tabla.
| Qué documentar | Gran apartado correspondiente | Qué conflicto surge si no se documenta |
|---|---|---|
| El horario de operación y el impacto en el negocio en caso de detención | Disponibilidad | «No me habían dicho que no se podía usar los sábados», «pensé que se podía detener por la noche para mantenimiento» |
| El intervalo de copias de seguridad y, en caso de fallo, «hasta qué momento» y «en cuántas horas» se restaura | Disponibilidad, operación y mantenimiento | El tercer caso mencionado al principio. Solo tras medio día de detención se descubre que nadie había verificado en cuántas horas se podía restablecer la configuración |
| El volumen y número de datos actuales, y la previsión para varios años después | Rendimiento y escalabilidad | El segundo caso mencionado al principio. Los datos aumentan y el proceso por lotes nocturno deja de terminar antes de la mañana. Como no se había estimado cuántas veces se multiplicaría en cuántos años, tanto el diseño como el dimensionamiento fallan |
| Los valores objetivo del tiempo de respuesta o del tiempo de procesamiento por lotes. Basta con fijar un criterio, aunque sea «igual o mejor que el sistema actual» | Rendimiento y escalabilidad | El primer caso mencionado al principio. Aunque digan que «va lento», como no hay ningún criterio ni en el contrato ni en las especificaciones, no se puede ni objetar ni decidir si hace falta mejorarlo |
| El reparto de la supervisión, las copias de seguridad y la primera respuesta ante fallos | Operación y mantenimiento | No está decidido quién recibe el primer aviso de un fallo: «cuando nos dimos cuenta, llevaba tres días detenido», «cada uno pensaba que la otra parte hacía las copias de seguridad» |
Lo que no se debe olvidar aquí es la relación entre nivel y costo. Por ejemplo, si se busca «un sistema que nunca se detenga», el costo se dispara por la redundancia del servidor y el sistema de supervisión. Si se puede determinar que «basta con restablecerlo el mismo día, porque el negocio puede esperar hasta la mañana siguiente», ese presupuesto se puede destinar a otra cosa. El nivel de la Escala de requisitos no funcionales no es una herramienta para elevar las exigencias: la distancia correcta es usarlo como un lenguaje común para discutir el equilibrio entre el impacto en el negocio y el costo.
6. Relación con el contrato y el presupuesto
Los requisitos no funcionales también están directamente vinculados al contrato.
Primero está la comparación de presupuestos. Si se piden presupuestos a varias empresas sin igualar las premisas no funcionales, es posible que la empresa A cotice una configuración redundante y la empresa B, un solo servidor. El cliente ya no puede distinguir si la diferencia de precio se debe a una diferencia de configuración o a una estimación poco rigurosa.
Después está la recepción del sistema y el período posterior al inicio de la operación. Si el acuerdo sobre el tiempo de respuesta y las copias de seguridad está documentado, discusiones como «va lento» o «no lo esperábamos» se convierten en la simple verificación de hechos frente a un criterio.
El «Contrato y transacción modelo de sistemas de información» del IPA también contempla documentar los requisitos no funcionales como resultado del proceso de definición de requisitos. La Escala de requisitos no funcionales encaja de forma natural en el flujo de contratación por etapas en el que la definición de requisitos se realiza mediante un contrato de cuasi-mandato y, sobre la base de lo acordado, el desarrollo se contrata como un contrato de obra. Sobre la forma del contrato, consulte nuestro artículo sobre el «Contrato y transacción modelo» del IPA.
Resumen
Resumimos los puntos clave de la «Escala de requisitos no funcionales» del IPA.
- Los requisitos no funcionales definen «con qué calidad y en qué condiciones funciona» el sistema. Aunque no se definan, el sistema funciona, pero el problema sale a la luz y genera conflictos tras iniciar la operación
- La Escala de requisitos no funcionales es un conjunto de herramientas gratuitas del IPA para acordar, mediante niveles escalonados, los 6 grandes apartados y las 238 métricas de disponibilidad, rendimiento y escalabilidad, operación y mantenimiento, migración, seguridad, y entorno del sistema y ecología
- Los niveles van de 0 a un máximo de 5, en seis escalones. Por ejemplo, en la tasa de disponibilidad, 99% (87.6 horas de interrupción al año) es el nivel 2, y 99.99% (52.6 minutos al año) es el nivel 4: así, diferencias de requisitos que suenan parecidas en palabras quedan alineadas en números (capítulo 3)
- Se toma como punto de partida el nivel orientativo de los tres sistemas modelo y se ajusta a partir de los elementos importantes. No es necesario completar todos los elementos
- El contenido de los 6 grandes apartados son, en su mayoría, preguntas sobre el negocio. Quien tiene las respuestas es el cliente
- Cuanto más alto es el nivel, mayor es el costo. Elija el equilibrio calculando hacia atrás desde el impacto en el negocio, y deje el resultado documentado en la definición de requisitos
Decidir de antemano «con qué calidad debe seguir funcionando», tanto como «qué se va a construir». Esa es la forma más económica de evitar un sistema que funciona pero no sirve, y los conflictos que vienen después.
Referencias
La Escala de requisitos no funcionales se encuentra en una página tratada como archivo dentro del sitio del IPA, y es difícil llegar a ella mediante una búsqueda, así que dejamos aquí los enlaces directos. Todas son gratuitas y se descargan a través de una página de condiciones de uso.
- Fortalecimiento de los procesos iniciales de construcción de sistemas (Escala de requisitos no funcionales) ─ Página de entrada dentro del archivo del IPA. Desde aquí se accede a cada documento
- Página de presentación de la Escala de requisitos no funcionales ─ Explica la composición del conjunto de herramientas y el procedimiento de uso, desde la selección del sistema modelo hasta la decisión del nivel de los elementos importantes
- Condiciones de uso del cuerpo principal de la Escala de requisitos no funcionales (versión en japonés) ─ Descarga del conjunto completo: la guía de uso (partes explicativa, de uso y de aplicación práctica), la tabla de niveles, el listado de elementos, el diagrama de árbol y la hoja de trabajo (Excel). Este es el que hay que descargar primero
- Condiciones de uso de la 2.ª edición de la parte «de aplicación práctica» de la guía de uso de la Escala de requisitos no funcionales 2018 ─ La parte de aplicación práctica, revisada en marzo de 2019
- Condiciones de uso del material de formación de la Escala de requisitos no funcionales ─ Conjunto completo de material que se puede usar en sesiones de estudio internas
- Contrato y transacción modelo de sistemas de información ─ Documento del IPA mencionado en el capítulo 6, que trata la relación entre el contrato y la definición de requisitos
La definición de niveles y el tiempo de interrupción anual orientativo citados en el capítulo 3 de este artículo provienen de la hoja de trabajo incluida en el «cuerpo principal (versión en japonés)» mencionado arriba (números A.1.1.1, «horario de operación (normal)», y A.1.5.1, «tasa de disponibilidad»).
Para quienes necesiten ayuda ordenando los requisitos de un sistema de negocio
Acordar los requisitos no funcionales exige ir y venir entre la realidad del negocio (los períodos pico, el volumen de datos, el impacto de una detención) y la configuración del sistema que los hace posibles.
En KomuraSoft LLC, al recibir consultas sobre el desarrollo por encargo o la modificación de aplicaciones de negocio para Windows y sistemas web, ordenamos junto con el cliente, ya en la etapa de requisitos, el rendimiento, la operación y el comportamiento ante fallos, siguiendo el enfoque presentado en este artículo. Puede consultarnos incluso desde etapas como «el procesamiento del sistema actual se ha ido volviendo lento» o «queremos aprovechar una actualización para revisar los acuerdos de operación».
Artículos relacionados
Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.
Introducción a ADR (Architecture Decision Record) — El método mínimo para dejar constancia de «por qué se eligió este diseño» en desarrollos de pequeña escala
El código no dice «por qué» se hizo así. Aprenda a registrar cada decisión de diseño con ADR (Architecture Decision Record): plantilla, t...
Las 10 principales amenazas de seguridad de la información 2026 — cómo leer el ranking y qué deben abordar realmente las pymes
En el «Top 10 de amenazas de seguridad de la información 2026» de IPA, el ransomware repite en el 1.º puesto por 11.º año consecutivo, la...
Cómo desarrollar sistemas con subvenciones — el calendario con cálculo inverso desde la resolución de concesión y la elaboración del plan de negocio
El desarrollo de sistemas con subvenciones sigue un proceso distinto al habitual. Explicamos el calendario con cálculo inverso desde la r...
¿Se pueden usar subsidios para externalizar el desarrollo de sistemas? — Un mapa de programas por objetivo y las trampas que conviene conocer antes de contratar (edición del año fiscal 2026)
¿Se pueden usar subsidios para externalizar el desarrollo de sistemas? Explicamos por qué el Subsidio de Introducción de TI no cubre el d...
Lo que también debe saber quien encarga un sitio web — cómo usar la guía «Cómo crear un sitio web seguro» de la IPA como checklist
¿Con qué criterio revisar la seguridad de su sitio web? Explicamos las 11 vulnerabilidades de la guía IPA «Cómo crear un sitio web seguro...
Temas relacionados
Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.
Temas técnicos de Windows
Portal sobre desarrollo de Windows, investigación de fallos y aprovechamiento de activos existentes.
Servicios relacionados con este tema
El artículo está directamente relacionado con los siguientes servicios.
Consultoría técnica y revisión de diseño
Porque acordar los requisitos no funcionales implica decidir el nivel adecuado observando tanto la realidad del negocio como la configuración del sistema, y es uno de los temas centrales de la consultoría técnica que incluye revisión de diseño.
Desarrollo de aplicaciones para Windows
Porque en el desarrollo por encargo de aplicaciones de negocio verificamos, ya en la etapa de requisitos, el rendimiento, la operación y el comportamiento ante fallos siguiendo el enfoque de la Escala de requisitos no funcionales presentado en este artículo.
Mantenimiento y modernización de software Windows
Porque en la modificación o actualización de sistemas existentes, ordenar los valores no funcionales actuales (tiempo de procesamiento, volumen de datos, procedimientos de operación) como valores de referencia es la base para una migración segura.
Preguntas frecuentes
Preguntas habituales en las consultas sobre el tema del artículo.
- ¿Qué son los requisitos no funcionales?
- Son los requisitos relativos a «con qué calidad y en qué condiciones funciona» el sistema, a diferencia de los requisitos funcionales, que definen «qué hace». Por ejemplo: cuándo debe estar disponible el sistema (disponibilidad), cuántas personas lo usan simultáneamente y en cuántos segundos responde (rendimiento y escalabilidad), quién y cómo lo opera y mantiene (operación y mantenimiento), cómo se traspasan los datos del sistema anterior (migración), qué defensas incorpora (seguridad) y en qué entorno se instala (entorno del sistema). Si se olvida definirlos, el resultado suele ser un sistema que «funciona, pero no sirve».
- ¿La Escala de requisitos no funcionales se puede usar de forma gratuita? ¿Dónde se consigue?
- Se puede descargar de forma gratuita desde el sitio web del IPA. El paquete incluye la tabla de niveles, el listado de elementos, el diagrama de árbol, la hoja de trabajo y la guía de uso (en sus tres partes: explicativa, de uso y de aplicación práctica). La versión más reciente es «Escala de requisitos no funcionales 2018», publicada en abril de 2018. Actualmente se encuentra en una página tratada como archivo dentro del sitio del IPA, pero en la práctica sigue usándose ampliamente como criterio para verificar que no falte ningún requisito no funcional.
- ¿Es necesario decidir los 238 elementos?
- No. La propia guía de uso no contempla discutir todas las métricas una por una. El uso indicado es progresivo: primero se elige el sistema modelo más cercano a la propia empresa para fijar un nivel general orientativo, después se ajustan los elementos importantes de la tabla de niveles según la situación real de la empresa, y solo cuando hace falta se profundiza con el listado de elementos en el rango necesario. En un sistema de gestión de una pequeña o mediana empresa, con solo acordar los elementos importantes ya se evita la mayoría de los conflictos causados por requisitos olvidados.
- ¿En qué momento se deben decidir los requisitos no funcionales?
- En la etapa de definición de requisitos. Los objetivos de disponibilidad y rendimiento afectan a la configuración del servidor y a la base del diseño, por lo que cambiarlos una vez avanzado el desarrollo tiene un gran impacto en el costo y en el plazo. El «Contrato y transacción modelo de sistemas de información» del IPA también contempla documentar, como resultado de la definición de requisitos, no solo los requisitos funcionales sino también los no funcionales. Si no se igualan las premisas no funcionales al comparar presupuestos, resulta imposible saber si la diferencia de precio se debe a una diferencia de configuración o a una estimación poco rigurosa.
Perfil del autor
Página de presentación del autor del artículo.
Go Komura
Representante de KomuraSoft LLC
Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.