ANALISIS Y DESARROLLO DE SOFTWARE

(2721467)

Especificación de los requerimientos funcionales y no funcionales del

software. GA1-220501092-AA4-EV01

Por:
YAMILETH GARCIA VALDES

TECNOLOGÍA EN ANÁLISIS Y DESARROLLO DE SOFTWARE

CENTRO DE INDUSTRIA Y CONSTRUCCION
IBAGUE - TOLIMA
2023
 INTRODUCCION

Este trabajo está orientado a nuestro emprendimiento de Divas Estampados,

Si queremos aprender a diseñar, y administrar nuestros sistemas durante su ciclo
de vida}; primero debemos aprender a analizar y estructurar sus requisitos, u
sistema cuyos requisitos no se hayan establecido claramente, probablemente
funcionara de manera no optimizada y no abordara adecuadamente el problema
que intentamos resolver
 DESCRIPCIÓN DE LOS REQUERIMIENTOS FUNCIONALES

Los requisitos funcionales de un software se suelen registrar en la matriz de

trazabilidad de requerimientos y en la especificación de requerimientos de
software, este último, documenta las operaciones y actividades que el
sistema debe desempeñar

Los requerimientos funcionales de un sistema, son aquellos que describen

cualquier actividad que este debe realizar, en otras palabras, el
comportamiento o función particular de un sistema o software cuando se
cumplen ciertas condiciones

Por lo general, estos deben incluir funciones desempeñadas por pantallas

especificas. Descripciones de los flujos de trabajo a ser desempeñados por
el sistema y otros requerimientos de negocio, cumplimiento, seguridad u
otra índole.

TIPOS DE REQUISITOS FUNCIONALES

Estos son los tipos de requisitos funcionales más comunes:

 Regulaciones comerciales
 Requisitos de Certificación
 Los requisitos de información
 Funciones administrativas
 Niveles de autorización
 Seguimiento de auditoría
 Interfaces externas
 Administración de datos
 CREACIONDE REQUISITOS FUNCIONALES:

Al crear requisitos funcionales, es importante tener en cuenta que deben ser

específicos, medibles, alcanzables, relevantes y limitados en el tiempo (SMART).
En otras palabras, sus requisitos funcionales deben:

 Sea específico sobre lo que debe hacer el sistema

 Ser medible para que pueda saber si el sistema lo está haciendo.
 Ser alcanzable dentro del marco de tiempo que ha establecido
 Sea relevante para sus objetivos comerciales
 Tener un límite de tiempo para que pueda seguir el progreso

Al seguir estas pautas, puede estar seguro de que sus requisitos funcionales son
claros y ayudarán a su equipo de desarrollo a crear el producto adecuado.

Ejemplo # 1

: Un usuario podrá iniciar sesión en el sistema utilizando su nombre de usuario y

contraseña.

En este ejemplo, la función es "iniciar sesión" y el comportamiento es "El sistema

permitirá que un usuario inicie sesión con su nombre de usuario y contraseña".

Ejemplo # 2

: El sistema calculará el impuesto a las ventas por la compra del usuario.

En este ejemplo, la función es "calcular el impuesto sobre las ventas" y el

comportamiento es "El sistema calculará el impuesto sobre las ventas
multiplicando el precio de compra por la tasa impositiva".
Ejemplo # 3

: El sistema enviará un correo electrónico de confirmación al usuario después de

que haya realizado un pedido con éxito.

En este ejemplo, la función es "enviar correo electrónico de confirmación" y el

comportamiento es "El sistema enviará un correo electrónico de confirmación al
usuario después de que haya realizado un pedido con éxito".

Como puede ver, los requisitos funcionales son declaraciones específicas sobre lo
que debe hacer el sistema. Son diferentes de los requisitos no funcionales, que
definen cómo funciona internamente el sistema (p. ej., rendimiento, seguridad,
etc.).

Al crear requisitos funcionales, es importante tener en cuenta que deben ser

específicos, medibles, alcanzables, relevantes y limitados en el tiempo (SMART).
Al seguir estas pautas, puede estar seguro de que sus requisitos funcionales son
claros y ayudarán a su equipo de desarrollo a crear el producto adecuado.
 DESCRIPCIÓN DE LOS REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales describen características específicas que el

software debe poseer durante el desarrollo de la aplicación. Por lo general, se
dividen en tres categorías: rendimiento, seguridad y calidad.

Requerimientos de rendimiento

Los requerimientos de rendimiento suelen dividirse en dos categorías: tiempo de

respuesta y rendimiento. El tiempo de respuesta es el tiempo que tarda un sistema
en responder a la solicitud de un usuario, mientras que el rendimiento es el
número de solicitudes que un sistema puede manejar. Son más críticos para los
sistemas interactivos, como las aplicaciones de escritorio y los sitios web, donde
los usuarios esperan respuestas inmediatas a sus acciones.
Requerimientos de seguridad

Los requerimientos de seguridad

especifican las medidas que un sistema debe tomar para proteger los datos del
acceso no autorizado. En algunos casos, los requerimientos de seguridad también
pueden especificar el nivel de protección requerido, como confidencial o de alto
secreto. Implica autenticación, autorización y cifrado.

Requerimientos de calidad

Especifica el nivel de calidad que debe cumplir un sistema. En algunos casos, los
requerimientos de calidad también pueden especificar los métodos utilizados para
medir la calidad, como la densidad de defectos o la satisfacción del cliente. Los
requerimientos de calidad son generalmente cuatro medidas de calidad:
conformidad, usabilidad, confiabilidad y mantenibilidad.

Especifica el nivel de calidad que debe cumplir un sistema. En algunos casos, los
requerimientos de calidad también pueden especificar los métodos utilizados para
medir la calidad, como la densidad de defectos o la satisfacción del cliente. Los
requerimientos de calidad son generalmente cuatro medidas de calidad:
conformidad, usabilidad, confiabilidad y mantenibilidad.
¿Qué son las técnicas de licitación de requisitos no funcionales?

Hay algunas mejores prácticas que deben seguirse al escribir requisitos no

funcionales. Éstos incluyen:

 Asegúrese de que los requisitos sean claros y concisos.

 Sea específico sobre lo que se requiere.
 Evite el uso de jerga.
 Utilice un lenguaje sencillo.
 Asegúrese de que los requisitos sean alcanzables.
 Sea realista acerca de lo que se puede lograr.
 Priorizar los requisitos.
 Mantenga los requisitos flexibles.
 Revisar y modificar los requisitos según sea necesario.
 Obtenga comentarios de las partes interesadas sobre los requisitos.

Los requisitos no funcionales son una parte esencial de cualquier proyecto de

desarrollo de sistemas. Al seguir estas mejores prácticas, puede asegurarse de
que sus requisitos no funcionales sean claros, concisos y alcanzables.

Técnicas de análisis de requisitos

En la Ingeniería de requisitos, el análisis de los requerimientos del software es la

etapa que sigue después que estos han sido levantados y documentados en un
registro o matriz de trazabilidad.

La especificación de requerimientos, es una actividad que cada vez toma mayor

preponderancia en la gerencia de proyectos, dado que se ha demostrado que una
causa recurrente en su fracaso se origina de una inadecuada especificación de
requisitos.

El análisis de requerimientos consiste en aplicar una serie de técnicas para

desglosar y analizar los requisitos y sus partes, algunas de estas técnicas son:
Modelado de procesos, Modelado de dominio, casos de uso, inspecciones, listas
de chequeo y prototipos.
Técnicas para analizar requerimientos de software

 1.- Descomposición funcional: La descomposición funcional se refiere al

proceso de identificar y resolver las relaciones funcionales en sus partes
constituyentes, de tal forma que la función global pueda ser reconstruida a partir
de sus partes.
 Por lo general, la descomposición funcional se realiza para identificar y
entender los componentes o partes que constituyen un todo (o función global).
 En este proceso, es vital identificar las interacciones entre componentes.
 Aplicado a la Ingeniería de requisitos, consiste en tomar
los requerimientos de software, dividirlos en partes y analizarlos
individualmente. De ser necesario, se pueden descomponer en más partes hasta
lograr un nivel adecuado de detalle.
 En cierto sentido, el proceso es similar al de la elaboración de
una estructura de desglose de trabajo de un proyecto.
 En Ingeniería de sistemas, la descomposición funcional consiste en definir
un sistema en términos funcionales, para luego definir funciones de más bajo nivel
y establecer las relaciones con estas funciones de alto nivel.
 La intención es dividir un sistema de tal forma que cada componente se
pueda describir sin necesidad de referir a otro componente.
 De esta forma, cada parte del sistema tendrá funciones independientes,
que pueden reusarse y reemplazarse.

2.- Especificación vía Sentencias Textuales

 Es la forma tradicional de la especificación de requerimientos de
software.
 Se usan especificaciones textuales en lenguaje natural, que se documentan
en matrices de trazabilidad de requerimientos o definiciones del alcance.
 El procedimiento consiste en tomar el requerimiento producto del
levantamiento de información, para desarrollar una narrativa más detallada.
 No usa herramientas visuales como los flujogramas o estructura como los
casos de uso, es simplemente una descripción más detallada del requerimiento en
lenguaje natural.
3.- Modelado del proceso
RECIBE PEDIDO DE
CLIENTE

CANCELA PEDIDO
VERIFICA DISPONIBILIDAD
DE PRODUCTOS

¿TODOS LOS
PRODUCTOS
DISPONIBLES?

MODIFICA PEDIDO

PROCESO DE PEDIDO DE VENTA

 INFORMA AL CLIENTE
E INDICA SI DESEA
NO ESPERAR O COMPRAR
EXISTENCIAS
SI

ENVIA A ALMACEN PARA

SER PREPARADO

 Comprende la elaboración de diagramas de flujo de procesos (Flujogramas)

a partir de los requerimientos del software.
 Existen diversas herramientas de modelado de procesos, cada una de las
cuales posee sus propios símbolos y reglas.
 Es muy útil para entender el trabajo realizado en múltiples pasos, tareas,
roles y departamentos intervinientes.
 Los procesos son iniciados por eventos y pueden abarcar actividades
automatizadas, manuales o combinación entre ambas.
 Su naturaleza visual ayuda a la comprensión y comunicación a terceros.
 Cuando los procesos son complejos, deben desglosarse en componentes
(subprocesos).
 La relación entre los diagramas de flujo y la gerencia de proyectos es
fundamental para el éxito.

4.- Modelo de dominio

Un modelo de dominio describe los tipos de dominio que admite una organización

y sus restricciones. Un modelo de dominio está formado por un grupo de dominios
atómicos. Un dominio atómico representa un tipo de datos abstracto que se puede
restringir mediante la adicción de restricciones.
 STORE

Catalogue Payment Security

Bank transfer Credit card High Standard

5.- Casos de Uso

 cliente
VISUALIZAR PRODUCTOS

AGREGAR PRODUCTOS A LA
CANASTA

REALIZAR PAGO

ADMINISTRAR QUE TODO ESTE EN

ORDEN

6.- Checklists

 La lista de chequeo (Checklist) consiste en una serie de preguntas o

revisiones que se realizan sobre los requerimientos de software, que nos sean
presentados de forma escrita.
 Una lista de chequeo puede realizar preguntas como:
o ¿Se han especificado los requisitos de hardware y software?
o ¿Se han realizado consideraciones de seguridad?
o ¿El nivel de granularidad del requerimiento se ha incluido?
o ¿Se ha incluido el código de referencia en para identificar el requisito
en el desglose de requerimientos?
o ¿Está escrito el requerimiento en un lenguaje claro y conciso?
o ¿El requerimiento es único? (no existe duplicidad con otro
requerimiento).
o Y muchas preguntas más.
 La lista de chequeo sirve de marco de trabajo y procedimental para revisar
el requerimiento, facilitando su análisis de forma estructurada.
 Los requerimientos se pueden revisar sobre la matriz de trazabilidad de
requerimientos o sobre la definición del alcance.

7.- Inspección

 Revisión no destructiva de los requerimientos de software. Por ejemplo:

Examinar un software visualmente para constatar que las pantallas solicitadas se
encuentran incluidas.
Verificar la inclusión de los campos necesarios para el ingreso de datos.
Verificar la existencia de los botones necesarios para iniciar la funcionalidad que
ha sido requerida.
Verificar que el requerimiento se apega a los estándares definidos para la
aplicación. Por ejemplo estándares de navegación entre pantallas y estándares de
interfaz gráfica.
De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el
requerimiento definido en la matriz de trazabilidad o definición de alcance, leerlo
y producir un resultado para su corrección.

Priorización de requisitos
El proyecto de desarrollo de software al igual que cualquier otro proyecto tiene
múltiples técnicas de priorización de requerimientos, restricciones presupuestarias
y plazos ajustados. Por lo tanto, existe la necesidad de priorizar los requisitos de
software ya que es imposible hacer todo a la vez. Por lo tanto, se deben tomar
decisiones sobre qué conjunto de requisitos se deben implementar primero y
cuáles se pueden retrasar hasta una versión posterior.
Normalmente, los PO de proyectos ágiles desean desarrollar software que sea de
alta calidad y de gran valor, y la forma más sencilla de desarrollar software de alto
valor es implementar primero los requisitos de mayor prioridad. Esto les permite
maximizar el ROI de las partes interesadas.
Como normalmente los requisitos cambian con frecuencia, se necesita un enfoque
simplificado y flexible para la gestión de cambio de requisitos, por ejemplo, product
backlog (Scrum). Por lo tanto, en el desarrollo ágil, la priorización de
requerimientos de software se considera una parte vital del proyecto. Y, por
ejemplo, para priorizar las historias de usuario, podríamos usar los 5 criterios
principales de priorización de requerimientos, como el valor que los usuarios le
dan a la visión del producto, la urgencia, las limitaciones de tiempo, la técnica de
complejidad y las preferencias de las partes interesadas.
Además, muy a menudo los proyectos deben ser priorizados adecuadamente
tanto para los objetivos principales del proyecto como para las tareas específicas
que lograrán los objetivos. Por lo tanto, nos ocupamos de la priorización en dos
niveles: nivel de producto y nivel de tarea. Especialmente teniendo en cuenta que
los clientes normalmente tienden a no entender que no pueden obtener todas las
características que desean en la versión 1.0 de un nuevo producto de software.
Cada proyecto debe tener prioridades de las características solicitadas, casos de
uso y requisitos funcionales. La priorización de requerimientos de software ayuda
al gerente de proyectos a resolver conflictos, planificar entregas escalonadas y
tomar las decisiones de compensación necesarias.
Una de las mayores diferencias entre las empresas que prosperan y las que
fracasan es la capacidad de priorizar de manera efectiva, pero la priorización de
los requisitos de software nunca es fácil. A menudo implica decisiones dolorosas y
pocas compensaciones, y para las empresas en etapa inicial y de expansión,
existe la presión adicional de tratar de lograr mucho con tiempo y recursos
limitados. Para lograr crecimiento, un equipo debe estar dirigido únicamente a las
cosas que realmente importan y que van a tener un impacto máximo.
La priorización de requisitos de software es uno de los mayores desafíos que
enfrenta un equipo de software. De hecho, el 25% de los líderes tecnológicos dijo
que priorización de requerimientos de software es su mayor desafío.
Pero de acuerdo con las investigaciones de Jeanne Ross y Peter Weill en su libro
IT Governance, «Las empresas que gestionan sus inversiones en IT con mayor
éxito generan retornos que son hasta un 40% más altos que los de sus
competidores».
En general, las empresas deben asegurarse de que cada miembro del equipo no
solo esté trabajando en una lista de tareas. Deben tener una comprensión clara
del impacto que tiene la tarea en la que están trabajando, al ver su contribución
directa al proyecto. También necesitan tener claro el propósito del producto, no
solo comprender la necesidad del cliente sino también el valor y los objetivos del
negocio.
Puede haber ciertas cosas como la arquitectura de back-end que no es visible
para los clientes, sino para los desarrolladores que pueden señalar cualquier
problema arquitectónico que podría afectar el rendimiento del producto en el
futuro. Por eso es tan importante asegurarse de que todos los ingenieros del
equipo entiendan el producto hacia atrás y hacia adelante.

Técnica de puntos de historia y valor del negocio

Requerimientos Valor de Negocio Puntos de Historia Cociente
R01 6 3 2
R02 7 1 7
R03 9 5 1.8
R04 3 3 1
R05 4 2 2
R06 5 4 1.25
R07 2 8 0.25

Técnica MoSCoW
Matriz de priorización
OPCIONES ESTUDIO VENTAS ATENCI CONOCIMIE TOT ORDEN
DE TELEFONIC ON AL NTO AL
MERCAD AS CLIENT TECNICO
EO E
ESTUDIOS 2 0.8 0 2.8 TERCE
DE RO
MERCADEO
VENTAS 1 1 0 2 CUART
TELEFONICA O
S
ATENCION 3 1 0 4 PRIMER
AL CLIENTE O
CONOCIMIE 1 1 1 3 SEGUN
NTO DO
TECNICO

Descomposición funcional
La descomposición funcional es un análisis método en el que se examinan
procesos complejos dividiéndolos en sus partes constituyentes. Realizar una
descomposición funcional significa primero definir una función general concisa que
se alinee con las metas un objetivo del proyecto .

GESTION DE COMERCIALIZACION
DE PRODUCTOS

GESTION DE CLIENTES GESTION DE PROVEEDORES GESTION DE PRODUCTOS

GESTIONAR GESTIONAR GESTIONAR GESTIONAR

INFORMES FACTURAS PEDIDOS ALTAS Y BAJAS