Ingeniería de 

Requisitos

"Patrones básicos y genéricos"

Ingeniería del Software

​Dr. Jose María Alvarez-Rodríguez

Contexto

• Los requisitos textuales son la forma más habitual de transmitir un deseo/necesidad.
• Por ello, nos encontramos con el problema del lenguaje natural
• ...
• Existen formas de mitigarlo...
  • Reglas de escritura de INCOSE (ya se han repasado las principales)
  • Utilización de patrones
    • Gramática restringida para evitar errores de una forma estructural
    • Unificación de los requisitos escritos

Ejemplos de Patrones

• No son únicos

• No son todos

• Se deberían adaptar a los diferentes contextos

  • ​Dominio
  • Tipo de requisito
  • ...

• Se requiere un vocabulario dominio: conceptos y relaciones

• ...

Patrón #1

<sistema>  <acción_futuro_simple> 

• El <sistema> puede ser el sistema en sí, subsistema o componente.
  • Coche, subsistema de frenado, pedal de freno
• La acción o capacidad mejor en futuro simple.

El coche  frenará.

Patrón #2

<sistema>  <acción_futuro_simple> <entidad>

• ...
• La <entidad> sobre la que se realiza la capacidad.

El coche frenará al pisar el pedal del freno

Patrón #3

<sistema>  permitirá  <entidad> estar en <estado_X>

• ...
• El <estado_X> se representa por un concepto o verbo del dominio.

El coche permitirá al motor estar sin la marcha engranada.

Patrón #4

<sistema> estará  <entidad>

• (Ver anteriores)

El coche estará en punto muerto.

Patrón #5

<sistema> tendrá <entidad>

• (Ver anteriores)

El coche tendrá un pedal de freno.

Patrón #6

<sistema> tendrá <factor_calidad>  

de al menos <cantidad> <unidad> 

• (Ver anteriores)

El sistema de calefacción del coche  tendrá disponibilidad 

de al menos 4 horas.

• Magnitudes y unidades de medida

Patrón #7

<sistema> tendrá <factor_calidad>  

de un máximo <cantidad> <unidad> 

• (Ver anteriores)

El sistema de calefacción del coche  tendrá disponibilidad 

de un máximo  6 horas.

Patrón #8

<sistema> no <acción_futuro_simple>​ 

• (Ver anteriores)
• ¡Cuidado con el uso de requisitos negativos!

El coche no hibernará.

Patrón #9

<sistema> no <acción_futuro_simple> <entidad>

• (Ver anteriores)
• ¡Cuidado con el uso de requisitos negativos!

El coche no acelerará al pisar el pedal del freno

Patrón #10

<sistema> no permitirá  <entidad> estar en <estado_X>

• (Ver anteriores)
• ¡Cuidado con el uso de requisitos negativos!

El coche no permitirá al conductor estar en marcha sin el cinturón abrochado.

Patrón #11

<sistema> no permitirá  <acción> <entidad>

• (Ver anteriores)
• ¡Cuidado con el uso de requisitos negativos!

El coche no permitirá manipular la centralita.

Patrón #12

<usuario> será capaz de <acción> 

• (Ver anteriores)
• Capaz de...->¡No recomendable en general!

El conductor será capaz de cambiar de marcha manualmente.

Patrón #13

<sistema> estará en <estado_X> <cantidad> <unidad>

• (Ver anteriores)
• Capaz de...->¡No recomendable en general!

El motor del coche estará en  reposo 5 minutos.

...¿más patrones?...

Diseñarlos

• Dominio
• Necesidad (cobertura del problema)
• Vocabulario
• Tipo de requisito
• ...

Créditos

• CESAR (Cost-efficient methods and processes for safety relevant embedded systems) Project, entregable D_SP2_R3.3_M3_Vol2: http://www.cesarproject.eu/

• Requirements Quality Suite. The Reuse Company Inc.