UNIDAD II REQUERIMIENTOS FUNCIONALES

Republica Bolivariana de Venezuela.

Maracaibo-zulia

Angela Gonzalez. C.I.: 14.832071

Seccion: 33H

Requerimientos funcionales y no funcionales

1.1. Requerimientos funcionales

 Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente.

Ejemplos de requerimientos funcionales

REGISTRO

· Los registros deben hacerse de forma interactiva. Se le preguntara al paciente sus datos personales, su antecedentes médicos entre otros.

· Se realiza historia la cual será guardada en la base de datos, y a su vez en una copia de seguridad alternativa.

· Luego de la asistencia medica obtener un registro impreso que contenga los datos y las indicaciones del medico al.

· Para el sistema es de gran importancia que los datos registrados puedan ser editados, eliminados en el momento requerido (luego de la consulta o censos),

1.2. Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, y otros 

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

Ejemplos de requerimientos NO funcionales

Interfaces

· Software: No existe posibilidad de adquirir software. La aplicación deberá funcionar sobre una plataforma que permita su funcionamiento correcto.

· El software de ser comprado debe ser determinado si es factible económicamente.

· El software debe ser realizado en un tiempo predeterminado (por el cliente)

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

1.2.1. Requerimientos del producto

Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. • Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.

Ejemplo:

Se determina los requerimientos mínimos que se necesitan para el funcionamiento del sistema:

ü Se debe tener un equipo con un sistema operativo Windows X-p, Vista.

ü Con una memoria RAM de 512.

ü Un disco duro de 160 GB.

ü Visual Basic 6.0.

ü MySql.

ü El sistema será entregado en el lapso de 1 año (18/01/2010-18/01/2011).

2. Requerimientos del dominio

Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.

Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares.

3. Requerimientos del usuario y del sistema

3.1. Requerimientos del usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.

Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado.

Y muchos de los casos hay problemas ya que falta de claridad, confusión de requerimientos y conjunción de requerimientos.

Ejemplo: al momento de la entrevista se observa que el solicita los requerimiento de un forma coloquial nada explicito como:

*Deseo que el sistema permita guardar, modificar y eliminar de ser necesario los datos personales.

*Que tenga la opción de imprimir los registro con las indicaciones especificadas.

3.2. Los requerimientos del sistema

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.

Ejemplo:

*Los requerimientos solicitados por el cliente deben ser pasados en limpio ya que es como un contrato entre el diseñador y cliente es te puede ser presentado por medio de flujo de dato.

4. Lenguaje o notación usada en la especificación de requerimientos.

El lenguaje o notación usada para la especificación de requerimientos por excelencia es el UML (Lenguaje de modelado unificado), específicamente los diagramas de caso de uso, estados y actividades, estos dos últimos describen en detalles los usos del sistema establecidos.

4.1. Diagrama de caso de uso.

Los diagramas de Casos de Uso describen o especifican lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que el cómo.

Asistencia al CentroMedico Barrio Adentro

Ejemplo:

Fig. No. 1 Diagrama de Casos de Uso nivel 1

En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempeñan.

Un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo:

Fig. No. 2: Diagrama Casos de Uso nivel 2 A

“Paciente ingresa los datos personales luego los antecedentes médicos, y registra si es alérgico a algún tipo de medicamento y por ultimo se guarda la Información.”

Fig. No. 3: Diagrama Casos de Uso nivel 2 B

“medico al llegar el paciente lo consulta, busca su registro, Llena la consulta con lo malestares del paciente, se llena el informe con las indicaciones a seguir y se imprime el mismo.”

Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una separación entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos.

Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramente gráfico.

Fig. No. 4: Diagrama Casos de Uso nivel 1 detallado

“El Medico consultar al paciente. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera consiste en Llenar registra los datos del paciente. Una vez llenado el registro procede a la consulta, busca la historia, toma los datos de la nueva consulta, da un diagnostico llena el formulario de diagnostico e imprime.

4.2. Diagrama de Estados y Diagrama de Actividades

Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado, en los usos establecidos para el sistema. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición dentro de los usos.

Las transiciones son las líneas que unen los diferentes estados. En ellas se representa la condición que provoca el cambio, seguida de la acción oportuna separada por “/”. En un estado en que el objeto esta pendiente de algún tipo de validación que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado de éste. En estos casos es conveniente, por claridad, incluir la condición que de la que depende la transición (entre corchetes).

Ejemplo:

Notación textual de los requerimientos

Ejemplo:

RESUMEN DE ESPECIFICACIÓN FUNCIONAL
Uso	Registro de Historias Medicas del Paciente
ID	RFP001
Descripción	A través de este caso de uso, el sistema le permite al Promotor de SAlud registrar los pacientes en el sistema.
Entrada	NOMBRE PRINCIPAL (Obligatorio) NOMBRE SECUNDARIO APELLIDO PRINCIPAL (Obligatorio) APELLIDO SECUNDARIO CEDULA DE IDENTIDAD (Obligatorio) TELÉFONO CELULAR TELÉFONO DE HABITACIÓN (Obligatorio ) DIRECCIÓN (Obligatorio) FOTO (Opcional) o Correo electrónico Correo electrónico. o Clave suministrado (Obligatorio) o Antecedentes médicos. (Obligatorio) o Alergia a Medicamento. (Obligatorio) o Tipo de Sangre. (Obligatorio)
Salida	Impresión de Estadísticas y clave inicial Mensaje de excepciones
Excepciones	E-1 En blanco cualquier campo obligatorio. E-2 Usuario existente o registrado en la Base de Datos. E-3 Clave suministrada errada. E-4 Campos Nombres y Apellidos con números.