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.
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Introduce los conceptos de requerimientos del usuario y del sistema. Asimismo describe los requerimientos funcionales y no funcionales, y explica la organización del documento de requerimientos de software. Está basado en Sommerville 7ma. Edición.
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.
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Introduce los conceptos de requerimientos del usuario y del sistema. Asimismo describe los requerimientos funcionales y no funcionales, y explica la organización del documento de requerimientos de software. Está basado en Sommerville 7ma. Edición.
Tema N° 14 Especificación de Requisitos del SoftwareSaraEAlcntaraR
Tema N° 14 Especificación de Requisitos del Software correspondiente a la Unidad IV.- Especificación de los Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Similar a IEEE 830 1998: Software Requirements Specification (Especificación de requisitos de software) (20)
Los sistemas de planificación de recursos empresariales ('ERP', por sus siglas en inglés, enterprise resource planning) son los sistemas de información gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía en la producción de bienes o servicios.
IEEE 829 2008:Software and System Test DocumentationJesús Navarro
Documento basado en el estándar 829 2008 donde se establecen las pruebas de caja blanca (Whitebox) y caja negra (Blackbox) para el código fuente y la interfaz gráfica de los sistemas informáticos.
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
En esta charla, nos sumergiremos en los desafíos emergentes que la inteligencia artificial (IA) y los Large Language Models (LLMs) traen al mundo de la calidad del software y el testing. Exploraremos cómo la integración, uso o diseño de modelos de IA plantean nuevos retos, incluyendo la calidad de datos y detección de sesgos, sumando la complejidad de probar algo no determinístico. Revisaremos algunas propuestas que se están llevando adelante para ajustar nuestras tareas de testing al desarrollo de este tipo de sistemas, incluyendo enfoques de pruebas automatizadas y observabilidad.
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
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
2. SRS iAccess
1
Índice General
1. Introducción
1.1 Propósito
1.2 Ámbito del Sistema.
1.3 Definiciones,Acrónimos y Abreviaturas.
1.4 Referencias
1.5 Visión General del Documento
2. Descripción General
2.1 Perspectivadel Producto
2.2 Funciones del Producto
2.3 Características de los Usuarios
2.4 Restricciones
2.5 Suposicionesy dependencias
2.6 Requerimientos futuros
3. RequerimientosEspecíficos
3.1 Interfaz
3.2 Requisitos Funcionales
3.3 Requerimientos No Funcionales
3.4 Otros Requisitos
4. Apéndices
3. SRS iAccess
2
1. Introducción
Este documento es una Especificaciónde Requisitos Software (ERS)
para el sistema iAccess. Esta especificación se ha estructurado
basándose en las directrices dadas por el estándar IEEE “Practica
Recomendada para Especificaciones de Requisitos Software IEEE
830, 1998”.
1.1 Propósito
El presente documento tiene como propósito definir las
especificaciones de un sistema de información que gestiona por
medio de credenciales inteligentes el acceso a planteles
universitarios, préstamo de libros en biblioteca y toma de asistencia.
1.2Alcance
Esta especificación de requisitos está dirigida al usuario del sistema,
para continuar con el desarrollo de sistemas basado en esta
tecnología.
1.3 Definiciones, Acrónimos y Abreviaturas.
• BD – Bases de datos
• UML– Lenguaje de Modelado Unificado
• IEEE – Institute of Electrical and Electronics Engineers
1.4 Referencias
Protocolos de la W3C.
http://www.w3.org/standards/webarch/protocols
PDF
Especificación de requerimientos de software IEEE/830
1.5 Visión General del Documento
Dar una descripción general sobre el sistema, el cual contiene
información necesaria para saber el funcionamiento del proyecto, en
el cual se especifican los requisitos, diagramas UML, diseño,
aplicación y los beneficios que se tendrán.
4. SRS iAccess
3
2. Descripción General
2.1 Perspectiva del Producto
El sistema iAccess será un producto diseñado para trabajar en
entornos escolares en una plataforma basada en aplicación de
escritorio, lo que permitirá su instalación en los computadores con los
que cuenta la institución.
2.2 Funciones del Producto
Diagrama de casos de uso general
2.3 Características de los Usuarios
2.4 Restricciones
Lenguajes y tecnologías en uso: MySQL y Java
Los servidores deberán estar siempre activos
El sistema deberá ser sencillo de usar
2.5 Suposiciones y dependencias
Se asume que los requisitos aquí descritos son estables
Los equipos en los que se vaya a ejecutar el sistema deben
cumplir con los requisitos indicados para garantizar una
ejecución correcta de la misma
Tipo de usuario Administrador
Formación Licenciatura
Actividades Agregar y/o eliminar a los estudiantes del
sistema
Tipo de usuario Estudiante
Formación NA
Actividades Solicitar libros, solicitar acceso a la
institución, solicitud de asistencia a clases
5. SRS iAccess
4
3. Requerimientos Específicos
Requerimientos Funcionales
Identificación del
requerimiento:
ACRF01
Nombre del
requerimiento:
Autentificación del administrador
Características: Los administradores deben de loguearse en el
sistema antes de comenzar a usarlo.
Descripción del
requerimiento:
El sistema cuenta con un login que requiere un
usuario y contraseña para los administradores,
esta credencial es dada por la universidad.
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF02
Nombre del
requerimiento:
Registro de estudiante
Características: Los estudiantes deben estar registrados en el
sistema para poder hacer uso de él.
Descripción del
requerimiento:
El sistema admitirá usuarios de diferentes
licenciaturas, para ello el administrador debe
solicitar su número de matrícula, nombre
completo y licenciatura que cursa.
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF03
Nombre del
requerimiento:
Consulta de datos
Características: El sistema debe ser capaz de consultar datos
desde internet
Descripción del
requerimiento:
Cuando el sistema requiera consultar el
estado o dato del estudiante este debe ser
capaz de conectarse a internet y traer la
información solicitada.
Requerimiento no
funcional:
6. SRS iAccess
5
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF04
Nombre del
requerimiento:
Modificación de datos
Características: Los administradores pueden modificar datos
del estudiante en caso de errores ortográficos
Descripción del
requerimiento:
Cuando se encuentre un error ortográfico en
los datos del estudiante este podrá ser
corregido
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF05
Nombre del
requerimiento:
Alta de estado
Características: Notificar a la base de datos cambio en los
estados del sistema
Descripción del
requerimiento:
Para las diferentes capacidades con las que
cuenta el sistema este es capaz de enviar a la
base de datos un cambio en el estado del
sistema.
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF06
Nombre del
requerimiento:
Interfaz del sistema
Características: El sistema presentara una interfaz de
administrador sencilla de uso
Descripción del
requerimiento:
La experiencia de uso del sistema debe ser
rápida y consistente
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
7. SRS iAccess
6
Identificación del
requerimiento:
ACRF07
Nombre del
requerimiento:
Mantenimiento
Características: El sistema deberá de tener un manual de
instalación y manual de usuario para que el
uso de este sea más sencillo
Descripción del
requerimiento:
El sistema debe disponer con un manual
entregado en formato PDF junto con el disco
de instalación para un correcto uso del mismo.
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
Identificación del
requerimiento:
ACRF08
Nombre del
requerimiento:
Seguridad
Características: El sistema garantiza la seguridad de los datos
Descripción del
requerimiento:
Garantizar la seguridad y el buen manejo de
los datos que se manejan.
Requerimiento no
funcional:
Prioridad del
requerimiento:
Alta
3.1 Requisitos comunes de las interfaces
3.1.1 Interfaces de usuario
La interfaz de usuario consistirá en un conjunto de ventanas
con botones, listas y campos de texto que desplegaran
información necesaria para llevar a cabo las tareas.
3.1.2 Interfaces de hardware
Será necesario disponer de equipos de cómputo con las
siguientes características:
Tarjeta de red
Procesador de 1.20GHz o superior
Memoria interna de 1 Gb
512 Mb de RAM o superior
Teclado
8. SRS iAccess
7
Mouse
3.1.3 Interfaces de software
Sistema operativo: Windows 7 o superior
Java versión 1.6 o superior
3.1.4 Interfaces de comunicación
Los servidores y aplicaciones se comunicarán entre si
continuamente mediante protocolos estándares de internet,
por ejemplo, para dar de alta un usuario se envía una
petición por medio del protocolo TCP/IP.
3.2 Requisitos funcionales
3.2.1 Requisito funcional 1
3.2.2 Requisito funcional 2
3.3 Requisitos no funcionales
3.3.1 Requisitos de rendimiento
Garantizar que el diseño de las consultas y otros
procesos no afecte el desempeño de la base de
datos ni el tráfico de la red.
3.3.2 Seguridad
Garantizar el buen manejo de datos personales
Mantener un cifrado de datos entre la computadora
del administrador y la base de datos
3.3.3 Fiabilidad
El sistema debe tener una interfaz de usuario de
uso intuitiva y sencilla
La interfaz de usuario debe ajustarse
exclusivamente a las necesidades del sistema
3.3.4 Disponibilidad
La disponibilidad del sistema debe ser en horarios
de clase establecidos por la universidad, fuera de
ello el sistema lo registrara como una brecha de
seguridad.
9. SRS iAccess
8
3.3.5 Mantenibilidad
El sistema debe disponer de una documentación
fácilmente actualizable que permita realizar
operaciones de mantenimiento con el menor
esfuerzo posible.
La interfaz de sistema debe de disponer con un
sistema de ayuda en caso de dudas a la hora de
llevar a cabo procesos.
3.3.6 Portabilidad
El sistema será implantado bajo la plataforma
Windows.
4. Apéndices
Diagramas de UML (explicacióngraficadel funcionamientodelsistema).
Caso de Uso