FASE DE INICIO
Requisitos Funcionales
Requisitos Funcionales
Los requisitos funcionales son declaraciones de los servicios que
prestará el sistema, en la forma en que reaccionará a determinados
insumos. Cuando hablamos de las entradas, no necesariamente hablamos
sólo de las entradas de los usuarios. Pueden ser interacciones con otros
sistemas, respuestas automáticas, procesos predefinidos. En algunos
casos, los requisitos funcionales de los sistemas también establecen
explícitamente lo que el sistema no debe hacer. Es importante recordar
esto: un RF puede ser también una declaración negativa. Siempre y cuando
el resultado de su comportamiento sea una respuesta funcional al
usuario o a otro sistema, es correcto. Y más aún, no sólo es correcto,
sino que es necesario definirlo. Y eso nos lleva al siguiente punto.
Esto es facilmente explicado como el medio de todo lo necesario para ser definido o mostrado de forma automatica para su correcta ejecucion sin problemas teniendo casos en lo que define que no hacer o que hacer para llegar a este fin
Entre los posibles requerimientos funcionales de un sistema, se incluyen:
- Descripciones de los datos a ser ingresados en el sistema.
- Descripciones de las operaciones a ser realizadas por cada pantalla.
- Descripción de los flujos de trabajo realizados por el sistema.
- Descripción de los reportes del sistema y otras salidas.
- Definición de quien puede ingresar datos en el sistema.
- Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean aplicables.
Requisitos No Funcionalesa
Analisis:
Otra forma de muestra para un jefe de proyecto o la vision de un cliente se muestra como estara relacionado y estructurado el trabajo mostrando las operaciones, relaciones y contenidos.
Diagrama de Secuencia
Se
trata de requisitos que no se refieren directamente a las funciones
específicas suministradas por el sistema (características de usuario),
sino a las propiedades del sistema: rendimiento, seguridad,
disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el
sistema, sino de “cómo” lo hace. Alternativamente, definen
restricciones del sistema tales como la capacidad de los dispositivos de
entrada/salida y la representación de los datos utilizados en la
interfaz del sistema.
No hay mejor forma de decirlo si no como previamente esta descrito diciendo que esta seccion se refiere especificamente a como hace las tareas o formas y no que hacen en estos casos.
Requisitos Candidatos
Suelen estar divididos de la siguiente manera:
- Datos
- Procesos
- Procedimiento
- Tecnicas
Modelo de Dominio
El
modelo de dominio puede ser tomado como el punto de partida para el
diseño del sistema. Cuando se realiza la programación orientada a
objetos, el funcionamiento interno del software
va a imitar en alguna medida a la realidad, por lo que el mapa de
conceptos del modelo de dominio constituye una primera versión del
sistema.
Ademas de lo que estaran mostrados a continuacion estan estos:
- Formas de conexion
- Programa
- Tecnicas de programacion
- lenguaje de programacion
Diagrama de casos de uso
Un caso de
uso es una descripción de las acciones de un sistema desde el punto de
vista del usuario. Es una herramienta valiosa dado que es una técnica de
aciertos y errores para obtener los requerimientos del sistema,
justamente desde el punto de vista del usuario.
Los
diagramas de caso de uso modelan la funcionalidad del sistema usando
actores y casos de uso.
Los casos de uso son servicios o funciones
provistas por el sistema para sus usuarios.
Símbolos de los casos de uso
Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del Sistema.
Sistema de Casos de Uso
Caso de uso: Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema.
Casos de Uso
Actor:
Un diagrama de caso de uso contiene los símbolos del actor y del caso
de uso, junto con líneas conectoras. Los actores son similares a las
entidades externas; existen fuera del sistema. El término actor se
refiere a un rol específico de un usuario del sistema.
Actor que inicia el caso de uso
Analisis
En
pocas palabras este decime que hara el sistema pero no como lo hara es
una forma idealizada que plantea la idea de como sera el sistema
permitiendo mostrarselo a el interesado para un posterior correcciones y nuevos resultados
Diagrama de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las
clases que involucran el sistema, las cuales pueden ser asociativas, de
herencia, de uso y de agregación, ya que una clase es una descripción de
conjunto de objetos que comparten los mismos atributos, operaciones,
métodos, relaciones y semántica; mostrando un conjunto de elementos que
son estáticos, como las clases y tipos junto con sus contenidos y
relaciones.
Un diagrama de clases esta compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Analisis:
Otra forma de muestra para un jefe de proyecto o la vision de un cliente se muestra como estara relacionado y estructurado el trabajo mostrando las operaciones, relaciones y contenidos.
Ejemplo:
Diagrama de Secuencia
Un diagrama de secuencia es un tipo de diagrama de interacción porque
describe cómo —y en qué orden— un grupo de objetos funcionan en
conjunto. Tanto los desarrolladores de software como los profesionales
de negocios usan estos diagramas para comprender los requisitos de un
sistema nuevo o documentar un proceso existente. A los diagramas de
secuencia en ocasiones se los conoce como diagramas de eventos o
escenarios de eventos.
Analisis:
Este
es un Modelo Nos muestra el funcionamiento completo del software y como
se desarrollara segun sus funciones atributos y requisitos permite
tener una idea clara de todo el proceso existente y documentarlo para
ser mostrado en una grafica modulada sencilla un ejemplo sera mostrado a
continuacion
Modelo de Analisis
El modelo de
análisis es la primera representación técnica de un sistema. Utiliza una
mezcla de formatos en texto y diagramas para representar los requisitos
del software, las funciones y el comportamiento. De esta manera se hace
mucho más fácil de comprender dicha representación, ya que es posible
examinar los requisitos desde diferentes puntos de vista aumentando la
probabilidad de encontrar errores, de que surjan debilidades y de que se
descubran descuidos.
Análisis de requisitos
El análisis de
requisitos le proporciona al diseñador de software una representación de
datos, función y comportamiento que puede trasladar a diseños
arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece
al desarrollador y al cliente los medios para evaluar la calidad una vez
construido el software.
Objetivos generales del modelo de análisis
El modelo de análisis debe cumplir tres objetivos primarios:
- Describir los que requiere el cliente
- Establecer una base para la creación de un diseño de software
- Definir un conjunto de requisitos que pueda validarse una vez construido el software.
1.2 ELEMENTOS DEL MODELO DE ANÁLISIS
El modelo de análisis se
complementa de cuatro elementos fundamentales. Estos elementos sirven
para clasificar principalmente los diferentes diagramas y otros
derivados conocidos en plataformas como sistemas de información e
ingeniería de software entre otros. Además estos con clasificados en
elementos de escenario, elementos de flujo, elementos de clases y
elementos de comportamiento.