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.

UNIDAD I REQUERIMIENTOS

REPUBLICA BOLIVARIANA DE VENEZUELA

INSTITUTO UNIVERSITARIO TECNOLOGICO DE MARACAIBO

MARACAIBO-ZULIA.

REQUERIMIENTOS.

NOMBRE: Angela GONZALEZ.

C.I.: 14832071

SECCION: 33 H

REQUERIMIENTOS

1.- Requerimiento.

Es un atributo o características necesarias dentro de un sistema, ya que por medio de estos, permite saber que desea el cliente. Existen dos tipos de requerimientos:

Ø Los indicados: son aquellos que da el usuario al momento de realizar la entrevista para la realización del sistema.

Ø Los reales: son los que al final de un sistema cubren las necesidades del usuario.

Los requerimiento debe ser especificado por escrito, en el momento de la entrevista ambas partes estén de acuerdo con dichos requerimientos deben ser conciso y completo, para poder entender lo que se desea sin tener que ampliar su redacción y no halla contradicción, de esta manera ser consistente, que no sea ambiguo, debe ser posible verificar los requerimientos para poder verificar si cumple o no con lo impuesto, al momento de las pruebas del sistema.

Ejemplo:

Al momento de diseñar un sistema se debe conversar con el cliente para que el exponga sus ideas, con respecto a lo que desea que haga su sistema, estas deben ser lo mas claras y precisas de hecho el diseñador esta atento para ayudar a expresar lo que se debe hacer, se transcriben para llevar un control.

Esta información no es más que los requerimientos del sistema a realizar.

2.- Ingeniería de requerimientos.

Es el proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema. Tiene la finalidad de entregar una especificación de requisitos de software correcta y completa.

Este permite definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software determinado, aquí se debe tomar en cuenta la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), luego realizar un subproceso de obtención y análisis de requerimientos, su especificación formal, para finalizar la validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

Ejemplo:

Luego de tener la información del cliente sobre el sistema, esta información, es analizada, verifica si es factible, se le realizan correcciones o agregan requerimientos si se considera necesario para el sistema, estas deben ser tomadas en conjunto con el cliente para mantener una comunicación clara y evitar inconvenientes mas adelante.

3.-Importancia de la ingeniería de requerimientos.

La ingeniería de requerimientos es de gran importancia al momento de realizar un software ya que:

*Permite gestionar las necesidades del proyecto en forma estructurada ya que cada actividades una serie de pasaos bien definidos y organizados.

*Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, la estimación de costos, tiempo y recursos necesarios.

· Disminuye los costos y retrasos del proyecto: el hecho de tener claro lo que se desea evita un gran margen de error por lo tanto se ahorra tiempo al momentos de corregirlos y económicamente es mucho más factible.

· Mejora la calidad del software: se mejora la calidad ya que permite cumplir con los requerimientos ya expuestos tales como la funcionalidad, factibilidad de uso, entre otros.

· Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

· Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Ejemplo:

Al manejar la información del sistema concreta del sistema a desarrollar permite al desarrollador realizar un trabajo de manera eficiente y más rápida ya que su idea es clara y al tener un margen de error más pequeño evita la perdida de tiempo y dinero.

En ello radica la gran importancia de la ingeniería de requerimientos

4.-Actividades de la ingeniería de requerimientos (Ejemplos).

Para completar el proceso de ingeniería de requerimiento se requiere llevar a cabo diversas actividades:

v Extracción (Análisis del problema)

En esta fase los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que debe prestar, las restricciones que se pueden presentar y otros. Es importante, es de gran importancia que esta sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente.

v Análisis (Evaluación y negociación de los requerimientos)

Basándose en la información que se tiene de la fase de la extracción realizada previamente, se enfoca el análisis para captar los problemas del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; se leen detenidamente los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimien

Especificación

Por medio de esta fase se documentan detalladamente los requerimientos acordados con el cliente. Se trata de transcribir el análisis anteriormente realizado utilizando técnicas y/o estándares de documentación, como la notación UML .

v Validación

Es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, en otras palabras, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, Esto implica verificar que los requerimientos sean consistentes y que estén completos.

v Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones. Las más frecuentes son:

· Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.

· Porque cambió el problema que se estaba resolviendo.

· Porque los usuarios cambiaron su forma de pensar o sus percepciones.

· Porque cambió el ambiente de negocios.

· Porque cambió el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular

Ejemplo:

Como ya se menciono anteriormente para poder tener claro los requerimientos se deben realizar las siguientes actividades.

ü Extracción (Análisis del problema)

Se realiza en primera estancia entrevista al cliente el cual suministra la información de que desea que realice el sistema incluyendo sus restricciones estas son transcripta para ser utilizado como apoyo para el desarrollador.

ü Análisis (Evaluación y negociación de los requerimientos)

EL desarrollador la información ya recopilada analiza dicha información buscando verificar su factibilidad, las posibles nuevas opciones y hasta los errores que puede arrojar.

ü Especificación

Los resultados del análisis se discuten con el cliente llegando a un acuerdo, se trascribe toda la información de manera organizada utilizando técnicas y estándar con algún tipo de lenguaje adecuado

ü Validación

La información ya organizada se verifica par ratificar que cumpla con los requerimientos solicitado y no falte nada, de ser así se agregan o eliminan procesos dependiendo de cual sea la necesidad.

ü Evolución de los requerimientos

En esta fase se desarrolla el sistema, es recomendable en esta actividad guardar todo lo referente a los códigos de programación e interfases graficas, ya que a medida del desarrollo surgen diversas modificaciones dados, por el cliente, por errores arrojados por el sistema o por las necesidades del mismo.

5.-Técnicas y herramientas en la Ingeniería de requerimientos, ejemplos de sus usos, ventajas y desventajas

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios es una técnica que se utiliza para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido.

Lluvia de ideas (Brainstorm)

Este es un modelo que se usa para generar ideas. Las reglas básicas a seguir son:

· Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.

· Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas.

· Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.

· A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.

· Escribir las ideas sin censura.

Prototipos

Para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas).

Casos de Uso

Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas.

Ejemplo:

ü Las entrevistas se utiliza con gran prioridad en un principio es de gran importancia ya que por medio de ella se obtienen los requerimientos del sistema

Su gran ventaja es que nos permite recolectar toda la información indispensable para es sistema.

Su desventaja radica que al momento de hacerse se debe realizar de una manera concisa para que no se preste a confusiones mas adelante.

ü Los sistemas existentes pueden ser utilizados luego de tener la información sobre el sistema para ubicar uno parecido y poder utilizarse como guía, como los que son permitidos observar en las hemerotecas.

Su ventaja radica en que ya estos existen y pueden ser de gran ayuda para guiarse.

Su desventaja es que se debe estar claro en que los requerimientos lo mas seguro es que sean parecido, y es para ser utilizado como guía mas no como copia exacta lo cual nos puede traer contratiempo.

ü Lluvia de ideas esta técnica se utiliza en conjunto de entrevistas a una muestra de la población que utilizara el sistema ya que las ideas son diversas,

Su ventaja es que la cantidad de ideas es bastante grande por lo tanto salen a resaltar ideas que tal ves no habían salido a relucir y fuesen de gran importancia.

Su desventaja es que se utiliza un poco mas de tiempo para la recolección de ideas y luego deben ser analizada para desechar las que no sean de interés.

Prototipos los realizamos antes del desarrollo del sistema para que el usuario tenga una idea del sistema.

Su ventaja es que por medio de este prototipo el cliente observa si lo que se esta realizando