ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

El documento de especificación de requerimientos de software consta de las siguientes partes: Documento de especificacion de requerimientos de software


Enviado por   •  19 de Abril de 2018  •  Apuntes  •  1.014 Palabras (5 Páginas)  •  257 Visitas

Página 1 de 5

Especificación de requerimientos de Software

Es un documento formal donde se plasman los requerimientos que desea el cliente tenga un determinado software para cubrir una necesidad del negocio. El documento también refleja los requerimientos no funcionales del software.

Es un documento formal, de carácter obligatorio, a la hora de desarrollar un sistema. Este documento debe ser aprobado por el cliente antes de iniciar el desarrollo del software para evitar ambigüedades en los requerimientos más adelante.

El documento de especificación de requerimientos de software consta de las siguientes partes:

  • Hoja de control

En la hoja de control se especifican: los datos básicos del proyecto de software, los registros de cambios en el documento y finalmente la aprobación del documento de las partes involucradas.

Organismo

Proyecto

Entregable

Autor

Versión/Edición

Fecha de Versión

Nº Total de Páginas

Registro de Cambios

Versión

Causa del Cambio

Responsable del Cambio

Fecha del Cambio

Validación/Aprobación

Cliente

Empresa que presta el servicio

Aprobado por:

Aprobado por:

Fecha de Aprobación:

Fecha de Aprobación:

  • Introducción

La introducción está compuesta por dos áreas de relevancia:

  1. Alcance: define lo que abarca el software, es importante que en este punto se declare muy bien todo aquello que el sistema va a cubrir. Este es uno de los aspectos más importantes del documento, por lo cual debe ser claro indicando las bondades del software y, delimitando los procesos que no hará.

  1. Objetivos: establece los objetivos que se van a cumplir con el documento de especificación de requerimientos de software.

  • Información del problema a solucionar

En esta sección se hace una introducción al proceso que se va mejorar con el software a desarrollar; se hace con la finalidad de poner en contexto al lector, así como hacerle ver que el redactor entiende el problema a solucionar.

Adicionalmente, se agrega un glosario de términos del proceso que se va a mejorar con el software y algunos términos asociados al área de tecnología.

 

  • Necesidades de negocio

Una vez se conoce bien el proceso a mejorar, debemos identificar las necesidades del negocio que se van a cubrir y cómo el producto que se va a desarrollar apoyará a dicho proceso. De igual manera, debe definir los objetivos del negocio a cumplir y describir los procesos del negocio que se desean mejorar.  

Es posible que usted desee mejorar un solo proceso del negocio, pero indirectamente esa mejora afectará otras áreas. Las áreas afectadas, deben ser descritas indicando cuáles son sus dependencias (gerencias) o quienes la afectan y cuáles son las labores que se ejecutaran para su mejora. Así mismo, señalar la importancia del proceso y los actores que intervienen en el desarrollo del proceso.  Se recomienda hacer un cuadro para plasmar la información. Ejemplo:

Numero  de Proceso: P1

Agotamiento de la cobertura de la póliza

Dependencias

  • Gerencia de Reclamo
  • Gerencia de Administración y Finanzas
  • Gerencia de Estadísticas

Descripción

Para mejorar el proceso de agotamiento de la cobertura se realizan las labores siguientes:

  • Se define un código único para la enfermedad y el protocolo de la enfermedad.
  • Se establece un código único para los procedimientos.
  • Los reclamos se vinculan a un código único de enfermedad.

Importancia

Se estandariza la enfermedad con un solo código, evitando existan enfermedades duplicadas.

Se normalizan los procedimientos haciendo uso de un código único.

El proceso de agotamiento de la cobertura de la póliza se optimiza al asociar los reclamos con un código único de enfermedad. Por lo tanto, facilita al analista determinar que el nuevo siniestro ya tiene un reclamo vinculado con una misma enfermedad y se registra como complemento del reclamo anterior. En consecuencia, se realiza un correcto agotamiento de la cobertura por la enfermedad que ya se encontraba relacionada en un reclamo preliminar.

Los tiempos de análisis y respuesta mejoran considerablemente.

Actores

  • Analista de reclamo

  • Requisitos del sistema

Esta sección se divide en tres partes:

  • Casos de uso

Para un mayor entendimiento del producto a desarrollar, debemos:

  • Diagramar los casos de uso del sistema.

Elabore los diagramas de los casos de uso del software que sean necesarios para modelar la solución del proceso de negocio a mejorar.

  • Realizar especificación de los actores.

Luego de la diagramación de los casos de uso es importante detallemos cada uno de los actores que intervienen en los casos de uso. Se recomienda hacer la especificación en un cuadro como el siguiente:

...

Descargar como (para miembros actualizados) txt (8 Kb) pdf (115 Kb) docx (19 Kb)
Leer 4 páginas más »
Disponible sólo en Clubensayos.com