El documento clasifica y proporciona ejemplos de diferentes tipos de requisitos no funcionales, incluidos los requisitos de producto, organización y externos. Explica que los requisitos no funcionales definen cómo debe comportarse el sistema y cubren áreas como rendimiento, seguridad, fiabilidad y más. Además, proporciona ejemplos específicos de requisitos no funcionales para un sistema de administración de registros.
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
UTN - FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad I. Craig Larman. Primeros Artefactos de Análisis. Análisis de los Requerimientos. Casos de Uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
UTN - FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad I. Craig Larman. Primeros Artefactos de Análisis. Análisis de los Requerimientos. Casos de Uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
Luego de haber estudiado los tipos de vulnerabilidades más comunes, las herramientas usadas para proteger los datos, y haber generado sus procedimientos, está listo para generar la “carta magna” de la seguridad de la red: El manual de procedimientos
Administración potente y escalable para redes, aplicaciones y entornos en la nube:
Gestión de rendimiento de red
Detectar fallas de la red en tiempo real, solucionar errores y prevenir el tiempo de inactividad
Optimizar el uso de ancho de banda de más de un millón de interfaces en todo el mundo
Administración de conformidad, configuración,cambios de red (NCCCM) de múltiples proveedores para switches, routers, firewalls, y otros dispositivos de red
Soporte de monitoreo incorporado para más de 100 aplicaciones y servidores
Mantenimiento y mejora continua de la performance de las aplicacionesAbstracta
¿Cómo se puede garantizar que la performance de los sistemas no empeore con el transcurso del tiempo? Si un sistema hoy responde rápidamente, ¿eso garantiza que seguirá siendo así en el futuro?
De la misma forma que los sistemas, sus funcionalidades, el hardware, drivers, y sistemas operativos que les dan soporte van cambiando, también lo hace la carga sobre el sistema. La carga, entendida como la cantidad de usuarios que accede al sistema, la forma en que los usuarios ejecutan las funcionalidades, y el volumen de datos que debe ser procesado por las solicitudes del negocio son todos ejemplos de elementos que van cambiando durante la vida de una aplicación informática.
A medida que el contexto va cambiando, el sistema debe adaptarse para mantener la calidad de la performance en las respuestas a sus usuarios.
Luego que un sistema es puesto en producción comienza la etapa de mantenimiento. Para que el mantenimiento sea menor, se pueden realizar pruebas funcionales y no funcionales, con el objetivo de anticiparse a situaciones que ocurrirán en producción. La etapa de mantenimiento se caracteriza por ser tan larga cómo la vida del sistema. En esta etapa es donde ocurren todas esas situaciones inesperadas y todos los cambios en el ambiente a los que debemos adaptarnos.
Es importante entonces mantener una permanente monitorización sobre los componentes del sistema con el objetivo de detectar problemas rápidamente y adaptar lo que sea necesario para solucionarlos.
Monitorización y revisión de los tiempos de respuesta en los access logs de los servidores web y servidores de aplicaciones. Uso de los recursos (CPU, memoria, acceso a disco). Crecimiento de las tablas en la base de datos. Estos son algunos pocos ejemplos de indicadores que pueden ser monitorizados para conocer el sistema e identificar problemas.
En esta charla veremos metodología, buenas prácticas, herramientas útiles y ejemplos para mantener y mejorar la performance durante la vida de los sistemas informáticos.
Esta charla fue expuesta por Simon de Uvarow en el marco del Encuentro Internacional GeneXus 2014, #GX24
Detalla los conceptos de interfaces , métodos abstractos, atributos de una interfaz, métodos por defecto, métodos státicos en una interfaz, la herencia entre interfaces
Detalla los conceptos de elicitación de requisito y detalla las principales técnicas de elicitación como la entrevista, encuestas, brainstorm, jad, focus group, análisis de documentos, análisis de sistemas existentes, observación, prototipo
Detalla los conceptos fundamentales de los sistemas distribuidos. Además detalla los elementos las caracterísitcas y los modelos de comunicación existentes
El modelo C4 se creó como una forma de ayudar a los equipos de desarrollo de software a describir y comunicar la arquitectura de software, tanto durante las sesiones de diseño iniciales como cuando se documenta retrospectivamente una base de código existente. Es una forma de crear mapas de su código, en varios niveles de detalle, de la misma manera que usaría algo como Google Maps para acercar y alejar un área que le interesa.
El objetivo de este capítulo es introducir un enfoque de diseno de software en el que el diseño se representa como objetos que interactúan. Cuando termine de leer este capítulo:
• conocerá cómo se representa un diseño de software como un conjunto de objetos que interactúan entre sí y que administran su propio estado y operaciones;
• conocerá las actividades más importantes en un proceso general de diseño orientado a objetos;
• comprenderá los diversos modelos que se utilizan para documentar diseño orientado a objetos;
• habrá sido introducido en la representación de estos modelos en el Lenguaje Unificado de Modelado (UML).
Tiempo, causalidad y estado global Alberto Lafuente TeorìaRene Guaman-Quinche
Documento del PhD. Alberto Lafuente donde trata los relojes físicos y lógicos con sus algoritmos de sincronización. Algoritmos de cristian, berkeley, lamport, relojes vectoriales, candy lamport
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
2. Requisitos No Funcionales
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Junio, 2021
Loja, Ecuador
3. 3
1. Clasificación de Requisitos No funcionales
1.1. Producto
1.2. Orgnización
1.3. Externos
1.4. Ejemplos
2. Tipos
Agenda
4. 4
Clasificación de Requisitos No funcionales
Requisitos de producto:
espeficican el comportamiento del
producto
Tiempos de respuestas, memoria
requerida, fiabilidad, portabilidad,
usabilidad
Requisitos de organización: se
derivan de las políticas y
procedimientos existentes en la
organización del cliente y en la del
desarrollador
Estándares de procesos, lenguajes de
programación, métodos de diseño,
estándares de documentación
Requisitos externos: factores externos al sistema y de su proceso
de desarrollo
Interoperabilidad, éticos, legilastivos, privacidad, seguridad
5. 5
Clasificación de Requisitos No funcionales
“El máximo espacio de almacenamiento ocupado por el sistema debe ser de 8 MB
porque el sistema debe alojarse completamente en una memoria de solo lectura e
instalarse en el coche”
Requisito de producto que define una restricción en el tamaño del producto
“El proceso software y los documentos a realizar deben conformar el proceso y los
estándares de documentación recogidos en la norma TELMo-ES-2003”
Requisito de organización que especifica que el sistema debe desarrollarse de acuerdo a
un proceso estándar dentro de la compañía
“El sistema no debe revelar ninguna información personal sobre los clientes excepto su
nombre y su número de referencia”
Requisito externo se deriva de la necesidad del sistema de cumplir la legislación vigente
sobre protección de datos
7. 7
Ejemplos
De producto
●
Fiabilidad
●
“El servicio A del sistema debe tener una disponibilidad de 99%”
●
Rendimiento
●
“El sistema Y procesará un mínimo de 8 transacciones por segundo”
●
Espacio
●
“El código ejecutable del sistema Z estará limitado a 512 Kb”
●
Portabilidad
●
“El sistema se desarrollará para las plataformas PC y Macintosh”
●
Seguridad
●
“El sistema encriptará todas las comunicaciones externas usando el algoritmo RSA”
8. 8
Ejemplos
De proceso
●
El proceso de desarrollo debe ser conforme con ISO 9003
●
El sistema debe desarrollarse usando la herramienta Visual Pardigm
●
Los informes de Gestión sobre el esfuerzo dedicado a cada componente se deben
generar cada dos semanas
9. 9
Tipos de Requisitos No Funcionales
Los requisitos no funcionales definen cómo debe hacerlo el sistema
Los requisitos no funcionales no especifican la implementación
• Arquitectónico
• Capacidad, energía y pronóstico
• Documentación
• Eficiencia
• Efectividad
• Ambiental
• Tolerancia a fallos
• Privacidad
• Calidad
• Resistencia
• Robustez
• Accesibilidad
• Disponibilidad
• Integridad de los datos
• extensibilidad
• interoperabilidad
• manejabilidad
• Mantenibilidad
• portabilidad
• calidad
• Fiabilidad
• recuperabilidad
• escalabilidad
• seguridad
• Facilidad de servicio
• Estabilidad
• Capacidad de soporte
• Testabilidad
• Usabilidad
10. 10
Tipo Arquitectónico
Su organización puede exigir algunos estándares de arquitectura que su sistema debe
seguir
El sistema será diseñado con un SOA (Service Oriented Architecture)
El sistema será diseñado con una arquitectura basada en microservicios
El sistema deberá seguir la Transferencia de estado representativa (REST)
El sistema deberá seguir la arquitectura de entornos de plataforma operativa común
(COPEs)
11. 11
Tipo Capacidad
Examinará la capacidad de almacenamiento que necesita para su sistema
La Administración de Registros del SGA tendrá una capacidad de 12 Terabytes de datos
12. 12
Tipo Restricciones
Puede haber muchas restricciones en el sistema que se debe abordar
Estas declaraciones son restricciones sobre lo que puede hacer: como restricciones
ambientales o de privacidad, otros pueden ser restricciones arquitectónicas
La Administración de registros requerirá que todos los registros estén en uno de los
siguientes formatos: DOC, DOCX, XLS, XLSX, PPT, PPTX, JPG, or TIFF
13. 13
Tipo Documentación
Son los documentos que ya existen relacionados con un proyecto
La documentación es diferente de un documento que captura todos sus requisitos
¿Existen requisitos específicos para la documentación que forma parte del sistema?
La unidad de registro de firma eletrónica tendrá una guía de usuario impresa que
explica todas las funciones para obtener la firma electrócnica
El Sistema de gestión de registros de la UNL tendrá una guía de usuario en línea que
explica todas las funciones del Sistema de gestión de Académica
14. 14
Tipo Eficacia / Efectividad
Debe definir qué tan buenas son ciertas funciones dentro de su sistema
El Sistema Operativo del Sistema de Gestión de Registros debe ingerir el 100% de los
registros presentados
15. 15
Tipo Tolerancia a Fallas
¿Qué sucede cuando falla una parte del sistema, pero no todo el sistema?
El Sistema de Administración de Registros del SGA tendrá implementadas todas las
funciones de servicios dentro de una arquitectura orientada a servicios para permitir
que el sistema opere en caso de que uno o más servicios fallen
16. 16
Tipo Privacidad
Hay varias situaciones en las que debe considerar los problemas de privacidad
Las personas están legítimamente preocupadas por su información personal
Esta es una consideración comercial crítica dada la preocupación del consumidor sobre
la información de su persona
La Administración de registros del SGA-UNL deberá proteger la privacidad de las
personas identificadas en un registro de acuerdo con las políticas de privacidad del
gobierno
17. 17
Tipo Calidad
Tiene que ver con la calidad de datos que se va obtener de una cualquier fuente
El escaneo de los libros del registros de la propiedad del año 1900 capturará el 75% de
los caracteres de cada acta por página, para ser considerado un escaneo de calidad
18. 18
Tipo Resilience (Resilience) o Recuperación
Define lo que debe preservarse cuando se produce una interrupción del sistema
La Administración de registros del SGA mantendrá todos los registros durante una
interrupción hasta el momento en que se restablezca el sistema.
19. 19
Tipo Robustez
Significa que el sistema no se bloquea fácilmente y es capaz de soportar cambios que
podrían debilitarlo
La función de búsqueda de administración de registros del SGA no hará que el sistema
falle
20. 20
Tipo Ambiental
¿Cuáles son los entornos externos en los que su sistema necesitará operar? ¿Será este un
sistema informático de 24 horas, siete días a la semana?
La Administración de Registros del SGA operará de 6 a.m. a 11 p.m. diariamente de
lunes a viernes.
21. 21
Tipo Integridad de datos
•
Se refiere a mantener y asegurar la precisión y consistencia de los datos durante todo
su ciclo de vida
•
Podría ser la interrupción o pérdida de datos debido a una falla de hardware, como un
problema en un disco duro y falla
•
La integridad de los datos se corrompe cuando no se puede encontrar un registro
porque el puntero dentro de una base de datos pierde su enlace
El Sistema de Administración de Registros del SGA mantendrá la integridad de los
datos al mantener copias de seguridad de todas las actualizaciones de la base de datos
para cada transacción de registros
22. 22
Tipo Normas o Estándares
Puede haber muchos y variados estándares que están regulados en su proyecto o incluso
que su organización grava con usted debido a la política de la compañía. Podría haber
estándares de programación para sus desarrolladores o para estándares arquitectónicos
de la empres
El sistema deberá seguir el Estándar de Interfaz de Usuario Organizacional
23. 23
Tipo Rendimiento
Es la ejecución de una acción.Es la forma en que funciona un mecanismo, por ejemplo,
el rendimiento del motor
Performance Response Time: ¿Qué tan rápido desea que se complete su solicitud, sea
lo que sea?
La función de búsqueda de gestión de registros del SGA devolverá los resultados en 4
segundos, el 80% del tiempo
La función de búsqueda de gestión de registros del SGA devolverá los resultados en 10
segundos, el 90% del tiempo.
24. 24
Tipo Rendimiento
Performance Response Time: ¿Qué tan rápido desea que se complete su solicitud, sea
lo que sea?
La función de búsqueda de gestión de registros del SGA devolverá los resultados dentro
de un minuto, el 99% del tiempo.
La función de búsqueda de gestión de registros del SGA devolverá los resultados dentro
de diez minutos, el 100% del tiempo
La función de búsqueda de gestión de registros del SGA devolverá todos los resultados
de la consulta en menos de diez minutos
25. 25
Tipo Rendimiento
Rendimiento de carga de trabajo: Otro factor que debe tener en cuenta es la carga de
trabajo en el sistema (concurrencia).¿Cuántos usuarios habrá para su sistema?
La función de búsqueda de gestión de registros del SGA tendrá 500 usuarios
La función de búsqueda de gestión de registros del SGA tendrá 40 usuarios
concurrentes promedio
La función de búsqueda de gestión de registros del SGA tendrá 120 usuarios
concurrentes máximos
La función de búsqueda de gestión de registros del SGA devolverá los resultados dentro
de 10 segundos, el 80% del tiempo durante las dos horas pico del día
26. 26
Tipo Rendimiento
Rendimiento de plataforma: Rendimiento de hardware
La impresora de red del SGA imprimirá al menos cien páginas por minuto
El escáner de red del SGA escaneará al menos veinte páginas por minuto a 2400 puntos
por pulgada
27. 27
Tipo Rendimiento
Perfiles de rendimiento: A veces es posible que deba considerar perfiles de
rendimiento que son diferentes entre sí. Por ejemplo, está buscando una red de área
local (LAN) para oficinas de ventas en empresas dispersas por todo el país. Algunas
oficinas son más grandes que otras:
• Las oficinas pequeñas varían de 3 a 6 personas.
• Las oficinas medianas varían de 10 a 26 personas.
• Las oficinas grandes varían de 30 a 56 personas.
28. 28
Tipo Rendimiento
Perfiles de rendimiento:
El servidor de ventas de la red para una pequeña oficina de ventas almacenará 10
megabytes de registros de ventas
El servidor de ventas de la red para una oficina de ventas mediana almacenará 40
megabytes de registros de ventas
El servidor de ventas de la red para una oficina de ventas grande almacenará 100
megabytes de registros de ventas
Throughput: la cantidad de material, datos, etc., que ingresa y pasa por algo (como una
máquina o sistema)
29. 29
Tipo Fiablilidad (Reliability, Availability, and
Maintainability RAM )
La confiabilidad del sistema, componente o lo que sea el elemento significa que no
falla, solo definirá la confiabilidad para todo el sistema y las principales áreas
funcionales (servicios y / o subsistemas)
El sistema SGA estará disponible el 99,99% del tiempo
Se producirá una falla del sistema SGA cuando alguna de las siguientes funciones
críticas no esté funcionando:
• Acceso de seguridad al sistema.
• Búsqueda en la base de datos .
• Agregar registros a la base de datos
• Actualización de registros dentro de la base de datos.
• Eliminar registros de la base de datos
30. 30
Tipo Seguridad
Acceso de Control: aquí especifica cómo las personas obtienen acceso al sistema. Por
lo general, tiene algún tipo de identificación de usuario única (ID de usuario y
contraseña)
El sistema deberá mantener una identificación de usuario única para cada persona que
utilizará el sistema
El sistema deberá mantener una contraseña para cada identificación de usuario única
en el sistema
31. 31
Tipo Seguridad
Acceso de Control
El sistema le permitirá al usuario tres intentos de ingresar su ID de usuario y
contraseña (y seleccionar el dominio, cuando corresponda) antes de que finalice esa
sesión.
Cuando el usuario no pudo ingresar su ID de usuario y contraseña correctamente, el
sistema le permitirá al usuario tres intentos de inicio de sesión después de una hora.
Cuando el usuario no pudo ingresar su ID de usuario y contraseña correctamente, el
sistema solo le permitirá al usuario tres intentos de iniciar sesión nuevamente después
de que un administrador del sistema lo haya autorizado
32. 32
Tipo Seguridad
Acceso de Control
El sistema debe permitir roles que permitan a las personas leer la base de datos
El sistema debe permitir roles que permitan a las personas agregar a la base de datos
El sistema debe permitir roles que permitan a las personas cambiar la base de datos
El sistema debe permitir roles que permitan a las personas eliminar de la base de datos
El sistema debe permitir roles de administrador del sistema
El sistema permitirá a los usuarios tener múltiples roles
El sistema debe permitir roles de administrador del sistema
El sistema debe permitir funciones de monitoreo del sistema
El sistema debe permitir funciones de auditoría del sistema
33. 33
Tipo Seguridad
Importar y exportar al exterior del sistema: debe proteger la información que llega a
su aplicación.
El sistena se asegurará de que todos los datos que se importen al sistema no tengan
virus.
El sistema se asegurará de que todos los usuarios externos al sistema no tengan acceso
a los datos del sistema
34. 34
Tipo Seguridad
Importar y exportar al exterior del sistema:
El sistema proporcionará a los usuarios la capacidad de exportar datos a Microsoft
Excel en formato .xlsx.
El sistema proporcionará a los usuarios la capacidad de exportar datos a Microsoft
Excel en formato .csv.
El sistema proporcionará a los usuarios la capacidad de exportar datos a Microsoft
Word en formato .csv.
El sistema proporcionará a los usuarios la capacidad de exportar datos a Microsoft
Word en formato .docx.
35. 35
Tipo Seguridad
Importar y exportar al exterior del sistema:
El sistema prohibirá la exportación de datos de nómina del Sistema.
El sistema prohibirá que la información de propiedad de la compañía se exporte del
Sistema.
El sistema identificará todos los datos de nómina dentro del Sistema.
El sistema identificará toda la información de propiedad de la compañía dentro del
Sistema.
El sistema prohibirá la exportación de datos del Sistema
36. 36
Tipo Seguridad
Conexiones al exterior del sistema: Es sobre las interfaces con otros sistemas en otros
lugares. Aborda la protección de los datos. Primero, debe abordar la autorización de los
usuarios para mover datos hacia y desde sus sistemas, como en estos ejemplos, incluido
el formato de datos apropiado
El sistema proporcionará a los usuarios la capacidad de exportar datos a CUALQUIER
sistema en formato .csv.
El sistema proporcionará a los usuarios la capacidad de importar datos desde
CUALQUIER sistema en formato .csv.
37. 37
Tipo Seguridad
Conexiones al exterior del sistema:
• El sistema proporcionará CUALQUIER sistema para importar datos en formato .csv
• El sistema proporcionará CUALQUIER sistema para exportar datos en formato .csv
• El sistema proporcionará CUALQUIER sistema para importar datos en el formato
especificado en CUALQUIER formato de interfaz del sistema
• El sistema proporcionará CUALQUIER sistema para exportar datos en el formato
especificado en CUALQUIER formato de interfaz del sistema
38. 38
Tipo Seguridad
Conexiones al exterior del sistema:
El sistema prohibirá la exportación de datos de nómina del Sistema
El sistema no permitirá que los datos de la nómina se exporten desde el Sistema
El sistema consultará libros sobre vikingos pero no sobre el equipo de fútbol americano
de los Minnesota Vikings.
El sistema tendrá un firewall para protegerse de la intrusión de Internet.
El sistema tendrá protección contra virus.
El sistema evitará la captura de pulsaciones de teclas.
El sistema protegerá contra la denegación de servicio (DOS).
39. 39
Tipo Seguridad
Reutilizar: Una vez que haya definido ciertos requisitos de seguridad, en particular el
control de acceso, debería poder reutilizarlos a lo largo de su carrera. Realice los
requisitos de reutilización siempre que pueda
El sistema requerirá que un cliente ingrese su nombre como nombre y apellido.
El sistema requerirá que un cliente ingrese una dirección de correo electrónico.
El sistema requerirá que un cliente ingrese su nombre como nombre y apellido.
El sistema requerirá que un cliente ingrese una dirección de correo electrónico
40. 40
Tipo Escalabilidad
Se refiere a la capacidad de un sistema para escalar (o bajar) a capacidades adicionales
o para permitir el crecimiento. Algunas organizaciones pueden llamarlo extensibilidad
• El sistema podrá almacenar 6 terabytes de datos cuando se implemente
• Los datos del sistema podrán crecer un 24% por año
• El sistema será extensible / escalable
• Los datos del sistema deberán poder agregar cinco servicios por año sin afectar los
requisitos de rendimiento del sistema
42. 42
Tipo Interoperabilidad
Capacidad de un sistema para trabajar o usar las partes o equipos de otro sistema
El sistema seguirá la arquitectura orientada al servicio
El sistem tendrá una capa de comunicaciones con una sola interfaz para todos los
servicios que deben seguir
El sistema requerirá que todos los servicios se comuniquen solo con la capa de
comunicaciones, no con otros servicios
43. 43
Tipo Portabilidad
Es la capacidad de ejecutarse en numerosas plataformas informáticas diferentes
Debe abordar las siguientes preguntas, como mínimo:
¿Se puede ejecutar la aplicación en diferentes sistemas operativos?
¿Puedes migrar los datos a otros sistemas?
¿Sus aplicaciones web funcionarán en diferentes navegadores?
¿Se puede ejecutar la aplicación en diferentes plataformas sin modificaciones
significativas?
El sistema funcionará en Windows 8.
El sistema funcionará en Mac OS X.
El sistema funcionará en la versión 7 de Unix
44. 44
Tipo Portabilidad
Diferentes sistemas
El sistema funcionará en computadoras personales
El sistema funcionará en teléfonos Android
El sistema funcionará en Xbox 360
Diferentes navegadores
El sistema funcionará en Internet Explorer 11
El sistema funcionará en Firefox 29
45. 45
Tipo Soportabilidad
Soportabilidad
Se refiere a "las características inherentes del diseño y la instalación que permiten el
mantenimiento y soporte efectivos y eficientes del sistema durante todo el ciclo de
vida"
Los servicios del sistema serán unidades individuales reemplazables que se pueden
conectar a la infraestructura sin requerir ningún otro servicio en el sistema
46. 46
Tipo Testeabilidad (Testability)
Inicialmente, puede pensar que esto no es algo que especifique en los requisitos, que
esto se captura en la documentación del contrato o en la documentación de
planificación de pruebas. ¿Qué pasa con tener cierta capacidad de prueba integrada en
el hardware y el software?
La función de escaneo de gestión de registros del sistema contendrá registros de
muestra que se utilizarán para la calibración en el escaneo
47. 47
Tipo Recuperabilidad
Esto significa la capacidad de recuperarse de algún evento, por ejemplo, el bloqueo de
un sistema. ¿Qué tan rápido vuelve a las operaciones completas?:
En caso de que el sistema de Gestión de Registros del sistema se bloquee, el sistema
volverá a funcionar por completo en 48 horas desde el comienzo del accidente
En caso de que el sistema de Gestión de Registros del sistema se bloquee, las seis
funciones críticas se devolverán a las operaciones en 4 horas desde el comienzo del
accidente
48. 48
Cŕeditos
Transparencias basadas por:
• George Koelsch, Requirements Writing for System Engineering
• Toni Granollers, Requisitos
http://ocw.udl.cat/enginyeria-i-arquitectura/interaccio-persona-ordinador/
4.-requisitos