Introducción

La ingeniería de requisitos es una aproximación multidisciplinar para el desarrollo de soluciones de sistemas informáticos balanceados; la cual es posible gracias un conjunto de herramientas que nos van a permitir definir un sistema informático (producto software) de tal forma que:

• No sea ambiguo: cualquier miembro del equipo pueda saber qué tiene que hacer dentro del proyetcto,
• El cliente pueda verificar cuán acertados estamos sobre la idea/problema/solución que tiene o necesita sobre algún problema de la vida real (motivado, normalmente, por alguna actividad de negocio) y para
• Tener claros los objetivos en todo momento: lo que ayudará a que el producto no se desvíe del camino estrictamente necesario para lograr la meta y, por ende, repercuta positivamente al negocio con el menor esfuerzo posible. Relaciona el producto con una necesidad de negocio a satisfacer.

Además, dependiendo del tipo de proyecto, estas herramientas nos ayudarán a crear un sistema escalable, modular y reutilizable.

Para conseguir esto, la ing. de requisitos se centra en definir bien las necesidades al principio del desarrollo seguido de diseño, síntesis y validación, mientras se considera el problema completo en su conjunto.

Modelos de desarrollo

La primera herramienta básica para la ingeniería de requisitos son los modelos de desarrollo, los cuales nos van a permitir organizar la forma de trabajar, de modo que se ajuste mejor al tipo de producto que se quiere crear (por ejemplo, no es lo mismo un producto pequeño pero que necesita salir cuanto antes al mercado que todo el sistema de una central nuclear).

Hay 3 conceptos a diferenciar:

• Ciclo de vida software: se refiere a la extensión temporal desde la cual el producto software es concebido hasta su retirada, pasando por sus fases de desarrollo, depliegue y uso.
• Modelo de ciclo de vida del desarrollo software: framework (esto es, conjunto de herramientas y buenas prácticas) para el ciclo de vida del software que se compone de procesos, actividades (agrupación de tareas), tareas (acciones que transforman inputs en outputs), uso y mantenimiento del producto software.
• Proceso de desarrollo software: modelos abstractos que describen cómo realizar las tareas durante el ciclo de vida del desarrollo software. Se conocen también como:
  – Metodología/Proceso de desarrollo ,
  – Metodología de proyecto,
  – Modelo (de proceso o de desarrollo),

Cada una de las metodologías de desarrollo existentes se diferencian, principalmente, en el tamaño de la “mordida” (en inglés «morsel») que se aplica a cada paso del proceso; es decir, la cantidad de requisitos (o la unidad de trabajo que use la metodología en cuestión) que se usan/consumen en cada iteración o fase del proceso.
Algunos tienen que consumirlos todos de golpe en pasos de diferente índole (por ejemplo metodología en cascada) y otros van poco a poco, realizando todos los subprocesos pero sobre un conjunto pequeño de requisitos (por ejemplo metodología ágil).

Algunos modelos de desarrollo destacados son los siguientes:

Cascada (Waterfall)

Consiste en realizar todos los pasos de golpe, sin iteraciones: se extraen todos los requisitos, se realiza todo el diseño del producto, se genera todo el código, etc y finalmente se entrega todo de una sola vez. No puede haber cambios en las fases intermedias.

• Tradicional
• Común en la industria del IT
• El cambio es “anatema”
• Uno de los más populares para Ing. De sistemas.
• Requiere que el problema esté bien definido, acotado y no sea cambiante.

Prototyping (prototipado)

• Tradicional, evolutivo.
• El cliente no sabe exactamente los requisitos a priori.
• El prototipo del producto final se desarrolla, testea y refina según el feedback del cliente hasta tener un prototipo que conformará la base del producto final.
• El sistema se implementa parcialmente en la fase de análisis (el cliente puede ver el producto en fases tempranas del desarrollo para verificar que el desarrollo lleva el rumbo adecuado para solventar la necesidad de negocio).

Esta metodología tiene dos variantes:

• Throw-away prototyping (prototipos desechables): Se usan prototipos para ayudar a determinar los requisitos y especificaciones y luego son descartados (los prototipos).
• Evolutionary prototyping (prototipos evolutivos): Se desarrollan modelos funcionales del sistema (o parte de él) en base a requisitos generales y a las evaluaciones de los usuarios. Se refinan hasta obtener el producto final.

Modelo en V (Verification and Validation)

• Éxito en el 42% de los proyectos.
• Está guiado por procesos de verificación y validación: cada fase tiene asociada otra de verificación previa para poder continuar a la siguiente; es decir, hay una relación directa entre las fases de diseño y las de testing.
• Trazabilidad de los requisitos clara durante todo el proceso.

Spiral process (modelo en espiral)

• Se basa en el concepto de “fast prototyping” (prototipos evolutivos de rápido desarrollo).
• Muchas oportunidades de feedback de usuarios y clientes, en cada iteración hay output en forma de prototipo.
• Identifica rápidamente los cambios (en la fase de concepto) gracias a los prototipos.
• Mezcla iteraciones (repetición de secciones/actividades para todos los ciclos) con metodología en cascada (cada iteración deriva en una nueva fase del ciclo de vida sw) ayudado con prototipos evolutivos de rápido desarrollo (fast prototyping).

Ágiles

• Iterativo.
• Requisitos de alto nivel y poco definidos; y por ende no validados y susceptibles a interpretaciones y asunciones por parte de arquitectos y desarrolladores (pero siembre en base a las necesidades del negocio).
• Dificultad para testear las funcionalidades (pues no están definidas con exactitud).
• Bajo porcentaje de entregas a tiempo del producto final (8%), pero hay pequeñas y constantes entregas funcionales.
• Siguen funcionando aún con cambios significativos en el proyecto (51%).
• Scrum:
  • Tipo de metodología ágil.
  • Utiliza un listado de requisitos, el “product backlog”.
  • Priorización cuantitativa de requisitos.
  • La validación puede dar lugar a mover de nuevo un requisito al product backlog.

Hybrid (Modelo híbrido)

• Modelo incremental, ideal para sistemas.
• 3 ciclos de desarrollo interconectados y disgregados entre sí con trabajo en paralelo: especificación, desarrollo y verificación (El ciclo de especificación del sistema puede iterar más rápido que el de desarrollo).
• Sigue la misma estructura general del modelo en V y del modelo incremental pero paralelizando iteraciones de especificación, desarrollo y verificación-integración.
• El rendimiento de los ciclos dependerá en el tipo de sistema (y en el grado de riesgo del proyecto). Es decir, es muy útil si se aprovecha su «estructura» paralelizada.

Modelos de dominio y la MBSE

Modelos de dominio: diagramas/modelos conceptuales que ilustra los datos y comportamientos, las entidades y relaciones entre ellas de un problema específico (Ej: UML).
Tienen características muy útiles:

• Es un medio de intercambio de información entre ingenieros, en lugar comunicarse mediante documentación literal, la cual puede ser ambigua, demasiado extensa y propensa a errores.
• Capturan mejor la intención, impacto de los cambios y análisis del diseño antes de construir el sistema.
• Facilitan la trazabilidad.
• Los modelos usados pueden ser leídos y entendidos por otros stakeholders que no sean ingenieros (lo cual ayuda a que estos validen el rumbo del proyecto).

Algunos ejemplos de modelos de dominio son:

• SysML (Systems Modeling Language): Es la versión de UML para sistemas, es un ADL (Architecture Description Language) estándar.
• AP233.
• UML2.

MBSE: Model Based System Engineering: Ingeniería de Sistemas Basada en modelos: Aplica modelos de dominio en su metodología de desarrollo (framework) para el análisis de requisitos en sistemas con actividades de diseño, análisis, verificación, y validación, desarrollo y el resto de ciclo de vida software (sistemas complejos).

Stakeholders

Los stakeholders son todas aquellas personas, grupos y organizaciones que están relacionados con nuestro software de una u otra forma:

• el equipo de desarrollo,
• el interesado en la salida del producto software,
• aquellos que pueden influir en los requisitos y objetivos de la organización
• en general aquellos a quienes les afecta nuestro software ya sea en su desarrollo, uso, mantenimiento y/o cambio que generará en el mundo real

Serán la fuente de nuestros requisitos: definen los objetivos (la mejora en el negocio) y el alcance del software/problema (y a su vez, el alcance del problema nos señala cuáles serán nuestros stakeholders, es un ciclo).

Clasificación (taxonomies)

Hay diferentes clasificaciones de stakeholders dependiendo del autor, del método empleado para clasificarlos, etc; pero en general se usan los grupos de “Operadores/usuarios” y “Clientes”.

En modelos ágiles se habla de “System stakeholders” (todo aquél que se vea afectado por el despliegue -deployment- y la operación/uso/interacción con el sistema) y “Project stakeholders” (aquellos interesados en el desarrollo en sí del proyecto: patrocinadores, gestores, personal ejecutivo, financiero…).

Cualquier sistema de clasificación de stakeholders es susceptible de ser modificado para adecuar los grupos o roles no existentes o ambiguos a las necesidades concretas del proyecto.

Ejemplos de taxonomías:

NOTA: Volere es una organización que se dedica al agrupamiento de buenas prácticas para la ing. de requisitos. La plantilla para la identificación y clasificación de stakeholders de Volere puede encontrarse en su página oficial (https://www.volere.org/templates/stakeholder-analysis-download/). El diagrama anterior es una representación visual y reducida de dicha plantilla.

Elicitación – Identificación de Stakeholders

Identificar un stakeholder, dentro de la ingeniería de requisitos, forma parte de la fase de la “elicitation” (extracción de requisitos); tras la cual le sigue el «plan de educción» (un plan para extraer, de la forma más eficiente, los requisitos de los stakeholders identificados).

Destacan 2 métodos de elicitación:

Plantilla Volere

Plantilla Volere: Plantilla de posibles stakeholders clasificados por grupos y roles; sirve como guía para la deducción de stakeholders y de sus grupos de conocimientos/fuentes de tipos de requisitos. La plantilla puede ser descargada desde la página de Volere (https://www.volere.org/templates/stakeholder-analysis-download/). Es literalmente una hoja de cálculo.

Patrón expandir-contraer

Patrón expandir-contraer: brainstorming (lluvia de ideas) en la que se deducen los stakeholders del dominio (expandir) para luego refinar y agrupar por similitud de tipo de información (tipo de requisitos/área de conocimientos, contraer) que nos puedan proporcionar, entre otras cosas para tener claro quién puede contestar a qué preguntas durante la extracción de requisitos y para realizarles dichas preguntas a la vez (entrevistas grupales por ejemplo). Al final del proceso se firma por todos los participantes, los cuales deben estar todos de acuerdo para el aseguramiento de la calidad (QA, Quality Assurance).
Se usa en modelos de desarrollo ágil cuando el dominio del proyecto está claro.

Plan de Educción – Extracción de requisitos

Tras identificar a los stakeholders, se extraen los requisitos de estos mediante actividades de educción que pueden ser del tipo:

• Facilitadas
• No-facilitadas
• De observación (Actividades independientes)

Actividades facilitadas

Actividades facilitadas: aquellas actividades de extracción de requisitos que impliquen a varios stakeholders a la vez (técnicas grupales); requerirá también de un facilitador que conduzca los grupos adecuadamente para la extracción de requisitos. Técnicas:

• Workshops (grupo de trabajo con especialistas en contenido y stakeholders donde se debaten y refinan los requisitos).
• Brainstorming (nuevas ideas para el proyecto, no se debaten ni se refinan, como mucho se crean nuevas ideas sobre otras ideas).
• Focus groups (extracción de requisitos mediante estadísticas, normalmente para stakeholders ajenos a la organización, tales como análisis de tendencias, análisis de la competencia, etc).
• Storyboarding (creación de viñetas/sketches para la representación y afinamiento de historias de usuario y, en general, acciones).

Actividades no-facilitadas

Actividades no-facilitadas: aquellas que no requieren del facilitador pues son técnicas más personales (face-to-face), las cuales pueden hacerse directamente entre un miembro del «core-team» y un stakeholder. Técnicas:

• Cuestionarios
• Entrevistas

De observación (Actividades independientes):

De observación (Actividades independientes): extracción de requisitos mediante la observación de la lógica/funcionamiento de los procesos de negocio. Técnicas:

• Observación silenciosa (se observa el proceso de negocio sin interrumpir a los trabajadores).
• Observación interactiva (se observa el proceso, se pregunta y se puede incluso participar en el proceso).

Análisis (Clasificación y modelado de requisitos)

Una vez que hemos identificado a nuestros stakeholders (elicitación), y hemos seguido el plan de educción para la extracción de los requisitos, ahora se procede a la clasificación y modelado de estos (análisis).

El modelado normalmente se hace mediante los modelos de dominio.

Clasificación de requisitos

Los requisitos pueden categorizarse según:

• La fuente de información de los requisitos
• Distinción entre funcionalidades y resto de necesidades (taxonomía clásica)

Taxonomía clásica: distinción entre requisitos funcionales (funciones que realiza el sistema) y requisitos no-funcionales (restricciones y reglas no-funcionales a las que debe adaptarse el sistema).

Clasificación según la taxonomía clásica

Taxonomía clásica según Alberta (2017)

Siguiendo la clasificación de requisitos según Alberta (2017), tenemos los siguientes tipos de requisitos:

1. Business rules
2. Business requirements
3. User requirements
4. Functional Requirements (including temporal requirements)
5. Non-functional requirements
6. External Interfaces
7. Design restrictions Physical settings

1. Business rule (Regla de negocio): Restricciones de cómo debe ser desarrollado el producto (bajo qué condiciones), del ámbito legales, temporales, de presupuesto, etc.

2. Business requirements (Requisito de negocio): Porqué del proyecto desde el punto de vista del negocio (por qué se necesita el producto, qué problema del mundo real va a solventar). Estos requisitos definirán posteriormente los “business objectives” (valores de negocio que va a aportar). Es parecido a los casos de uso pero a un nivel mucho más alto de abstracción (high-level needs) y siempre desde el punto de vista del negocio (Teniendo siempre en mente qué va a mejorar de mi negocio esta funcionalidad/necesidad de alto nivel de abstracción).

La diferencia entre decir qué quiero, grosso modo, que haga el producto de cara a mi negocio -requisito de negocio- y qué funcionalidades concretas debe tener ese sistema -requisito funcional-.

3. User requirements: qué puede hacer el usuario con el sistema de forma directa, no confundir con las funcionalidades que tiene el sistema (que serían, en esencia, los requisitos funcionales), sino cuáles de ellas interactúan directamente con el usuario. Deben proceder de los end-users (tanto directos como indirectos; incluyendo aquella información que le puede dar el usuario al sistema). Estarán relacionados con la “satisfacción del usuario” (user satisfaction).

Se pueden representar con “historias de usuario”: Como <tipo_usuario> quiero <función_del_sistema> para lograr <objetivo_de_negocio>.

4. Functional requirements: también llamados “capacidades” o “características” del sistema, definen lo que los desarrolladores deben implementar para permitir a los usuarios realizar sus tareas (User requirements), satisfaciendo así los requisitos de negocio(Bussiness requirements); deben estar bien alineados los 3 tipos de requisitos anteriores para asegurar el éxito del proyecto (el negocio debe determinar qué va a necesitar el usuario para mejorar la lógica de negocio y, este a su vez, debe ser una funcionalidad):

Bussiness => User => Functional

Se expresan en función de inputs, outputs, condiciones y el comportamiento en sí de la funcionalidad; todo ello de forma independiente a la tecnología en la que se vaya a implementar.

5. Non-functional requirements (NFR): en general, son descripciones (de diferentes tipos) sobre cuán bien debe funcionar el producto (por ello también se conocen como “Quality requirements”). Los req. funcionales son verbos (acciones) mientras que los no-funcionales son adjetivos (cualidades). Dentro de los requisitos no-funcionales hay categorizaciones, incluyendo las reglas de negocio:

Resumen

Modelado de requisitos

El modelado de requisitos sigue formando parte del análisis y consiste en el uso de modelos de dominio para «traducir» los requisitos extraídos en dichos modelos (y/o en la especificación formal de los requisitos).

Cada modelo describe al sistema de una forma concreta, teniendo así los tres grandes grupos:

• Conductuales (De comportamiento): cómo funciona el sistema; incluye a los diagramas de casos de uso y de actividad.
• Estructurales (De estructura): cómo está dividido el sistema de forma lógica y/o física, está más relacionado con la arquitectura del sistema; incluye el diagrama de bloques.
• De requisitos.

IMPORTANTE: No confundir diagrama con modelo, el modelo es la representación, mediante varias herramientas, de un aspecto del sistema; el diagrama una de muchas posibles representaciones visuales del modelo (Delligati, 2013).

NOTA: Para esta sección se tendrá en cuenta la representación visual para el modelado de sistemas mediante el estandar SysML (una extensión de UML para sistemas); pero gran parte de estos pueden ser aplicados a la ingeniería del software sin problemas.

Sintaxis general de diagramas

Antes de empezar a crear diagramas, es necesario conocer la sintaxis que se utiliza para englobar a cada uno de ellos.

Todos los diagramas estarán encapsulados en un cuadro que vendrá titulado con:

• La abreviación del tipo de diagrama: Se usa la abreviación estandar de SysML.
• Contexto del diagrama: En qué contexto se va a usar el diagrama, si se trata de un diagrama general del tipo indicado anteriormente, de un diagrama raíz del que se van a nutrir otros, si se trata de una librería que puede ser reutilizada en otros proyectos, etc.
• El tipo general del diagrama: uno de los tres grandes grupos; requisitos, estructural o conductual.
• El nombre del diagrama: un nombre representativo del ámbito o sección del sistema en el que nos estamos centrando.

• tipoDiagrama:
  • bdd= block definition diagram
  • ibd= internal block diagram
  • uc= use case diagram
  • act= activity diagram
  • sd= sequence diagram
  • stm= state machine diagram
  • par= parametric diagram
  • req= requirements diagram
  • pkg= package diagram

• contexto:
  • package: contenedor genérico. Puede contener otros «packages».
  • model: contenedor raíz de una jerarquía de contenedores.
  • modelLibrary: conjunto de elementos del sistema que podrán reutilizarse en otros modelos.
  • view: reprentación visual de varios tipos de modelos que explican un comportamiento concreto del sistema en diferentes aspectos a la vez.

• tipoGlobalDiagrama: behavior, requirement, structure.

Modelos de requisitos

Requisitos de negocio (modelado de objetivos de negocio)

Al igual que el resto de los requisitos iniciales, los requisitos de negocio serán inicialmente frases sueltas e ideas amplias que deben descomponerse/sintetizarse para definir, de manera formal, los siguientes elementos:

• Business objectives,
• Success metrics,
• Product vision (a vision statement),
• Business risks,
• Business assumptions and dependencies

Business Objectives

Beneficios (en términos tangibles/cuantificables) que el producto aportará a la organización (valores de negocio).

Estos serán enlazados posteriormente con los casos de uso para relacionar funcionalidades del sistema con los beneficios aportados en un modelo de dominio.

Todos los objetivos de negocio tienen una o más métricas de éxito asociada.

Success metrics

Indicadores cuantitativos para saber si el proyecto está en el buen camino para alcanzar sus objetivos de negocio.

Para definirlas hay que tener en cuenta:

• los indicadores (cualquier cosa que usen los stakeholders para determinar sus métricas de éxito) y
• los factores de mayor impacto en el éxito (ya estén bajo el control de la organización o no).

Modelo de objetivos de negocio

Con estos dos componentes se puede ir preparando el modelo de objetivos de negocio que será representado por cajas que enuncien «objetivo + métrica de negocio» y que, posteriormente, se enlazarán mediante segmentos con los casos de uso. Todas las cajas parten de la caja padre que es el nombre del proyecto o producto:

NOTA: Si un objetivo de negocio tiene dos o más métricas asociadas, se debe poner otra caja distinta para ese «objetivo+métrica».

Product Vision

Describe, de forma sintetizada, el producto final que va a lograr los objetivos de negocio.
Nos asegura que todos sepamos hacia a dónde queremos ir.
Debe reflejar una visión balanceada para que todos los stakeholders encuentren ahí sus expectativas plasmadas y las de los demás (para poder ponerse en contexto los unos con los otros).

Plantilla de la visión del producto según Geoffrey (2002):

• For. [target customer] 
– Ej: Para los clientes
• Who. [statement of the need or opportunity] 
– Ej: que tengan una necesidad X
• The. [product name] 
– Ej: Nuestro sistema chachi pistachi
• Is. [product category] 
– Ej: será una pasarela de pago 
• That. [major capabilities, key benefit, compelling reason to buy or use] 
– Ej: que haga esto, eso y aquello.
• Unlike. [primary competitive alternative, current system, current business process] 
– Ej: Y, a diferencia de cómo lo hace otro sistema o proceso de negocio actualmente, ...
• Our product. [statement of primary differentiation and advantages of new product] 
– Ej: ... nuestro sistema hará estas otras cosas que los anteriores no son capaces de hacer.

Bussiness risks

No confundir con los riesgos del proyecto (los cuales están más relacionados con la disponibilidad de recursos y factores tecnológicos). Son todos aquellos factores a tener en cuenta para determinar si se debería o no desarrollar el producto.

Entre los riesgos habituales se encuentran:

• La saturación del mercado
• Problemas de tiempo
• Aceptación de los usuarios

Bussiness assumptions and dependencies

Todas aquellas cosas que se han dado por supuestas al realizar los requisitos de negocio. Deben ser anotadas para ser capaces de reaccionar rápidamente ante alguna información nueva que cambie estas suposiciones y dependencias (como por ejemplo, dar por supuesto que una ley, que podría afectar a nuestro sistema, seguirá vigente y sin modificaciones).

Modelos conductuales

Modelos que representan el comportamiento dinámico del sistema.

Requisitos de usuario (casos de uso)

Los requisitos de usuario se modelan en el diagrama de casos de uso.

Diagramas de caso de uso

Los diagramas de casos de uso pretenden plasmar visualmente la relación entre las funcionalidades del sistema que pueden usar los usuarios directamente (requisitos de usuario) y los usuarios/stakeholders que las van a usar.
Es un resumen visual de los requisitos de usuario y de qué stakeholders van a interactuar con nuestro sistema.
NOTA: No serán plasmados los requisitos funcionales, sólo los de usuario.

Caso de uso

Estas funcionalidades se representarán visualmente con óvalos y un título enunciativo (y sucinto) del requisito de usuario (el cual debe incluir un verbo ya que describirá la acción que hace el sistema). Se les conoce como casos de uso y se dibujan dentro de una caja que será la representación abstracta de los límites de nuestro sistema, «the system boundary».

Si algún caso de uso no pertenece a nuestro sistema/producto a desarrollar, pero es necesario para conocer el contexto funcional del sistema, se situará fuera de la caja limítrofe. Normalmente esos caso de uso están más relacionados con requisitos no funcionales de interfaz de comunicación (los cuales, técnicamente, son requisitos de usuarios que serán utilizados por otros sistemas, en lugar de humanos).

Caso de uso extendido

En inglés llamado «use case specification» describirá, en algún documento anexo y en lenguaje literal (no son diagramas), el comportamiento del requisito de usuario para conseguir la meta deseada; incluyendo: actores implicados en el proceso y el flujo de comportamiento normal ante una petición del usuario (y en la medida de o posible, flujos alternativos al flujo normal como control de excepciones, comportamiento excepcional e incluso secuencias de flujo alternativas).

Actor

Entidades ajenas al sistema (se dibujan fuera de la caja delimitadora del mismo) que hacen uso directo de las funcionales del sistema.

Pueden ser humanos, computadoras, algún tipo de hardware, sistemas externos e incluso objetos (físicos, no confundir con orientación a objetos).

La representación visual es un muñeco de palo o bien una caja que indique el estereotipo «actor».

Relaciones

Los diferentes elementos del diagrama de casos de uso se relacionan de diferentes formas:

• Asociación (association): Indica el uso de un actor con una funcionalidad del sistema para obtener un resultado (que será de interés para ese actor).

• Generalización (Generalization): Se usa para indicar que un caso de uso hijo es un caso particular de otro caso de uso padre (que será el caso de uso general). El caso de uso hijo añade comportamiento extra/especializado, respecto al comportamiento generalista y extensible del caso de uso padre.

Ejemplo: un caso de uso general sería «realizar pago» y dos casos de uso especializados serían «realizar pago con tarjeta» y «realizar pago contra-reembolso».

• Extensión (extend): forma de extensión más controlada que la relación de generalización, en la que el caso de uso padre declara un comportamiento concreto y un conjunto de «puntos de extensión». El caso de uso hijo tiene un comportamiento especializado sólo en una serie de situaciones/condiciones concretas (los antes mencionados «puntos de extensión»).
  Es decir, se crea una especialización del caso de uso padre únicamente en unas situaciones/condiciones concretas llamadas «puntos de extensión».

Ejemplo: Un caso de uso general sería «Selección de método de envío» y un punto de extensión (una condición de especialización) sería «Pedido inferior a 50€», para la cual se ofrecen métodos de envío exclusivamente de pago (mientras que el uso general es ofrecer todos los métodos de envío, gratuitos y de pago).

• Inclusión (include): o uso (uses, deprecated) es una relación que indica que un caso de uso está incluido dentro de otro (esto es, que el comportamiento o un conjunto de pasos de un CU forma parte de otro caso de uso). Se hace esta separación/factorización/encapsulado del comportamiento para ser reutilizado en otros casos de uso (sino, no tiene sentido realizar dicha factorización).

Ejemplo: Dos casos de uso «añadir fondos» y «retirar fondos» de una cuenta bancaria implica, en ambos casos, actualizar el saldo en la BDD.

Ejemplo de diagrama de caso de uso en SysML

Diagramas de actividad

Diagrama que representa el flujo de control y transformación de los inputs en outputs de alguna funcionalidad concreta del sistema mediante una secuencias de actividades. Comparándolo con los casos de uso extendidos, este diagrama sería la representación visual de los flujos de actividad.

Elementos:

Acción

Representa un conjunto entendible de pasos para realizar algún procesamiento ó transformación mediante notación literal; el título de la acción deberá empezar por un verbo no ambiguo.

Acciones opacas: Se pueden representar acciones con lenguaje de programación (llamadas «acciones opacas»).
Sintaxis:

{Lenguaje} Sentencia
ej: {C} count++

La salida de la acción puede ser mediante «streaming» (el output de la actividad es ofrecido al siguiente nodo incluso antes de que este primero haya terminado de ejecutarse) o de forma «nonstreaming» (el output se ofrece sólo después de haber terminado la acción).

Objeto

Es la representación de algún dato, materia o energía. Normalmente aparecen entre dos nodos de acción para representar que es el output de la primera y el input de la segunda.

La representación es una caja con un texto en su interior con el formato:

 <object node name> : <type> [<multiplicity>] 

Siendo type algún nombre de bloque (del diagrama de bloques), un tipo de valor (ej: kilómetros, km) o el nombre de una señal (evento, que aparezca en algún diagrama de actividad ).

Siendo multiplicity el número de objetos de este tipo que se esperan (tanto en la entrada como en la salida).

• [0..*] – pueden ser 0 a N, indicando que es un parámetro de entrada/salida opcional.
• [4] – Si sólo hay un número indica que ese es el mínimo y el máximo a la vez.
• [1] / nada – Si no aparece este parámetro, implica que la multiplicidad es de mínimo 1 y de máximo 1

Pin

Notación alternativa al nodo objeto que aparece entre dos acciones.

Estas dos notaciones son equivalentes:

Parámetros de la actividad (activity parameter)

Nodo objeto que se usa para definir el input inicial y el output final del diagrama de actividad.

Edges

Las acciones pueden tener como entradas y salidas flujos de control y/o de objetos a la vez. Las de control se representan con líneas punteadas y las de objetos con líneas sólidas.

Para que una acción se ejecute, debe recibir todos los objetos/controles no opcionales (no tiene por qué ocurrir en el mismo instante de tiempo). Si una acción sólo tiene flujos de entrada opcionales, esta comenzará su ejecución a la vez que la propia actividad en la que está contenida.

Tipos de acciones

• Call behaviour actions: Son acciones que invocan a otra actividad o a un modelo state-machine (modelo de estados). Útiles para encapsular sub-actividades que se pueden reusar en otras actividades.

Notación: <Nombre de la acción> : <Nombre Actividad>

Si lo invocado es una actividad, se pinta un tridente hacia abajo en la esquina inferior derecha; si se invoca un modelo de estados el tridente se dibuja hacia arriba y no se dibuja nada si es ambiguo.

• Envío de señal (send signal): Un tipo de acción que manda, de forma asíncrona, una señal (objeto o flujo de control) sin indicar quién será el receptor de dicha señal (es parecido a la elevación de un evento en una arquitectura orientada a eventos). Estas señales deben haber sido definidas previamente en algún diagrama de bloques bajo el estereotipo «signal».

• Recepción de señal (accept event): Es la acción asíncrona de la recepción de una señal. Normalmente se mete dentro de un bucle para indicar espera activa del evento.

• Espera temporal (wait time action): Es la acción que espera por un tiempo ya sea en valores absolutos (fecha el algún formato), en valores relativos (tras X segundos) o tras el cumplirse alguna variable definida en el diagrama de bloques.

Elementos de control

Para indicar flujos más complejos de control:

• Inicio de la actividad:

• Final de la actividad

• Final de un flujo de control: no confundir con el final de la actividad total. A veces un flujo de control puede acabar en un dead-end sin implicar que el resto de la actividad termine ahí (por ejemplo, flujos de control concurrentes).

• Decisión: indica la bifurcación de un flujo dependiendo de alguna condición.

• Fusión (merge): indica un punto de confluencia de diferentes flujos de actividad. No confundir con flujos concurrentes, cuando algún flujo de control llega a este nodo, la actividad continúa por ahí (no es un punto de sincronización de flujos). Se suelen usar para representar bucles.

• Ramificación (fork): indica inicio de flujos de control concurrentes.

• Sincronización (join): indica final de flujos de control concurrentes bajo sincronización (espera de la finalización de todos los demás flujos de control concurrentes para continuar).

Modelos estructurales

Modelos que definen la estructura estática del sistema.

Diagramas de definición de bloques

En inglés BDD (block definition diagram), es un diagrama que ayuda a la visualización de los módulos físico-lógicos del sistema, la clase de información que almacenan cada uno de ellos y las relaciones que tendrán entre sí.

Este es un diagrama muy enfocado a la encapsulación y extensibilidad de los elementos del sistema (lo cual reducirá el esfuerzo de cambio cuando los stakeholders necesiten alguna evolución del sistema).

Cada elemento del diagrama se conoce como «elementos de definición» (elements of definition), principalmente serán bloques, valores (información que se almacena) e interfaces.

Bloque (block)

Representan a cualquier tipo de entidad ya sea interna o externa al entorno de nuestro sistema; no representan instancias de estas.

Cada bloque se compone de partes (part property) que representa algún tipo de información almacenada por el bloque. Las partes sólo se incluyen en el diagrama de diseño (un nivel algo más bajo de abstracción que el de modelado).

Relaciones

Los bloques se relacionan entre sí de diferentes maneras, la representación y la forma de relación es similar al diagrama de clases en UML.

• Asociación de referencia (reference association): indica una posible (no necesaria) conexión entre dos bloques de tal forma que puedan acceder el uno al otro. La multiplicidad indica el número de instancias mínimas y máximas de estos bloques pueden llegar a estar conectados entre sí. Si es bidireccional no se pone flecha (en otro caso, la flecha indica qué bloque va a acceder a qué otro bloque).

• Asociación de composición (composite association): es una descomposición estructural en dos o más bloques, indica que un bloque se compone de otros. La flecha se pone sólo si el bloque A se compone y accede al bloque B (sino se entiende que ambos bloques pueden acceder el uno al otro).

• Generalización (Generalization): herencia de un bloque padre a uno o más bloques hijos especializados. Se usa principalmente para crear clasificaciones jerarquizadas.

• Dependencia (Dependency): indica que un bloque (client) depende de otro (supplier) para funcionar; lo que se suele traducir en que, si cambia el supplier, probablemente también deba hacerlo el client.

Ejemplo de diagramas de bloques:

Diagrama de análisis (un nivel de abstracción más alto, podría considerarse el punto de inicio, las relaciones son sencillas, sin nombres y no se incluyen las part properties).

Diagrama de diseño (un nivel de especificación de los bloques más concreta).

Especificación de requisitos

Tras el análisis y modelado de los requisitos se procede a realizar la especificación formal de estos. Se redactan en lenguaje literal, categorizados por tipos de requisitos de forma que sean autocontenidos, no-ambigüos, sin faltas ortográficas-semánticas, y todo aquello que se tiene en cuenta posteriormente para la validación de requisitos.

Normalmente se aglutina todo en un solo documento formal que lleva una estructura estandarizada, el SRS de la IEEE es un buen ejemplo.

SRS – Software Requirements Specifications

Documento formal y estandarizado de la especificación de requisitos creado por la IEEE. Incluye todas las secciones que un sistema o producto software puede necesitar para definirse a sí mismo.

TODO.

Validación de requisitos

TODO.