Qué es la especificación de requisitos: definición, mejores herramientas y técnicas | Guía

La especificación de requisitos es una parte crítica del proceso de ingeniería de requisitos. Es la

tercera fase, después de la Captura y Análisis de Requerimientos. El objetivo es crear un
documento, o Especificación de Requisitos, con el nivel de detalle correspondiente. Este
documento contendrá todos los requisitos que se van a imponer en el diseño y verificación del
producto. También contendrá otra información relacionada necesaria para el diseño, verificación y
mantenimiento del producto.

¿Qué es la especificación de requisitos?

La especificación de requisitos, también conocida como documentación, es un proceso de anotar

todos los requisitos del sistema y del usuario en forma de documento. Estos requisitos deben ser
claros, completos, completos y coherentes. 

Durante la actividad de captura, recopilamos todos los requisitos de varias fuentes. Durante las
actividades de análisis y negociación, analizamos y entendemos esos requisitos. Ahora, debemos
preparar un documento formal que explique esos requisitos. Esa es la especificación de
requisitos. Para ser precisos, es el proceso de documentar todas las necesidades y restricciones
del usuario y del sistema de manera clara y precisa.

¿Qué es un requisito del sistema?

Los requisitos del sistema se pueden llamar la versión ampliada de los requisitos del usuario. Los
requisitos del sistema actúan como punto de partida para cualquier nuevo diseño de sistema.
Estos requisitos son una descripción detallada de los requisitos del usuario que el sistema debe
satisfacer.

¿Qué es un requisito de usuario?

El requisito del usuario es una combinación de requisitos funcionales y no funcionales. Estos

requisitos de usuario deben diseñarse de tal manera que sean fácilmente comprensibles para los
usuarios que no tienen ningún tipo de conocimiento técnico. Por lo tanto, deben estar escritos en
lenguaje natural utilizando tablas, formularios y diagramas simples. Además, asegúrese de que el
documento no tenga detalles sobre el diseño del sistema, el software o las anotaciones formales. 

¿Qué son los requisitos funcionales y no funcionales?

Los requisitos funcionales, como sugiere su nombre, describen las funciones del sistema que se
va a diseñar. Es una descripción de lo que será el sistema y cómo funcionará para satisfacer las
necesidades del usuario. Proporcionan una descripción clara de cómo se supone que el sistema
debe responder a un comando en particular, las características y lo que esperan los usuarios. 

Los requisitos no funcionales explican las limitaciones y restricciones del sistema a diseñar. Estos
requisitos no tienen ningún impacto en la funcionalidad de la aplicación. Además, existe una
práctica común de subclasificar los requisitos no funcionales en varias categorías, como

 Interfaz de usuario
 Confiabilidad 
 La Seguridad
 Rendimiento
 Mantenimiento
 Estándares 
Subclasificar los requisitos no funcionales es una buena práctica. Ayuda a la hora de crear una
lista de verificación de los requisitos que se deben cumplir en el sistema a diseñar. 

Los requisitos no funcionales son tan importantes como los requisitos funcionales. Si los
requisitos funcionales especifican lo que debe hacer un sistema, los requisitos no funcionales
describen cómo lo hará el sistema. Por ejemplo, la nueva aplicación nos proporcionará la lista
final de todos los usuarios conectados. Eso es parte de los requisitos funcionales. Si el requisito
dice que el sistema solo funcionaría en un sistema Windows y Linux, eso sería parte de los
requisitos no funcionales. 

La única diferencia entre los dos es que el sistema no puede funcionar sin satisfacer todos los
requisitos funcionales. Por otro lado, el sistema le dará el resultado deseado incluso cuando no
satisfaga los requisitos no funcionales.

¿Cuáles son los beneficios de tener una especificación de requisitos?

Hay muchos beneficios de tener una especificación de requisitos. Algunos de ellos se enumeran a
continuación:

 Ayuda a garantizar que todas las partes interesadas tengan un entendimiento común del
sistema que se va a desarrollar. Esto evita cualquier malentendido durante las etapas
posteriores del desarrollo.
 Sirve como punto de referencia para todas las partes interesadas durante el proceso de
desarrollo.
 Ayuda a identificar cualquier brecha en los requisitos en una etapa temprana.
 Reduce el costo general y el tiempo de desarrollo, ya que evita la repetición del trabajo
debido a cambios en los requisitos.

¿Estándares para los requisitos de escritura?

EARS sería una metodología efectiva aquí. Significa enfoque fácil para la sintaxis de requisitos.
En este método, escribimos un lenguaje claro, conciso y comprensible. Esto mejora todo el flujo
de trabajo de ingeniería de requisitos y simplifica el trabajo al hacer que las cosas sean bastante
fáciles de entender. 

Para lograr esto, aquí hay algunos principios que deben tenerse en cuenta al escribir los
requisitos. Implican:

 Cada requisito debe tener la forma de una oración completa. No se deben utilizar viñetas,
acrónimos, abreviaturas o palabras de moda. Trate de hacer oraciones cortas, directas y
completas. 
 Asegúrese de que cada requisito tenga un sujeto, un predicado y un verbo adecuados. El
tema sería el tipo de usuario o el sistema del que estamos hablando. El predicado serían
las condiciones o acciones o resultados deseados que esperamos. Debemos usar palabras
como 'deberá', 'voluntad' y 'debe' para expresar algún tipo de necesidad, y palabras como
'puede' para expresar opcionalidad en el requisito. 
 Cada requisito debe explicar de manera eficiente el resultado final que deseamos del
sistema. 
 Además, el requisito debe describir la calidad que esperamos del sistema. Ayuda cuando
medimos el resultado final y vemos si el requisito se implementa correctamente o no.

Tipos de Requisitos Especificaciones:

Existen numerosos tipos de especificaciones de requisitos. Incluyen especificaciones de

requisitos funcionales (FRS), especificaciones de requisitos de rendimiento (PRS),
especificaciones de requisitos de configuración (CRF), especificaciones de requisitos comerciales
(BRS), especificaciones de requisitos de confiabilidad (RRF), especificaciones de requisitos de
compatibilidad (CRF) y especificaciones de requisitos de software (SRS). ).

Especificaciones de requisitos funcionales: Una especificación de requisitos funcionales

(FRS) es un documento que captura las funciones que debe realizar un sistema. Incluye todas las
funcionalidades, instalaciones, medidas de seguridad y otra información relevante. En pocas
palabras, un FRS es un documento que contiene todo lo que debe hacer un sistema en particular.

Especificaciones de requisitos de rendimiento: Una especificación de requisitos de

rendimiento (PRS) es un documento que captura todos los aspectos relacionados con el
rendimiento de un sistema. Esto incluye el tiempo de respuesta, el rendimiento de datos, la
eficiencia, la escalabilidad, etc. Básicamente, todo lo que se puede cuantificar y mejorar se
incluye en la categoría PRS.

Especificación de requisitos de configuraciones: Una especificación de requisitos de

configuración (CRS) es un documento que captura toda la información relacionada con la
configuración de un sistema. Esto incluye detalles como plataformas compatibles, dependencias
de software/hardware, requisitos mínimos del sistema, etc.

Especificaciones de requisitos comerciales: Una especificación de requisitos comerciales

(BRS) es un documento que captura todos los aspectos relacionados con el negocio de un
sistema. Esto incluye características tales como administración de usuarios, seguridad, integridad
de datos, etc. Básicamente, cualquier cosa que afecte las operaciones comerciales de un sistema
se incluye en la categoría BRS.

Especificaciones de requisitos de confiabilidad: Una especificación de requisitos de

confiabilidad (RRF) es un documento que captura toda la información relacionada con la
confiabilidad de un sistema. Esto incluye aspectos como el tiempo de actividad, el tiempo de
recuperación, las tasas de error, etc.

Especificaciones de requisitos de compatibilidad: Una especificación de requisitos de

compatibilidad (CRF) es un documento que captura toda la información relacionada con la
compatibilidad de un sistema. Esto incluye aspectos como plataformas compatibles,
dependencias de software/hardware, requisitos mínimos del sistema, etc.

Especificaciones de requisitos de software: Una especificación de requisitos de software

(SRS) es un documento que captura todos los aspectos relacionados con el software de un
sistema. Esto incluye aspectos como la funcionalidad, el rendimiento, la escalabilidad, etc.
Básicamente, cualquier cosa que afecte las operaciones de software de un sistema se incluye en
la categoría SRS.

Especificación de requisitos de software frente a especificación de requisitos comerciales:

Las personas a veces mezclan los conceptos de software y las especificaciones de requisitos
comerciales. En realidad, ambos son bastante diferentes.

La principal diferencia entre la especificación de requisitos de software y la especificación de

requisitos comerciales es que la primera captura toda la información relacionada con el software,
mientras que la segunda captura toda la información relacionada con el negocio.
 Especificación de
Especificación de requisitos de
requisitos comerciales
software (SRS)
(BRS)

Es un documento formal que

describe los diversos Especifica los requisitos
requisitos proporcionados funcionales y no funcionales que
por el cliente/partes están presentes en el software. 
interesadas.

Se deriva de los requisitos e Se deriva de la Especificación de

interacciones del cliente. requisitos comerciales (BRS).

Lo crea un analista de sistemas,

Es creado por un analista de
un arquitecto de sistemas o un
negocios.
analista de negocios. 

Describe las especificaciones Describe las especificaciones

funcionales del software a un técnicas y funcionales del
nivel muy alto. software también a un alto nivel.

Se ocupa de los requisitos Se trata de los recursos que

comerciales. proporciona la empresa.

Define las necesidades del

Describe cómo funciona el
cliente. El documento se
negocio cuando se utiliza el
utiliza desde el principio
software o la aplicación.
hasta el final del proyecto.

No se incluyen tablas ni Se incluyen tablas y casos de

casos de uso. uso.
Características de un Documento de Especificación de Requisitos de Software:

 Preciso – El objetivo de un documento SRS es que sea fácil de comprender. Nada debe
quedar poco claro, por lo que no hay disputas entre las partes interesadas.
 Mensurable – Los requisitos en su documento SRS deben ser medibles, por lo tanto, el
producto terminado puede validarse y certificarse según los requisitos.
 Finalizar el proyecto – El documento SRS debe incluir suficiente información para que su
equipo de desarrollo y evaluadores completen el producto y garanticen que cumple con los
requisitos del usuario sin errores.
 Factible – Los requisitos deben reflejar el estado real de las cosas, incluido el costo, el
cronograma y la tecnología. No deberían depender de futuros avances tecnológicos.
 Planes de pago – Debido a que las circunstancias pueden cambiar en el lugar de trabajo,
su documento SRS debe ser lo suficientemente adaptable para adaptarse a los cambios.
No incluya material superfluo en varias secciones que deberán actualizarse cada vez que
haya un turno.
 Verificable – Todos los miembros del equipo de desarrollo deben tener acceso al
documento para que puedan consultarlo tantas veces como sea necesario. Debido a que
los requisitos deben ser claros, los miembros del equipo no quieren más información.
Todos deben estar accesibles en el documento SRS.
 Consistente – Los requisitos deben ser compatibles. No debe haber ninguna contradicción
entre las partes de su documento de requisitos. El documento debe estar estructurado de
manera consistente y la terminología debe usarse de la misma manera en todo el
documento.
  Sin restricciones de implementación – En general, un documento SRS debe ser lo
suficientemente detallado para realizar el trabajo, pero no tan específico como para
detener el desarrollo. Gran parte del desarrollo se basa en servicios de terceros sobre los
que los desarrolladores no tienen control.
 Preciso – Los requisitos especificados en los documentos deben ser muy precisos para
evitar cualquier tipo de confusión. No deben tener lagunas, ambigüedades, subjetividad,
superlativos o comparaciones.

Componentes esenciales de un SRS:

Las secciones principales de una especificación de requisitos de software son:

 Impulsores del negocio – Las razones por las que el cliente busca construir un sistema
se describen en esta sección. Esta sección incluye además los problemas que enfrenta el
cliente con el sistema actual y las oportunidades que brindará el nuevo sistema.
 Modelo de negocio – El modelo de negocio que el sistema debe soportar se analiza en
esta sección. Además, incluye varios otros detalles como el contexto organizacional y
comercial, las principales funciones comerciales y los diagramas de flujo de procesos del
sistema.
 Requisitos funcionales y del sistema – Esta sección normalmente detalla los requisitos
que están organizados en una estructura jerárquica. Los requisitos funcionales se
encuentran en el nivel superior y los requisitos detallados del sistema se enumeran como
subelementos.
 Casos de uso del sistema – Esta sección consta de un diagrama de casos de uso del
lenguaje de modelado unificado (UML) que explica todas las entidades externas clave que
interactuarán con el sistema y los diferentes casos de uso que tendrán que realizar.
 Requerimientos Técnicos – Esta sección analiza todos los requisitos no funcionales que
conforman el entorno técnico y las limitaciones técnicas en las que operará el software.  
 Cualidades del sistema – En esta sección, se definen las numerosas cualidades del
sistema, como la confiabilidad, la facilidad de servicio, la seguridad, la escalabilidad, la
disponibilidad y la mantenibilidad.
 Limitaciones y supuestos – Esta sección describe todas las limitaciones impuestas al
diseño del sistema desde el punto de vista del cliente. Las diversas suposiciones del
equipo de ingeniería sobre qué esperar durante el desarrollo también se analizan aquí.
 Criterios de aceptación – En esta sección se analizan los detalles de todas las
condiciones que deben cumplirse antes de que el sistema se entregue a los clientes
finales.

Estructura de un SRS:

1. Introducción -

La introducción explica el significado de SRS en general, su alcance para su equipo y su

estructura.

1.1. Propósito

Aquí, explique el objetivo y la estructura de la documentación del software SRS: los tipos de
requisitos que se abordarán, así como el personal que lo utilizará.

Mantenga esta sección corta: 1-2 párrafos son suficientes.

1.2. Público objetivo

Puede profundizar y explicar cómo las partes interesadas y los equipos trabajarán con SRS, así
como también participarán en su desarrollo. Estos suelen ser propietarios de productos,
inversores, analistas de negocios, desarrolladores, a veces probadores y personal de
operaciones. Toda la estructura está determinada por su enfoque de desarrollo de software y la
configuración organizativa del equipo.

1.3. Uso previsto

Describa en qué situaciones su equipo utilizará el SRS. Por lo general, se utiliza en los siguientes
casos:

 diseño y lluvia de ideas sobre nuevas características

 planificación de la duración del proyecto, sprints, estimación de costos
 evaluación de riesgos
 monitorear y medir el éxito del equipo
 situaciones conflictivas cuando las partes involucradas tienen diferentes visiones de un
producto bien ejecutado.

1.4. Alcance

Esta parte cubre el alcance del producto, por lo que deberá brindar una descripción general
rápida del sistema: su propósito principal, función y posición. Es comparable a cómo explicaría un
producto en una reunión de partes interesadas, excepto que se permite profundizar en detalles
técnicos.

Esta sección tiene que describir:

 Todos los tipos de usuarios que se espera que interactúen con el sistema
 Todas las partes esenciales de la arquitectura.

1.5 Definiciones y siglas

Los componentes antes mencionados constituyen una definición. Las definiciones brindan
información sobre la función, las tecnologías subyacentes, las personas objetivo, las entidades
comerciales (usuarios, clientes, intermediarios) y las partes interesadas. Puede usar un acrónimo
para escribir su SRS más rápidamente si así lo desea. El documento será legible siempre que la
tabla de definiciones lo tenga incluido.

A lo largo de su documento, el equipo usa con frecuencia ciertas palabras. Eliminar cualquier
posible malentendido, permitir que nuevos desarrolladores se incorporen y resolver situaciones
conflictivas será más fácil si aclara el significado de estas palabras.

2. Descripción general

En la segunda parte, describe a los lectores las características principales del producto, los
usuarios objetivo y el alcance del sistema. Esta descripción se concentra solo en las
características clave y la arquitectura del software sin entrar en detalles sobre complementos y
conexiones.

2.1 Necesidades del usuario

Esta parte es una cuestión de elección, por lo que algunas organizaciones optan por no incluirla
en su documentación de ingeniería de SRS. Creemos que es mejor enumerar los problemas que
desea resolver con su funcionalidad en este momento. Será útil más adelante durante las
funciones de lluvia de ideas y monitoreo. Puede volver a esta sección en cualquier momento
durante el proceso de desarrollo del producto y ver si el equipo de experiencia del usuario no se
ha desviado del camino previsto.

Las necesidades se refieren a problemas que los usuarios podrán resolver con el sistema. Puede
dividir estas necesidades en subcategorías si trata con una audiencia altamente segmentada.
Trate de no entrar en detalles sobre las necesidades de cada usuario. Debe dejar algo de espacio
para la interpretación, en caso de que un problema resulte ser más importante de lo que pensó
inicialmente.

2.2 Supuestos y Dependencias

Las suposiciones son las suposiciones del equipo sobre el producto y sus capacidades que serán
correctas en el 99 % de las situaciones. Es natural suponer, por ejemplo, que una plataforma que
ayuda a los conductores a navegar de noche se utilizará principalmente en modo nocturno.

¿Cuál es la importancia de las suposiciones? Le permiten concentrarse primero en las funciones

más importantes de la aplicación. Esta suposición ayuda a comprender que los diseñadores
deben desarrollar una interfaz adecuada para la visión en la oscuridad para un asistente de
conducción nocturna. Es posible que algunos usuarios abran la aplicación durante el día, pero es
una posibilidad remota, por lo que no necesita incluir elementos relacionados en el prototipo de
inmediato.

3. Características y requisitos del sistema

Esta parte cubre las características del producto y los criterios de ejecución en detalle. Debido a
que las dos secciones anteriores abordan el producto como un todo, aquí encontrará una
descripción más completa.

3.1 Requisitos funcionales

Los requisitos funcionales se establecen en una lista de funciones que se llevarán a cabo en un
sistema. Estos criterios tienen que ver con "¿qué se creará?" en lugar de "cómo" y "cuándo".

Los requisitos funcionales comienzan describiendo la funcionalidad requerida en función de lo

esencial que es para la aplicación. Si desea trabajar en él primero, puede comenzar con el
diseño, pero luego debe pasar al desarrollo. Los requisitos funcionales no entran en gran detalle
sobre las pilas de tecnología, ya que pueden cambiar a medida que avanza el proyecto. En lugar
de concentrarse en la lógica interna, los requisitos funcionales se centran en la funcionalidad del
usuario final.

3.2 Requisitos de la interfaz externa

Los requisitos funcionales son una parte importante de una especificación de requisitos del
sistema. Para cubrir todas las características necesarias del sistema, necesitará 4-5 páginas de
información. Algunos equipos los desglosan por temas para que el documento sea más fácil de
leer.

Por lo general, los componentes de diseño de SRS se denominan independientes del back-end y
la lógica empresarial. Esto tiene sentido ya que los diseñadores en lugar de los desarrolladores
manejan la mayor parte de esta área, pero también porque es donde comenzará el proceso de
desarrollo del producto.

Según el proyecto, los requisitos de la interfaz externa pueden ser de cuatro tipos:

 Interfaz de usuario
  Interfaz de software
 Interfaz de hardware
 Interfaz de comunicaciones

Los requisitos de la interfaz externa describen los elementos de la página que serán visibles para
el cliente final. Pueden incluir la lista de páginas, elementos de diseño, temas estilísticos clave,
incluso elementos artísticos y más si son esenciales para el producto.

3.3 Requisitos del sistema

Los requisitos del sistema del producto establecen las condiciones en las que se puede utilizar.
Por lo general, pertenecen a las especificaciones y características del hardware. Los requisitos de
hardware de SRS a menudo se definen por rangos mínimos y máximos, así como por un umbral
óptimo de rendimiento del producto.

Crear requisitos del sistema antes de comenzar a crear un producto puede parecer difícil, pero es
esencial. Los desarrolladores deben cumplir con los requisitos de hardware para no tener que
reiniciar el proyecto más tarde. Las aplicaciones móviles (con muchas variables a considerar) y
las aplicaciones que necesitan una alta reactividad (juegos, cualquier producto con VR/AR o IoT)
son particularmente vulnerables.

3.4 Requisitos no funcionales 

Para muchas organizaciones, esta parte de un SRS es la más difícil. Si los requisitos funcionales
abordan la cuestión de qué crear, los estándares no funcionales definen cómo. Establecen los
criterios de acuerdo con la eficacia con la que debe operar el sistema. Los umbrales de
rendimiento, seguridad y facilidad de uso están todos incluidos en esta área.

El valor real es lo que dificulta la definición de requisitos no funcionales. Es difícil definir frases
como "simultaneidad" o "portabilidad", ya que pueden tener varias interpretaciones para todas las
partes involucradas. Como resultado, recomendamos otorgar una puntuación a cada requisito no
funcional. Puede revisar los requisitos de su proyecto en cualquier momento para ver si el sistema
actual satisface las expectativas iniciales.