Software">
Nothing Special   »   [go: up one dir, main page]

Análisis de Requisitos Del Software

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 6

Análisis de Requisitos del Software

Sebastian Robayo Cardozo

FUNDACION UNIVERSITARIA UNIPANAMERICANA


DESARROLLO DE SISTEMAS DE INFORMACIÓN
INGENIERIA DE SISTEMAS
2020
La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento,
modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel
asignado al software. (PRESSMAN, 2002).

El desarrollador tiene un papel importante a la hora de elaborar los requisitos de un software


lo cual dicho papel significa el análisis; el desarrollador cumple ciertas actividades en el
momento de especificar los requisitos, lo cual, consulta al cliente que tipo de funciones y
comportamientos requiere para que el sistema tenga un correcto funcionamiento.

Al momento de realizar los requisitos se puede dividir en los siguientes ítems para el
reconocimiento del software, lo cual son:

1. Reconocimiento del problema


2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión

La especificación: es un documento que expone, “de forma completa, precisa y verificable,


los requisitos, el diseño, el comportamiento u otras características de un sistema o de un
componente de un sistema” (Guevara, s.f).

El termino análisis de requisitos se define como “ el proceso del estudio de las necesidades
de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de
software, así como el proceso de estudio y refinamiento de dichos requisitos” (Guevara, s.f).

Existen unas fases para definir los requisitos de un software según el estándar IEEE 1074
[IEEE, 1991]:

• Definir los requisitos de software. Tarea iterativa para crear una definición o
especificación preliminar de los requisitos que debe cumplir el software a partir de
la información obtenida mediante técnicas de recogida de información analizadas
en el punto anterior.
• Definir los requisitos de las interfaces del software con el resto del sistema y
con el exterior. Deben definirse las propiedades que se deben satisfacer para
obtener una interacción eficaz con otros elementos del sistema (el usuario, el
hardware, otras aplicaciones software, ...). En particular la interfaz con el usuario es
crítica para la facilidad de uso (y por tanto el éxito) del software. Los requisitos de
interfaz con otras aplicaciones deben describir las características para que el
software se relacione con ellas, las cuales pueden estar muy influenciadas por
restricciones de trabajo del sistema (S.O. utilizado, SGBD empleado, Compiladores,
controladores de red, etc.).Así mismo deben definirse las características de las
interrelaciones con elementos hardware.

• Integrar los requisitos en un documento de especificación y asignarles


prioridades. La asignación de prioridades debe hacerse en función de su
importancia o los beneficios que puede aportar su cumplimiento. (Guevara, s.f).

La especificación: es un documento que expone, “de forma completa, precisa y verificable,


los requisitos, el diseño, el comportamiento u otras características de un sistema o de un
componente de un sistema” (Guevara, s.f).

Los métodos que pueden ser usados para la recolección de información son las siguientes
actividades:

1. Entrevistas
2. Talleres
3. Observación
4. Encuestas
5. Revisión documental
6. Uso de especificaciones formales para requerimientos

En conjunto a esto debemos tener presente que existen dos tipos de requisitos para poder
realizar una descripción exacta debemos definir que tipo es relacionado a ello, lo cuales
son:

Requisitos funcionales: Se compone de las interacciones entre el sistema y su ambiente,


en forma independiente a su implementación. El ambiente incluye al usuario y cualquier
otro sistema externo con el cual interactúe el sistema.

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.

Para sustentar el significado de este tipo de requisito son los siguientes ejemplos:

• El sistema enviará un correo electrónico cuando se registre alguna de las siguientes


transacciones: pedido de venta de cliente, despacho de mercancía al cliente,
emisión de factura a cliente y registro de pago de cliente.
• Se permitirá el registro de pedidos de compra con datos obligatorios incompletos,
los cuales podrán completarse posteriormente modificando el pedido. Antes de
poder aprobarse los datos del pedido deben estar completos.
• Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo
(workflow) de aprobación configurado en el sistema.
• El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de
proyecto.
• El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de
proyecto.
• El sistema permitirá el envío automatizado de cartas de entrega de órdenes
directamente al almacén.
• A cada orden se le asignará un identificador único, que será utilizado para
identificarla en todos los procesos subsecuentes que se realicen sobre esta.
• Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido
de venta.

Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del
sistema que no están relacionados directamente con los requisitos funcionales. Los
requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta
o precisión, tipo de plataforma, leguajes de programación, etc.

Para sustentar el significado de este tipo de requisito son los siguientes ejemplos:

Eficiencia

• El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá
por medio de la herramienta SoapUI aplicada al Software Testing de servicios web.
• Toda funcionalidad del sistema y transacción de negocio debe responder al usuario
en menos de 5 segundos.
• El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios
con sesiones concurrentes.
• Los datos modificados en la base de datos deben ser actualizados para todos los
usuarios que acceden en menos de 2 segundos.
Usabilidad

• El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
• La tasa de errores cometidos por el usuario deberá ser menor del 1% de las
transacciones totales ejecutadas en el sistema.
• El sistema debe contar con manuales de usuario estructurados adecuadamente.

Un método abierto para reunir información es la entrevista, lo cual, nos permite identificar
de diferentes opiniones personales que pueden sustentar su análisis mediante hipótesis
realizadas al finalizar cada entrevista.
¿Pero que es una entrevista?, para muchos “pueden ser de tipo científicas, cuya intención
es promover la investigación sobre algún tema relacionado con la ciencia y que supone la
obtención de información en torno a la labor de un individuo o grupo para poder influir
sobre las opiniones y sentimientos que la comunidad a la que vaya dirigida la entrevista
tenga sobre ese tema.” (Porto, 2008).

En el análisis de requerimientos pueden no se detallados o específicos, que su finalidad


llega a ser ambiguo o se puede no tener una buena interpretación y se puede generar
confusión entre los desarrolladores y los usuarios o clientes.
Las características que posee el realizar los requerimientos de un software son las
siguientes:
✓ Comprender la naturaleza de los problemas puede ser muy difícil, especialmente
si es nuevo.
✓ Son las descripciones de los servicios.
✓ La Ingeniería de requerimientos es el proceso de descubrir, analizar documentar y
verificar estos servicios.
También es de tener en cuenta que existen dos tipos de lectura para los requerimientos
los cuales se menciona que:
REQUERIMIENTOS DEL USUARIO: Administradores clientes , usuarios finales del
sistema, ingenieros clientes, administradores contratistas, arquitectos del sistema.
REQUERIMIENTOS DEL SISTEMA: usuarios finales del sistema, ingenieros clientes,
arquitectos del sistema, desarrolladores del software.
REFERENCIAS

• Guevara,J. (s.f). Introducción al análisis de requisitos (A.R.). Recuperado de


https://sites.google.com/site/adai6jfm/home/introduccin-al-anlisis-de-requisitos-ar
• Ingeniería del Software. Un enfoque práctico. 5ta. Edición Pressman, Roger
McGraw-Hill, 2002 ISBN 84-481-3214-9
• N/A; (s.f), Análisis de requisitos del software. Recuperado de:
https://tesuva.edu.co/phocadownloadpap/Anlisis%20de%20requisitos%20del%20s
oftware.pdf.
• Julián Pérez Porto y Ana Gardey. Publicado: 2008. Actualizado: 2012. Recuperado
de: https://definicion.de/entrevista/
• Soomerville, I. (s.f), Requerimientos del software. Recuperado de:
https://www.uv.mx/personal/fcastaneda/files/2015/08/F_Capitulo_5_Requerimiento
s_del_software.pdf.
• Eriksson, U. (2017). Requerimientos funcionales: Ejemplos, Recuperado de:
http://www.pmoinformatica.com/2017/02/requerimientos-funcionales-ejemplos.html
• Cohn, Mike (2015), Requerimientos no funcionales: Ejemplos. Recuperado de:
http://www.pmoinformatica.com/2015/05/requerimientos-no-funcionales-
ejemplos.html

También podría gustarte