📋 Tipos de requerimientos

1. Según Ian Sommerville, ¿cuál de las siguientes opciones define correctamente un requerimiento funcional?

1. Una restricción sobre los servicios o funciones del sistema, aplicada por lo general al sistema como un todo
2. Una declaración de un servicio que el sistema debe proporcionar o de cómo debe reaccionar ante una entrada particular
3. Un objetivo estratégico de alto nivel que justifica ante el cliente la construcción del sistema de software
4. Una limitación impuesta sobre las opciones de diseño o de implementación de la solución técnica

Sommerville define los requerimientos funcionales como declaraciones de los servicios que debe prestar el sistema y de su reacción ante entradas particulares; la opción 0 describe un requerimiento no funcional y la opción 3 describe una restricción de diseño. (Ian Sommerville, Ingeniería de Software (9.ª/10.ª ed.), cap. Ingeniería de requerimientos)

2. ¿Cuál de los siguientes enunciados describe correctamente a los requerimientos no funcionales, según Sommerville?

1. Son restricciones sobre los servicios o funciones del sistema, aplicadas por lo general al sistema como un todo
2. Son declaraciones de los servicios específicos que el sistema debe prestar ante entradas determinadas del usuario
3. Son descripciones del comportamiento que debe tener el sistema frente a cada característica funcional individual
4. Son objetivos estratégicos del negocio que motivan y justifican el desarrollo del producto de software

Sommerville define a los requerimientos no funcionales como restricciones sobre los servicios o funciones ofrecidos, aplicadas normalmente al sistema como un todo, a diferencia de los requerimientos funcionales (opción 1). (Ian Sommerville, Ingeniería de Software, cap. Ingeniería de requerimientos)

3. En el documento de requerimientos de un sistema bancario se lee lo siguiente: 'Cuando el usuario introduce un número de cuenta inválido, el sistema debe mostrar el mensaje "Cuenta no encontrada" y solicitar el dato nuevamente'. ¿Qué tipo de requerimiento ejemplifica este enunciado?

1. Requerimiento no funcional de usabilidad, porque su objetivo es mejorar la experiencia del usuario
2. Requerimiento organizacional, porque depende de las políticas y procedimientos internos del banco
3. Requerimiento funcional, porque describe cómo debe reaccionar el sistema ante una entrada particular
4. Requerimiento de negocio, porque refleja un objetivo estratégico de la institución bancaria

El enunciado especifica la reacción del sistema ante una entrada concreta (una cuenta inválida), lo que corresponde a un requerimiento funcional; no impone una restricción de calidad sobre el sistema en su conjunto. (Ian Sommerville, Ingeniería de Software, cap. Ingeniería de requerimientos)

4. Un cliente solicita que la aplicación móvil inicie sesión en menos de 2 segundos en el 95% de los casos, incluso con una conexión de datos de baja velocidad. ¿A qué tipo de requerimiento corresponde esta especificación?

1. Requerimiento funcional, porque describe un servicio concreto que el sistema debe prestar ante la petición del usuario
2. Requerimiento de usuario, porque está redactado en lenguaje natural, sin diagramas ni detalles técnicos de implementación
3. Requerimiento del dominio, porque refleja una característica propia del área de aplicación del sistema
4. Requerimiento no funcional de rendimiento, porque impone una restricción medible sobre el comportamiento en ejecución

La especificación impone un límite de tiempo medible sobre el comportamiento en ejecución del sistema, característico de un requerimiento no funcional de producto (rendimiento), y no describe un servicio específico. (Ian Sommerville, Ingeniería de Software, clasificación de requerimientos no funcionales)

5. Sommerville clasifica los requerimientos no funcionales en tres categorías principales. ¿Cuáles son?

1. Requerimientos de producto, organizacionales y externos
2. Requerimientos de usuario, del sistema y del dominio
3. Requerimientos funcionales, de negocio y de restricción
4. Requerimientos de proceso, de calidad y de mantenimiento

Sommerville organiza los requerimientos no funcionales en tres tipos: de producto, organizacionales y externos; la opción 1 corresponde a otra clasificación distinta según el origen del requerimiento. (Ian Sommerville, Ingeniería de Software, sección Requerimientos no funcionales)

6. ¿Cuál de las siguientes listas corresponde a ejemplos de requerimientos no funcionales de producto, según la clasificación de Sommerville?

1. Cumplimiento regulatorio, conformidad legislativa y consideraciones éticas
2. Rendimiento, fiabilidad, usabilidad, eficiencia y portabilidad
3. Estándares de proceso, requisitos operacionales y del entorno de desarrollo
4. Objetivos de negocio, necesidades de usuario y reglas del dominio

Los requerimientos de producto especifican o restringen el comportamiento en ejecución del software e incluyen rendimiento, fiabilidad, usabilidad, eficiencia y portabilidad; la opción 0 corresponde a requerimientos externos. (Ian Sommerville, Ingeniería de Software, clasificación de requerimientos no funcionales)

7. ¿De dónde se derivan los requerimientos no funcionales organizacionales, según la clasificación de Sommerville?

1. Del comportamiento en tiempo de ejecución que debe tener el software una vez instalado y operando
2. De factores regulatorios y legislativos externos al sistema y a su proceso de desarrollo
3. De las políticas y los procedimientos de las organizaciones del cliente y del desarrollador
4. De los objetivos estratégicos de alto nivel que justifican y motivan la ejecución del proyecto

Los requerimientos organizacionales se derivan de las políticas y procedimientos de las organizaciones del cliente y del desarrollador; los factores regulatorios (opción 1) corresponden a requerimientos externos. (Ian Sommerville, Ingeniería de Software, clasificación de requerimientos no funcionales)

8. Un requerimiento establece que el sistema de historiales clínicos debe cumplir con la legislación vigente en materia de protección de datos personales de los pacientes. ¿A qué categoría de requerimiento no funcional pertenece?

1. Requerimiento de producto, porque restringe el comportamiento del software durante su ejecución
2. Requerimiento organizacional, porque proviene de las políticas y procedimientos internos del hospital
3. Requerimiento funcional, porque describe un servicio concreto que el sistema debe prestar
4. Requerimiento externo, porque se deriva de un factor legislativo ajeno al proceso de desarrollo

La exigencia proviene de una ley externa al sistema y a su proceso de desarrollo, lo que corresponde a un requerimiento externo (legislativo), y no de las políticas internas de la organización. (Ian Sommerville, Ingeniería de Software, clasificación de requerimientos no funcionales)

9. Una empresa desarrolladora establece internamente que todo su software debe documentarse siguiendo el estándar de codificación propio de la compañía, mientras que un organismo gubernamental exige que el sistema de nómina calcule las retenciones fiscales conforme a la ley vigente. ¿Cómo se clasifican, respectivamente, estos dos requerimientos no funcionales?

1. El primero es organizacional y el segundo es externo, por derivar de una política interna y de una ley, respectivamente
2. El primero es externo y el segundo es organizacional, por derivar de una ley y de una política interna, respectivamente
3. Ambos son requerimientos de producto, porque restringen el comportamiento del software en ejecución
4. Ambos son requerimientos funcionales, porque describen servicios obligatorios que el sistema debe prestar

El estándar de codificación de la propia empresa se deriva de sus políticas internas (requerimiento organizacional), mientras que la exigencia legal de un organismo externo al sistema es un requerimiento externo de tipo legislativo. (Ian Sommerville, Ingeniería de Software, clasificación de requerimientos no funcionales)

10. ¿Cómo se caracterizan los requerimientos de usuario, según Sommerville?

1. Como especificaciones formales y detalladas que forman parte exclusiva del contrato entre proveedor y cliente
2. Como declaraciones en lenguaje natural y con diagramas, dirigidas a clientes y usuarios, sobre servicios y restricciones
3. Como descripciones técnicas y minuciosas de las funciones del sistema, destinadas al equipo de programadores
4. Como enunciados cuantitativos y medibles que permiten verificar de forma objetiva el desempeño del sistema

Los requerimientos de usuario se redactan en lenguaje natural y con diagramas, dirigidos a clientes y usuarios, a diferencia de los requerimientos del sistema, que son descripciones técnicas detalladas para los desarrolladores. (Ian Sommerville, Ingeniería de Software, Requerimientos de usuario y del sistema)

11. ¿Qué son los requerimientos del sistema, de acuerdo con Sommerville?

1. Objetivos de alto nivel de la organización o del cliente que explican el porqué del proyecto
2. Restricciones impuestas por factores externos al sistema, como leyes, reglamentos o normas obligatorias
3. Descripciones detalladas de las funciones, servicios y restricciones operacionales que definen qué debe implementarse
4. Declaraciones generales, en lenguaje natural, dirigidas a los clientes sobre los servicios que esperan

Los requerimientos del sistema son descripciones detalladas de funciones, servicios y restricciones operacionales que pueden formar parte del contrato entre cliente y proveedor; la opción 3 describe a los requerimientos de usuario. (Ian Sommerville, Ingeniería de Software, Requerimientos de usuario y del sistema)

12. En un proyecto de software, el cliente escribe: 'El sistema debe permitir a los empleados registrar sus horas trabajadas de forma sencilla'. El equipo de análisis lo traduce como: 'El módulo de asistencia debe almacenar cada entrada y salida con marca de tiempo con precisión de un minuto y validarla contra el turno asignado en la base de datos'. ¿Cómo se relacionan ambos enunciados?

1. El primero es un requerimiento del sistema y el segundo es un requerimiento de usuario más detallado
2. Ambos son requerimientos no funcionales que restringen el mismo servicio del sistema de asistencia
3. Ambos son requerimientos del dominio derivados del área de recursos humanos de la empresa
4. El primero es un requerimiento de usuario y el segundo es el requerimiento del sistema derivado de él

El primer enunciado, general y en lenguaje natural, es un requerimiento de usuario; el segundo, técnico y detallado, es el requerimiento del sistema que especifica cómo implementarlo. (Ian Sommerville, Ingeniería de Software, Requerimientos de usuario y del sistema)

13. Un contrato de desarrollo de software incluye la siguiente cláusula: 'El sistema de facturación electrónica debe generar el comprobante fiscal en formato XML validado contra el esquema publicado por la autoridad tributaria, en un tiempo no mayor a 3 segundos por transacción'. Esta cláusula forma parte del contrato entre cliente y proveedor. ¿Qué tipo de requerimiento es?

1. Requerimiento del sistema, porque es una descripción técnica y contractual de lo que debe implementarse
2. Requerimiento de usuario, porque está redactado para que el cliente lo entienda sin conocimientos técnicos
3. Requerimiento de negocio, porque expresa el objetivo estratégico de alto nivel que justifica el proyecto
4. Restricción de diseño, porque limita las opciones de implementación sin describir función alguna del sistema

La descripción es técnica, precisa y forma parte del contrato entre cliente y proveedor, rasgos propios de un requerimiento del sistema; un requerimiento de usuario se redactaría en lenguaje natural general, sin ese nivel de detalle. (Ian Sommerville, Ingeniería de Software, Requerimientos de usuario y del sistema)

14. ¿Qué característica distingue a los requerimientos del dominio, según Sommerville?

1. Se derivan de las políticas y los procedimientos internos de la organización desarrolladora
2. Se derivan del dominio de aplicación del sistema y pueden ser funcionales o no funcionales
3. Se derivan de factores regulatorios y legislativos externos al proceso de desarrollo
4. Forman parte del contrato legal que se firma entre el cliente y el proveedor del software

Los requerimientos del dominio se derivan del dominio de aplicación del sistema y reflejan sus características; pueden ser funcionales o no funcionales, a diferencia de los organizacionales o externos. (Ian Sommerville, Ingeniería de Software, Requerimientos del dominio)

15. En el desarrollo de un sistema de control de tráfico aéreo se incluye el siguiente enunciado: 'Debido a las normas de separación mínima entre aeronaves usadas en la práctica de la aviación civil, el sistema debe recalcular la ruta cuando dos aeronaves reduzcan su distancia vertical a menos de 300 metros'. ¿Qué tipo de requerimiento ejemplifica mejor este enunciado?

1. Requerimiento de usuario, porque está redactado en lenguaje natural para que lo entienda el cliente
2. Requerimiento organizacional, porque proviene de las políticas internas de la aerolínea operadora
3. Requerimiento del dominio, porque refleja una característica propia del área de aplicación del sistema
4. Requerimiento externo, porque se deriva de un factor legislativo ajeno al sistema y su desarrollo

La regla de separación mínima entre aeronaves es una característica propia del dominio de la aviación, por lo que constituye un requerimiento del dominio, y no de una política interna o de una ley específica citada. (Ian Sommerville, Ingeniería de Software, Requerimientos del dominio)

16. El estándar IEEE 830-1998 establece las características que debe tener una buena Especificación de Requerimientos de Software (SRS). ¿Cuántas características define este estándar?

1. Cinco: correcta, completa, consistente, verificable y modificable
2. Seis: no ambigua, completa, consistente, jerarquizada, verificable y rastreable
3. Diez: correcta, no ambigua, completa, consistente, jerarquizada, verificable, modificable, rastreable, medible y trazable
4. Ocho: correcta, no ambigua, completa, consistente, jerarquizada, verificable, modificable y rastreable

El IEEE 830-1998 define ocho características de una buena SRS: correcta, no ambigua, completa, consistente, jerarquizada, verificable, modificable y rastreable; las demás opciones omiten o agregan elementos que no forman parte de la lista oficial. (IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications, sección 4.3)

17. De acuerdo con el estándar IEEE 830-1998, ¿cuál de las siguientes opciones NO forma parte de las características de una buena Especificación de Requerimientos de Software (SRS)?

1. Consistente, sin contradicciones entre los requerimientos que la componen
2. Rentable, en el sentido de minimizar el costo total del proyecto
3. Verificable, de modo que exista un proceso finito y de costo razonable para comprobar cada requerimiento
4. Rastreable, de manera que el origen de cada requerimiento sea claro

El IEEE 830-1998 no incluye 'rentable' entre las ocho características de una SRS; consistente, verificable y rastreable sí forman parte de esa lista. (IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications, sección 4.3)

18. ¿Cuál es el estándar vigente para la ingeniería de requerimientos que sustituyó a los estándares IEEE 830-1998, IEEE 1233-1998 e IEEE 1362-1998?

1. ISO/IEC 12207
2. ISO/IEC/IEEE 29148
3. ISO/IEC 25010
4. IEEE 1471-2000

El estándar ISO/IEC/IEEE 29148 sustituyó y dejó obsoletos a los estándares IEEE 830-1998, IEEE 1233-1998 e IEEE 1362-1998; ISO/IEC 25010 es un estándar de modelos de calidad, no de requerimientos. (ISO/IEC/IEEE 29148, Systems and software engineering — Life cycle processes — Requirements engineering)

19. El SWEBOK distingue entre requerimientos de producto y requerimientos de proceso dentro del área de conocimiento de Requerimientos de Software. Un enunciado que exige que el equipo de desarrollo utilice un lenguaje de programación específico durante la construcción del sistema corresponde, según esa distinción, a un requerimiento de:

1. Producto, porque especifica una necesidad que el software debe cumplir una vez terminado y en operación
2. Producto, porque restringe el comportamiento en tiempo de ejecución del sistema ya construido
3. Proceso, porque es una restricción sobre el desarrollo del software, no sobre el producto construido
4. Negocio, porque refleja un objetivo estratégico de alto nivel de la organización desarrolladora

El SWEBOK define al requerimiento de proceso como una restricción sobre el desarrollo del software, como el uso obligatorio de cierto lenguaje, a diferencia del requerimiento de producto, que es una necesidad del software resultante. (SWEBOK V3.0, Software Requirements Knowledge Area, 1.2 Product and Process Requirements)

20. ¿Por qué es importante que los requerimientos no funcionales se expresen de forma cuantitativa mediante métricas?

1. Porque de esa manera se transforman automáticamente en requerimientos funcionales del sistema construido
2. Porque solo así es posible incluirlos en los requerimientos de usuario redactados en lenguaje natural
3. Porque es la única manera de derivarlos del dominio de aplicación en el que opera el sistema
4. Porque permiten verificar de forma objetiva su cumplimiento, p. ej. en transacciones por segundo o tasa de fallas

Expresar los requerimientos no funcionales con métricas cuantificables, como transacciones por segundo o tasa de fallas, permite verificar objetivamente si el sistema los cumple, en lugar de dejarlos como afirmaciones subjetivas. (Ian Sommerville, Ingeniería de Software, tabla de métricas para requerimientos no funcionales)

21. ¿Cuántas características de calidad define el modelo de calidad del producto de ISO/IEC 25010:2011 como base de los requerimientos no funcionales?

1. Ocho: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad
2. Seis: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad
3. Cuatro: rendimiento, seguridad, usabilidad y portabilidad
4. Nueve: adecuación funcional, desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad, portabilidad y escalabilidad

La norma ISO/IEC 25010:2011 define ocho características de calidad del producto; la opción 1 corresponde en realidad al modelo anterior ISO/IEC 9126, con seis características. (ISO/IEC 25010:2011, Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models)

22. Según Karl Wiegers, ¿qué describen los requerimientos de negocio dentro de un proyecto de software?

1. Las limitaciones impuestas al diseño, como el lenguaje de programación o la plataforma obligatoria
2. Los objetivos de alto nivel de la organización o del cliente y el beneficio esperado del sistema
3. Las funciones específicas que el sistema debe ejecutar ante cada entrada del usuario
4. Las restricciones de rendimiento y fiabilidad que debe cumplir el software en producción

Wiegers describe a los requerimientos de negocio como los objetivos de alto nivel de la organización o del cliente y el beneficio esperado del sistema, es decir, responden al 'porqué' del proyecto, por encima de los requerimientos de usuario y del sistema. (Karl Wiegers, Software Requirements (Microsoft Press), cap. Tipos de requisitos)

23. Un cliente indica que el nuevo sistema debe construirse utilizando la plataforma de nube que la empresa ya tiene contratada. ¿Cómo se clasifica este tipo de enunciado dentro de la ingeniería de requerimientos?

1. Como un requerimiento funcional, ya que especifica un servicio concreto que el sistema debe prestar al usuario
2. Como un requerimiento de usuario, ya que se redacta en lenguaje natural, sin diagramas ni detalle técnico
3. Como una restricción (constraint), ya que limita las opciones de diseño o implementación sin describir una función
4. Como un requerimiento del dominio, ya que refleja una característica propia del área de aplicación del sistema

Exigir el uso de una plataforma de nube específica no describe una función del sistema, sino que limita las opciones de diseño o implementación de la solución, lo que corresponde a la definición de restricción (constraint). (Karl Wiegers, Software Requirements; ISO/IEC/IEEE 29148, definición de constraint)

24. ¿Cuántas características de calidad conforman el modelo de calidad de producto establecido por la norma ISO/IEC 25010:2011, utilizado como base para especificar requerimientos no funcionales?

1. Seis características
2. Ocho características
3. Diez características
4. Doce características

ISO/IEC 25010:2011 define ocho características: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. (ISO/IEC 25010:2011, Systems and software Quality Requirements and Evaluation (SQuaRE))

25. Dentro del modelo de calidad ISO/IEC 25010, ¿qué característica se refiere a la facilidad con la que un producto de software puede ser modificado, corregido o adaptado sin introducir defectos nuevos?

1. Usabilidad
2. Mantenibilidad
3. Portabilidad
4. Fiabilidad

La mantenibilidad agrupa la capacidad de análisis, de modificación y de prueba del software; la usabilidad se refiere a la facilidad de uso, no a la facilidad de modificar el código. (ISO/IEC 25010:2011, característica Mantenibilidad.)

26. Un analista especifica que 'un usuario sin experiencia previa debe poder completar el proceso de registro en menos de tres minutos sin recibir ayuda externa.' Este requerimiento pertenece principalmente al atributo de calidad de:

1. Mantenibilidad
2. Seguridad
3. Usabilidad
4. Desempeño

La facilidad de aprendizaje y de uso sin asistencia es una métrica típica de usabilidad; aunque se menciona un tiempo, lo que se evalúa es la curva de aprendizaje del usuario y no la velocidad de procesamiento del sistema. (Ian Sommerville, Ingeniería de Software, tabla de métricas para requerimientos no funcionales.)

27. Un requerimiento establece: 'El sistema debe procesar un mínimo de 500 transacciones por segundo con un tiempo de respuesta promedio no mayor a 200 milisegundos bajo carga máxima.' Este requerimiento se clasifica como un atributo de calidad de:

1. Fiabilidad
2. Desempeño
3. Portabilidad
4. Mantenibilidad

Las métricas de transacciones por segundo y tiempo de respuesta corresponden a la eficiencia de desempeño; la fiabilidad se mide en términos de disponibilidad o tasa de fallas, no de velocidad de procesamiento. (Ian Sommerville, tabla de métricas (transacciones/segundo); ISO/IEC 25010, eficiencia de desempeño.)

28. De acuerdo con Sommerville, siempre que sea posible los requerimientos no funcionales deben expresarse de forma:

1. Narrativa y descriptiva, sin valores numéricos
2. Cuantitativa y medible mediante métricas verificables
3. Mediante diagramas de flujo, sin texto explicativo
4. Ordenada alfabéticamente por nombre de módulo

Sommerville recomienda cuantificar los requerimientos no funcionales con métricas objetivas, como transacciones por segundo o tasa de fallas, para poder verificarlos objetivamente. (Ian Sommerville, tabla de métricas para requerimientos no funcionales.)

29. Una empresa exige que, ante un defecto identificado en el módulo de cálculo de impuestos de su sistema de nómina, un programador pueda corregirlo en un máximo de cuatro horas hábiles sin afectar otros módulos. Este requerimiento corresponde al atributo de calidad de:

1. Portabilidad
2. Usabilidad
3. Mantenibilidad
4. Seguridad

La rapidez y el aislamiento con que puede corregirse un defecto son indicadores de mantenibilidad, específicamente de la capacidad de análisis y de modificación del software. (ISO/IEC 25010:2011, característica Mantenibilidad.)

30. ¿Cuál de las siguientes opciones NO es un atributo de calidad considerado por el modelo de calidad de producto de la norma ISO/IEC 25010?

1. Portabilidad
2. Seguridad
3. Trazabilidad
4. Usabilidad

La trazabilidad es una característica de una buena especificación de requerimientos según IEEE 830, no un atributo de calidad del producto; ISO/IEC 25010 sí incluye portabilidad, seguridad y usabilidad. (ISO/IEC 25010:2011 vs. IEEE Std 830-1998, sección 4.3.)

31. En la clasificación de Sommerville, los atributos de rendimiento, fiabilidad, usabilidad, eficiencia y portabilidad forman parte del grupo de requerimientos no funcionales denominado:

1. Requerimientos organizacionales
2. Requerimientos de producto
3. Requerimientos externos
4. Requerimientos de dominio

Sommerville agrupa estos atributos como requerimientos de producto, pues especifican o restringen el comportamiento en ejecución del software; los organizacionales derivan de políticas y los externos de factores fuera del sistema. (Ian Sommerville, clasificación de requerimientos no funcionales.)

32. 'El sistema debe desarrollarse utilizando exclusivamente el motor de base de datos PostgreSQL, por política tecnológica de la organización.' Este enunciado se clasifica principalmente como:

1. Un atributo de calidad de desempeño
2. Una restricción de diseño (constraint)
3. Un requerimiento de interfaz externa
4. Un atributo de calidad de seguridad

Una restricción limita las opciones de diseño o implementación, como el motor de base de datos obligatorio, sin describir una función ni un atributo de calidad medible del sistema. (Karl Wiegers, Software Requirements; ISO/IEC/IEEE 29148, definición de constraint.)

33. Un requerimiento indica que 'el sistema debe verificar la identidad del usuario mediante autenticación de dos factores, cifrar las comunicaciones con el protocolo TLS 1.2 o superior, y bloquear la cuenta tras cinco intentos fallidos de inicio de sesión.' Estas tres condiciones en conjunto corresponden principalmente al atributo de calidad de:

1. Mantenibilidad
2. Seguridad
3. Usabilidad
4. Desempeño

La autenticación robusta, el cifrado de comunicaciones y el bloqueo de cuentas son mecanismos de protección contra accesos no autorizados, característicos del atributo de seguridad. (ISO/IEC 25010:2011, característica Seguridad.)

34. Dentro de la sección de requerimientos de interfaz externa de una Especificación de Requerimientos de Software (SRS) basada en IEEE 830, ¿cuál de las siguientes es una de las cuatro subcategorías reconocidas por el estándar?

1. Interfaces de desempeño
2. Interfaces de hardware
3. Interfaces de negocio
4. Interfaces de calidad

IEEE 830 divide los requerimientos de interfaz externa en interfaces de usuario, de hardware, de software y de comunicaciones; el desempeño, el negocio y la calidad se documentan en otras secciones de la SRS. (IEEE Std 830-1998, sección 3.1 Requerimientos de interfaces externas.)

35. Los requerimientos de interfaz externa de un sistema de software describen principalmente:

1. Los objetivos estratégicos y el beneficio esperado por la organización solicitante
2. La manera en que el sistema se conecta con usuarios, hardware, software y redes externas
3. Las políticas internas de desarrollo y codificación del equipo de programación
4. Las normas éticas y sociales que el sistema debe respetar durante su operación

Estos requerimientos especifican cómo el software intercambia información con elementos externos al propio sistema; los objetivos estratégicos corresponden a requerimientos de negocio y las normas éticas a requerimientos externos regulatorios. (IEEE Std 830-1998, sección 3.1.)