Tipos de Requerimientos

iTunes U - UAEH
10 Jan 201917:51

Summary

TLDREl video presenta una introducción a los tipos de requisitos en la ingeniería de software, impartido por Felipe de Jesús Núñez Cárdenas, maestro de tiempo completo en la Universidad Autónoma del Estado de Hidalgo. Se discuten los requerimientos funcionales y no funcionales, destacando la importancia de entender y definir estos para el desarrollo de productos de software que satisfagan tanto a los clientes como al mercado. Los requisitos funcionales se relacionan con las funciones que el software debe realizar, mientras que los no funcionales son restricciones o calidades que limitan la solución, como la usabilidad, eficiencia y conformidad con leyes y normas. Se ofrecen ejemplos prácticos y se destaca la necesidad de una guía para escribir requerimientos claros y consistentes, distinguiendo entre lo obligatorio y lo deseable, y evitando el lenguaje técnico cuando sea ambiguo o difícil de entender para el usuario final.

Takeaways

  • 📚 Los requerimientos son fundamentales en la ingeniería de software, ya que determinan cómo funcionará el sistema y son el base para el desarrollo y las pruebas futuras.
  • 🔍 La ingeniería de requisitos comienza con un análisis y la especificación de los mismos, que luego se reflejan en un documento formal llamado Especificación de Requerimientos (ER).
  • 👥 Los requerimientos funcionales se dividen en dos tipos: los del usuario, que son declaraciones en lenguaje natural sobre los servicios y restricciones esperadas, y los del sistema, que establecen los servicios y restricciones detallados.
  • 🛠️ Los requerimientos no funcionales son restricciones o requisitos de calidad que limitan la solución y pueden ser del producto, organizacionales o externos.
  • 📈 Un ejemplo de requerimiento no funcional del producto es el límite de espacio de almacenamiento que el sistema debe ocupar, como mencionado en el script.
  • 🏢 Los requerimientos organizacionales son aquellos que surgen de las políticas y procedimientos existentes dentro de una organización y que deben ser incluidos en el producto de software.
  • 📋 Los requerimientos externos son aquellos que provienen de factores fuera del sistema, como leyes o regulaciones, y que deben ser considerados en el diseño del software.
  • 💡 Para escribir requerimientos adecuadamente, se debe utilizar un formato estándar, mantener un lenguaje consistente y evitar la ambigüedad.
  • 📝 Se debe distinguir entre los requisitos obligatorios y deseables, ya que no todos los deseos del usuario son necesarios para el funcionamiento del software.
  • 🖍️ Resaltar el texto de los requerimientos para identificar las partes claves es recomendable para que el análisis sea más eficiente.
  • 🚫 Se debe evitar el uso de lenguaje técnico excesivo, optando por un lenguaje natural que sea comprensible tanto para el equipo de desarrollo como para el usuario final.
  • 📉 Ejemplos dados en el script incluyen requerimientos no funcionales enfocados en la eficiencia, usabilidad, fiabilidad y soporte, así como requerimientos funcionales específicos para el usuario o el sistema.

Q & A

  • ¿Qué es un requerimiento en la ingeniería de software?

    -Un requerimiento en la ingeniería de software es un elemento que determina cómo debe funcionar el sistema, incluyendo las necesidades de los usuarios y los estándares que debe cumplir el producto final.

  • ¿Cuáles son las dos categorías principales de requerimientos en la ingeniería de software?

    -Las dos categorías principales de requerimientos son los requerimientos funcionales y los requerimientos no funcionales.

  • ¿Qué se entiende por requerimientos funcionales?

    -Los requerimientos funcionales se refieren a las funcionalidades específicas que el software debe proporcionar, incluyendo los servicios y la reacción ante diferentes situaciones o entradas.

  • ¿Cómo se dividen los requerimientos funcionales?

    -Los requerimientos funcionales se dividen en requerimientos del usuario y requerimientos del sistema, con el primero enfocado en las declaraciones en lenguaje natural y diagramas, y el segundo en los servicios y restricciones detallados del sistema.

  • ¿Qué son los requerimientos no funcionales?

    -Los requerimientos no funcionales son aquellas restricciones o características que limitan la solución y no están directamente relacionadas con la funcionalidad del software, como la usabilidad, eficiencia y conformidad con las leyes y regulaciones.

  • ¿Cuáles son los tipos de requerimientos no funcionales?

    -Los tipos de requerimientos no funcionales incluyen los requerimientos del producto, los requerimientos organizacionales y los requerimientos externos.

  • ¿Cómo se pueden identificar los requerimientos del usuario en un producto de software?

    -Los requerimientos del usuario se identifican a través de declaraciones en lenguaje natural y diagramas que describen los servicios que se esperan que el sistema proporcione y las restricciones bajo las cuales debe operar.

  • ¿Por qué es importante diferenciar entre requerimientos obligatorios y deseables?

    -Es importante diferenciar entre requerimientos obligatorios y deseables para asegurar que el producto de software cumpla con las expectativas fundamentales y legales, mientras se mantiene flexible para incluir características adicionales deseadas pero no esenciales.

  • ¿Qué es el proceso de análisis y especificación de requerimientos en la ingeniería de software?

    -El proceso de análisis y especificación de requerimientos es la fase inicial en la que se identifican y documentan las necesidades de los usuarios, resultando en una especificación de requerimientos que servirá como base para el diseño y desarrollo subsiguiente del software.

  • ¿Cómo se debe escribir un requerimiento para que sea correcto y efectivo?

    -Un requerimiento debe escribirse utilizando un formato estándar, un lenguaje consistente y claro, distinguiendo entre lo obligatorio y lo deseable, resaltando las partes clave y evitando el uso de lenguaje técnico cuando no sea necesario.

  • ¿Cómo se relacionan los requerimientos con los casos de uso en la ingeniería de software?

    -Los casos de uso son una técnica utilizada para describir los requerimientos funcionales del sistema, mostrando cómo los usuarios interactuarán con el software para alcanzar objetivos específicos.

  • ¿Por qué es fundamental cumplir con los requerimientos no funcionales relacionados con la legalidad?

    -Cumplir con los requerimientos no funcionales relacionados con la legalidad es fundamental para asegurar que el software respete las leyes y regulaciones aplicables, evitando posibles sanciones o problemas legales y protegiendo los derechos de los usuarios.

Outlines

00:00

😀 Introducción a la Ingeniería de Requisitos

Este primer párrafo presenta el video y establece el tema de la discusión: los tipos de requerimientos en la ingeniería de software. Felipe de Jesús Núñez, el presentador y maestro de tiempo completo de la Universidad Autónoma del Estado de Hidalgo, introduce el concepto de requerimientos y su importancia en el desarrollo de productos de software. Se menciona que los requerimientos son cruciales para satisfacer las necesidades del cliente y del mercado, y que determinan cómo funcionará el sistema. Además, se destaca la importancia de la ingeniería de requisitos, que es el conjunto de métodos y técnicas para identificar y documentar estos requerimientos, y cómo estos son el punto de partida para el diseño del producto de software.

05:00

📚 Tipos de Requerimientos Funcionales y No Funcionales

El segundo párrafo profundiza en los tipos de requerimientos, particularmente en los funcionales y no funcionales. Se explica que los requerimientos funcionales se enfocan en las funciones que el software debe realizar, y se dividen en requerimientos del usuario y del sistema. Mientras tanto, los requerimientos no funcionales, también conocidos como restricciones o requisitos de calidad, limitan la solución y se dividen en requerimientos del producto, de la organización y externos. Se proporcionan ejemplos de cada tipo, como el almacenamiento máximo del sistema, la conformidad con normas de documentación y la protección de datos personales.

10:03

📝 Guía para Escribir Requerimientos Efectivos

Este párrafo ofrece una guía para escribir requerimientos de manera efectiva. Se sugiere el uso de un formato estándar para todos los requerimientos, la distinción entre requerimientos obligatorios y deseables, y la importancia de resaltar las partes clave del texto para facilitar la identificación por parte del analista. Se recomienda evitar el lenguaje técnico y optar por un lenguaje natural que sea comprensible tanto para el equipo de desarrollo como para el usuario final.

15:05

🎯 Ejemplos de Requerimientos y su Categorización

El cuarto y último párrafo presenta una serie de ejercicios con ejemplos de requerimientos, y cómo categorizarlos como funcionales o no funcionales. Se discuten casos específicos, como el diseño responsivo para múltiples plataformas, la tasa de tiempos de fallo, la conformidad con estándares de desarrollo de software y la inclusión de funcionalidades específicas como el registro de facturas manuales. Cada ejemplo se alinea con los conceptos previamente explicados, reforzando la comprensión de los diferentes tipos de requerimientos en la ingeniería de software.

Mindmap

Keywords

💡Requerimientos de software

Son los criterios y condiciones que un producto de software debe cumplir para satisfacer las necesidades de los usuarios y del mercado. En el video, se discute cómo los requerimientos son fundamentales para el desarrollo de un software y cómo determinan cómo funcionará el sistema final.

💡Ingeniería de requisitos

Es una rama de la ingeniería del software que se enfoca en el análisis, la especificación, la validación y la gestión de los requerimientos de un sistema. En el contexto del video, la ingeniería de requisitos es crucial para entender y documentar las necesidades del usuario y del sistema para el diseño y la implementación del software.

💡Requerimientos funcionales

Estos son los requerimientos que definen las funciones que el software debe realizar. En el video, se menciona que los requerimientos funcionales tratan específicamente de la función que el producto de software realizará, como los servicios que debe proporcionar y cómo debe reaccionar a diferentes situaciones.

💡Requerimientos no funcionales

Son los requerimientos que limitan la solución y se refieren a restricciones o características de calidad del software. En el video, se discute que los requerimientos no funcionales pueden incluir aspectos como la usabilidad, la eficiencia, la fiabilidad y la conformidad con leyes y regulaciones.

💡Especificación de requerimientos (LR)

Es un documento que detalla los requerimientos del sistema, tanto funcionales como no funcionales. En el video, se destaca que la LR es esencial para reflejar las necesidades de los usuarios y para que pueda ser utilizada en la fase de diseño del producto de software.

💡Casos de uso

Son una técnica utilizada en la ingeniería de requisitos para describir las interacciones entre los usuarios y el sistema. Aunque no se menciona directamente en el video, están relacionados con los requerimientos funcionales y son una forma de ilustrar cómo el software debe funcionar en diferentes situaciones.

💡Requerimiento del usuario

Se refiere a las necesidades expresadas por los usuarios en términos generales sobre lo que el sistema debería hacer. En el video, se da como ejemplo que el sistema debe permitir a los usuarios buscar el producto por nombre, número de factura o código de barras, lo que es un requerimiento funcional del usuario.

💡Requerimiento del sistema

Estos requerimientos definen con detalle los servicios y restricciones del sistema. En el video, se indica que los requerimientos del sistema establecen los servicios que el sistema debe proporcionar y las restricciones bajo las cuales debe operar, como parte de los requerimientos funcionales.

💡Requerimiento del producto

Se refiere a los requerimientos específicos que definen el comportamiento del producto de software, como la plataforma en la que se ejecutará, la usabilidad o la eficiencia. En el video, se menciona como un tipo de requerimiento no funcional que se enfoca en las características intrínsecas del producto.

💡Requerimiento de la organización

Estos son los requerimientos que surgen de las políticas y procedimientos existentes dentro de una organización. En el video, se discute cómo los requerimientos de la organización son importantes para que el producto de software se alinee con las expectativas y regulaciones internas de la organización.

💡Requerimiento externo

Son los requerimientos que provienen de factores externos al sistema, como leyes y regulaciones. En el video, se da como ejemplo que el sistema no debe revelar información personal de los clientes, excepto su nombre y número de referencia, debido a la ley de protección de datos de los usuarios.

Highlights

El video es presentado por el Sistema Ciencia Garza Educativa de la Universidad Autónoma del Estado de Hidalgo.

Felipe de Jesús Núñez Cárdenas, maestro de tiempo completo, habla sobre los tipos de requerimientos en la ingeniería de software.

Los requerimientos son cruciales para el desarrollo de productos de software que satisfacen tanto al cliente como al mercado.

La ingeniería de requisitos es el proceso que define los requerimientos del sistema.

Los requerimientos funcionales se dividen en dos tipos: del usuario y del sistema.

Los requerimientos funcionales del usuario se expresan en términos generales y se enfocan en los objetivos del sistema.

Los requerimientos funcionales del sistema describen los servicios y restricciones detalladamente.

Los requerimientos no funcionales son restricciones o requisitos de calidad que limitan la solución.

Existen tres tipos de requerimientos no funcionales: del producto, organizacionales y externos.

El requerimiento del producto se refiere a las características específicas del comportamiento del software.

Los requerimientos organizacionales derivan de las políticas y procedimientos internos de la organización.

Los requerimientos externos provienen de factores fuera del sistema, a menudo legales o regulatorios.

La guía para escribir requerimientos incluye usar un formato estándar, un lenguaje consistente y evitar la ambigüedad.

Los requerimientos deben distinguir entre lo obligatorio y lo deseable.

Se debe resaltar el texto para identificar las partes claves de un requerimiento.

Es recomendable evitar el uso de lenguaje técnico y optar por un lenguaje natural.

Los requerimientos se pueden clasificar en funcionales y no funcionales, con subtipos para cada categoría.

Los ejemplos prácticos proporcionados muestran cómo se aplican los requerimientos funcionales y no funcionales en diferentes contextos.

El cumplimiento con normas y leyes es esencial para los requerimientos no funcionales externos.

Transcripts

play00:00

y este vídeo es presentado por el

play00:07

sistema ciencia garza educativa de la

play00:09

universidad autónoma del estado de

play00:11

hidalgo

play00:12

para mayor información visítanos en

play00:16

www.hp.com x gracias por aprender

play00:28

hola que tal buenas redes

play00:30

mi nombre es felipe de jesús núñez

play00:32

cárdenas y soy maestro de tiempo

play00:34

completo y en la universidad autónoma

play00:36

del estado de hidalgo de escuela

play00:38

superior de huejutla estoy escrito al

play00:40

programa de ciencias computacionales y

play00:42

el día de hoy quiero platicarles sobre

play00:44

lo que son los tipos de requerimiento

play00:46

todo ello dentro de la ingeniería de

play00:49

sombras

play00:51

hablar de requerimientos es hablar de

play00:54

los productos de software que estamos

play00:56

teniendo ahorita a nosotros en qué

play00:58

contexto cada día más personas están

play01:02

reteniendo los productos de software

play01:04

estos productos de software tienen que

play01:06

ser desarrollados de acuerdo a ciertos

play01:08

requerimientos que solicitan tanto el

play01:11

cliente como el mercado en el cual se

play01:14

van a desarrollar por eso es bien

play01:16

importante que nosotros podamos decidir

play01:19

cuáles son los requerimientos y qué tipo

play01:22

de requerimientos podría tener un

play01:24

producto de software

play01:27

en la parte de los requerimientos entran

play01:30

dentro de un conjunto de métodos y

play01:34

técnicas que hacen toda la ingeniería de

play01:37

hecho la ingeniería se llama ingeniería

play01:38

de requisitos esta ingeniería de

play01:41

requisitos pues determina hay que

play01:45

recordar que los requisitos son los

play01:46

requerimientos determinan lo que era el

play01:48

sistema es decir cómo va a funcionar el

play01:51

sistema para que nosotros podamos al

play01:54

final de haber elaborado el producto de

play01:56

software poder hacerle pruebas sobre

play01:59

estos requerimientos que hemos

play02:01

determinado previamente y en una primera

play02:03

fase las fases de la ingeniería de

play02:06

software pues básicamente empieza con un

play02:08

análisis que donde desde donde está la

play02:12

ingeniería de requisitos

play02:14

la de licitación el análisis y la

play02:16

especificación de requisitos es

play02:18

prácticamente el proceso en el cual

play02:21

nosotros vamos a sacar las necesidades

play02:24

de los usuarios para poder reflejar las

play02:26

a través de un documento el documento

play02:30

llamado especificación de requerimientos

play02:33

o lr es también conocido en este

play02:35

contexto técnico de la ingeniería de

play02:37

software para que posteriormente pueda

play02:39

pasar a lo que es un diseño del producto

play02:43

de software que nosotros esperamos

play02:48

hablemos de los tipos de requerimientos

play02:50

o requisitos que hay dentro de los

play02:53

productos de software primeramente los

play02:56

requerimientos funcionales los

play02:58

requerimientos funcionales tratan

play03:01

específicamente de la función que va a

play03:04

realizar el producto de software con las

play03:06

diferentes funciones esto lo podemos

play03:10

definir como son los servicios que el

play03:13

sistema debe proporcionar como debe

play03:16

reaccionar a una entrada particular y

play03:18

cómo se debe comportar ante situaciones

play03:20

particulares de manera genérica es las

play03:23

funciones que va a desempeñar el

play03:26

producto de software dentro del contexto

play03:29

en que se va a manejar ahora estos

play03:33

requisitos funcionales se dividen en dos

play03:35

tipos de gente el usuario y del sistema

play03:38

primeramente del usuario se le pide que

play03:41

son declaraciones en lenguaje natural y

play03:44

en diagramas de los servicios que se

play03:46

esperan

play03:47

vaya a proveer y las restricciones bajo

play03:51

las cuales debe operar es decir

play03:54

regularmente esto obedece a la operación

play03:57

propia del sistema enfocada a los

play03:59

usuarios y el otro tipo de requerimiento

play04:03

funcional es el del sistema en este caso

play04:07

establece con detalle los servicios y

play04:09

restricciones del sistema

play04:11

vuelvo a repetir esto tiene que

play04:13

envolverse en un documento al final para

play04:16

poder

play04:19

la parte de diseño vamos a ver algunos

play04:21

ejemplos de este

play04:24

de estos tipos de requerimientos

play04:25

volvemos a recapitular tenemos el primer

play04:28

tipo de requerimiento es un

play04:30

requerimiento funcional y se divide el

play04:32

requerimiento de usuario y requerimiento

play04:35

del sistema por ejemplo tenemos un

play04:37

requerimiento para un producto de

play04:39

software en el cual nos dice el sistema

play04:41

debe permitir al usuario introducir los

play04:44

datos de los estudiantes nuevos de qué

play04:46

tipo de requerimiento estamos hablando

play04:49

primero lo vamos a llamar a lo macro y

play04:52

estamos hablando de un requerimiento

play04:53

funcional y después en base a los dos

play04:56

tipos que teníamos de usuarios del

play04:57

sistema podemos definirlo como que es un

play05:00

requisito de usuario

play05:01

expresado en términos generales es decir

play05:04

el servicio debe prestar el sistema el

play05:08

circuto enunciado tendríamos nosotros el

play05:10

sistema debe permitir a los usuarios

play05:13

buscar el producto por nombre el número

play05:15

de factura el código de barras aquí

play05:17

estamos hablando por ejemplo podría ser

play05:19

un producto de un punto de venta o un

play05:21

sistema integral

play05:22

una empresa en este contexto analizando

play05:26

el enunciado podemos hablar que también

play05:28

es un requisito funcional pero cae

play05:31

dentro del tipo de requerimiento del

play05:34

sistema ya que define la funcionalidad

play05:36

que va a ser el producto de software

play05:38

entonces básicamente tenemos en este

play05:42

contexto ya lo que es el requerimiento

play05:45

funcional o el requisito funcional

play05:47

primero describen el funcionamiento del

play05:50

sistema sin los requerimientos

play05:52

funcionales del usuario pueden ser para

play05:54

ser muy generales sobre lo que el

play05:56

sistema debería hacer se suelen expresar

play05:59

como objetivos del sistema y los

play06:01

requerimientos funcionales del sistema

play06:04

debe describir los servicios el prox

play06:06

plan con todos los detalles estos meses

play06:09

también se hace a través de los casos de

play06:11

uso que hablaremos en un curso posterior

play06:15

otros de los de la gratificación dentro

play06:19

de los tipos de requerimiento tenemos el

play06:23

requerimiento no funcionan este

play06:25

requerimiento no funcionan son aquellos

play06:28

que actúan para limitar la solución se

play06:31

les conoce como restricciones o

play06:33

requisitos de calidad

play06:34

aquí tenemos tres tipos de

play06:37

requerimientos o requisitos no

play06:39

funcionales tenemos

play06:41

o requisitos del producto de la

play06:44

organización y externos veremos qué es

play06:48

el requerimiento del producto es

play06:50

específica en el comportamiento que

play06:53

tiene que hacer el producto de software

play06:55

y habremos aquí desde la plataforma

play06:57

donde va por ella la usabilidad la

play07:00

eficiencia todo ello que conlleva al

play07:03

producto en requisito de la organización

play07:06

se deriva de las políticas y

play07:08

procedimientos existentes dentro de una

play07:10

organización la cual va a implantar un

play07:14

producto de software y como tal desean

play07:17

que algunas políticas se incluyan dentro

play07:19

de ese producto de software entonces es

play07:21

un requerimiento no funcional desde el

play07:24

punto de vista organizacional y por

play07:26

último tenemos requerimiento externo

play07:29

este requerimiento externo son

play07:31

requisitos que derivan de los factores

play07:33

externos al sistema obedecen

play07:35

regularmente a leyes

play07:38

algunas estructuras regulatorias como lo

play07:41

son por ejemplo si hablamos actualmente

play07:45

de un producto de un producto de

play07:47

software en donde no podemos mostrar

play07:49

todos los datos del usuario pues estamos

play07:51

acatando la ley de propiedad de datos de

play07:55

los usuarios y entonces son estos

play07:58

requerimientos que nosotros podemos

play08:00

nosotros consideran volvemos a

play08:03

recapitular hablamos ahora de un

play08:06

requerimiento no funcional que se divide

play08:10

tipos de requerimiento por producto el

play08:13

requerimiento organizacional y el

play08:16

requerimiento externo vamos a ver

play08:19

algunos ejemplos de esto y decimos como

play08:22

un requerimiento que hemos detectado en

play08:23

el producto de software que vamos a

play08:25

elaborar y decimos que el máximo espacio

play08:28

de almacenamiento ocupado por el sistema

play08:30

debe ser de 20 megas porque el sistema

play08:33

debe lograrse completamente en una

play08:35

memoria de sólo lectura o instalarse en

play08:38

dispositivos móviles como una fan

play08:40

entonces estamos hablando que es un

play08:42

requisito del producto el cual define

play08:44

una restricción del tamaño del producto

play08:47

que podemos tener otro de los

play08:50

requerimientos

play08:51

al siguiente el proceso del software y

play08:54

los documentos se deben realizar

play08:56

conforme al proceso de los estándares de

play08:59

documentación recogidos por la norma y

play09:01

triplay de 830 bueno básicamente esta

play09:04

norma la está manejando la organización

play09:07

y obedece a la forma de documentar

play09:09

algunas tendencias entonces es un

play09:12

requerimiento de la organización es un

play09:15

requerimiento no funcional y por último

play09:18

tenemos un enunciado el cual dice el

play09:21

sistema no debe revelar ninguna

play09:23

información personal sobre los clientes

play09:24

excepto su nombre y su número de

play09:27

referencia este ejemplo es un

play09:29

requerimiento externo y se deriva de la

play09:32

necesidad de cumplir con una legislación

play09:35

vigente sobre la protección de datos que

play09:37

era lo que comentaba hace un momento

play09:39

entonces aquí tenemos los ejemplos de lo

play09:43

que es un requisito o requerimiento no

play09:45

funcional sobre el producto podemos

play09:48

decir que existe una norma que podemos

play09:53

aplicar para poder sacar los

play09:55

requerimientos de o no funcionales de

play09:58

liberados del producto ésta es lo que

play10:02

conocemos como curso curso son las

play10:05

siglas en inglés en la cual se dice que

play10:08

la usabilidad la fiabilidad el

play10:12

performance y el del soporte al soporta

play10:15

bien en cuanto a la especialidad de uso

play10:18

o usabilidad muchas veces tenemos algún

play10:21

requerimiento como que el texto

play10:24

fácilmente se tiene que leer a una

play10:26

distancia de un metro por ejemplo ese es

play10:28

un requerimiento que me pide el cliente

play10:30

entonces es un requerimiento propiamente

play10:33

no funcional pero enfocado a la

play10:37

estabilidad del producto de software el

play10:39

otro que se refiere a la fiabilidad

play10:41

puede ser un ejemplo que si se produce

play10:44

algún fallo dentro del servicio puedes

play10:47

solucionarlo localmente

play10:49

ejemplos del rendimiento sería algo así

play10:52

como conseguir la actualización de pagos

play10:54

menos de un minuto en el 90 por ciento

play10:57

de las veces si nos fijamos todos estos

play11:00

requerimientos que estoy mencionando

play11:02

pues tienen que ver con el producto de

play11:04

software pero no aplican directamente su

play11:06

función por eso deriva de que es un

play11:09

requerimiento no funcional y por último

play11:11

es el soporte el sistema debe ser

play11:14

instalarle por los usuarios esto es lo

play11:16

que son algunos ejemplos aplicarnos

play11:19

vuelvo a repetir a detenimiento del

play11:20

producto dentro de la clasificación del

play11:24

requerimiento no funcional entonces

play11:27

podemos decir que recapitulando ya está

play11:33

clasificación que los requerimientos se

play11:36

pueden dividir en dos tipos funcionales

play11:39

y no funcionan dentro del funcional

play11:41

podemos mencionar que uno es enfocado al

play11:44

usuario requerimientos de usuario con

play11:46

requerimiento del sistema mientras que

play11:48

el no funcional puede ir un

play11:50

requerimiento sobre el producto sobre la

play11:52

organización

play11:54

externó ahora cómo podemos escribir

play11:57

nosotros requerimientos tenemos una

play12:00

pequeña guía para poder escribir

play12:01

requerimientos correctos y no sólo para

play12:03

repetir primero tenemos que inventar un

play12:06

formato estándar de utilizarlo para

play12:08

todos los requisitos básicamente de este

play12:10

formato nos diría cuál es el aire y del

play12:13

requerimiento qué tipo de requerimiento

play12:16

es y es funcional no funcional una

play12:18

entrada a una salida y sobre todo diría

play12:21

cuál es el proceso que si ese

play12:24

requerimiento para que nosotros podamos

play12:26

identificarlo podemos incluir en el

play12:29

documento de la especificación de

play12:31

requerimientos y se ha pasado a un área

play12:34

de diseño y otro esquema de la guía

play12:37

sería utilizar lenguaje de forma

play12:39

consistente no podemos hacer

play12:41

requerimientos ambiguos que por ejemplo

play12:44

un requerimiento ambiguo puede decir a

play12:46

que el sistema sea rápido pero pues

play12:50

rápido es muy subjetivo y podemos decir

play12:52

que para una

play12:53

persona es rápida alguna cosa y para

play12:55

otra no entonces ahí no estamos siendo

play12:57

consistentes en la forma en que estamos

play12:59

desarrollando nuestros requerimientos

play13:01

otro de la guía sería distinguir de los

play13:05

requisitos obligatorios y deseables

play13:07

muchas veces cuando estamos con los

play13:09

usuarios o los clientes cuando nos piden

play13:11

un requisito el requisito se vuelve como

play13:15

el lo que desearía el usuario que

play13:18

hubiera y no necesariamente tiene que

play13:21

ser obligatorio entonces tenemos que

play13:23

diferenciar entre un requisito que sea

play13:26

obligatorio para nuestro producto de

play13:28

software y otro que sea deseable para

play13:30

nuestro producto de software después

play13:32

tenemos otro esquema de este área para

play13:35

describir requisitos que es resaltar el

play13:38

texto para identificar las partes claves

play13:40

del requisito normalmente cuando

play13:42

nosotros estamos lavando un este un

play13:45

requisito que tenemos que sobresalta del

play13:48

texto para que el analista se dé cuenta

play13:51

cuáles son las partes fundamentales

play13:54

ese fin

play13:55

y por último se recomienda mucho evitar

play13:59

el uso del lenguaje técnico tiene que

play14:00

ser más un lenguaje natural donde

play14:02

podamos entender y puede entender el

play14:05

usuario qué es lo que pretende cubrir

play14:07

con ese requerimiento

play14:11

vamos a ver a continuación algunos

play14:14

ejercicios de que podamos nosotros

play14:19

de tipo de requerimiento vamos a ver el

play14:21

primero inicia el sistema en gramos

play14:23

correo electrónico cuando se ha elegido

play14:24

alguna de las siguientes transacciones

play14:26

un pedido de venta de cliente y despacho

play14:29

de mercancía bueno totalmente el primero

play14:32

vamos a alinearlos a qué tipo de

play14:34

requerimiento es dada esta

play14:36

característica tenemos que es un

play14:37

requerimiento funcional y cada día sobre

play14:41

un requerimiento del sistema propiamente

play14:43

dicho

play14:44

después tenemos otro ejemplo el otro

play14:47

ejemplo dice el sistema debe ser capaz

play14:48

de operar adecuadamente con hasta

play14:51

100.000 usuarios con sesiones

play14:53

concurrentes

play14:54

este esquema nos permite identificar

play14:56

primero qué es un requerimiento no

play14:58

funcional y a su vez es un requerimiento

play15:01

que va dirigido al producto en el cual

play15:04

estamos viendo que puede ser la

play15:07

eficiencia enfocada al producto de

play15:09

software el siguiente dice la aplicación

play15:12

debe poseer un diseño responsible a fin

play15:16

de garantizar la adecuada visualización

play15:17

en múltiples plataformas aquí estamos

play15:20

hablando de un requerimiento no

play15:22

funcional que va sobre la parte de la

play15:24

usabilidad

play15:25

si tenemos también otro detenimiento que

play15:29

es la tasa de tiempos de falla del

play15:31

sistema no podrá ser mayor a punto cinco

play15:34

por ciento del tiempo de operación total

play15:36

que es un requerimiento no funcional que

play15:40

va a aplicado directamente al producto y

play15:42

acá

play15:43

leyes que acabamos de ver de curso y la

play15:47

fiabilidad

play15:49

tenemos otros 4

play15:53

ejemplos y podemos decir el siguiente el

play15:56

procedimiento de desarrollo de software

play15:58

a usar debe estar definido

play16:00

explícitamente de acuerdo a los

play16:02

estándares iso 9000 en este caso estamos

play16:05

hablando de un requerimiento no

play16:06

funcional pero enfocado en la

play16:09

organización ya que la organización que

play16:11

está cumpliendo la norma iso 9000

play16:14

después tenemos que el sistema también

play16:16

permitirá el registro de facturas

play16:18

manuales no asociadas apellidos sin

play16:20

embargo ésta requerirá la autorización

play16:22

por parte del grupo de gerentes antes de

play16:24

ser contabilizados aquí estamos viendo

play16:27

un tipo de requerimiento funcional

play16:30

enfocado directamente a lo que es el

play16:33

sistema lo que después tenemos el campo

play16:37

estado ciudad del municipio consistirá

play16:40

en una lista de proyección y los

play16:41

usuarios podrán escoger de estas listas

play16:44

este también tenemos que es un

play16:46

requerimiento funcional enfocado

play16:49

directamente a los usuarios porque la

play16:52

forma de operar el sistema y por último

play16:54

tenemos

play16:55

páginas vuelve a desarrollar debe

play16:57

cumplir con la ley de tratamientos en

play16:59

condiciones de igualdad para personas

play17:01

con discapacidad estamos hablando de que

play17:04

es un requerimiento no funcional

play17:06

aplicado a un requerimiento externo

play17:09

hablo otra vez de este requerimiento

play17:11

externo básicamente nos aplicamos a la

play17:14

legalidad que establece para poder

play17:16

cumplir ciertos requisitos pues bueno yo

play17:19

espero que con éstas

play17:21

explicación hayamos comprendido que es

play17:25

un tipo de requerimiento y sobre todo

play17:28

los dos requerimientos que hay tanto

play17:29

funcional como no funcionan dentro del

play17:32

funcional volvemos a recapitular existen

play17:35

dos tipos de requerimientos de usuario

play17:37

del sistema y dentro del requerimiento

play17:39

no funcional existe el requerimiento del

play17:41

producto de organización y externo por

play17:45

su atención muchas gracias y que dos de

play17:48

ustedes para el siguiente curso

Rate This

5.0 / 5 (0 votes)

Etiquetas Relacionadas
RequerimientosIngeniería de SoftwareFuncionalesNo FuncionalesDocumentaciónEspecificaciónClientesMercadoDesarrolloLeyes de Protección de DatosISO 9000UsabilidadFiabilidadEficiencia