#LyX 2.3 created this file. For more info see http://www.lyx.org/ \lyxformat 544 \begin_document \begin_header \save_transient_properties true \origin unavailable \textclass book \use_default_options true \begin_modules algorithm2e \end_modules \maintain_unincluded_children false \language spanish \language_package default \inputencoding auto \fontencoding global \font_roman "default" "default" \font_sans "default" "default" \font_typewriter "default" "default" \font_math "auto" "auto" \font_default_family default \use_non_tex_fonts false \font_sc false \font_osf false \font_sf_scale 100 100 \font_tt_scale 100 100 \use_microtype false \use_dash_ligatures true \graphics default \default_output_format default \output_sync 0 \bibtex_command default \index_command default \paperfontsize default \spacing single \use_hyperref false \papersize default \use_geometry false \use_package amsmath 1 \use_package amssymb 1 \use_package cancel 1 \use_package esint 1 \use_package mathdots 1 \use_package mathtools 1 \use_package mhchem 1 \use_package stackrel 1 \use_package stmaryrd 1 \use_package undertilde 1 \cite_engine basic \cite_engine_type default \biblio_style plain \use_bibtopic false \use_indices false \paperorientation portrait \suppress_date false \justification true \use_refstyle 1 \use_minted 0 \index Index \shortcut idx \color #008000 \end_index \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \paragraph_indentation default \is_math_indent 0 \math_numbering_side default \quotes_style french \dynamic_quotes 0 \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \html_math_output 0 \html_css_as_file 0 \html_be_strict false \end_header \begin_body \begin_layout Standard Un \series bold documento de requisitos \series default ( \series bold del proyecto \series default ) o \series bold especificación funcional \series default combina un SRS y un SyRS. Contiene un conjunto exhaustivo y preciso de los requisitos, validados, y sirve como contrato entre el cliente y los desarrolladores. \end_layout \begin_layout Standard Se prepara en un bucle de 4 fases: \end_layout \begin_layout Enumerate \series bold Obtención \series default , en que se determinan los requisitos para llegar un conocimiento suficiente del problema y establecer los límites del sistema. \end_layout \begin_layout Enumerate \series bold Análisis \series default , en que se examinan los requisitos para delimitarlos y definirlos exactamente. \end_layout \begin_layout Enumerate \series bold Especificación \series default , en que se escriben los requisitos. \end_layout \begin_layout Enumerate \series bold Validación \series default , en que se examina si los documentos de requisitos definen el software que los usuarios esperan. \end_layout \begin_layout Standard Los requisitos se pueden definir mediante: \end_layout \begin_layout Itemize \series bold Lenguaje natural. \series default Si el texto es preciso, es lo más fácil de entender, pero si la especificación es grande o compleja puede no ser manejable. \end_layout \begin_layout Itemize \series bold Texto y técnicas \series default intuitivas o formales, como diagramas, lenguajes de descripción de diseños o especificaciones lógicas formales. Es lo ideal para sistemas de tamaño medio o grande. \end_layout \begin_layout Itemize \series bold Solo técnicas. \series default Difícil de entender y rastrear. \end_layout \begin_layout Section Estándares \end_layout \begin_layout Standard La NASA, la ESA y el Departamento de Defensa de EE.UU. tienen sus propios estándares para especificación de requisitos, pero los más usados son: \end_layout \begin_layout Itemize \series bold \emph on \lang english IEEE Std. 830:1998, Recommended Practice for Software Engineering Requirements Specificat ion \emph default . IEEE Computer Society (1998) \lang spanish . \end_layout \begin_deeper \begin_layout Standard \begin_inset Note Comment status open \begin_layout Plain Layout Es una revisión del 830:1993 adaptada a ISO/IEC 12207, Procesos del Ciclo de Vida del Software. \end_layout \end_inset Describe el contenido y las cualidades de un buen documento de SRS y presenta modelos para organizar requisitos específicos. \end_layout \end_deeper \begin_layout Itemize \series bold \emph on \lang english ISO/IEC/IEEE 29148:2018, Systems and software engineering—Life cycle processes—R equirements engineering \emph default \lang spanish . \end_layout \begin_deeper \begin_layout Standard Suplanta al anterior \begin_inset Note Comment status open \begin_layout Plain Layout y armoniza IEEE 830, IEEE 1223, ISO/IEC 12207, IEEE 24765 (Vocabulario), ISO/IEC TR 19759 (SWEBOK) y otros \end_layout \end_inset . Incluye otros procesos y actividades relacionados con la ingeniería de requisitos, no solo la SRS, como la SyRS y la especificación de requisitos de \emph on \lang english stakeholders \emph default \lang spanish (StRS). \end_layout \end_deeper \begin_layout Standard Según estos estándares, la SRS debe incluir: \end_layout \begin_layout Itemize \series bold Funcionalidad \series default del software. \end_layout \begin_layout Itemize \series bold Interfaces externas \series default con el usuario, el hardware y otras aplicaciones. \end_layout \begin_layout Itemize \series bold Rendimiento: \series default Velocidad, disponibilidad, tiempo de recuperación tras una caída del sistema, etc. \end_layout \begin_layout Itemize \series bold Atributos \series default de portabilidad, corrección, mantenimiento, seguridad, etc. \end_layout \begin_layout Itemize \series bold Restricciones de diseño: \series default Políticas sobre estándares, lenguajes de programación, entornos operativos, límites de recursos, etc. \end_layout \begin_layout Standard Según el IEEE 830, la SRS no deben incluir el coste, los plazos de entrega, procesos de seguimiento, métodos de desarrollo, procedimientos generales de aseguramiento de calidad, criterios generales de validación y verificación ni procedimientos generales de aceptación. Tampoco se incluye el diseño. \end_layout \begin_layout Section Estructura \end_layout \begin_layout Standard El tipo y número de documentos de requisitos, su organización y preparación y la forma de definir interrelaciones o jerarquías entre los requisitos deben estar claras desde el principio del proyecto. Se recomienda convertir esto en una norma en la organización, aunque con posibilidad de variación de un proyecto a otro según las características de cada uno. \end_layout \begin_layout Standard Un documento de requisitos puede estructurarse como: \end_layout \begin_layout Enumerate Necesidades del usuario o requisitos del negocio. \end_layout \begin_layout Enumerate Documento de Requisitos del Producto ( \series bold PRD \series default , \emph on \lang english Product Requirements Document \emph default \lang spanish ). \end_layout \begin_layout Enumerate Especificación de requisitos de software (SRS) o hardware. \end_layout \begin_layout Enumerate \emph on \lang english Tests \emph default \lang spanish para los requisitos de software ( \series bold STS \series default , \emph on \lang english Software Test Specification \emph default \lang spanish ) o hardware. \end_layout \begin_layout Standard Otra posible estructura es: \end_layout \begin_layout Enumerate \series bold Documento de Visión \series default ( \series bold y Alcance \series default ), con la lista de participantes clave, los requisitos de negocio y el PRD. \end_layout \begin_layout Enumerate \series bold Documento de Casos de Uso \series default , con los requisitos de usuario como casos de uso. \end_layout \begin_layout Enumerate SRS. \end_layout \begin_layout Standard \begin_inset ERT status open \begin_layout Plain Layout \backslash begin{samepage} \end_layout \end_inset \end_layout \begin_layout Standard El IEEE 830 define la siguiente estructura para el SRS: \end_layout \begin_layout Standard \begin_inset ERT status open \begin_layout Plain Layout \backslash bgroup \end_layout \begin_layout Plain Layout \backslash renewcommand*{ \backslash theenumi}{ \backslash arabic{enumi}} \end_layout \begin_layout Plain Layout \backslash renewcommand*{ \backslash theenumii}{ \backslash theenumi. \backslash arabic{enumii}} \backslash renewcommand*{ \backslash theenumiii}{ \backslash theenumii. \backslash arabic{enumiii}} \backslash renewcommand*{ \backslash theenumiv}{ \backslash theenumiii. \backslash arabic{enumiv}} \end_layout \begin_layout Plain Layout \backslash renewcommand*{ \backslash labelenumi}{ \backslash theenumi.} \end_layout \begin_layout Plain Layout \backslash renewcommand*{ \backslash labelenumii}{ \backslash theenumii.} \end_layout \begin_layout Plain Layout \backslash renewcommand*{ \backslash labelenumiii}{ \backslash theenumiii.} \backslash renewcommand*{ \backslash labelenumiv}{ \backslash theenumiv.} \end_layout \end_inset \end_layout \begin_layout Enumerate \begin_inset Argument item:1 status open \begin_layout Plain Layout \end_layout \end_inset Tabla de Contenidos \end_layout \begin_layout Enumerate Introducción \end_layout \begin_deeper \begin_layout Enumerate Objetivo \end_layout \begin_layout Enumerate Ámbito \end_layout \begin_layout Enumerate Definiciones, siglas y abreviaturas \end_layout \begin_layout Enumerate Referencias \end_layout \begin_layout Enumerate Contenido \emph on (explicación del contenido y organización del documento) \end_layout \end_deeper \begin_layout Enumerate Descripción general \end_layout \begin_deeper \begin_layout Enumerate Perspectiva del producto \end_layout \begin_layout Enumerate Funciones del producto \end_layout \begin_layout Enumerate Características del usuario \end_layout \begin_layout Enumerate Limitaciones generales \end_layout \begin_layout Enumerate Supuestos y dependencias \end_layout \end_deeper \begin_layout Enumerate Requisitos específicos \end_layout \begin_layout Enumerate \begin_inset Argument item:1 status open \begin_layout Plain Layout \end_layout \end_inset Apéndices \end_layout \begin_layout Enumerate \begin_inset Argument item:1 status open \begin_layout Plain Layout \end_layout \end_inset Índice \end_layout \begin_layout Standard \begin_inset ERT status open \begin_layout Plain Layout \backslash egroup \end_layout \end_inset \end_layout \begin_layout Standard \begin_inset ERT status open \begin_layout Plain Layout \backslash end{samepage} \end_layout \end_inset \end_layout \begin_layout Section Clasificación de requisitos \end_layout \begin_layout Standard Los requisitos pueden ser: \end_layout \begin_layout Itemize \series bold Del dominio del problema: \series default \series bold requisitos de empresa \series default o \series bold de producto \series default , \series bold objetivos \series default , \series bold necesidades \series default o \series bold reglas de negocio \series default , y son requisitos de alto nivel de la organización o el cliente, recogidos en el PRD. Información general de las necesidades de los usuarios. Reglas. \end_layout \begin_layout Itemize \series bold Del dominio de la solución: Requisitos de usuario \series default , tareas que el usuario debe poder realizar con el producto, representadas mediante texto, casos de uso o descripciones de escenarios. \series bold Requisitos de software \series default , funcionales o no, atributos de calidad y restricciones de diseño. Requisitos de hardware. \end_layout \begin_layout Standard CMMi 2.0 distingue requisitos: \end_layout \begin_layout Description Del \begin_inset space ~ \end_inset cliente Resultado de obtener necesidades; resolver conflictos entre ellas y las expectativas, limitaciones e interfaces, y definir las soluciones con las partes interesadas afectadas de forma aceptable para ellas. \end_layout \begin_layout Description Contractual Resultado del análisis y refinamiento de los requisitos del cliente en un conjunto de requisitos adecuado para su inclusión en solicitudes o acuerdos con proveedores. \end_layout \begin_layout Description \series bold De \begin_inset space ~ \end_inset producto \series default Refinamiento de los requisitos de cliente en lenguaje próximo a los de \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset sa \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset rro \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset lla \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset do \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset res para guiar el diseño del sistema. \end_layout \begin_layout Description De \begin_inset space ~ \end_inset componente \begin_inset space ~ \end_inset de \begin_inset space ~ \end_inset producto Especificación completa de un componente de un producto o servicio, incluyendo ajuste, forma y función. \end_layout \begin_layout Description De \begin_inset space ~ \end_inset contexto Estándares aplicables, leyes, políticas, prácticas habituales, decisiones de dirección, rendimiento, etc. \end_layout \begin_layout Description Derivados Inferidos de requisitos de contexto o necesarios para especificar un componente. Puede aparecer también en el análisis y diseño de componentes. \end_layout \begin_layout Description Asignado \begin_inset space ~ \end_inset ( \emph on allocated \series bold \emph default ) \series default Requisito resultante de imponer todo o parte de un requisito de nivel superior a un componente de diseño de nivel inferior, lógico o físico, incluyendo una persona, un consumible, un incremento de la entrega o la arquitectura. \end_layout \begin_layout Description Técnicos Propiedades de productos o servicios a ser adquiridos o desarrollados. \end_layout \begin_layout Description No \begin_inset space ~ \end_inset técnicos Afectan a la adquisición o el desarrollo del sistema pero no son propiedades de este. \end_layout \begin_layout Section Propiedades de los requisitos \end_layout \begin_layout Standard Un requisito puede ser: \end_layout \begin_layout Itemize \series bold Necesario \series default si define una capacidad o característica esencial, aplicable en la actualidad y no obsoleta, de modo que su eliminación produce una deficiencia que no puede ser compensada por otras capacidades del producto. \end_layout \begin_deeper \begin_layout Standard Los requisitos que puedan tener capacidad o solo son aplicables en fechas concretas deben ser claramente identificados. \end_layout \end_deeper \begin_layout Itemize \series bold Independiente \series default ( \series bold de la implementación \series default ) si no establece restricciones innecesarias sobre el diseño arquitectural. \end_layout \begin_layout Itemize \series bold Preciso \series default , \series bold inequívoco \series default o \series bold no ambiguo \series default si admite una única interpretación. \end_layout \begin_deeper \begin_layout Standard La mayoría de defectos en los requisitos se deben a la ambigüedad del lenguaje, que puede surgir en la definición de nuevos requisitos, la incorporación de nuevas necesidades y los cambios en los requisitos durante el desarrollo. \end_layout \begin_layout Standard Para evitar esto debemos usar el lenguaje de forma precisa, pudiendo usar plantillas o estructuras fijas de lenguaje o técnicas de descripción rigurosas y estructuradas. Para resolver una ambigüedad existente, pedimos el significado correcto a quienes escribieron el requisito. \end_layout \end_deeper \begin_layout Itemize \series bold Consistente \series default si no entra en conflicto con otros requisitos. \end_layout \begin_layout Itemize \series bold Completo \series default si no necesita ampliarse para describir suficientemente la capacidad o característica requerida. \end_layout \begin_layout Itemize \series bold Singular \series default si no es des componible en varios requisitos y no usa conjunciones. \end_layout \begin_layout Itemize \series bold Factible \series default si es técnicamente alcanzable, no requiere grandes avances tecnológicos y cumple con las restricciones del proyecto con un riesgo aceptable. \end_layout \begin_layout Itemize \series bold Verificable \series default si hay una forma efectiva en tiempo y coste de determinar si el sistema satisface el requisito en grado suficiente para convencer a las partes relevantes. \end_layout \begin_layout Standard Los requisitos se pueden relacionar por: \end_layout \begin_layout Itemize \series bold Trazabilidad inclusiva: \series default Un requisito destino depende de uno origen, de modo que si desaparece el origen, el destino no tiene sentido y debe desaparecer. \end_layout \begin_layout Itemize \series bold Jerarquía \series default o \series bold refinamiento: \series default Un requisito padre es explicado con más detalle por sus hijos. Es un caso de trazabilidad inclusiva. \end_layout \begin_layout Itemize \series bold Exclusión: \series default La elección de un requisito impide la de otro incompatible. \end_layout \begin_layout Standard Un requisito es \series bold trazable hacia arriba \series default si enlaza a su fuente u origen, como una descripción documentada de una necesidad de \emph on \lang english stakeholder \emph default \lang spanish , un requisito de nivel superior, un plan de negocio, etc.; \series bold trazable hacia abajo \series default si enlaza a requisitos de nivel inferior más refinados o a otros artefactos resultantes de añadir el requisito, y \series bold trazable \series default si lo es hacia arriba y hacia abajo. \end_layout \begin_layout Section Meta-información \end_layout \begin_layout Standard Las SRS suelen incluir, junto con los requisitos, meta-información sobre estos, en forma de atributos. El método VOLERE incluye, entre otros los siguientes atributos de cada requisito: \begin_inset Note Comment status open \begin_layout Plain Layout Esto junta LO32 (recordar al menos 7 atributos posibles) y LO33 (recordar al menos 5 atributos de VOLERE). \end_layout \end_inset \end_layout \begin_layout Itemize \series bold Identificador de requisito \series default , único en todo el proyecto incluso entre requisitos bo \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset rra \begin_inset ERT status open \begin_layout Plain Layout \backslash - \end_layout \end_inset dos. \end_layout \begin_layout Itemize \series bold Tipo de requisito \series default . \end_layout \begin_layout Itemize \series bold Razón \series default o justificación. \end_layout \begin_layout Itemize \series bold Fuente \series default , trazabilidad hacia arriba. \end_layout \begin_layout Itemize \series bold Satisfacción del cliente \series default si el requisito se implementa, del 1 al 5. \end_layout \begin_layout Itemize \series bold Insatisfacción del cliente \series default si el requisito no se implementa, del 1 al 5. \end_layout \begin_layout Itemize \series bold Dependencias \series default , trazabilidad hacia abajo. \end_layout \begin_layout Section Propiedades de las SRS \end_layout \begin_layout Standard Un documento o grupo de requisitos puede ser: \end_layout \begin_layout Itemize \series bold Completo \series default si incluye todos los requisitos que los \emph on \lang english stakeholders \emph default \lang spanish esperan haber cumplido en la versión correspondiente del sistema o parte del sistema. Cuando un requisito o subgrupo no está completo, lo indicamos con una etiqueta como \series bold \lang english TBD \series default \lang spanish ( \series bold \emph on \lang english To Be Determined \series default \emph default \lang spanish ). \end_layout \begin_layout Itemize \series bold Consistente \series default si no contiene requisitos excluyentes ni duplicados, no se usan varios términos para el mismo concepto y su satisfacción no entra en conflicto con la de otro documento previamente aprobado. \end_layout \begin_layout Itemize \series bold Alcanzable \series default si se puede construir un sistema que satisfaga los requisitos. \end_layout \begin_layout Itemize \series bold Asequible \series default si se puede construir dicho sistema dentro del coste, la planificación, la tecnología disponible y la ley. \end_layout \begin_layout Itemize \series bold Limitado \series default si no extiende el alcance de la solución más de los necesario para satisfacer las necesidades de los usuarios. \end_layout \begin_layout Standard Según el IEEE 29148, un documento o grupo de requisitos debe ser completo, consistente, asequible y limitado, y sus requisitos deben ser necesarios, independientes de la implementación, no ambiguos, consistentes, completos, singulares, factibles, trazables y verificables. \end_layout \begin_layout Standard El no cumplimiento de alguna propiedad indica posibles problemas en los requisitos. Se puede crear una \series bold lista de comprobación \series default con propiedades de requisitos y de grupos de requisitos para asegurarse en la \series bold revisión de requisitos \series default de que estas se cumplen. \end_layout \begin_layout Section Gestión del cambio \end_layout \begin_layout Standard En el desarrollo o el mantenimiento, se puede cambiar el documento de requisitos rellenando una \series bold plantilla de solicitud de cambio \series default y enviándola al \series bold grupo de gestión de cambios \series default , un grupo idealmente de entre 3 y 5 personas, normalmente responsables de la construcción del documento de requisitos, que se encarga de estudiar los posibles cambios. \end_layout \begin_layout Standard Una plantilla podría contener como campos \begin_inset Quotes cld \end_inset Petición de cambio \begin_inset Quotes crd \end_inset (nombre del proyecto afectado), \begin_inset Quotes cld \end_inset Identificador del requisito afectado \begin_inset Quotes crd \end_inset (documento y código), \begin_inset Quotes cld \end_inset Nombre asignado al cambio \begin_inset Quotes crd \end_inset , \begin_inset Quotes cld \end_inset Descripción \begin_inset Quotes crd \end_inset (del cambio), \begin_inset Quotes cld \end_inset Pedido por \begin_inset Quotes crd \end_inset (nombre y cargo) y \begin_inset Quotes cld \end_inset Justificación \begin_inset Quotes crd \end_inset . \end_layout \begin_layout Section Problemas \end_layout \begin_layout Standard Manejar documentos de requisitos puede ser complicado por la gran cantidad de requisitos, por lo que hay que obviar requisitos obvios y no especificar absolutamente todo. \end_layout \begin_layout Standard El nivel de detalle en que debemos expresar los requisitos depende del nivel de abstracción en que nos encontremos, es decir, de si los requisitos son de empresa, de usuario o de software, por lo que es importante la trazabilidad para ligar niveles de abstracción. \end_layout \begin_layout Standard Finalmente, está el problema de que a veces un requisito pertenece a varias categorías y puede ser asignado a una o más secciones del documento de requisitos. Una solución es usar referencias cruzadas. \end_layout \end_body \end_document