Especificación de requisitos

Summary

El script aborda la importancia de la especificación de requisitos en la ingeniería de software, destacando la necesidad de comprender y documentar las necesidades del cliente y los usuarios para diseñar un software efectivo. Se describe el proceso de ingeniería de requisitos, que incluye la deducción, análisis, negociación y documentación de los requisitos, y cómo estos deben ser validados y mantenidos a lo largo del tiempo. Se enfatiza la importancia de la comunicación entre los interesados y el equipo de desarrollo, y cómo el ingeniero de requisitos actúa como un puente entre ellos. Además, se mencionan técnicas como entrevistas, cuestionarios y prototipado para recolectar requisitos, y se destaca la importancia de la tipificación y la clasificación de los mismos. Finalmente, se discute la gestión de cambios en los requisitos y la necesidad de un comité de control de cambios para decidir sobre la inclusión de modificaciones en el proyecto.

Takeaways

• 📋 La especificación de requisitos es una parte crucial en la ingeniería de software, donde se definen las necesidades y deseos del cliente y los usuarios.
• 🔍 El ingeniero de software actúa como un detective para descubrir y documentar las especificaciones, que son esenciales para diseñar y crear un software válido.
• 🤝 Los interesados, incluyendo al cliente y los usuarios, son clave en la definición de los requisitos, ya que su visión直接影响最终的 software.
• 🛠️ La ingeniería de requisitos incluye principios, métodos, técnicas y herramientas que ayudan a recolectar, documentar y mantener los requisitos a lo largo del tiempo.
• 👥 Los roles del ingeniero de requisitos son variados y pueden incluir analista funcional, analista de negocio o programador, dependiendo de la organización.
• 📈 Un requisito de software es una necesidad que debe ser solicitada por los interesados y cubierta por el software para resolver un problema específico.
• 📝 La documentación de los requisitos es esencial, ya que actúa como un contrato entre el cliente y el equipo de desarrollo, detallando el problema y la solución.
• 🔄 Los requisitos pueden cambiar con el tiempo, por lo que es importante tener un proceso para gestionar y documentar estos cambios.
• 📉 Los requisitos se clasifican en funcionales y no funcionales, y se priorizan según la importancia y el costo para el proyecto.
• 📈 El proceso de ingeniería de requisitos comienza con la identificación de necesidades y concluye con la validación de los requisitos por parte del cliente.
• 🔗 Es importante que los documentos de requisitos sean claros, completos, correctos, comprensibles, verificables, consistentes, concisos, independientes, trazables y modificables.
• 🛑 Si surgen cambios en los requisitos después de la validación, se requiere la intervención del comité de control de cambios para decidir si estos cambios se integran en el proyecto actual o se posponen.

Q & A

¿Qué es la especificación de requisitos en la ingeniería de software?

La especificación de requisitos es una parte crucial de la ingeniería de software que involucra la identificación, análisis y documentación de los requerimientos del usuario y del software para construir un sistema que aborde un problema específico.

¿Cuáles son las tareas que se realizan en la ingeniería de requisitos?

Las tareas en la ingeniería de requisitos incluyen la recolección, análisis, documentación, validación y mantenimiento de los requerimientos del usuario y del software.

¿Qué son los 'roles' en el contexto de la especificación de requisitos?

Los roles son las funciones o responsabilidades que las personas o el equipo asumen durante el proceso de especificación de requisitos. Estos incluyen al ingeniero de requisitos, analista funcional, analista de negocio, y otros interesados en el proyecto.

¿Cómo es la relación entre un problema de ingeniería de software y un proyecto de desarrollo de software?

Un proyecto de desarrollo de software surge después de identificar un problema de ingeniería de software. Si no se detecta un problema que requiera una solución de software, entonces no es necesario un proyecto de desarrollo de software.

¿Quiénes son considerados 'interesados' en un proyecto de software?

Los interesados son todas las partes que tienen un interés en el proyecto de software, incluyendo al cliente, los usuarios finales, gerentes, expertos del negocio, proveedores y otros terceros que puedan verse afectados por el sistema.

¿Qué es un 'requisito de software'?

Un requisito de software es una necesidad que debe ser solicitada por los interesados y cubierta por el artefacto del software. Es una descripción detallada de lo que el software debe hacer para resolver el problema presentado por el cliente.

¿Cómo se abordan los cambios en los requisitos durante el tiempo?

Los cambios en los requisitos son manejados a través de la ingeniería de requisitos, que incluye técnicas y herramientas para soportar el mantenimiento de los requisitos, asegurando que los cambios sean documentados y comunicados adecuadamente.

¿Por qué es importante documentar los requisitos del software?

Es importante documentar los requisitos del software para asegurar una comprensión clara del problema y de la solución, actuar como un contrato entre el cliente y el equipo de desarrollo, y facilitar la validación y verificación de que el software cumple con las expectativas.

¿Cuáles son los tipos de requisitos que se pueden definir en un proyecto de software?

Los requisitos se pueden dividir en tres tipos principales: requisitos funcionales, que especifican las funcionalidades que el sistema realizará; requisitos no funcionales, que establecen restricciones a las funcionalidades; y requisitos en negativo, que especifican lo que el sistema no hará.

¿Qué es la 'ingeniería de requisitos' y qué elementos componen?

La ingeniería de requisitos es el conjunto de elementos, principios, métodos, técnicas y herramientas que rigen y facilitan la obtención y documentación de los requisitos de un proyecto de software. Incluye la sistemática de tareas que pueden repetirse y aplicarse a cualquier tipo de proyecto de ingeniería de software.

¿Cómo se asegura que los documentos de requisitos sean útiles y efectivos para el proyecto?

Los documentos de requisitos deben ser no ambiguos, completos, correctos, comprensibles, verificables, internamente y externamente consistentes, concisos, independientes, trazables, modificables, versionados, no redundantes, con un nivel de detalle adecuado, y organizados para una rápida navegación.

Outlines

00:00

😀 Introducción a la Especificación de Requisitos

Ezequiel Baldissoni introduce el tema de la especificación de requisitos en la ingeniería de software. Explica que este proceso es crucial para los proyectos y cubre la ingeniería de requisitos, las tareas realizadas, las herramientas y conocimientos necesarios. El curso proporciona a los alumnos los elementos para especificar requisitos de usuario y software, y entender los roles en la definición de requisitos. Se destaca que el desarrollo de un proyecto comienza con la identificación de un problema de ingeniería de software, proporcionado por el cliente. Se menciona que sin un problema de este tipo, no es necesario un proyecto de desarrollo de software. Además, se describe la importancia de las especificaciones brindadas por el cliente y los usuarios para la construcción del software.

05:02

🔍 Proceso de Ingeniería de Requisitos y su Sistematización

Se profundiza en la ingeniería de requisitos, abarcando elementos, principios, métodos y técnicas para recolectar y mantener los requisitos a lo largo del tiempo. Destaca la importancia de la documentación de los requisitos y cómo estos deben ser manejados y actualizados. Se menciona la especialización requerida para ser un ingeniero de requisitos y se define formalmente lo que es un requisito de software. Además, se plantean preguntas sobre qué hacer con los requisitos y se enfatiza la importancia de la documentación como solución para no depender únicamente de la memoria. Se describe el proceso de deducción de requisitos, análisis, negociación, documentación y validación con el cliente, destacando la posibilidad de que los requisitos cambien y la necesidad de un mantenimiento adecuado.

10:04

🤔 Identificación y Desafíos en la Recopilación de Requisitos

Se discuten los problemas que pueden surgir durante la fase de recolección de requisitos, como la dificultad de los usuarios para describir sus tareas o la falta de claridad en sus necesidades. Se presentan técnicas para abordar estos desafíos, incluyendo entrevistas, cuestionarios, herramientas de apoyo, observación, análisis de tareas, planteo de escenarios, procesos y prototipado. Se destaca la función del ingeniero de requisitos como puente entre los interesados y el equipo de proyecto, y la importancia de la comunicación eficaz en este proceso. Además, se menciona la transformación de requisitos no técnicos en requisitos entendibles por el equipo técnico.

15:04

📝 Documentación y Negociación de Requisitos

Se abordan los aspectos de la documentación de los requisitos, destacando la importancia de tener un solo documento que abarque todos los requisitos. Se describe la división de los requisitos en dos documentos: el documento de requisitos de usuario y el documento de especificación de requisitos de software. Se enumeran las características deseables de estos documentos, como la falta de ambigüedad, completitud, corrección, comprensibilidad y verificabilidad. Se insiste en la necesidad de versionado y se sugiere una estructura para la organización de los documentos. Además, se describe el proceso de validación de requisitos con el cliente antes del diseño del proyecto y cómo este proceso ayuda a evitar el trabajo en requisitos incorrectos o que puedan cambiar.

20:07

🔄 Gestión de Cambios en los Requisitos

Se aborda el tema de los cambios en los requisitos y cómo estos pueden afectar el presupuesto y los recursos asignados al proyecto. Se menciona el papel del comité de control de cambios, compuesto por diferentes actores que deciden si los cambios serán considerados en el proyecto actual o en futuros proyectos. Se describe la gestión de requisitos, que incluye la búsqueda de problemas, la realización de reuniones y la negociación de cambios. Se concluye con una ilustración gráfica que representa de forma humorística los desafíos en la comunicación y la implementación de los cambios en los requisitos, resaltando la importancia de un enfoque estructurado y colaborativo en el proceso de ingeniería de software.

Keywords

💡Especificación de requisitos

La especificación de requisitos es una parte crucial de la ingeniería de software que involucra la definición detallada de lo que el software debe hacer para satisfacer las necesidades de los usuarios y los objetivos del proyecto. En el video, se destaca que es esencial para entender y documentar las expectativas y soluciones propuestas, y es fundamental para el éxito del proyecto de software.

💡Ingeniería de requisitos

La ingeniería de requisitos es el campo que abarca la recopilación, análisis, y gestión de los requisitos de software. Se menciona en el video como un conjunto de elementos, principios, métodos, técnicas y herramientas que un ingeniero de requisitos utiliza para descubrir, documentar y mantener los requisitos a lo largo del tiempo.

💡Roles en la especificación

Los roles en la especificación son las diferentes personas o grupos que participan en el proceso de definición de los requisitos. El video habla sobre el cliente, los usuarios y otros interesados, quienes aportan sus perspectivas y necesidades al proceso. Estos roles son clave para asegurar que los requisitos aborden adecuadamente las expectativas y funcionalidades deseadas.

💡Documento de requisitos

El documento de requisitos es un artefacto que detalla todas las especificaciones, funcionalidades y restricciones del software. En el video, se resalta la importancia de este documento como una fuente centralizada y actualizada de información que guía el desarrollo y actúa como 'contrato' entre el cliente y el equipo de desarrollo.

💡Requisitos funcionales y no funcionales

Los requisitos funcionales describen las tareas y procesos que el software debe realizar, mientras que los requisitos no funcionales establecen restricciones o condiciones que deben cumplirse, como el rendimiento, la usabilidad o la seguridad. En el video, se explica que estos tipos de requisitos son esenciales para definir completamente lo que el software debe hacer y cómo debe hacerlo.

💡Proceso de ingeniería de requisitos

El proceso de ingeniería de requisitos es una secuencia de fases que incluye la deducción, análisis, negociación, documentación y validación de los requisitos. El video describe este proceso como una guía para los ingenieros de requisitos para asegurar una comprensión clara y un acuerdo sobre los requerimientos del software.

💡Cambio de requisitos

El cambio de requisitos es un aspecto inevitable en el desarrollo de software que ocurre cuando las necesidades del cliente o el entorno cambian. El video discute la importancia de gestionar estos cambios a través de un comité de control de cambios y la gestión de requisitos para minimizar el impacto en el proyecto.

💡Validación de requisitos

La validación de requisitos es la etapa en la que se confirma que los requisitos recopilados son correctos, completos y viables. El video subraya que este proceso es crucial para evitar el trabajo en requisitos incorrectos y asegurar que el software desarrollado cumpla con las expectativas del cliente.

💡Comité de control de cambios

El comité de control de cambios es un grupo compuesto por diversos interesados que deciden si los cambios propuestos en los requisitos serán incorporados al proyecto. En el video, se describe su función como la de gestionar y controlar los cambios para evitar desvíos en el presupuesto y el plazo del proyecto.

💡Gestión de requisitos

La gestión de requisitos es el trabajo continuo de monitorear, evaluar y administrar los cambios en los requisitos a lo largo del tiempo. El video menciona que este esfuerzo es esencial para adaptarse a los cambios en el entorno y garantizar que el software desarrollado siga siendo relevante y útil.

💡Clientes y usuarios

Los clientes son las partes interesadas que solicitan una solución de software, mientras que los usuarios son quienes interactuarán directamente con él. En el video, se destaca la diferencia entre estos roles y cómo su colaboración es fundamental para el descubrimiento y la comprensión de los requisitos del software.

Highlights

La importancia de la especificación de requisitos en la ingeniería de software para el éxito de los proyectos.

Descripción de las tareas y herramientas utilizadas en la ingeniería de requisitos.

El papel del cliente y los usuarios en la definición de las especificaciones del software.

La distinción entre problemas de software y problemas no relacionados con el software.

La necesidad de documentar los requisitos para un diseño adecuado del artefacto de software.

La ingeniería de requisitos como una disciplina sistemática que abarca principios, métodos, técnicas y herramientas.

El papel del ingeniero de requisitos, también conocido como analista funcional o de negocios.

La definición formal de un requisito de software y su relación con el problema que resuelve.

La importancia de la documentación y mantenimiento de los requisitos a lo largo del tiempo.

La tipificación de requisitos y su utilidad para mejorar la definición de los mismos.

La categorización de requisitos en funcionales y no funcionales, y su impacto en el diseño del software.

El proceso sistemático de ingeniería de requisitos que incluye deducción, análisis, negociación y documentación.

La interacción entre los diferentes roles involucrados en la definición de los requisitos.

Las técnicas utilizadas para recolectar información de los interesados, como entrevistas y cuestionarios.

El análisis y modelado de requisitos para comprender y comunicar las necesidades del proyecto.

La negociación con el cliente como un paso crucial para definir los requisitos finales del software.

La documentación de requisitos como un contrato entre el cliente y el equipo de desarrollo.

La validación de requisitos con el cliente antes del diseño y la programación.

La gestión de cambios en los requisitos y el papel del comité de control de cambios.

El impacto de los cambios en los requisitos en el presupuesto, el tiempo y la satisfacción del cliente.

Transcripts

hola mi nombre es ezequiel baldissoni y

voy a explicar de qué se trata esta

parte tan importante para los proyectos

de ingeniería de software llamada

especificación de requisitos en este

curso se verá que es la ingeniería de

requisitos cuáles son las tareas que se

realizan en este ámbito de la ingeniería

de software cuáles son las herramientas

de conocimiento y demás herramientas con

el que se cuenta para realizar las

tareas y detalles de cada una de las

mismas

este curso brinda al alumno todo lo

necesario para especificar requisitos de

usuario y de software explica cuáles son

los roles involucrados en las tareas de

específicas requisitos y da una noción

de qué función cumple cada rol en cuanto

a las definiciones de lo que debe hacer

el software que se va a construir

todo proyecto de desarrollo es creado

luego de que se descubra un problema de

ingeniería de software este problema lo

detecta el cliente que solicita una

solución

sin un problema de este tipo podemos

afirmar que no es necesario un proyecto

de desarrollo de software por ejemplo si

a una oficina se le voló el techo por un

desastre climático este problema ya no

es un problema de software por ende

correspondería a otro equipo oa otro

proyecto

este problema cuenta con una serie de

especificaciones que lo detallan y que

de alguna forma delimitan sus partes y

son aportadas por el cliente y los

usuarios

el cliente es el mayor interesado en

buscar una solución pero los usuarios

son quienes utilizarán el software por

lo que deben ser considerados a la hora

de escuchar su versión del problema a

estos factores el cliente y los usuarios

se los denomina comúnmente de los

interesados las especificaciones que

describen los interesados y anne al

ingeniero del software en la realización

del artefacto de software por ende es él

quien debe detectarlas y documentar las

para que luego el equipo elija la mejor

manera de solucionarlo es importante

aclarar que una definición correcta de

estas especificaciones logran un diseño

adecuado del artefacto y terminan en un

software válido para el cliente que lo

solicita luego de haber explicado esto

podemos decir que las especificaciones

son los requisitos que el artefacto

software debe cumplir para solucionar el

problema que el cliente presenta para

poder lograr obtener todos estos

requisitos es necesario recurrir a la

ingeniería de requisitos

entonces surge una pregunta que es la

ingeniería de requisitos la ingeniería

de requisitos abarca una serie de

elementos

los principios que rigen e ingeniería de

requisitos los métodos que se utilizan

para recolectar los requisitos las

técnicas utilizadas y disponibles para

esto y las herramientas con las cuales

el ingeniero de requisitos cuenta para

lograr su cometido

estos elementos colaboran con el

descubrimiento de las definiciones del

problema con la documentación de las

mismas y dado que los requisitos pueden

cambiar en el tiempo también dan apoyo a

su mantenimiento la ingeniería de

requisitos es estudiada por muchos

autores por lo que cuenta con una

sistematización de las tareas lo que la

hacen repetible por ende sirven para

todo tipo de proyectos de ingeniería eso

la ingeniería de requisitos si bien es

aplicada por un ingeniero de software

éste debe especializarse y tomar el rol

de ingeniero de requisitos también

conocido como analista funcional

analista de negocio o analista

programador o también existen otras

definiciones pero todo depende de la

organización en la cual trabajó hasta

acá sólo definimos algunas cosas y dimos

un poco más de visibilidad del rol del

ingeniero

la siguiente pregunta es que es un

requisito un requisito de software esto

la necesidad de ser solicitado por el

interesado o por los interesados que se

deben cubrir con un artefacto del

software estos grandes rasgos cubre

cualquier tipo de requisito del software

ahora formalmente es un problema de

software p que se soluciona configurando

una máquina m para que ejerza un efecto

o requisito de red dentro de un dominio

de parece bastante confuso pero es

sencillo los efectos son el software que

realiza tareas que cumplen con la

solución del problema qué es lo que el

cliente necesita o desea el dominio es

el contexto en el cual están embebidos

los requisitos y la máquina m es la que

realiza los efectos seres que se

ejecutan en el dominio de

el ingeniero de requisitos solo

investiga o trabaja intentando obtener y

documentar el dominio la conexión de la

máquina m con el dominio y los

requisitos

dejando de lado como lo hará o sea lo

que sería el comportamiento interna de

la máquina en pocas palabras el software

en sí luego de definir lo que es un

requisito surge la siguiente pregunta

qué hacemos con los requisitos sería muy

fácil escuchar al cliente recordar todo

lo que se charló y luego contarle al

equipo lo que quiere pero esto no es

posible bajo ningún punto de vista por

lo que se hace mucho hincapié y mucho

hincapié en documentar los requisitos

una buena solución a esto es almacenar y

mantener el documento de requisitos en

este caso los requisitos se almacenan se

eliminan o se actualizan en el documento

de requisitos

este documento cuenta con

información detallada sobre el problema

propiedades y comportamiento deseado del

sistema restricciones de diseño y

fabricación del producto en caso de que

sean especificadas por el cliente una

descripción de cómo el sistema ayudará a

los usuarios a realizar sus tareas

restricciones en cuanto a la tecnología

que será utilizada en la construcción

del artefacto restricciones de

funcionamiento

para que los requisitos sean entendidos

como tales es muy importante

describirlos de la forma correcta

por ejemplo el sistema era tal o cual

cosa el producto solucionará tal o cual

problema o cuestiones también como

diagramas o anotaciones formales como

ser casos de uso historia del usuario

esto depende directamente la metodología

a utilizar y de las costumbres del

equipo de ingeniería de software

finalmente se definen al momento de

diseñar o especificar la metodología de

trabajo por ejemplo las metodologías

ágiles suelen usar historias de usuario

las metodologías basadas en caso de uso

suelen usar casos de uso las

metodologías tradicionales pueden usar

diagramas de flujo de datos

en este caso una parte de requisitos

sería el diagrama de contexto etcétera

para mejorar la definición de los

requisitos es posible utilizar la

tipificación las más conocidas son

definiciones sobre efectos sobre el

entorno cosas que provoca el sistema

sobre el ambiente muy generales los

exquisitos que por sí solo apuntan a

varios problemas por ejemplo generar una

bm para todas las tablas

en la dm alta baja y modificación de

tablas funcionales cosas que se refieren

a funcionalidades necesarias del sistema

de implementación relacionados al

ambiente en donde estará implementado el

sistema de rendimientos restricciones

sobre cuál será el rendimiento del

sistema frente a situaciones que lo

requieran y de usabilidad relacionados a

producto diario del sistema dado que el

documento de requisitos actúa de alguna

manera como contrato ya que define

detalles del problema y la solución

podemos de dividir los requisitos en

tres grandes grupos o tipos que dan

lugar a lo que el sistema hará o no

requisitos en negativo especifican lo

que el sistema no hará de ninguna manera

los requisitos funcionales especifican

las funcionalidades que el sistema

realizará requisitos no funcionales que

especifican restricciones a los

anteriores o sea son restricciones a los

requisitos funcionales un requisito

funcional podría llegar a ser el sistema

presentará una ventana para ingreso de

usuario y un no funcional podría ser el

usuario se validará en menos de 5

segundos

es una restricción al funcionar hasta

este momento sabemos que es un requisito

cuáles son los roles que interactúan en

la definición de los mismos donde serán

almacenados y mantenidos y cómo es la

mejor manera de redactar los y

organizados como dijimos en una

instancia anterior las tareas del

ingeniero de requisitos están

sistematizados esta sistematización es

guiada por un proceso que cuenta con

fases y técnicas estos están a su vez

guiados y mantenidos por estándares como

ser el 830 mil 983 the light triple o el

pss

05 de la agencia espacial europea un

proceso válido puede ser el siguiente

todo comienza con una necesidad lo que

dijimos en un principio el siguiente

paso sería una deducción de los

requisitos que darían lugar al análisis

negociación de los requisitos

luego una documentación de los

requisitos que genera el documento y por

último ese documento y esa definición

del documento será validada con el

cliente en una etapa de validación de

requisitos

y la variación de requisitos no es

positiva podría llegar a requerir volver

a una instancia anterior del proceso lo

que sigue es mostrarles cómo debe ser

utilizado este proceso el proceso

comienza con el problema que mencionamos

que son las necesidades o deseos el

dominio los estándares que impone el

cliente entre otros el trabajo del

ingeniero requisitos comienza con la

deducción de los requisitos que son

estos detalles o características del

problema que nos sirven de guía o sea el

problema en un principio es una

descripción muy amplia que luego es

necesario detallar para poder detallar

el problema es necesario capturar y

descubrir nuevos requisitos pero para

esto es necesario conocer quiénes son

los interesados ya que en un principio

sólo conocemos al cliente que es quien

nos solicita la solución

los interesados son gerentes

involucrados por ejemplo en los procesos

de la organización que luego serán

influenciados por el sistema de software

los expertos del negocio todo aquel

personal de la organización que se ha

influenciado por el sistema proveedores

otras personas

terceros etcétera por supuesto los

usuarios que manipularan este sistema

estos actores servirán de fuente de los

requisitos

con qué problema nos podemos encontrar

en esta fase bueno por ejemplo los

usuarios no pueden describir todas sus

tareas o en ocasiones no tienen claro o

no saben cuáles son en su totalidad

también a veces es difícil verbalizar de

forma correcta a cierta información hay

otros casos en los que hay que inventar

nuevos requisitos para cubrir baches es

necesario arrancarle de información a

las personas cuando en realidad deben

colaborar con el proyecto para

recolectar los requisitos faltantes del

ingeniero de requisitos cuenta con una

serie de técnicas entrevistas

cuestionarios o herramientas las

entrevistas son generalmente cara a cara

donde se hacen preguntas el usuario o el

entrevistado responde las preguntas

pueden ser abiertas dándole espacio al

entrevistado a que responda lo que él

quiera o pueden ser cerradas dándole a

de entrevista dos respuestas simples

como si no múltiples opciones los

cuestionarios son un tipo de entrevista

en la cual no es cara a cara sino que se

le hace al usuario bueno es la persona

completarlas y están formados por las

mismas

sean los mismos tipos de preguntas otra

cosa son las herramientas hub son

herramientas completas para el ingeniero

de requisitos en las cuales se les

facilita toda esta tarea

otra forma es observación y análisis de

tareas donde puede sentar al lado de la

persona y ver lo que es lo que hacen en

su ámbito de trabajo entonces ahí en ese

momento interpretar cómo son sus tareas

la otra zona el planteo de escenarios y

procesos de donde uno puede describir

después un escenario un proceso y el

usuario puede llevarlo a cabo y validar

si es correcto o no otra forma es el

prototipado evolutivo y desechable donde

se presenta un prototipo y es útil

cuando no es claro o hay incertidumbre

en el contexto de uso del sistema el

prototipado evolutivo generalmente parte

del prototipo donde se le muestra el

cliente y luego evoluciona al arte

factor software en cambio el desechable

o descartable una vez que compre su

función de ser el prototipo para

demostrar el cliente es desechado y nos

sirve más

una vez que el ingeniero de requisitos

cuenta con la totalidad de los

requisitos o sea los interesados no

aportan más información comienza la

etapa de análisis en esta etapa se

transforman los requisitos que fueron

por gente en negocios a requisitos

entendibles por el equipo de proyecto

esta etapa representa el puente entre

los interesados y el resto del equipo

otra forma de verlo es como el traductor

entre el personal de la organización que

espera la solución software y el equipo

en que mide eso

este chiste ilustra de forma gráfica la

realidad de la comunicación entre

usuarios

en la parte de arriba se puede ver a los

usuarios viendo al ingeniero de software

como un marciano que no se entiende lo

que dicen y una parte de abajo se puede

ver al ingeniero de software conservando

a los usuarios que son como cavernícolas

que no saben cómo expresar sus deseos y

necesidades y que además no saben

utilizar el software vamos a destacar

entonces el rol del traductor y el rol

de unir con un puente los dos sectores

involucrados que son tan diferentes

luego de traducir los requisitos en esta

etapa se comienza a clasificar los

requisitos con el fin de de separarlos

de alguna forma como para entender qué

papel cumple cada uno se puede

clasificar pro funcionales o no

funcionales dando a entender cuáles son

funcionalidades y cuáles son

restricciones a esas funcionalidades

otra forma es por prioridades esto

ayudaría al resto del equipo para

entender cuáles se deben resolver

primero o cuáles no según la importancia

del cliente por ejemplo

una pantalla urgente o una funcionalidad

urgente es recomendable darle más

prioridad de ese requisito que en los

demás también se pueden clasificar por

costo dando un valor del costo que

representa para el presupuesto del

proyecto por niveles de alto bajo medio

según su volatilidad vuestra habilidad

para entender si el requisito va a

cambiar en mayor o menor medida a través

del tiempo o también requisitos sobre el

proceso sobre el producto luego de

contar con los requisitos clasificados

comience el modelado de los requisitos

donde se comience a esbozar los

requisitos hay quienes utilizan

diagramas de contexto otros usan casos

de uso otro también son historia de

usuario todo depende de la naturaleza

del problema la experiencia de que en

módena las herramientas con la que se

cuenta lo que el cliente quiere o

incluso de la cultura del personal la

mejor forma de modelar los requisitos es

aquella que es entendida por el resto de

los integrantes del proyecto ya sean los

interesados como los miembros del equipo

de ingeniería de software

lo que sí es la negociación con el

cliente aquí se decide el cierre de los

requisitos y es donde se debate qué

requisitos se tomarán para el proyecto y

cuáles serán descartados y tomados para

futuros proyectos en pocas palabras se

negocia lo que se hará y lo que no será

todo lo que se negoció él debe ser

claramente expresado y validado con el

cliente cada aclarar y se hace mucho

hincapié que todos los requisitos deben

ser negociados y nunca tomar decisión

propia sobre los mismos el cliente

siempre tiene la última palabra sobre

sobre los requisitos

luego de haber negociado con el cliente

se presenta la etapa de documentación

como dijimos anteriormente la

documentación se realiza sobre el

documento de requisitos ahora sí tenemos

un solo documento que abarque todos los

requisitos que los interesados describen

y todos los requisitos que son

traducidos al lenguaje técnico sería muy

confuso

para evitar esto se divide en los

requisitos en dos documentos

el documento de requisitos de usuario

contiene todo lo que los interesados

describen del problema con un lenguaje

adaptado al negocio o el contexto

el documento de especificación de

requisitos de software de un documento

de requisitos de software se detalla lo

que el software debe hacer con un

lenguaje más técnico había adaptado al

lenguaje del grupo o del equipo de

ingeniería de software

estos documentos deben cumplir con una

serie de características deseables como

no será ambiguo si todos los requisitos

se interpretan de una sola manera deben

ser completos abarcando todas las

necesidades y deseos de los interesados

los documentos deben ser correctos

representando cada requisito una

necesidad real del negocio comprensible

o entendible por todos los actores

verificable ya que una vez terminado el

software debe controlarse que se cumple

con la totalidad de diferentes

internamente consistente no debe haber

contradicciones entre requisitos

externamente consistente debe existir un

hardware que los soportes realizables o

sea que todos requisitos debe ser

posible de traducirlo en un software

conciso breve debe ser independiente de

un solo diseño trazable o referencia

hablé con la evolución del proyecto o

sea y debe poder relacionarse con una

parte que representa el diseño o el

código o también en tests modificables

ya que pueden cambiar almacenados

electrónicamente en un archivo o por una

herramienta en caso de usar una

herramienta para los requisitos que se

traduzcan en diseños o códigos deben

darse a la misma en caso de haber

clasificado por importancia o por

estabilidad o volatilidad deben ser

ordenados por este valor

los documentos siempre deben estar

versionados y hago hincapié en esto si

cambia lo más mínimo cualquier requisito

debe cambiar la versión a la revisión no

redundante solo debe estar anotado en un

lugar nivel de extracción adecuado o sea

no debe tener ni mucho detalle ni poco

los documentos de bien se precisa

dándole valores para precisar

características como ser un ejemplo si

el sistema tendrá pocas opciones

tendríamos que haber puesto el sistema

cuenta con cinco opciones obligatorias y

dos opcionales

utilizables o sea que existente el place

del documento que pueden ser utilizados

en nuestros proyectos trazados o sea dar

información de quién origina el

requisito quien lo cambio quien pidió

eliminarlo de está organizado para poder

ir rápidamente a la información deseada

con referencias cruzadas en caso de que

uno haga referencia a otro oa otra

sección en el documento una vez

realizados los documentos siguiendo

estas características es el momento de

presentárselo al cliente y quien dará el

visto bueno tendrá

esto que acabo de decir es para lo que

sirve la etapa de validación esta etapa

es el paso previo al diseño por lo que

evita que el equipo se ponga a trabajar

en requisitos que podrían ser

incorrectos o podrían tener cambios

futuros por insatisfacción del cliente

es el cliente quien tiene que decidir

ciertos son correctos o válidos para

comenzar a comprometer recursos o sea

comenzar con el gasto del presupuesto

del cliente si el cliente no está de

acuerdo el proceso comienza desde la

etapa necesaria por ejemplo podría que

recomenzar por la reducción de

requisitos por el análisis sin

negociación por la documentación de

requisitos o comenzar con un nuevo

proyecto con nuevas necesidades e

información de dominio o estándares

en la validación suelen utilizarse las

revisiones para evitar problemas futuros

en los requisitos consta de tres etapas

la búsqueda de problemas reunirse con el

cliente establecer acuerdos sobre las

diferencias encontradas luego que el

cliente válido los requisitos

el equipo puede comenzar a trabajar en

base a este documento cuando el equipo

se pone a trabajar y el proyecto está en

marcha

los integrantes pueden detectar

faltantes o problemas puede ser que el

cliente cambia los requisitos también

puede cambiar el entorno como hacer

leyes o normas por motivos de mejoras

puede cambiar el hardware que soporta el

sistema incluso la organización cambia

su forma de trabajar todo esto puede

hacer que los requisitos cambien también

si el proceso terminó y surgen más

cambios es necesario ponerse de acuerdo

con las partes el problema aquí es que

ya se cerró un presupuesto el personal

involucrado y los tiempos establecidos

si existen un cambio en los requisitos

alguna parte del proyecto cambiará

algunos de los involucrados verá una

pérdida de su dinero o de su tiempo

debido a estos cambios por esto entre el

comité de control de cambios este comité

está conformado por una serie de actores

que deciden si los cambios serán tenidos

en cuenta en este proyecto o serán

dejados de lado y tenidos en cuenta en

futuros proyectos puede estar formado

por algunos o varios interesados

el ingeniero de software alguna persona

del equipo de desarrollo otros

involucrados como ser proveedores o

terceros y te comenté controlar las

revisiones de los requisitos el trabajo

que realiza el comité se conoce como

gestión de requisitos y es donde se

buscan problemas se realizan reuniones y

se establecen acuerdos todos sobre los

cambios bueno este es el fin de este

curso dejo esta esta imagen que

seguramente ya la hayan visto en otros

lados

esta imagen expresa bien cómo es que se

producen los cambios en los requisitos

según quien lo interpreta

por ejemplo la solicitud del usuario es

una marca con tres tablas lo que atendió

el líder de proyecto o sea el ingeniero

de software es una marca que va apoyada

en el árbol

en diseño del analista de sistemas

sucede el ingeniero de requisitos es un

árbol que hay que partir para que la

marca pase el programador terminó atando

la hamaca al árbol y ni siquiera explota

la recomendación del consultor externo

algún concepto de esta noche que se haya

integrado algún tercero es que se ponga

un sillón espectacular esté cómodo

la documentación termina siendo

inexistente

la implantación en producción termina

siendo una soga colgada el presupuesto

del proyecto fue para una montaña rusa

el soporte operativo luego de la

implementación es el árbol este que ni

siquiera existe está cortado y lo que el

usuario realmente necesitaba que era

unas horas con una rueda cuerda

espero que les haya servido llega hasta

la próxima