Requerimientos funcionales:
Expresan la naturaleza del funcionamiento del sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su estado y funcionamiento).
Deben estar redactados de tal forma que sean comprensibles para usuarios sin conocimientos técnicos avanzados (de Informática, se entiende), deben especificar el comportamiento externo del sistema y evitar, en la medida de lo posible, establecer características de su diseño, deben priorizarse (al menos, se ha de distinguir entre requisitos obligatorios y requisitos deseables).
Requerimientos no funcionales:
Restricciones sobre el espacio de posibles soluciones. Rendimiento del sistema: Fiabilidad, tiempo de respuesta, disponibilidad… Interfaces: Dispositivos de E/S, usabilidad, interoperabilidad… Proceso de desarrollo: Estándares, herramientas, plazo de entrega…
han de especificarse cuantitativa-mente, siempre que sea posible (para que se pueda verificar su cumplimiento).
Los requisitos funcionales definen qué debe hacer un sistema.
Los requisitos no funcionales definen cómo debe ser el sistema.
Los requerimientos… se suelen especificar en lenguaje natural, se expresan de forma individual (p.ej. esquemáticamente), se organizan de forma jerárquica (a distintos niveles de detalle), a menudo, se numeran (para facilitar su gestión),
Los requerimientos han de ser… claros y concretos (evitando precisiones y ambigüedades) p.ej. Uso de puntos suspensivos, etcétera… concisos (sin rodeos ni figuras retóricas), completos y consistentes,
Los requerimientos han de indicar… lo que se espera que haga el sistema (¿qué?), su justificación (¿por qué ha de ser así? ¿quién lo propuso?) y, en su caso, los criterios de aceptación que sean aplicables (¿como se verifica su cumplimiento?).
- El Alcance
Esto no es otra cosa que definir de forma clara y unívoca el objetivo que se persigue con el proyecto y cuya consecución marcará la finalización con éxito de este. En aquellos proyectos divididos por fases, la definición de los objetivos deberá ser efectuada por fase y para el conjunto del proyecto.
Los módulos promueven la modularidad y el encapsulamiento, pudiendo generar programas complejos de fácil comprensión.
- Módulo
Es un software que agrupa un conjunto de subprogramas y estructuras de datos. Los módulos son unidades que pueden ser compiladas por separado y los hace reusables y permite que múltiples programadores trabajen en diferentes módulos en forma simultánea, produciendo ahorro en los tiempos de desarrollo.
Los módulos promueven la modularidad y el encapsulamiento, pudiendo generar programas complejos de fácil comprensión.
EJEMPLO: REQUERIMIENTOS FUNCIONALES
Matriculación
- La matrícula será realizada de forma interactiva. Se le preguntará al alumno cuál es el plan de estudios en que desea matricularse (pueden ser varios).
- Se podrá generar una copia impresa de la matrícula (sin valor oficial) en el ordenador desde donde se realice el proceso de matriculación.
- Se podrá generar el impreso de pago debidamente cumplimentado.
- Para la matriculación se consultarán los datos del expediente y se realizarán las validaciones necesarias, descritas a continuación…
Pago de matrícula:
- La aplicación generará un impreso para que el alumno realice el pago correspondiente a la matrícula en 1 ó 2 plazos (según las fechas establecidas).
- Si el alumno tiene matrículas de honor de cursos anteriores o disfruta de algún tipo de beca, la aplicación deberá calcular automáticamente los descuentos correspondientes…
Organizados jerárquicamente y desglosados en requisitos individuales
EJEMPLO: REQUERIMIENTOS NO FUNCIONALES
Interfaces
- Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prácticas de la E.T.S. Ingeniería Informática.
- Software: No existe posibilidad de adquirir licencias de software. La aplicación deberá funcionar sobre Oracle.
Los casos de uso
Son muy útiles para explicar el funcionamiento del sistema, priorizar requerimientos cuando el sistema se desarrolla de forma incremental, elaborar manuales de usuario y especificar pruebas de aceptación.
Mejoran la trazabilidad de los requerimientos durante el proceso de desarrollo de software.
Dependiendo de la situación, los casos de uso se pueden especificar con distinto grado de detalle:
Especificación textual de un caso de uso (enumeración de pasos del caso de uso).
Especificación “esencial” de un caso de uso (eliminando todos los detalles no estrictamente necesarios).
Especificación detallada de un caso de uso (utilizando una plantilla para no olvidarnos de nada).
Especificación textual de un caso de uso (1/2)
El profesor ejecuta el programa de consulta de estadísticas.
Actor
|
Profesor
|
Rol
|
Consultar estadísticas
|
- El profesor ejecuta el programa de consulta de estadísticas.
- Se le pide su identificativo (login) y palabra clave de acceso (password).
- El sistema verifica la identificación del usuario.
- Si la identificación es positiva, se presenta una lista con las estadísticas disponibles:
- Nº de alumnos y porcentaje de repetidores de sus asignaturas.
- Clasificación de alumnos por nota en cada asignatura.
Especificación textual de un caso de uso (2/2)
Actor
|
Profesor
|
Rol
|
Consultar estadísticas
|
- Una vez que el profesor ha seleccionado una de las estadísticas, el programa presenta los datos correspondientes a la misma, agrupando la información por asignaturas y, al final, para todas sus asignaturas en conjunto.
- Al profesor se le da la opción de imprimir la estadística.
- Cuando el profesor termina de ver la estadística, se presenta de nuevo la lista de estadísticas disponibles.
- Si no desea ver otra estadística, termina la ejecución de la aplicación.
Especificación esencial de un caso de uso
Consulta de estadísticas
Profesor
|
Sistema
|
El profesor se identifica.
| |
El sistema autentifica al profesor y le ofrece una lista de estadísticas disponibles.
| |
El profesor selecciona una de las opciones disponibles.
| |
El sistema presenta un informe con los datos solicitados.
| |
Si así lo desea, el profesor imprime el informe.
|
Especificación detallada de un caso de uso (1/3)
Nombre
|
Consulta de estadísticas
|
Descripción
|
Se permite a los profesores consultar las estadísticas correspondientes a sus asignaturas
|
Dependencias
|
Autentificación de usuarios
|
Actores
|
Profesor (principal e iniciador)
|
Precondiciones
|
-
|
Postcondiciones
|
-
|
Especificación detallada de un caso de uso (2/3)
Escenario principal Profesor Sistema 1. El profesor se identifica. 2. El sistema autentifica al profesor y le ofrece una lista 29 de estadísticas disponibles. 3. El profesor selecciona una de las opciones. 4. El sistema presenta un informe con los datos solicitados. 5. Si así lo desea, el profesor imprime el informe.
Escenario principal
|
Profesor
|
Sistema
|
1. El profesor se identifica.
| ||
2. El sistema autentifica al profesor y le ofrece una lista de estadísticas disponibles.
| ||
3. El profesor selecciona una de las opciones.
| ||
4. El sistema presenta un informe con los datos solicitados.
| ||
5. Si así lo desea, el profesor imprime el informe.
|
Especificación detallada de un caso de uso (3/3)
Alternativas
|
2. Si, tras un tercer intento, la autentificación no se realiza con éxito, se guarda la incidencia en un registro y se impide volver a acceder a 30 la aplicación desde la misma IP durante 15 minutos.
| |
Observaciones
|
-
| |
Requisitos no funcionales
|
El sistema debe estar preparado para aceptar 100 sesiones simultáneas de profesores consultando sus estadísticas sin degradar su rendimiento más de un 50% con respecto a un usuario único.
| |
Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales
Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:
• ¿Cuál es el proceso básico de la empresa?
• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?
Siempre se debe comenzar con lo básico. Cuando se hacen preguntas y se reciben respuestas, se proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo.
Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:
• ¿Cuál es la finalidad de la actividad dentro de la empresa?
• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?
Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:
• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos
• Bases de datos
• Datos de las bases de datos
Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el sistema; o sea, cuántos tienen relación directa con el proyecto
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño documentados oficial o no oficialmente?. Si los hay, ¿Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, ¿se respetan dichos procedimientos?
• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
• ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?
urls:
imagenes:
https://www.google.com/search?q=Requisitos+Funcionales+y+No+Funcionales+de+un+Sistema+de+informaci%C3%B3n.&client=ubuntu&hs=8C0&channel=fs&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiF-6qoi9bOAhXFdh4KHQwFDz4Q_AUICCgB&biw=1855&bih=985#channel=fs&tbm=isch&q=Requisitos+Funcionales+y+No+Funcionales+&imgrc=_
No hay comentarios:
Publicar un comentario