Especificación de requisitos
Summary
TLDREl 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
😀 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.
🔍 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.
🤔 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.
📝 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.
🔄 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.
Mindmap
Keywords
💡Especificación de requisitos
💡Ingeniería de requisitos
💡Roles en la especificación
💡Documento de requisitos
💡Requisitos funcionales y no funcionales
💡Proceso de ingeniería de requisitos
💡Cambio de requisitos
💡Validación de requisitos
💡Comité de control de cambios
💡Gestión de requisitos
💡Clientes y usuarios
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
5.0 / 5 (0 votes)