República Bolivariana de Venezuela

Instituto Universitario Politécnico

“Santiago Mariño”

Sede Barcelona

Análisis y diseño de sistemas

Requerimientos
de
Sistemas
Profesor: Bachiller:

Manuel Ramírez González Arreaza José Antonio

C.I 27505140

Noguera Rose Valentina

C.I: 29510081

Miércoles 05/02/2020
 Introducción

A través de los años se ha podido constatar que los requerimientos o requisitos

son la pieza fundamental en un proyecto de desarrollo de software, ya que
marcan el punto de partida para actividades como la planeación, básicamente
en lo que se refiere a las estimaciones de tiempos y costos, así como la
definición de recursos necesarios y la elaboración de cronogramas que será
uno de los principales mecanismos de control con los que se contará durante la
etapa de desarrollo. Además la especificación de requerimientos es la base
que permite verificar si se alcanzaron o no los objetivos establecidos en el
proyecto ya que estos son un reflejo detallado de las necesidades de los
clientes o usuarios del sistema y es contra lo que se va a estar verificando si se
están cumpliendo las metas trazadas.

Requisitos para la elaboración de un proyecto de sistemas

¿Qué son Requerimientos?

Una condición o necesidad de un usuario para resolver un problema o alcanzar

un Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
objetivo.

Características de los requerimientos: completa, consistente, verificable, no

ambigua, factible, modificable, rastreable, precisa, entre otras.

Los requerimientos puedes dividirse en requerimientos funcionales y

requerimientos no funcionales.

Los requerimientos funcionales definen las funciones que el sistema será capaz
de realizar. Describen las transformaciones que el sistema realiza sobre las
entradas para producir salidas.

Los requerimientos no funcionales tienen que ver con características que de

una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
etc.

Inicio de un proyecto

El inicio de un proyecto consiste en la realización de las actividades

encaminadas a lograr el correcto arranque del proyecto y establecer los
aspectos internos y logísticos necesarios para la ejecución del mismo.

Durante esta fase se establecerán las normas de ejecución y el modelo de

relación con el cliente para el desarrollo del proyecto, identificando las
personas y recursos claves. Se deberá realizar una puesta en común de los
distintos puntos de vista y comprensión de los objetivos del proyecto por parte
de la dirección del mismo y de las áreas participantes.

Documentación e investigación preliminar

El analista de sistemas necesita investigar datos relevantes, incluyendo

reportes, documentos, estados financieros, manuales de procedimientos y
memorándums. Los datos relevantes muestran dónde ha estado la
organización y hacia dónde creen sus miembros que están yendo. Es
necesario que sean analizados documentos cuantitativos y cualitativos.

Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, se

comienza la investigación preliminar. Esta investigación requiere uno o más
analistas de sistemas analizando el “system request” para determinar la
verdadera naturaleza y alcance del problema y recomendar si es que se debe
continuar con el proyecto. El propósito de la investigación preliminar es buscar
información suficiente para determinar si se debe continuar con el Ciclo de Vida
del Desarrollo del Sistema. La investigación no es una actividad de recolección
de datos; no se espera que se definan todos los problemas ni que se
propongan todas las posibles soluciones. La investigación preliminar debe
cumplir con los siguientes cinco objetivos:

 Entender la naturaleza del problema

 Definir el alcance y las restricciones o limitaciones del sistema
 Identificar los beneficios que se obtendrían si el sistema propuesto es
completado.
 Especificar un estimado de tiempo y costo para las próximas fases de
desarrollo.
 Presentar un informe a la gerencia describiendo el problema y
detallando si se recomienda continuar con la fase de análisis del
sistema.

Requerimientos de un sistema

Identificar el problema

La primera acción formal de la ejecución de un proyecto, cualquiera sea su tipo,

es identificar el problema que se pretende resolver.

Para poder hacer una correcta identificación del problema de investigación es

necesario determinar algunos aspectos centrales que todo problema debe
mostrar de modo tal que al encontrarlo el problema identificado cumpla con
ciertas características que le confieren rigurosidad académica y le permiten
configurarse en el marco de una investigación seria.

Para evitar un desajuste en lo que el analista entrega, y lo que el cliente desea

es indispensable estar de acuerdo con la definición del problema real, entender
que un problema en una empresa puede ser percibido de manera distinta
según sea la persona que lo observe. A veces se confunden con los síntomas o
con los deseos y gustos personales.
Necesidades de datos

Todo sistema de información utiliza como materia prima los datos, los cuales
almacena, procesa y transforma para obtener como resultado final información,
la cual será suministrada a los diferentes usuarios del sistema, existiendo
además un proceso de retroalimentación o “feedback”, en la cual se ha de
valorar si la información obtenida se adecua a lo esperado

Para la consecución de dichos objetivos, un buen sistema de información ha de

ser capaz recibir y procesar los datos del modo más eficaz y sin errores,
suministrar los datos en el momento preciso, evaluar la calidad de los datos de
entrada, eliminar la información poco útil evitando redundancias, almacenar los
datos de modo que estén disponibles cuando el usuario lo crea conveniente,
proporcionar seguridad evitando la perdida de información o la intrusión de
personal no autorizado o agentes externo a la compañía y generar información
de salida útil para los usuarios de sistemas de información, ayudando en el
proceso de toma de decisiones.

Requerimientos de control
Las condiciones a las que debe someterse un control son las siguientes:

Requisitos de un buen control

Corrección de fallas y errores: El control debe detectar e indicar errores de

planeación, organización o dirección.

Previsión de fallas o errores futuros: el control, al detectar e indicar errores

actuales, debe prevenir errores futuros, ya sean de planeación, organización o
dirección.

Entre los principales objetivos que buscan los requerimientos de control

podemos encontrar:

 Proteger los recursos y bienes de los posibles riesgos.

  Garantizar la eficiencia, eficacia y economía en todas las operaciones y
facilitar que los funcionarios cumplan la misión institucional.
 Velar que actividad y recursos cumplan los objetivos de la organización.
 Garantizar la evaluación de la gestión en la organización.
 Asegurar la oportunidad y la confiabilidad de la información.
 Definir y aplicar medidas para prevenir riesgos.
 Garantizar que el sistema disponga de mecanismos de verificación y
evaluación.
 Velar porque se disponga de procesos de planeación.

Especificación de Requisitos de Software (SRS)

La especificación de requisitos de software es la actividad en la cual se genera

el documento, con el mismo nombre, que contiene una descripción completa de
las necesidades y funcionalidades del sistema que será desarrollado; describe
el alcance del sistema y la forma en como hará sus funciones, definiendo los
requerimientos funcionales y los no funcionales.

Debe ser un documento consensuado entre todas las partes y tener un carácter
contractual, de forma que cualquier cambio que se desee realizar en él una vez
acordada la primera línea base deba aplicarse siguiendo el Procedimiento de
Control de Cambios establecido en el proyecto.

En la SRS se definen todos los requerimientos de hardware y software,

diagramas, modelos de sistemas y cualquier otra información que sirva de
soporte y guía para fases posteriores.

Es importante destacar que la especificación de requisitos es el resultado final

de las actividades de análisis y evaluación de requerimientos; este documento
resultante será utilizado como fuente básica de comunicación entre los clientes,
usuarios finales, analistas de sistema, personal de pruebas, y todo aquel
involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe desarrollarse.
El personal de pruebas elaborará las pruebas funcionales y de sistemas en
base a este documento. Para el administrador del proyecto sirve como
referencia y control de la evolución del sistema.

La SRS posee las mismas características de los requerimientos: completa,

consistente, verificable, no ambigua, factible, modificable, rastreable, precisa,
entre otras. Para que cada característica de la SRS sea considerada, cada uno
de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se
considere verificable, cada requerimiento definido en ella debe ser verificable;
para que una SRS se considere modificable, cada requerimiento debe ser
modificable y así sucesivamente.

La estandarización de la SRS es fundamental pues ayudará, entre otras cosas,

a facilitar la lectura y escritura de la misma. Será un documento familiar para
todos los involucrados, además de asegurar que se cubren todos los tópicos
importantes.

Estructura sugerida para un SRS

1. Introducción

1.1 Propósito

Establece el propósito de este documento así como la audiencia para el mismo.

1.2 Alcance

a) Identificar el producto SW a ser producido por nombre.

b) Explicar lo que hará y no hará el producto SW.

c) Explicar en que se aplicara el producto SW, beneficios, objetivos, metas.

1.3 Definiciones, siglas y abreviaciones

Definir todos los términos, acrónimos, y abreviaciones requeridas para

interpretar el documento.
1.4 Referencias

Proveer una lista completa de todos los documentos referidos en el resto del
documento, así como sus fuentes.

1.5 Vista General / Resumen

Describir lo que contiene el resto del documento así como su organización.

2. Descripción General

Esta sección debe describir los factores generales que afectan al producto y
sus requerimientos. Esta sección no establece requerimientos específicos,
establece los antecedentes para ellos.

2.1 Perspectiva del Producto

Poner en perspectiva al producto con otros relacionados. Si el producto es

independiente y auto-contenido, debe ser especificado de esa manera.

2.1.1 Interfaces del Sistema

2.1.2 Interfaces con el usuario

2.1.3 Interfaces con el hardware

2.1.3 Interfaces con otros software

2.1.4 Interfaces con dispositivos de comunicación

2.1.5 Operaciones

2. 2. Descripción General (cont.)

2.2 Funciones del Producto

Esta sub-sección debe incluir un resumen de todas las funciones principales

que realizara el software sin incluir la gran cantidad de detalles que cada una
de esas funciones requiere.

2.3 Características del Usuario

Detallar las características generales de cada tipo de usuario incluyendo nivel
de educación, experiencia, y nivel de aptitud técnica.

2.4 Restricciones

Incluir una descripción general de cualquier aspecto que limitara las opciones
del desarrollador.

2.5 Suposiciones y dependencias

Listar cada uno de los factores que afectan los requerimientos establecidos en
este documento. Estos factores no son restricciones de diseño para el
software.

3 Requerimientos Específicos

 Esta sección del SRS debe contener todos los requerimientos de

software hasta un nivel de detalle suficiente como para permitir a los
diseñadores diseñar el sistema que satisfaga esos requerimientos, y a
los especialistas en pruebas para comprobar que el sistema satisfaga
esos requerimientos.

 Estos requerimientos deben incluir como mínimo una descripción de
cada entrada (estimulo) al sistema, toda salida (respuesta) del sistema, y
toda función realizada por el sistema en respuesta a la entrada o en
soporte a una salida.

3. Requerimientos específicos

3.1 Interfaces Externos

Esta debe ser una descripción detallada de todas las entradas y salidas del
sistema software. Deberá complementar la descripción de interfaces en la
sección 2 y no repetir la información en esa sección.

3.1.1 Interfaces de usuario

3.1.2 Interfaces de Hardware

3.1.3 Interfaces de Software

3.1.4 Interfaces de comunicación

3.2 Característica del Sistema

3.2.1 Caso de Uso 1

3.2.1.1 Introducción/Propósito

3.2.1.2 Secuencia Estimulo/Respuesta

3.2.1.3 Requerimientos funcionales asociados

3.2.1.3.1 Requerimiento Funcional 1 (El sistema deberá ...........)

3.2.1.3.n Requerimiento Funcional n

3.2.m Caso de Uso m

3.3 Requerimientos de rendimiento

Especificar los requerimientos numéricos estáticos y dinámicos puestos en el

producto software. (Ej. Número de terminales soportadas, usuarios
simultáneos, cantidad de info., etc.)

3.4 Restricciones de diseño

Especificar restricciones de diseño que pueden ser impuestas por otros

estándares, limitaciones de hardware, etc.

3.5 Atributos del sistema Software

Atributos del sistema que son especificado como requerimientos para poder ser
objetivamente evaluados.

3.6 Otros requerimientos

 Conclusión

Es muy importante mencionar que el poder formular una especificación de

requerimientos completa y consistente, es un paso muy importante para evitar
cometer errores en la definición de los requerimientos, ya que los mismos
pueden resultar muy caros de corregir una vez desarrollado el sistema. De ahí,
la vital importancia que tiene la ingeniería de requerimientos en generar una
adecuada especificación que contemple claramente y sin ambigüedades los
requerimientos del sistema a desarrollar, con el fin primordial de evitar que los
proyectos fracasen debido a una mala elaboración de la definición y
especificación de requerimientos.