Documentos de Requisitos

IEEE Std 1233, Edición 1998 (incluye IEEE Std 1233–1996 e IEEE Std 1233a-1998)
GUI ́A PARA EL DESARROLLO DE ESPECIFICACIONES DE

REQUERIMIENTOS DE SISTEMAS
1. Descripción
1.1 Alcance
Esta gui ́a nos de la pauta para el desarrollo de un conjunto de requerimientos que satisfarán una
necesidad especi ́fica. En esta gui ́a, a ese conjunto de requerimientos se le denomina Especificación
de Requerimientos del Sistema (System Requirements Specification, SyRS). El desarrollo de una
SyRS incluye la identificación, organización, presentación y modificación de los requerimientos.
Esta gui ́a trata las condiciones necesarias para incorporar conceptos operacionales, restricciones
de diseñ o, y requerimientos de la configuración del diseñ o en la especificación. Además, trata las
caracteri ́sticas y cualidades necesarias de los requerimientos individuales y del conjunto de todos
los requerimientos.
2. Referencias
IEEE Std 100-1996 IEEE Std 610.12-1990 IEEE Std 730-1998 IEEE Std 828-1998 IEEE Std 830-1998
IEEE Std 1074-1997 IEEE Std 1220-1998 ISO 9000-1:1994
ISO 9126:1991 MIL-STD-490A MIL-STD-498
IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998
3. Definiciones
Las definiciones listadas a continuación tienen un significado en el contexto de esta gui ́a. Los
términos que no están definidos en esta gui ́a están incluidos en IEEE Std 610.12-1990.
3.1 Analista
Un miembro de la comunidad técnica (ingenieros en sistemas o analistas de negocios, que

desarrollan los requerimientos del sistema) que está capacitado para definir problemas y analizar,
desarrollar y expresar algoritmos.
3.2 Anotación
Documentación adicional que acompañ a a un requerimiento, tal como antecedentes y/o material
descriptivo.
3.3 Li ́nea base
Una especificación o sistema que ha sido formalmente revisado y aprobado, que sirve como base
para un desarrollo posterior y que puede ser modificado sólo a través de procedimientos formales
de control de cambios (EEEE Std 610.12-1990).
3.4 Restricción
Un enunciado que expresa li ́mites medibles para un elemento o función del sistema. Esto es, una
restricción es un factor impuesto a la solución que puede limitar o modificar el diseñ o.
3.5 Cliente
La entidad o entidades para los cuales los requerimientos deben ser satisfechos en el sistema que
está siendo definido y desarrollado. Éste puede ser el usuario final de un sistema terminado, una
organización dentro de la misma compañ i ́a desarrolladora, una compañ i ́a o entidad externa a la
compañ i ́a desarrolladora, o una combinación de las anteriores. Ésta es la entidad para la cual el
desarrollador de sistema debe demostrar que el sistema terminado satisface los requerimientos
especificados.
3.6 Requerimientos derivados
Es un requerimiento derivado o inferido del conjunto de los requerimientos en una configuración y

solución particular del sistema.
3.7 Elemento
Un componente de un sistema; puede incluir equipo, un programa de computadora o un humano.
3.8 Usuario final
La persona o personas quienes al final usarán el sistema para el propósito deseado.
3.9 Ambiente
Las circunstancias, objetos, y condiciones que influenciarán el sistema terminado; éstas incluyen
influencias poli ́ticas, de mercado, culturales, organizacionales asi ́ como estándares y poli ́ticas que
afectarán lo que el sistema debe hacer y cómo debe hacerlo.
3.10 Función
Una tarea, acción o actividad que debe ser realizada para alcanzar el resultado deseado.
3.11 Modelo
Una representación de un proceso, dispositivo o concepto del mundo real.
3.12 Prototipo
Un modelo experimental del sistema o parte del sistema, ya sea funcional o no funcional. Un
prototipo es usado para obtener retroalimentación de los usuarios, para ser capaces de mejorar y
especificar una interfaz de usuario compleja, para realizar estudios de factibilidad, o para
identificar requerimientos.
3.13 Requerimiento sin estructura
Es un requerimiento del cliente o del ambiente que no ha sido analizado ni formulado como un
requerimiento bien formado.
3.14 Representación
Una ilustración, dibujo, diagrama de bloques, descripción o si ́mbolo que representa de manera
lógica una imagen o situación fi ́sica, operacional o conceptual.
3.15 Requerimiento
1. a) Una condición o capacidad requerida por un usuario para resolver un problema o

alcanzar un objetivo.
2. b) Una condición o capacidad que debe ser posei ́da por un sistema o componente del
sistema para satisfacer un contrato, estándar, especificación, u otro documento
formalmente impuesto.
3. c) Una representación documentada de una condición o capacidad como las descritas en
los incisos a) o b) (IEEE 610.12-1990)
3.16 Sistema
Un grupo interdependiente de personas, objetos y procedimientos constituido para alcanzar

objetivos predefinidos o algún tipo de rol operacional para realizar funciones especi ́ficas. Un
sistema completo incluye equipo, material, programas de computadora, firmware, documentación
técnica, servicios, y el personal requerido para operar y dar el soporte adecuado para el uso
autosuficiente en el ambiente deseado.
3.17 Especificación de los requerimientos del sistema (SyRS)
Un conjunto o colección estructurada de información que contiene los requerimientos del sistema.
3.18 Capacidad de ser sometido a pruebas
El grado para el cual un requerimiento es declarado en términos que permitan establecer criterios
de prueba para determinar si esos criterios han sido alcanzados.
3.19 Rastreabilidad
El grado para el cual puede ser establecida una relación entre dos o más productos del proceso de
desarrollo, en particular aquellos productos que tienen relaciones predecesor-sucesor o maestro-
subordinado; por ejemplo, el grado en el que los requerimientos y el diseño de un elemento dado
del sistema concuerdan.
3.20 Validación
El proceso de evaluar un sistema o componente del sistema durante o al final del proceso de
desarrollo, para determinar si el sistema o componente satisface los requerimientos especificados.
3.21 Verificación
El proceso de evaluación de un sistema o componente para determinar si el sistema de una fase

de desarrollo determinada satisface las condiciones impuestas al principio de esa fase.
3.22 Requerimiento bien formado
Una declaración de la funcionalidad (o capacidad) del sistema que puede ser validada, y que debe
ser posei ́da o alcanzada por un sistema para resolver un problema del cliente o lograr los objetivos
del cliente, y que puede ser calificada mediante condiciones medibles y acotada por restricciones.
4. Especificación de Requerimientos del Sistema
Una SyRS tradicionalmente ha sido vista como un documento que comunica los requerimientos
del cliente a la comunidad técnica que especificarán y construirán el sistema. La colección de
requerimientos que constituyen la especificación y su representación actúan como el puente entre
los dos grupos y debe ser entendible tanto por el cliente como por la comunidad técnica. Una de
las tareas más difi ́ciles en la creación de un sistema, es aquella de comunicar a todos los
subgrupos, especialmente en un solo documento. Este tipo de comunicación usualmente requiere
diferentes formalismos y lenguajes.
4.1 Definición
La SyRS presenta los resultados de la definición de necesidades, los conceptos de operación y las
tareas de análisis de sistema. Como tal, es una descripción de lo que los clientes del sistema
esperan de éste, el ambiente del sistema, el perfil de uso del sistema, sus parámetros de
desempeñ o, y la calidad y efectividad deseados. Esto es, presenta las conclusiones del proceso de
desarrollo de la SyRS tal como se describe en la cláusula 5.
Esta gui ́a sugiere una distinción entre este conjunto estructurado de información y la manera en la
cual es presentada a sus varias audiencias. La presentación de la SyRS debe tomar una forma que
sea apropiada para su uso expli ́cito. Esta forma puede ser un documento, modelos, prototipos,
una representación en papel o cualquier combinación. De cualquier manera, se debe tener
cuidado de asegurar que cada una de estas representaciones sea rastreable hacia una fuente
común.
Esta gui ́a hace una clara distinción entre los requerimientos del sistema (qué debe hacer el
sistema) contenidos en la SyRS y los requerimientos del proceso (cómo se construye el sistema)
que deben estar contenidos en los documentos del contrato como seri ́a el Contrato de Trabajo.
4.2 Propiedades
El conjunto de requerimientos deberi ́a tener las siguientes propiedades:
1. a) Conjunto Ú nico. Cada requerimiento debe ser declarado sólo una vez.
2. b) Normalizado. Los requerimientos no se deben traslapar (Por ejemplo, no se deben
referir a
otros requerimientos ni a las capacidades de otros requerimientos).
3. c) Conjunto interdependiente. Se deben definir expli ́citamente las relaciones entre los
requerimientos individuales para mostrar cómo los requerimientos están relacionados

para
formar el sistema completo.
4. d) Completo. Una SyRS debe incluir todos los requerimientos dados por el cliente, asi ́
como
aquellos requerimientos necesarios para la definición del sistema.

5. e) Consistente. El contenido de una SyRS debe ser consistente y sin contradicciones en el
nivel de detalle, estilo de la declaración de los requerimientos y en la presentación del
material.
6. f) Acotado. Los li ́mites, alcance y el contexto de los requerimientos del sistema deben ser
identificados.
7. g) Modificable. La SyRS deberi ́a ser modificable. Requerimientos claros y sin
traslapamientos contribuyen a lograrlo.
8. h) Configurable. Las versiones deberi ́an ser mantenidas a través del tiempo y a través de
las
instancias de la SyRS.
9. i) Granular. Éste debe ser el nivel de abstracción para el sistema que está siendo definido
4.3 Propósito
El propósito de la SyRS es proveer una descripción tipo caja negra de lo que el sistema debe hacer,
en términos de las interacciones del sistema o las interfaces con su ambiente externo. La SyRS
debe describir completamente todas las entradas, salidas, y las relaciones requeridas entre salidas
y entradas. La SyRS organiza y comunica los requerimientos del cliente y la comunidad técnica.
4.3.1 Organizando los requerimientos
El propósito de la SyRS puede ser logrado mas fácilmente organizando los requerimientos en
categori ́as conceptuales. En la práctica, difi ́cil identificar y separar los requerimientos de otros
aspectos de la percepción del cliente del sistema que a menudo están incluidos en documentos
que se definen como “requerimientos”. Frecuentemente, los procedimientos tradicionales del
usuario y las suposiciones de la comunidad técnica acerca de la implementación nublan la
declaración fundamental de la necesidad.
Mientras se organizan las declaraciones no estructuradas del usuario en un conjunto estructurado

de requerimientos, el analista debe identificar los requerimientos técnicos sin intentar enunciar las
técnicas de implementación. El distraerse en temas de implementación antes de lograr entender
claramente los requerimientos nos puede llevar una declaración inadecuada de requerimientos asi ́
como a una implementación con fallas. Discernir entre requerimientos técnicos e
implementaciones técnicas en un constante reto para los analistas.
La descripción del sistema debe ser establecida en términos operacionales y logi ́sticos. Los temas a
tratar incluyen capacidades operacionales, caracteri ́sticas fi ́sicas, parámetros de rendimiento y
valores esperados, interfaces e interacciones con su ambiente, documentación requerida,
requerimientos de seguridad y confianza; asi ́ como requerimientos personales que se esperan del
sistema.
Estos requerimientos deberi ́an ser comunicados de manera estructurada para asegurar que el
cliente y la comunidad técnica puedan hacer lo siguiente:
1. a) Identificar requerimientos derivados de otros requerimientos.

2. b) Organizar requerimientos en diferentes niveles de detalle en un nivel apropiado.
3. c) Verificar que el conjunto de requerimientos esté completo.
4. d) Identificar inconsistencias entre los requerimientos.
5. e) Claramente identificar las capacidades, condiciones, y restricciones de cada
requerimiento.
6. f) Desarrollar un entendimiento común con el cliente del propósito y los objetivos del
conjunto de requerimientos.
7. g) Identificar requerimientos que completarán la SyRS.
Es importante que la estructura que sea dada al conjunto de requerimientos por los analistas, y
que las representaciones de la SyRS comuniquen los requerimientos de manera estructurada. La
cláusula 6 nos provee una gui ́a para definir expli ́citamente los requerimientos.
4.3.2 Comunición con dos audiencias
La SyRS tiene dos audiencias principales y esencialmente sirve para documentar un acuerdo entre
el cliente y la comunidad técnica.
4.3.2.1 Cliente
Cliente es un término colectivo que puede incluir al cliente del sistema propuesto, la persona que
aceptará y firmará la entrega, y los encargados quienes serán los responsables de vigilar la
implementación, operación y mantenimiento del sistema.
Todos los clientes tienen intereses e inquietudes que deben ser resueltos en la SyRS. Además,
algunos clientes podri ́an no entender el proceso de cómo establecer los requerimientos o el
proceso de creación del sistema. Aunque sean competentes en sus áreas de responsabilidad y en
la aplicación para el cual el sistema será definido, generalmente no están familiarizados con el
vocabulario ni con las técnicas de representación normalmente usadas para especificar
requerimientos. Como uno de los objetivos principales del análisis de requerimientos del sistema
es asegurar que la SyRS sea entendida, será necesario darle al cliente una representación de la
SyRS completa, concisa y clara, en un lenguaje que el cliente entienda.
4.3.2.2 Comunidad Técnica
La SyRS deberi ́a también comunicar los requerimientos del cliente a la comunidad técnica. La
comunidad técnica incluye analistas, estimadores, diseñ adores, desarrolladores, auditores de
aseguramiento de calidad, ingenieros, personal de integración, de pruebas, de mantenimiento y
de manufactura. Para esta audiencia la representación de la SyRS debe ser técnicamente precisa y
presentada en un formalismo adecuado para que ellos puedan diseñ ar, construir y probar el
sistema requerido.
4.4 Uso recomendado
Los usos recomendados de la SyRS pueden variar conforme el ciclo de desarrollo progrese, son los
siguientes:
a) Durante el diseñ o del sistema, los requerimientos son asignados a subsistemas, hardware,
software, operaciones y otros componentes importantes del sistema.
b) La SyRS es utilizada para construir el sistema resultante. También es usada para escribir
apropiadamente los planes de verificación del sistema. Si el sistema contiene hardware y software,
entonces el plan de pruebas de hardware y el plan de pruebas de software son generados para los
requerimientos del sistema.
c) Durante la fase de implementación, los procedimientos de prueba serán definidos a partir de la

SyRS.
d) Durante el proceso de validación, los procedimientos de validación basados en la SyRS serán

usados para darle al cliente las bases para aceptar el sistema.
Si se van a hacer cambios a la li ́nea base de la SyRS, éstos deberán ser controlados a través de un
proceso formal de gestión de cambios. Este proceso debe incluir una negociación apropiada entre
las partes afectadas por el cambio y debe activar procedimientos de control riesgos cuando sea
pertinente (por ejemplo: calendario, costos).
4.5 Beneficios
Una SyRS apropiadamente escrita beneficia todas las subsecuentes fases del ciclo de vida de varias
maneras. La SyRS documenta el conjunto completo de capacidades del sistema y nos provee de los
siguientes beneficios:
1. a) Asegura al cliente que la comunidad técnica entiende sus necesidades y que están
respondiendo a ellas.
2. b) Una oportunidad temprana para una mutua retroalimentación entre el cliente y la
comunidad técnica.
3. c) Un método para que el cliente y la comunidad técnica puedan identificar problemas y
malentendidos mientras los costos de corregirlos son relativamente baratos.
4. d) Una base para la calificación y calidad del sistema para establecer que el sistema
cumple con las necesidades del cliente.
5. e) Protección para la comunidad técnica, proporcionando una li ́nea base para las
capacidades del sistema y una base que determine cuando la construcción del sistema
está completa.
6. f) Soporte para el desarrollador en la planificación, diseñ o y desarrollo del programa.
7. g) Ayuda en la evaluación de los efectos de los inevitables cambios en los requerimientos.
h) Incrementa la protección en contra de los malentendidos entre el cliente y la comunidad

técnica durante el progreso del desarrollo.
4.6 Dinamismo de los requerimientos del sistema
Los requerimientos son raramente estáticos. Aunque es deseable congelar un conjunto de

requerimientos permanentemente, esto es raramente posible. Los requerimientos que son
propensos a evolucionar deben ser identificados y comunicados tanto a la comunidad técnica
como al cliente. Un subconjunto medular de requerimientos puede ser congelado al inicio. El
impacto al proponer nuevos requerimientos debe ser evaluado para asegurar que la propuesta
inicial de la li ́nea base de requerimientos se mantenga, o que los cambios a dicha propuesta sean
entendidos y aceptados por el cliente.
5. Descripción del proceso de desarrollo de la SyRS
Esta cláusula proporciona una descripción de los pasos en el proceso de desarrollo de la SyRS. El
proceso de desarrollo de los requerimientos del sistema, en general, se relaciona con 3 agentes
externos (cliente, ambiente y comunidad técnica) Cada uno de estos agentes es descrito en la
figura siguiente:
Cliente
objetivos, necesidades y problemas

retroalimentación del cliente
Representación para el cliente restricciones / influencia
Obtención del conjunto de requerimientos del sistema
retroalimentación técnica
5.1 Cliente
Ambiente
representación técnica
Figura 1 - Contexto de desarrollo de SyRS
Los clientes son el elemento clave del contexto de la SyRS. Ellos son los principales conductores del
sistema proporcionando sus objetivos, necesidades o problemas para el proceso de generación de
la SyRS.
5.1.1 Requerimientos sin estructura
Previo al proceso de SyRS, el cliente tuvo la idea de un sistema, para mejorar un proceso o para
resolver un problema. En este punto, cualquier concepto inicial para un sistema puede ser
impreciso y sin estructura. Los requerimientos usualmente serán entremezclados con las ideas y
sugerencias
Comunidad técnica

de un diseñ o potencial. Estos requerimientos sin estructura son muchas veces expresados en
documentos iniciales parecidos a los siguientes:
1. a) Concepto de operaciones. Este tipo de documento se enfoca en las metas, objetivos y

capacidades deseadas del sistema potencial sin indicar como se implementará el sistema
para lograr su objetivo.
2. b) Concepto de sistema. Este tipo de documento incluye información sobre el concepto
de operaciones, pero además va a incluir un diseño de la interfaz preliminar para el
sistema y otros requerimientos expli ́citos.
3. c) Especificaciones de mercadotecnia. Este tipo de documento incluye una lista de
caracteri ́sticas para un nuevo sistema o sistemas e identificarán el alcance de sus
caracteri ́sticas y su prioridad para proporcionar una ventaja en el mercado. Además,
incluye un contexto definiendo cómo el nuevo sistema debe interactuar con los sistemas
existentes. Un análisis de costo/beneficio y un calendario de entrega podri ́an ser
provistos.
4. d) Petición de la oferta (Request for proposal - RFP). En algunas situaciones un RFP será
preparado. Ésta puede incluir uno o más de los documentos anteriores. El propósito será
solicitar ofertas para construir el sistema, o para simplemente requerir asistencia para
generar documentos iniciales del sistema.
5. e) Interfaces externas del sistema. La definición de todas las interfaces externas del
sistema, literalmente o por referencia, es una de las actividades más importantes a lograr
antes de la generación de la SyRS. Una definición aprobada del universo externo del
sistema limita razonablemente o restringe lo que el sistema debe hacer internamente.
Todos los elementos conocidos de cada interfaz definida individualmente deben ser
descritos. Esta información puede ser incluida en la SyRS siempre y cuando no sea
demasiado extensa. Aunque en la mayori ́a de los casos es mejor tener un documento de
control de interfaces externas del sistema. Hay muchos tipos de posibles interfaces
externas al sistema y un solo sistema puede tener varias interfaces de diferentes tipos. La
siguiente lista provee algunos ejemplos:
 Operacional
 Computadora a computadora
 Eléctrica
 Intercambio de datos y protocolos
 Li ́neas de telecomunicaciones
 Dispositivo a sistema, sistema a dispositivo
 Computadora a sistema, sistema a computadora
 Sensible al ambiente y control de interfaces
5.1.2 Representación para el cliente
Retroalimenta al cliente, incluye representaciones de SyRS e intercambio técnico o comunicación

de aclaraciones y/o confirmación de requerimientos.
5.1.3 Retroalimentación del cliente
Incluye información actualizada de los objetivos, problemas o necesidades del cliente;

modificación de requerimientos concernientes a la comunicación de intercambio técnico; e
identificar nuevos requerimientos.
5.2 Ambiente
Además del analista y del cliente, el ambiente puede impli ́cita o expli ́citamente influenciar o poner
restricciones en los requerimientos del sistema. El analista debe estar enterado de estas
influencias en las capacidades del sistema. En caso de que el sistema sea sensible a las influencias
del ambiente, el cliente y el analista especificarán las influencias que afectan los requerimientos
del sistema. Las influencias ambientales pueden ser clasificadas en categori ́as traslapadas, como
sigue:
 Poli ́tica
 De mercado
 Estándares y poli ́ticas técnicas
 Cultural
 Organizacional
 Fi ́sicas
5.2.1 Influencia Poli ́tica
Agencias gubernamentales internacionales, federales, estatales y locales tienen leyes y

regulaciones que influyen en los requerimientos del sistema. Algunas agencias gubernamentales
pueden tener organizaciones que regulan y obligan a cumplir sus leyes y regulaciones. Ejemplos de
leyes gubernamentales son derechos reservados, patentes, y marcas registradas. Ejemplos de
regulaciones gubernamentales son zonas de ubicación, riesgos ambientales, desechos, reciclaje,
sistemas de seguridad y salud.
La influencia poli ́tica cambia en función de limitaciones poli ́ticas, lo cual afecta los requerimientos
de sistema, ya que un ambiente puede ser completamente diferente de otro. Por lo que es
importante hacer una investigación del ambiente poli ́tico donde será manufacturado y/o usado
para asegurar que el sistema cumple con todas las leyes y regulaciones gubernamentales.
5.2.2 Influencia del mercado
Hay tres tipos de condiciones de mercado que influyen en el desarrollo de las especificaciones del
sistema. La primera es cumplir las necesidades del cliente haciendo una investigación de mercado
o desarrollando mercados que cumplan con la investigación técnica. Cumplir las necesidades del
cliente en los sistemas afecta los requerimientos del sistema y se convierte en parte de los
requerimientos del cliente.
La segunda influencia del mercado es la satisfacción de la demanda. Esta influencia debe ser
considerada porque afecta la distribución y accesibilidad del sistema, lo cual es agregado a los
requerimientos del sistema. Sin acceso sencillo al sistema, el éxito será limitado. Por lo que, es
importante considerar los segmentos de mercado para los que el sistema está enfocado y
considerar la información de mercado puede ser usado para derivar los requerimientos del
sistema.
La tercera influencia del mercado es la competencia. Conociendo los sistemas de la competencia

nos ayudará a definir los requerimientos. Para mantenerse competitivo, se debe considerar lo
siguiente:
a) Funcionalidad b) Precio
c) Confiabilidad
d) e) f) g)
Durabilidad Funcionamiento Mantenimiento Seguridad del sistema
Analizar la
los sistemas nuevos y de los ya existentes. Los sistemas pueden evolucionar en sistemas
completamente diferentes que pueden tener pequeñ as semejanzas a los conceptos originales del
cliente.
5.2.3 Influencia de los estándares y reglamentos técnicos
Los requerimientos del sistema están influenciados directamente por los clientes quienes tienen
que estar conforme a los estándares y reglamentos técnicos dictados por el gobierno o industrias.
Las poli ́ticas técnicas y estándares asociados y los lineamientos ayudan a asegurar lo siguiente:
1. a) consistencia del sistema

2. b) seguridad del sistema
3. c) confiabilidad y mantenimiento del sistema
Los estándares de seguridad industrial son generalmente impuestos para ayudar a prevenir riesgos
y problemas legales potenciales. Cumplir con las reglas de seguridad debe estar claramente
identificado en el documento de SyRS. El cliente y la comunidad técnica pueden requerir que el
sistema pase ciertos criterios de confiabilidad como está prescrito en los estándares técnicos. Los
requerimientos de confiabilidad y mantenimiento deben estar identificados en la SyRS. Estos
requerimientos pueden venir en varias formas.
5.2.4 Influencia cultural
La cultura son los patrones de comportamiento humanos que son transmitidos de generación en
generación. Es una experiencia adquirida que proviene de creencias religiosas, pai ́s de origen,
grupo étnico, nivel socioeconómico, lenguaje, medios de comunicación, empleo y familia
inmediata. Para entender la cultura de la región o de un segmento de mercado, deben conocerse
los valores y creencias de la gente. La influencia cultural debe ser considerada cuando se está
desarrollando un sistema porque afectará los requerimientos de éste.
5.2.5 Influencia organizacional
Los requerimientos del sistema son influenciados por la organización en la cual los requerimientos
son desarrollados. La influencia de la organización puede tomar la forma de mercadotecnia,
poli ́ticas internas, reglamentos técnicos y estándares internos. Por ejemplo, cada compañ i ́a tiene
su propia cultura, propósito, valores, objetivos, que pueden e influenciarán el sistema que
desarrollan, manufacturan y/o entregan.
5.2.6 Influencia fi ́sica
Incluyen las influencias naturales y humanas tales como temperatura, radiación, humedad,
presión y qui ́micos.
competencia en el mercado es un proceso continuo que afectará los requerimientos de
5.3 Comunidad técnica
La comunidad técnica está compuesta de aquellos involucrados en las actividades de diseño,

implementación, integración, pruebas, manufactura, despliegue, operaciones y mantenimiento del
sistema. Todos los elementos de la comunidad técnica deben estar involucrados en el proceso de
desarrollo de la SyRS tan pronto como sea posible. La inclusión temprana de la comunidad técnica
provee un mecanismo para que los desarrolladores de la SyRS reduzcan la posibilidad de que
nuevos requerimientos y cambios a los requerimientos originales sean descubiertos después en el
ciclo de vida del sistema.
5.3.1 Representación técnica
Representación del conjunto de los requerimientos, preparados para la comunidad técnica, puede
incluir intercambios técnicos o comunicaciones que clarifican y/o conforman requerimientos.
5.3.2 Retroalimentación técnica
La comunidad técnica proporciona retroalimentación durante varias actividades que pueden

causar modificaciones, adiciones y/o eliminaciones al conjunto de requerimientos. La SyRS es
refinada debido a la necesidad de apoyar las fases subsecuentes del ciclo de vida del sistema. Por
ejemplo, después de la fase de requerimientos, se desarrolla un plan de pruebas del sistema
donde los requerimientos individuales son asignados a pruebas especi ́ficas. Este proceso puede
revelar requerimientos que no pueden ser probados, resultando en la modificación de la SyRS.
Otra retroalimentación de la comunidad técnica puede proveer a los clientes de las caracteri ́sticas
más recientes del sistema, tecnologi ́a de punta, asi ́ como recomendaciones de métodos avanzados
de implementación.
6. Requerimientos bien formados
Esta cláusula explica las propiedades de un requerimiento bien formado. Provee un ejemplo de un
requerimiento bien formado, y señ ala los errores comunes en los requerimientos.
6.1 Definición de un requerimiento bien formado
Un requerimiento bien formado es una declaración de la funcionalidad del sistema que puede ser
validada, y que debe ser posei ́do por el sistema para resolver el problema de un cliente o lograr el
objetivo del cliente, y que está calificado por condiciones medibles y delimitado mediante
restricciones. Esta definición ayuda en la clasificación de los requerimientos generales del cliente.
Éstos pueden ser tomados de las necesidades del cliente y pueden ser derivados del análisis
técnico. La definición provee un medio para distinguir entre requerimientos como capacidades y
los atributos de estos requerimientos. Las restricciones pueden ser funcionales o no funcionales.
Un ejemplo de una restricción no funcional podri ́a ser que el sistema sea pintado con un tono
particular de azul solamente para propósitos decorativos.
Esta gui ́a recomienda que el proceso de implementación de requerimientos del sistema, tal como
demandar una metodologi ́a particular de diseñ o no sea incluido en la SyRS. Éstos deben ser
capturados en otra documentación técnica de control del sistema como seri ́a planes de calidad o
contratos de trabajo.
6.1.1 Capacidades
Son los requerimientos fundamentales del sistema y representan las caracteri ́sticas o funciones
del sistema requerido por el cliente. Una capacidad debe usualmente ser enunciada de tal manera
que describa lo que el sistema debe hacer. La capacidad debe además ser enunciada de tal manera
que sea independiente de la solución. Esto permitirá considerar diferentes maneras de alcanzar
los objetivos o de proveer la caracteri ́stica o función.
Por ejemplo, capacidades de un sistema de trenes de alta velocidad entre L.A. y N.Y. puede incluir
la capacidad de arrancar, acelerar, circular, desacelerar, parar, subir y bajar pasajeros. De
cualquier manera, ni el tipo de computadora ni el sistema operativo se consideran capacidades del
sistema de trenes de alta velocidad.
6.1.2 Condiciones
Son atributos y características medibles, cualitativa o cuantitativamente, que son estipulados para
una capacidad. Permiten calificar una capacidad necesaria, y proporciona atributos que permiten
que una capacidad sea formulada y enunciada de tal manera que pueda ser validada y verificada.
Por ejemplo, en el sistema de trenes de alta velocidad antes mencionado, la capacidad de circular
puede ser circular en un rango de 0-300 Km/hr o en un rango óptimo de 200 Km/hr.
Tiene sentido incluir condiciones (atributos medibles) sólo si son aplicadas a algo que pueda ser
medido tal como una capacidad. Por ejemplo, es insignificante tener un requerimiento de sistema
que diga de 0-200 Km/hr en abstracto. Este rango puede describir una velocidad de circulación
para una vi ́a de alta velocidad, pero no la velocidad de un elevador.
6.1.3 Restricciones
Son requerimientos que son impuestos sobre la solución por circunstancias, por la fuerza o por
compulsión. Limita absolutamente las opciones abiertas al diseñ ador de la solución imponiendo
li ́mites inamovibles.
Una lista de restricciones puede incluir una lista de interfaces a sistemas ya existentes (por
ejemplo, formato, protocolos o contenidos) donde la interfaz no puede ser cambiada, limitaciones
fi ́sicas (por ej, cuando un controlador debe caber en cierto espacio en el ala de un avión), leyes de
la naturaleza, leyes de un pai ́s, tiempo o presupuesto disponibles, prioridad (obligatorio u
opcional), o plataformas existentes.
Las restricciones pueden ser identificadas como requerimientos por si ́ mismas, o como
limitaciones de requerimientos individuales. Muchas restricciones, tal como el uso de determinada
tecnologi ́a (por ej, el sistema operativo) serán aplicables a todo el conjunto de capacidades. Otras
restricciones son aplicables a una o a pocas capacidades.
6.1.4 Ejemplo
Capacidad: Trasladar personas entre L.A y N.Y. Condición: Velocidad de circulación de 200 Km/hr
Restricción: Velocidad máxima de 300 Km/hr
6.2 Propiedades de un requerimiento
Cada requerimiento debe poseer las siguientes propiedades:
1. a) Abstracto. Cada requerimiento debe ser independiente de su implementación.

2. b) No ambiguo. Cada requerimiento debe ser enunciado de tal manera que pueda ser
interpretado de una sola manera.
3. c) Rastreable. Para cada requerimiento debe ser factible determinar una relación entre las
declaraciones realizadas por el cliente y los requerimientos especificados en la SyRS,
esto como evidencia del origen del requerimiento.
4. d) Validable. Para cada requerimiento debe existir la manera de probar que el sistema
satisface los requerimientos.
6.3 Clasificación
Los requerimientos deben ser clasificados de acuerdo a un identificador, prioridad, criticismo,

factibilidad, riesgo, fuente, y tipo.
1. a) Identificación. Cada requerimiento debe ser identificado de forma única (por ej, un
número, etiqueta, mnemónico, etc.).
2. b) Prioridad. El cliente debe identificar la prioridad de cada requerimiento. Ésta puede ser
establecida mediante un consenso entre los clientes potenciales. Se puede usar una escala
1:10, o bien, un esquema tal como alta, media, baja para identificar la prioridad de cada
requerimiento.
3. c) Criticismo. El analista, junto con el cliente, debe definir el criticismo de cada
requerimiento. Algunos requerimientos pueden tener una prioridad baja desde el punto
de vista del cliente, pero ser esenciales para el éxito del sistema. Por ejemplo, un
requerimiento para medir la temperatura ambiente externa puede ser esencial para otros
requerimientos tal como mantener la temperatura interna de la cabina de un avión.
4. d) Factibilidad. El cliente y el analista deben identificar la factibilidad de incluir cada
requerimiento particular en el sistema y clasificar cada requerimiento por tipos de
factibilidad apropiados para el dominio del sistema. La factibilidad puede basarse en el
estado actual de la tecnologi ́a (por ej, componentes disponibles comercialmente vs
análisis original del sistema), el ambiente del cliente (por ej, la facilidad de adaptar un
cambio), y los riesgos y costos asociados al nuevo requerimiento.
5. e) Riesgo. Las técnicas de análisis de riesgos pueden ser usadas para determinar un nivel
de riesgo para los requerimientos del sistema. En término de sus consecuencias, los
riesgos pueden estar relacionados con pérdidas financieras potenciales, impacto en el
ambiente, temas de seguridad y salud, y leyes y estándares nacionales.
6. f) Origen. Cada requerimiento deberi ́a ser clasificado mediante una etiqueta que indique
su origen. Puede haber múltiples fuentes que pueden ser todas ellas consideradas los
creadores del requerimiento. Es útil identificar los creadores de cada requerimiento, de tal
manera que si el requerimiento no es claro, hay conflictos, o requiere ser modificado o
eliminado, será posible identificar los individuos u organizaciones a ser consultados.
7. g) Tipo. Los requerimientos pueden ser clasificados por uno o más de los siguientes tipos:
- Entrada
- Salida
- Confiabilidad - Disponibilidad
IEEE
Std 1233, Edición 1998
------------------
Desarrollo de Especificaciones de Requerimientos de Sistemas
Facilidad de mantenimiento Desempeño

Rutas de acceso Condiciones ambientales Ergonomi ́a
Seguridad
Facilidad de uso
Medios de transporte
Entrenamiento
Documentación
Interfaces externas
Pruebas
Calidad
Poli ́ticas y regulaciones Compatibilidad con sistemas existentes Conversión
Capacidad de expansión
Instalación
6.4 Errores comunes
Algunos errores ti ́picos que deben evitarse a la hora de construir un requerimiento bien formado
son los siguientes:
1. a) Diseñ o e implementación. Hay una tendencia por parte de los analistas y clientes,
quienes están definiendo los requerimientos, de incluir decisiones de diseñ o e
implementación en los requerimientos. En este caso, la información debe ser
documentada y comunicada en algún otro tipo de documento auxiliar de diseño e
implementación
2. b) Sobre-especificación.
1. 1) Requerimientos que describen un sistema comercial que puede ser comprado
en
lugar de construido (ésta no es una declaración de lo que el sistema debe hacer).
2. 2) Requerimientos que establecen rangos de tolerancia para elementos de muy

bajo
nivel del sistema conceptual.
3. 3) Requerimientos que implementan soluciones (los requerimientos describen

una
necesidad).
3. c) Sobre-restringido. Requerimientos con restricciones innecesarias (por ej, si un sistema
debe trabajar con bateri ́as recargables, un requerimientos derivado podri ́a ser que el
tiempo de recarga de la bateri ́a fuera menor a 3 hr. Si este tiempo es muy restrictivo,
soluciones potenciales podri ́an ser desechadas).
4. d) Sin li ́mites.
1. 1) Requerimientos que establecen enunciados relativos (estos requerimientos no
pueden ser verificados y podri ́an requerir ser reescritos. Por ej, el requerimiento
“minimizar ruido” puede ser enunciado como “los rangos de ruido no deben
exceder ... ”).
2. 2) Requerimientos abiertos (por ej, enunciados que contienen “etc.”).

3. 3) Requerimientos que hacen declaraciones subjetivas o vagas (frecuentemente
contienen términos como “amigable con el usuario”, “rápida respuesta”, o
“costeable”).
5. e) Suposiciones.
IEEE
Std 1233, Edición 1998
1) 2)
Desarrollo de Especificaciones de Requerimientos de Sistemas
Requerimientos basados en suposiciones no documentadas (la suposición debe ser documentada

tanto como el requerimiento).
Requerimientos basados en suposiciones de que un sistema o estándar en particular será
terminado en determinada fecha (se debe documentar la suposición y una solución alternativa).
7. Desarrollo de la SyRS
El desarrollo de SyRS es un proceso iterativo. Los cuatro subprocesos que incluye son los
siguientes:
1. a) Identificar requerimientos del usuario, el ambiente y la experiencia de la comunidad

técnica;
2. b) Construir requerimientos bien formados;
3. c) Organizar los requerimientos en una SyRS;
4. d) Presentar la SyRS en varias representaciones para diferentes audiencias.
El propósito de descomponer el proceso de desarrollo de la SyRS en subprocesos auxilia a un

desarrollo completo y correcto de la SyRS. Los subprocesos presentes en la siguiente figura
ocurren secuencialmente. Sin embargo, frecuentemente, existirá algún grado de traslape o
iteración.
La aplicación iterativa de este proceso resulta en la subsecuente modificación de la SyRS. Las

modificaciones son generalmente aplicadas a una li ́nea base de la SyRS, y gestionada bajo
procedimientos de control de cambios. Ver IEEE Std 1220-1998 para procedimientos de control de
cambios.
Cliente
Ambiente
Requerimientos sin estructura

Identificar Restricciones/Influencia los
requerimientos
Conjunto de Requerimientos
Requerimientos bien formados
Requerimientos clasificados
Construir requerimientos bien formados
Organizar los requerimientos
Retroalimentació n del cliente

Cliente
Comunidad técnica
Retroalimentació n técnica
Presentar la SyRS
Representación técnica
Figura 2 – proceso de desarrollo de la SyRS
Representación para el cliente
Cliente
Comunidad técnica
7.1 Identificar los requerimientos
Mientras se trabaja con los clientes, los analistas filtran las entradas y extraen un conjunto de
requerimientos, establecen los requerimientos derivados necesarios y crean los requerimientos.
Los requerimientos pueden ser extrai ́dos desde los documentos iniciales hasta ejercicios anali ́ticos
conducidos con el cliente. La meta de este proceso iterativo es extraer todos los requerimientos
del sistema, y asegurarse de que cada requerimiento es establecido sólo una vez y que no falta
ninguno.
Existen una variedad de enfoques que pueden aplicarse durante la identificación de

requerimientos. En la práctica, cada organización tendrá sus propias técnicas para identificar los
requerimientos e iniciar el proceso de crear una solución para el sistema. En algunas
organizaciones, los clientes tomarán el proceso de identificación de forma interna. En este caso la
identificación y especificación de requerimientos es dirigida por el cliente. En otras organizaciones,
los clientes identificarán un conjunto preliminar de requerimientos y solicitarán asistencia de un
analista dentro de su organización o a través de un contrato con un consultor externo o un
integrador de sistemas.
El analista, ya sea interno o externo a la organización, trabajará junto con el cliente para identificar
y estructurar los requerimientos. En algunas organizaciones el analista trabajará directamente con
el cliente. En otras organizaciones, el analista no tendrá acceso directo al cliente y trabajará a
través de uno o más intermediarios (legales, técnicos, administrativos) representantes del cliente.
Debido a la dinámica que involucra la identificación de requerimientos, es importante que el

cliente y el analista estén de acuerdo en el proceso. El analista requiere preparar un plan para
guiar el proceso, definir representaciones de la SyRS que serán producidas para las diferentes
audiencias, e identificar las herramientas y técnicas a ser usadas.
Un proceso de gestión de requerimientos debe ser usado para asegurar lo siguiente:

1. a) El proceso está orientado a los objetivos y dirigido a la producción de un conjunto de
requerimientos.
2. b) El alcance del sistema es definido.
3. c) Todos los requerimientos son detectados, evaluados y documentados.
4. d) Los requerimientos son especificados como capacidades, y condiciones calificativas y
restricciones son identificadas para cada capacidad.
5. e) Los requerimientos son validados, o desechados si son inválidos, del conjunto de
requerimientos.
6. f) Se considera la consistencia del documento cuando participan varios autores en la
producción de la SyRS.
7. g) El conjunto de requerimientos bajo desarrollo es comprendido al nivel apropiado de

detalle
por todos los individuos participantes del proceso.
7.1.1 Técnicas para identificar requerimientos
Los requerimientos surgen como ideas o conceptos que pueden originarse como una respuesta a
una amenaza percibida o competencia del mercado, de una imposición legal o regulación, del
deseo de crear un nuevo o mejor sistema o proceso, de la necesidad de reemplazar un sistema
existente o alguna otra necesidad percibida.
Hay muchas técnicas para identificar los requerimientos, incluyendo las siguientes:
1. a) Talleres estructurados
2. b) Sesiones de tormentas de ideas
3. c) Entrevistas
4. d) Cuestionarios
5. e) Observación de campo
6. f) Revisión de la documentación técnica
7. g) Análisis de mercado
8. h) Ingenieri ́a inversa
9. i) Simulaciones
10. j) Prototipos
7.1.2 Interacción entre clientes y analistas
En una situación donde un analista ha sido contratado para trabajar con un cliente, será necesario
establecer un proceso efectivo de interacción entre las dos partes. Para hacer esta interacción
efectiva, cada parte necesita entender que ellos tienen el rol de enseñ ar a la otra parte y que
deben trabajar juntos para definir los requerimientos.
7.1.2.1 Educación mutua
La educación debe ser un proceso de dos vi ́as. Primero, el analista necesita aprender acerca del
ambiente del cliente, del sistema actual (si existe) y de los requerimientos. Se requiere asignar
tiempo y esfuerzo por ambas partes para este proceso educativo.
Segundo, los clientes también necesitan educación. Pueden necesitar educación del analista
durante el proceso de identificación y especificación de los requerimientos. Además, el analista
puede ser requerido para educar a sus clientes con respecto a los requerimientos por si ́ mismos y
contribuir requerimientos desde su experiencia.
7.1.2.2 Definición conjunta de los requerimientos
Hay múltiples maneras en las cuales el cliente y el analista pueden interactuar en el proceso de
definición de requerimientos. Por ejemplo, el analista puede simplemente conducir entrevistas
para solicitar datos y entonces organizar y presentar los requerimientos para ser revisados por el
cliente.
La experiencia del analista es muy importante, pero no debe influir ni menospreciar la

participación del cliente de ninguna manera. Mientras trabajan con el cliente, su objetivo principal
debe ser el de solicitar y organizar los requerimientos derivados del cliente. También deben
agregar requerimientos desde su propia experiencia o de previas soluciones de sistemas
predefinidos sólo cuando estos requerimientos han sido olvidados por el cliente.
Como otro ejemplo, personal del cliente puede trabajar con el analista en sesiones de trabajo en
grupo. En estas sesiones puede haber una gran cantidad de ideas y definición interactiva de
requerimientos. Estas sesiones son normalmente dirigidas por el analista. Los resultados de estas
sesiones son documentados por los analistas.
Una forma más cooperativa puede involucrar al cliente directamente en la definición de los
requerimientos. Personal del cliente puede participar en la definición de los requerimientos hasta
el punto de que ellos también sean autores del documento.

Cualquiera que sea la técnica usada, el objetivo es definir los requerimientos mientras se consigue
un consenso y un nivel común de entendimiento. El cliente y el analista deben llegar al punto en el
cual tienen un entendimiento común de los requerimientos y puedan representarlos
consistentemente en forma de una SyRS, a satisfacción del cliente.
7.2 Construir requerimientos bien formados
El analista realiza esta subfase haciendo lo siguiente:
1. a) Se asegura de que cada requerimiento es una declaración breve y definitiva de una

necesidad.
2. b) Define las condiciones apropiadas para cada requerimiento (medidas cuantitativas y
cualitativas) y evite adjetivos tal como “resistente” o “aceptado por industria”
3. c) Evite los errores comunes de especificación (ver sección 6.4).
4. d) Se asegura de la legilibilidad de los requerimientos, lo cual involucra lo siguiente:
1. 1) Palabras/frases/conceptos simples
2. 2) Una estructura y relaciones uniformes
3. 3) Definición de palabras, si ́mbolos y notaciones únicas.
4. 4) El uso de un lenguaje y simbologi ́a gramaticalmente correctos.
5. e) Se asegura de que los requerimientos puedan ser probados.
El siguiente ejemplo es un requerimiento bien formado:
Capacidad: Trasladar personas entre L.A y N.Y.

Condición: Velocidad de circulación de 200 Km/hr
Restricción: Velocidad máxima de 300 Km/hr
Requerimiento bien formado: El sistema debe trasladar personas entre L.A y N.Y. a una
velocidad óptima de circulación de 200 Km/hr con un li ́mite máximo de velocidad de 300 Km/hr.
7.3 Organizar los requerimientos
En este subproceso, el analista da estructura al conjunto de los requerimientos relacionándolos

unos con otros de acuerdo a algún método comparativo definido. Algunas tareas de este
subproceso pueden ser automatizadas.
Esta actividad se caracteriza por lo siguiente:
Los atributos siguiente manera:
---
--
Busca patrones para poder agrupar conjuntos de requerimientos
Usa la experiencia y el juicio para usar técnicas apropiadas.
Usa la creatividad y la intuición para generar diferentes alternativas y para priorizar
los requerimientos de acuerdo a la información proporcionada por el cliente. Define las

propiedades de los requerimientos
Define los atributos de los requerimientos.
de los requerimientos pueden ser asignados a cada requerimiento bien formado de la
Identificador = 2.1.3.6 Prioridad = alta Criticismo = bajo Factibilidad = alta Riesgo = medio Fuente =
cliente
Tipo = desempeño
Existen varios esquemas para organizar las especificaciones en forma de un conjunto ordenado. El
esquema más común es organizar los requerimientos en una jerarqui ́a de capacidades (servicios)
donde las capacidades generales son descompuestas en requerimientos subordinados. Otro
esquema es mediante el uso de referencias cruzadas para mostrar las relaciones entre los
requerimientos de menor nivel. Sin importar el método que se use, la SyRS debe mostrar la
relación entre los requerimientos. Algunas relaciones entre los requerimientos incluyen las
siguientes dependencias jerárquicas:
1. a) Eventos
2. b) Datos
3. c) Objetos fi ́sicos o abstractos
4. d) Funciones
7.4 Presentar la SyRS
En este subproceso, el analista trabajará con el cliente para identificar la mejor manera de
comunicar los requerimientos a todos los individuos que necesiten entender, revisar, aceptar o
usar la SyRS. Una sola representación no siempre es conveniente porque:
1. a) El cliente y la comunidad técnica usualmente tienen diferentes culturas y lenguajes; asi ́,

los mismos requerimientos del sistema deberi ́an ser presentados de manera diferente a
los técnicos o a los clientes.
2. b) La recuperación de información especi ́fica es difi ́cil mediante algunas representaciones.
3. c) La presentación de interacciones puede ser difi ́cil de realizar en algunos métodos de
representación.
4. d) Relacionar información de un lugar con información en otro lugar puede ser difi ́cil en
algunas representaciones.
Por lo tanto, es importante que los analistas junto con el cliente identifiquen la mejor manera de
comunicar los requerimientos a todos los individuos involucrados en el proceso de desarrollo de la
SyRS. Para lograr lo anterior, deben usarse diferentes representaciones; estas representaciones no
deben ser mantenidas por separado, sino que deben ser derivadas y generadas de la SyRS. Por
ejemplo, se puede producir un resumen que contenga una descripción narrativa para el cliente.
Para el individuo responsable de aceptar los requerimientos por parte del cliente, se puede
generar un documento más detallado que incluya modelos formales. Para el equipo de diseñ o, un
conjunto completo de modelos formales pueden ser generados. Deben usarse herramientas
automatizadas para mantener la SyRS y producir sus diferentes representaciones.
7.5 Métodos de representación
Los métodos de representación pueden incluir uno o una combinación de los siguientes:
a) Textual
a. Papel
b. Electrónico b) Modelos
a. Fi ́sico
b. Simbólico c. Grafico
d. Prototipo
Anexo A
(informativo)
Plantilla para Especificación de Requerimientos de Sistemas
Esta gui ́a reconoce que existen una gran cantidad de técnicas y formas de comunicar los
requerimientos, incluyendo texto y modelos. El propósito de esta plantilla es ayudar a esclarecer el
contenido técnico de una SyRS. Vea IEEE Std 1220-1998 para los procesos de requerimientos y
desarrollo de SyRS. La representación y contenido puede ser expandido o comprimido para el
cliente o la comunidad técnica. Existen muchas representaciones posibles de una SyRS y la
siguiente es simplemente un ejemplo.
Tabla de contenido Lista de figuras Lista de tablas
1. Introducción
1.1 Propósito del sistema

1.2 Alcance del sistema
1.3 Definiciones, acrónimos y abreviaturas 1.4 Referencias
1.5 Panorama general
2 Descripción general del sistema 2.1 Contextodelsistema
2.2 Modos y estados del sistema

2.3 Principales capacidades del sistema 2.4 Principales condiciones del sistema 2.5 Principales restricciones
del sistema 2.6 Caracteri ́sticas de los usuarios
2.7 Suposiciones y dependencias
2.8 Escenarios de operación
3. Capacidades, condiciones y restricciones del sistema 3.1 Condiciones fi ́sicas
3.1.1 Construcción
3.1.2 Durabilidad
3.1.3 Adaptabilidad
3.1.4 Condiciones ambientales
3.2 Caracteri ́sticas de desempeñ o del sistema 3.3 Seguridad

3.4 Administración de la información
3.5 Operaciones del sistema
3.5.1 Factores humanos 3.5.2 Mantenibilidad 3.5.3 Confiabilidad
3.6 Poli ́ticas y regulaciones
3.7 Ciclo de vida del sistema 4. Interfaces del sistema

ESPECIFICACION DE REQUISITOS SEGUN EL ESTANDAR
DE IEEE 830
IEEE Std. 830-1998 22 de Octubre de 2008
Resumen
Este documento presenta, en castellano, el formato de Especifica- ci o ́ n de Requisitos Software

(ERS) segu n ́ la u ĺ tima versi ó n del est á ndar IEEE 830. Segu n ́ IEEE, un buen Documento de
Requisitos, pese a no ser obligatorio que siga estrictamente la organizaci o ́ n y el formato dados
en el est á ndar 830, s í deber á incluir, de una forma o de otra, toda la informaci o ́ n presentada en
dicho est á ndar. El est á ndar de IEEE 830 no est á libre de defectos ni de prejuicios, y por ello ha
sido jus- tamente criticado por mu ĺ tiples autores y desde mu ĺ tiples puntos de vista, lleg á ndose a
cuestionar incluso si es realmente un est á ndar en el sentido habitual que tiene el t é rmino en
otras ingenier í as. El presente documento no pretende pronunciarse ni a favor ni en contra de
unos u otros: tan s o ́ lo reproduce, con prop o ́ sitos fundamentalmente docentes, c o ́ mo se
organizar í a un Documento de Requisitos segu n ́ el est á ndar IEEE 830.
́INDICE 2 ́Indice
1. Introduccio ́n 3
1.1. Propo ́sito ............................. 3 1.2. A ́mbitodelSistema........................ 3 1.3. Definiciones, Acro ́nimos y
Abreviaturas . . . . . . . . . . . . . 3 1.4. Referencias ............................ 3 1.5.
Visio ́nGeneraldelDocumento.................. 4
2. Descripci ́on General 4
2.1. PerspectivadelProducto..................... 4 2.2. FuncionesdelProducto...................... 4 2.3.

Caracter ́isticasdelosUsuarios.................. 5 2.4. Restricciones ........................... 5 2.5.
SuposicionesyDependencias................... 5 2.6. RequisitosFuturos ........................ 6
3. Requisitos Espec ́ificos 6
3.1. InterfacesExternas ........................ 7 3.2. Funciones ............................. 7 3.3.

RequisitosdeRendimiento.................... 9 3.4. RestriccionesdeDisen ̃o...................... 9 3.5.
AtributosdelSistema....................... 9 3.6. OtrosRequisitos ......................... 9
4. Ap ́endices 9
1 INTRODUCCIO ́N 3 1. Introduccio n
́
En esta seccio ́n se proporcionara ́ una introducci ́on a todo el documento de Especificacio ́n de Requisitos
Software(ERS). Consta de varias subsecciones: propo ́sito, ambito del sistema, definiciones, referencias y
visio ́n general del documento.
1.1. Prop o
́ sito
En esta subsecci ́on se definira ́ el propo ́sito del documento ERS y se especificara ́ a qui ́en va dirigido el
documento.
́
1.2. A mbito del Sistema
En esta subseccio ́n:
1.3.
Se podra ́ dar un nombre al futuro sistema (p.ej. MiSistema)
Se explicar ́a lo que el sistema har ́a y lo que no har ́a.
Se describira ́n los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema.
Se referenciar ́an todos aquellos documentos de nivel superior (p.e. en In- genier ́ia de Sistemas, que
incluyen Hardware y Software, deber ́ia mantenerse la consistencia con el documento de especificacio ́n de
requisitos globales del sistema, si existe).
Definiciones, Acro ́nimos y Abreviaturas
En esta subsecci ́on se definir ́an todos los t ́erminos, acro ́nimos y abreviaturas utilizadas en la ERS.
1.4. Referencias
En esta subseccio ́n se mostrar ́a una lista completa de todos los documentos referenciados en la ERS.
2 DESCRIPCIO ́N GENERAL 4 1.5. Visi o

́ n General del Documento
Esta subseccio ́n describe brevemente los contenidos y la organizaci ́on del resto de la ERS.
2. Descripci o
́ n General
En esta secci ́on se describen todos aquellos factores que afectan al producto y a sus requisitos. No se
describen los requisitos, sino su contexto. Esto permitira ́ definir con detalle los requisitos en la seccio ́n 3,
haciendo que sean ma ́s fa ́ciles de entender.
Normalmente, esta seccio ́n consta de las siguientes subsecciones: Pers- pectiva del producto, funciones del
producto, caracter ́isticas de los usuarios, restricciones, factores que se asumen y futuros requisitos.
2.1. Perspectiva del Producto
Esta subsecci ́on debe relacionar el futuro sistema (producto software) con otros productos. Si el producto
es totalemente independiente de otros productos, tambi ́en debe especificarse aqu ́i. Si la ERS define un
producto que es parte de un sistema mayor, esta subsecci ́on relacionar ́a los requisitos del sistema mayor
con la funcionalidad del producto descrito en la ERS, y se identificara ́n las interfaces entre el producto
mayor y el producto aqu ́i descrito. Se recomienda utilizar diagramas de bloques.
2.2. Funciones del Producto
En esta subseccio ́n de la ERS se mostrar ́a un resumen, a grandes rasgos, de las funciones del futuro
sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subseccio ́n mostrar ́a que el
sistema soportara ́ el mantenimiento de cuentas, mostrara ́ el estado de las cuentas y facilitar ́a la
facturacio ́n, sin mencionar el enorme detalle que cada una de estas funciones requiere.
Las funciones deber ́an mostrarse de forma organizada, y pueden utilizarse gr ́aficos, siempre y cuando
dichos gra ́ficos reflejen las relaciones entre funciones y no el disen ̃o del sistema.
2 DESCRIPCIO ́N GENERAL 5 2.3. Caracter í sticasdelosUsuarios
Esta subseccio ́n describira ́ las caracter ́isticas generales de los usuarios del producto, incluyendo nivel
educacional, experiencia y experiencia t ́ecnica.
2.4. Restricciones
Esta subseccio ́n describir ́a aquellas limitaciones que se imponen sobre los desarrolladores del producto
2.5.
Pol í ticas de la empresa

Limitaciones del hardware
Interfaces con otras aplicaciones Operaciones paralelas
Funciones de auditor ́ia
Funciones de control
Lenguaje(s) de programacion Protocolos de comunicaci ́on
Requisitos de habilidad
Criticalidad de la aplicacio ́n Consideraciones acerca de la seguridad
Suposiciones y Dependencias
Esta subsecci ́on de la ERS describir ́a aquellos factores que, si cambian, pueden afectar a los requisitos. Por
ejemplo, los requisitos pueden presuponer una cierta organizacio ́n de ciertas unidades de la empresa, o
pueden presuponer que el sistema correr ́a sobre cierto sistema operativo. Si cambian dichos detalles en la
organizacio ́n de la empresa, o si cambian ciertos detalles t ́ecnicos, como el sistema operativo, puede ser
necesario revisar y cambiar los requisitos.
3 REQUISITOS ESPEC ́IFICOS 6 2.6. Requisitos Futuros
Esta subsecci ́on esbozara ́ futuras mejoras al sistema, que podra ́n anali- zarse e implementarse en un
futuro.
3. Requisitos Espec í ficos

Esta seccio ́n contiene los requisitos a un nivel de detalle suficiente como para permitir a los disen ̃adores
disen ̃ar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar
las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aqu ́i es- pecificado
describir ́a comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y
otros sistemas. Esta es la seccio ́n ma ́s larga e importante de la ERS. Debera ́n aplicarse los siguientes
principios:
El documento deber ́ia ser perfectamente legible por personas de muy distintas formaciones e intereses.
Deber ́an referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos.
Todo requisito deber ́a ser un ́ivocamente identificable mediante algu ́n co ́digo o sistema de numeraci ́on
adecuado.
Lo ideal, aunque en la pra ́ctica no siempre realizable, es que los requisitos posean las siguientes
caracter ́isticas:
 Correccion: La ERS es correcta si y s ́olo si todo requisito que figura aqu ́i (y que ser ́a implementado
en el sistema) refleja alguna necesidad real. La correccio ́n de la ERS implica que el sistema
implementado sera ́ el sistema deseado.
 No ambiguos: Cada requisito tiene una sola interpretacio ́n. Para eliminar la ambigu ̈edad inherente
a los requisitos expresados en lenguaje natural, se deber ́an utilizar gra ́ficos o notaciones forma-
les. En el caso de utilizar t ́erminos que, habitualmente, poseen ma ́s de una interpretaci ́on, se
definir ́an con precisi ́on en el glosario.
 Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las
posibles respuestas del sistema a los datos de entrada, tanto v ́alidos como no va ́lidos.
3 REQUISITOS ESPEC ́IFICOS 7
 Consistentes: Los requisitos no pueden ser contradictorios. Un con-
junto de requisitos contradictorio no es implementable.
 Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden
clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad (cambios
que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos
en implementar requisitos no esenciales.
 Verificables: La ERS es verificable si y so ́lo si todos sus requisitos son verificables. Un requisito es
verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple
con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como a veces,
bien, adecuado, etc. introducen ambigu ̈edad en los requisitos. Requisitos como “en caso de acci-
dente la nube t ́oxica no se extendera ́ ma ́s all ́a de 25Km” no es verificable por el alto costo que
conlleva.
 Modificables: La ERS es modificable si y s ́olo si se encuentra estructurada de forma que los
cambios a los requisitos pueden realizarse de forma fa ́cil, completa y consistente. La utilizacio ́n
de herramientas autom ́aticas de gesti ́on de requisitos (por ejemplo RequisitePro o Doors) facilitan
enormemente esta tarea.
 Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de
cada requisito a los componentes del disen ̃o y de la implementacio ́n. La trazabilidad hacia atra ́s
indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un
requisito R indica qu ́e componentes del sistema son los que realizan el requisito R.
3.1. Interfaces Externas
Se describir ́an los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y
software) e interfaces de comunicaciones.
3.2. Funciones
Esta subsecci ́on (quiza ́ la ma ́s larga del documento) debera ́ especificar todas aquellas acciones (funciones)
que debera ́ llevar a cabo el software. Nor-
3 REQUISITOS ESPEC ́IFICOS 8
malmente (aunque no siempre), son aquellas acciones expresables como “el sistema deber ́a ...”. Si se
considera necesario, podr ́an utilizarse notaciones gra ́ficas y tablas, pero siempre supeditadas al lenguaje
natural, y no al rev ́es.
Es importante tener en cuenta que, en 1983, el Est ́andar de IEEE 830 establec ́ia que las funciones deber ́ian
expresarse como una jerarqu ́ia funcional (en paralelo con los DFDs propuestos por el an ́alisis estructurado).
Pero el Esta ́ndar de IEEE 830, en sus u ́ltimas versiones, ya permite organizar esta subseccio ́n de mu ́ltiples
formas, y sugiere, entre otras, las siguientes:
Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Pa- ra cada clase de usuario que exista
en la organizaci ́on, se especificar ́an los requisitos funcionales que le afecten o tengan mayor relacio ́n con
sus tareas.
Por objetos: Los objetos son entidades del mundo real que sera ́n refle- jadas en el sistema. Para cada
objeto, se detallar ́an sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta
organizacio ́n de la ERS no quiere decir que el disen ̃o del sistema siga el paradigma de Orientacio ́n a
Objetos.
Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una
determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo que se persiga con el
sistema, se detallar ́an las funciones que permitan llevarlo a cabo.
Por est ́imulos: Se especificara ́n los posibles est ́imulos que recibe el sistema y las funciones relacionadas
con dicho est ́imulo.
Por jerarqu ́ia funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del
sistema se especificar ́a como una jerarqu ́ia de funciones que comparten entradas, salidas o datos
internos. Se detallara ́n las funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no
implica que el disen ̃o del sistema deba realizarse segu ́n el paradigma de Disen ̃o Estructurado.
Para organizar esta subseccio ́n de la ERS se elegir ́a alguna de las anteriores alternativas, o incluso alguna
otra que se considere ma ́s conveniente. Deber ́a, eso s ́i, justificarse el porqu ́e de tal eleccio ́n.
4 APE ́NDICES 9 3.3. Requisitos de Rendimiento
Se detallar ́an los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por
ejemplo, el nu ́mero de terminales, el nu ́mero esperado de usuarios simultaneamente conectados, nu ́mero
de transacciones por segundo que deber ́a soportar el sistema, etc.
Tambi ́en, si es necesario, se especificara ́n lo requisitos de datos, es decir, aquellos requisitos que afecten a
la informacio ́n que se guardara ́ en la base de datos. Por ejemplo, la frecuencia de uso, las capacidades de
acceso y la cantidad de registros que se espera almacenar (decenas, cientos, miles o millones).
3.4. Restricciones de Disen o

̃
Todo aquello que restrinja las decisiones relativas al disen ̃o de la aplicacio ́n: Restricciones de otros
esta ́ndares, limitaciones del hardware, etc.
3.5. Atributos del Sistema

Se detallar ́an los atributos de calidad (las “ilities”) del sistema: Fiabilidad, mantenibilidad, portabilidad, y,
muy importante, la seguridad. Debera ́ especificarse qu ́e tipos de usuario est ́an autorizados, o no, a
realizar ciertas tareas, y c ́omo se implementara ́n los mecanismos de seguridad (por ejemplo, por medio
de un login y una password).
3.6. Otros Requisitos
Cualquier otro requisito que no encaje en otra seccio ́n.
4. Apendices
Pueden contener todo tipo de informacio ́n relevante para la ERS pero que, propiamente, no forme parte de
la ERS. Por ejemplo:
1. Formatos de entrada/salida de datos, por pantalla o en listados. 2. Resultados de an ́alisis de costes.

3. Restricciones acerca del lenguaje de programaci ́on.
DOCUMENTO DE VISION
Un documento de visión define el alcance y el objetivo de alto nivel de un programa,
producto o proyecto. Una declaración clara del problema, una propuesta de solución y las
características de alto nivel de un producto ayudan a establecer expectativas y reducir
riesgos. Este tema ofrece un esquema del contenido potencial de un documento de visión.
Este tema describe el contenido típico del documento. Puede copiar este esquema,
pegarlo en un nuevo documento y utilizarlo como base para el documento de visión.
Utilice las partes del esquema que sean relevantes para el proyecto.
Cuando un equipo utiliza la capacidad Gestión de requisitos (RM) en Rational solution for
Collaborative Lifecycle Management(CLM), el documento de visión se puede expresar en
uno o varios documentos de texto enriquecido o módulos. Puede incluir requisitos y
artefactos relacionados en documentos de texto enriquecido o utilizar la estructura
jerárquica numerada de un módulo para organizar el contenido. Los miembros del equipo
pueden definir atributos, como la prioridad y el estado, en cada artefacto y crear enlaces
de rastreo entre documentos relacionados, módulos y artefactos individuales.
Para revisar los pasos para crear y enlazar documentos y módulos, consulte:
 Creación de módulos
ESQUEMA DE DOCUMENTO DE VISIÓN
1: INTRODUCCIÓN
Esta introducción ofrece una visión general de todo el documento de visión. Incluye el
objetivo, el alcance, las definiciones, los acrónimos, las abreviaturas, las referencias y una
visión general de todo el documento.
1.1 Objetivo: Presentar el objetivo de este documento de visión.
1.2 Alcance: Describir brevemente el alcance de este documento de visión, incluidos los
programas, proyectos, aplicaciones y procesos empresariales asociados con el documento.
Incluya cualquier otro elemento que afecte o influya en el documento.
1.3 Definiciones, acrónimos y abreviaturas: Defina todos los términos, acrónimos y
abreviaturas necesarias para interpretar la visión correctamente. Esta información se
puede proporcionar por referencia al glosario del proyecto, que se puede desarrollar en
línea en el repositorio RM.
1.4 Referencias: Enumere todos los documentos al que hace referencia el documento de
visión. Identifique cada documento por el título, número de informe (si procede), fecha y
organización de publicación. Especifique los orígenes desde los cuales los lectores pueden
obtener las referencias; los orígenes están idealmente disponibles en RM o en otros
repositorios en línea. Esta información puede ser proporcionada en relación con un
apéndice u otro documento.
1.5 Visión general: Describa el contenido del documento de visión y explique cómo se
organiza el documento.
2: POSICIONAMIENTO
2.1 Oportunidad de negocio: Describa brevemente la oportunidad de negocio que aborda
este proyecto.
2.2 Declaración de problema: Resuma el problema que este proyecto soluciona. Utilice las
declaraciones siguientes como modelo, proporcionando detalles para sustituir los
elementos entre paréntesis:
El problema de (describir el problema) afecta a (las partes interesadas a las que afecta el
problema). El impacto del problema es (impacto del problema). Una solución eficaz sería
incluir (listar algunos beneficios clave de una solución eficaz).
2.3 Declaración de posición de producto: Proporcione una declaración general que
resuma al nivel más alto la única posición que el producto trata de ocupar en el mercado.
Utilice las declaraciones siguientes como modelo, proporcionando detalles para sustituir
los elementos entre paréntesis:
Para el (cliente destino), que (declaración de la necesidad u oportunidad). El (nombre del
producto) es un (categoría del producto) que (declaración del beneficio clave, es decir, la
razón que persuade a realizar la compra). A diferencia de (alternativa principal de la
competencia), nuestro producto (declaración de la diferenciación principal).
Una declaración de la posición del producto comunica la intención de aplicación y la
importancia del proyecto a todas las partes interesadas en cuestión.
3: DESCRIPCIONES DE LA PARTE INTERESADA Y DEL USUARIO
Para proporcionar productos y servicios que satisfagan las necesidades de partes
interesadas y usuarios, debe identificar e implicar a todos las partes interesadas como
parte del proceso de definición de requisitos. También debe identificar a los usuarios del
sistema y asegurarse de que la comunidad de las partes interesadas los representa
adecuadamente.
Esta sección ofrece un perfil de las partes interesadas y los usuarios que están implicados
en el proyecto. Esta sección también identifica los problemas clave que las partes
interesadas y los usuarios consideran que la solución propuesta debe abordar. Esta
sección no describe solicitudes ni requisitos específicos; un artefacto de solicitudes de
parte interesada independiente se ocupa de estas cuestiones. La descripción del problema
clave ofrece los fundamentos y la justificación de los requisitos.
3.1 Datos demográficos del mercado: Resuma los datos demográficos clave del mercado que motivan las
decisiones que toma sobre el producto. Describa y posicione los segmentos del mercado objetivo. Calcule el
tamaño y el crecimiento del mercado utilizando el número de posibles usuarios. Como alternativa, calcule el
importe de dinero que los clientes gastan intentando cumplir con las necesidades que el producto o la mejora
satisfarán. Revise las tendencias y las tecnologías principales del sector. Responda a estas preguntas
estratégicas:
 ¿Cuál es la reputación de su organización en estos mercados?

 ¿Cómo le gustaría que fuese esta reputación?
 ¿Cómo apoya este producto o servicio sus objetivos?
3.2 Resumen de la parte interesada: Enumere a todas las partes interesadas identificadas. Para cada tipo de
parte interesada, proporcione la información siguiente:
 Nombre: nombre del tipo de parte interesada.

 Representaciones: describa brevemente los individuos, equipos u organizaciones a las
cuales representa este tipo de parte interesada.
 Rol: describa brevemente el rol que este tipo de parte interesada juega en el esfuerzo de
desarrollo.
3.3 Resumen de usuario: enumere todos los tipos de usuario identificados. Para cada tipo de usuario,
proporcione la información siguiente:
 Nombre: nombre del tipo de usuario

 Descripción: describa brevemente la relación de este tipo de usuario con el sistema en
desarrollo.
 Parte interesada: enumere el tipo de parte interesada que representa a este tipo de
usuario.
3.4 Entorno de usuario: detalle el entorno de trabajo del usuario de destino. Aquí se presentan algunas
sugerencias:
 ¿Cuántas personas están implicadas en finalizar la tarea? ¿Está cambiando esta situación?
 ¿Cuánto dura un ciclo de tarea? ¿Cuánto tiempo pasan los usuarios en cada actividad?
¿Está cambiando esta situación?
 ¿Qué limitaciones de entorno únicas afectan al proyecto? Por ejemplo, ¿necesitan los
usuarios dispositivos móviles, trabajan al aire libre o durante vuelos?
 ¿Qué plataformas de sistema se utilizan a día de hoy? ¿Se tiene previsto utilizar otras
plataformas nuevas?
 ¿Qué otras aplicaciones se están utilizando? ¿Necesita su aplicación integrarse con ellas?
En esta sección, puede incluir extractos del modelo empresarial para esquematizar la tarea y los trabajadores
implicados.
3.5 Perfiles de parte interesada: describa cada parte interesada en el proyecto

completando la tabla siguiente para cada parte interesada. Recuerde: los tipos de parte
interesada pueden ser usuarios, departamentos de estrategia, departamentos jurídicos o
de cumplimiento, desarrolladores técnicos y equipos de operaciones, entre otro. Un perfil
exhaustivo incluye los temas siguientes para cada tipo de parte interesada:
 Representante: especifique quién representa a la parte interesada en el proyecto (esta
información es opcional si se ha documentado en otro lugar.) Especifique los nombres de
los representantes.
 Descripción: describa brevemente el tipo de parte interesada.
 Tipo: califique la experiencia de la parte interesada, como "gurú", "experto empresarial" o
"usuario ocasional". Esta designación puede sugerir formación técnica y un grado de
sofisticación.
 Responsabilidades: enumere las responsabilidades clave de la parte interesada en el
sistema en desarrollo; enumere sus intereses como parte interesada.
 Criterios de éxito: especifique qué significa éxito para la parte interesada. ¿Cómo se
recompensa a la parte interesada?
 Implicación: describa cómo se implica la parte interesada en el proyecto. Cuando sea
posible, especifique la implicación con los roles de proceso; por ejemplo, una parte
interesada puede ser un revisor de requisitos.
 Entregables: identifique los entregables adicionales que requiere la parte interesada.
Estos elementos pueden ser entregables de proyecto o salida del sistema en desarrollo.
 Comentarios o problemas: especifique los problemas que interfieren con el éxito y
cualquier otra información relevante.
3.6 Perfiles de usuario: describa cada usuario del sistema completando la tabla siguiente para cada tipo de
usuario. Recuerde que los tipos de usuarios pueden ser expertos y principiantes; por ejemplo, un experto
puede necesitar una herramienta flexible y sofisticada con soporte para varias plataformas, mientras que un
principiante puede necesitar una herramienta que sea fácil de utilizar. Un perfil exhaustivo cubre estos temas
para cada tipo de usuario:
 Representante: especifique quién representa al usuario en el proyecto. (Esta información

es opcional si se ha documentado en otro lugar.) Este representante con frecuencia hace
referencia a la parte interesada que representa un conjunto de usuarios; por ejemplo,
Parte interesada: Parte interesada1.
 Descripción: describa brevemente el tipo de usuario.
 Tipo: califique la experiencia del usuario, como "gurú" o "usuario ocasional." Esta
designación puede sugerir formación técnica y un grado de sofisticación.
 Responsabilidades: enumere las responsabilidades de usuario clave con respecto al
sistema; por ejemplo, indique quien recoge los datos del cliente, produce informes y
coordina el trabajo, etc.
 Criterios de éxito: especifique qué significa éxito para el usuario. ¿Cómo se recompensa al
usuario?
 Implicación: describa cómo se implica el usuario en el proyecto. Cuando sea posible,
especifique la implicación con los roles de proceso; por ejemplo, una parte interesada
puede ser un revisor de requisitos.
 Entregables: identifique los entregables que el usuario crea y cuáles son los destinatarios
de éstos.
 Comentarios o problemas: especifique los problemas que interfieren con el éxito y
cualquier otra información relevante. Describe las tendencias que dificultan o facilitan el
trabajo del usuario.
3.7 Necesidades clave de la parte interesada o del usuario: enumere los problemas clave con las soluciones
existentes según la percepción de la parte interesada. Aclare estos temas para cada problema:
 ¿Qué causa este problema?

 ¿Cómo se soluciona el problema ahora?
 ¿Qué soluciones desea utilizar la parte interesada?
Debe comprender la importancia relativa que la parte interesada asigna a la solución de cada problema. Las
técnicas de clasificación y votación acumulativa ayudan a indicar los problemas que deben resolverse en
comparación con las cuestiones que les gustaría abordar a las partes interesadas. Utilice esta tabla para
capturar las necesidades de la parte interesada.
Necesidad Prioridad Problemas Solución actual Solución propuesta
Tabla 1. Necesidades de la parte interesada
3.8 Alternativas y competencia: identifique las alternativas que la parte interesada

percibe como disponibles. Estas alternativas pueden incluir la compra de un producto de
la competencia, la creación de una solución local o el mantenimiento de una situación
invariable. Enumere todas las opciones competitivas conocidas y disponibles. Incluya los
puntos fuertes y débiles principales de cada competidor según la percepción de la parte
interesada.
4: VISIÓN GENERAL DEL PRODUCTO
Esta sección ofrece una vista de alto nivel de las capacidades del producto, interfaces de otras aplicaciones y
configuraciones de sistema. Esta sección suele constar de tres subsecciones:
 Perspectiva del producto

 Funciones del producto
 Suposiciones y dependencias
4.1 Perspectiva del producto: coloque el producto en perspectiva en relación con otros
productos relacionados y el entorno del usuario. Si el producto es independiente y
totalmente autocontenido, indíquelo aquí. Si el producto es un componente de un sistema
más amplio, explique cómo estos sistemas interactúan e identifique las relaciones
relevantes entre los sistemas. Un modo de visualizar los componentes principales de los
sistemas, interconexiones y relaciones externas más amplios consiste en utilizar un
proceso de negocio o un diagrama de caso de uso.
4.2 Resumen de capacidades: resuma los principales beneficios y características que proporcionará el
producto. Por ejemplo, un sistema de soporte de cliente puede utilizar esta parte para abordar la
documentación del problema, el direccionamiento y los informes de estado sin elaborar en detalle lo que
estas funciones requieren. Organice las funciones de modo que la lista sea comprensible para el cliente o a
cualquier persona que lea el documento por primera vez. Puede bastar con una simple tabla que enumere los
beneficios clave y sus características de soporte, tal como en el ejemplo siguiente.
Beneficio de cliente Características de soporte
El nuevo personal de soporte puede Una base de conocimiento ayuda al personal de soporte a
aprender rápidamente a utilizar el identificar rápidamente los arreglos y soluciones conocidos.
producto.
La satisfacción del cliente mejora Los problemas se identifican, clasifican y rastrean de forma
porque todo queda contemplado. exclusiva en todo el proceso de resolución. Cualquier problema
relacionado con incompatibilidades relacionadas con el paso del
tiempo, se notifica de forma automática.
Beneficio de cliente Características de soporte
La gestión puede identificar áreas de Los informes de tendencias y distribución permiten llevar a cabo
problemas e identificar carga de una revisión de alto nivel del estado del problema.
trabajo de personal.
Equipos de soporte distribuidos En un servidor de réplica, la información de base de datos actual

pueden trabajar conjuntamente para puede compartirse en toda la empresa.
resolver problemas.
Los clientes pueden ayudarse a sí Se puede poner a disposición una base de conocimientos por
mismos, reduciendo los costes de Internet. La base de conocimiento incluye capacidades de búsqueda
soporte y mejorando el tiempo de de hipertexto y un motor de consultas gráficas.
respuesta.
Tabla 2. Ejemplo de beneficios y características
4.3 Suposiciones y dependencias: enumere todos los factores que afectan a las
características que incluye el documento de visión. Enumere las suposiciones que, de
modificarse, alterarán el documento de visión. Por ejemplo, una suposición puede afirmar
que un sistema operativo específico se encontrará disponible para el hardware designado
del producto de software. Si el sistema operativo no se encuentra disponible, el
documento de visión deberá modificarse.
4.4 Coste y precios: registre las repercusiones y limitaciones relativas a los costes y
precios. Por ejemplo, los costes de distribución (el número de CD y la masterización de CD)
u otras limitaciones relacionadas con la venta de bienes (manuales y empaquetado)
pueden ser relevantes o irrelevantes para el éxito del proyecto, en función de la
naturaleza de la aplicación.
4.5 Concesión de licencia e instalación: los problemas relacionados con la concesión de
licencia y la instalación también pueden afectar directamente al esfuerzo de desarrollo.
Por ejemplo, la necesidad de soportar la serialización, la seguridad con contraseña o la
concesión de licencia de red crearán requisitos de sistema adicionales que deberán
tenerse en cuenta en el esfuerzo de desarrollo. Los requisitos de instalación también
pueden afectar a la codificación o crear la necesidad de software de instalación
independiente.
5: CARACTERÍSTICAS DEL PRODUCTO
Enumere y describa brevemente las características del producto. Las características son las
capacidades de nivel superior del sistema que son necesarias para ofrecer beneficios para
los usuarios. Cada característica es un servicio solicitado que normalmente requiere una
serie de entradas para lograr un resultado satisfactorio. Por ejemplo, una característica
del sistema de rastreo de problemas puede ser la capacidad de ofrecer informes de
tendencia. A medida que el modelo caso de uso toma forma, actualice la descripción que
hará referencia a los casos de uso.
Puesto que el documento de visión es revisado por una gran variedad de personal
implicado, mantenga el nivel de detalle lo suficientemente general para que todo el
mundo lo comprenda. Con todo, ofrezca detalles suficientes para que el equipo disponga
de la información que necesita para crear un modelo de caso de uso u otros documentos
de diseño.
Para gestionar la complejidad de la aplicación, para un sistema nuevo o un cambio
incremental, enumere las capacidades a un nivel suficientemente alto que permita incluir
entre 25 y 99 características aproximadamente. Estas características ofrecen la base para
la definición del producto, la gestión del alcance y la gestión del proyecto. Cada
característica se expandirá en mayor detalle en el modelo de caso de uso.
En toda esta sección, haga que cada característica sea relevante para los usuarios, operadores y otros sistemas
externos. Incluya una descripción de las funciones y cuestiones de usabilidad que deben abordarse. Se aplican
las directrices siguientes:
 Evite el diseño. Mantenga las descripciones de las características a un nivel general.

Céntrese en las capacidades necesarias y en los motivos por los que deben o no aplicarse.
 Designe todas las características como requisitos de un tipo de características específico
para cada referencia y rastreo.
5.1 Característica 1.
5.2 Característica 2.
6: RESTRICCIONES
Tenga en cuenta cualquier restricciones de diseño, restricción externa, como requisitos operativos o
reglamentarios u otras dependencias.
7: RANGOS DE CALIDAD
Define los rangos de calidad relativos al rendimiento, la solidez, la tolerancia a fallos, la usabilidad y
características similares que la característica establecida no describe.
8: PRECEDENCIA Y PRIORIDAD
Defina la prioridad de las diferentes características de sistema.
9: OTROS REQUISITOS DEL PRODUCTO

En un nivel elevado, enumere los estándares aplicables, los requisitos de hardware o
plataforma, los requisitos de rendimiento y los requisitos de entorno.
9.1 Estándares aplicables: enumere todos los estándares con los que debe cumplir el producto. La lista puede
incluir los estándares siguientes:
 Estándares legales y reguladores (FDA, UCC)

 Estándares de comunicación (TCP/IP, ISDN)
 Estándares de cumplimiento de plataforma (Windows, UNIX, etc.)
 Estándares de calidad y seguridad (UL, ISO, CMM)
9.2 Requisitos de sistema: defina los requisitos de sistema de la aplicación. Éstos pueden
incluir las plataformas de red y sistemas operativos de host, configuraciones, memoria,
dispositivos periféricos y el software correspondiente.
9.3 Requisitos de rendimiento: detalle los requisitos de rendimiento. Los problemas de
rendimiento pueden incluir elementos como factores de carga de usuario, ancho de banda
o capacidad de comunicación, rendimiento, precisión, fiabilidad o tiempos de respuesta
en varias condiciones de carga.
9.4 Requisitos de entorno: detalle los requisitos de entorno según convenga. En el caso de
los sistemas basados en hardware, las cuestiones relacionadas con el entorno pueden
incluir la temperatura, el choque, la humedad y la radiación. En el caso de aplicaciones de
software, los factores de entorno pueden incluir las condiciones de uso, el entorno del
usuario, la disponibilidad de los recursos, los problemas de mantenimiento, el manejo de
errores y la recuperación.
10: REQUISITOS DE DOCUMENTACIÓN
Esta sección describe la documentación que debe desarrollarse para dar soporte al despliegue exitoso de la
aplicación.
10.1 Notas del release y archivo Léame: las notas del release o el archivo Léame abreviado pueden incluir una
sección de novedades, una discusión de cuestiones de compatibilidad con releases anteriores y alertas sobre
instalación y actualización. El documento también puede contener arreglos o enlaces a éstos en el release y
cualquier problema o solución conocidos.
10.2 Ayuda en línea: muchas aplicaciones ofrecen un sistema de ayuda en línea para asistir al usuario. La
naturaleza de estos sistemas es única en el desarrollo de aplicaciones ya que combinan aspectos de
programación (información que se puede buscar y navegación parecida a la web) con aspectos de escritura
técnica (organización y presentación). Muchos equipos encuentran que el desarrollo de un sistema de ayuda
en línea es un proyecto dentro de otro que se beneficia la gestión y planificación del alcance desde el inicio
del proyecto.
10.3 Guías de instalación: un documento que incluye instrucciones relativas a la instalación, la configuración
y la actualización que forma parte de la oferta de la solución completa.
10.4 Etiquetado y empaquetado: un aspecto coherente empieza por el empaquetado del producto y se aplica
a los menús de instalación, las pantallas de carga, sistemas de ayuda, cuadros de diálogo GUI, etc. Esta sección
define las necesidades y los tipos de etiquetado que deben incorporarse en el código. Los ejemplos incluyen
avisos de copyright y patentes, logotipos corporativos, iconos estandarizados y otros elementos gráficos.
11: APÉNDICE 1 - ATRIBUTOS DE CARACTERÍSTICA

Proporcione atributos de característica que puedan ser utilizados para evaluar, rastrear, priorizar y gestionar
los elementos del producto que se proponen para la aplicación. Realice un esquema de todos los tipos de
requisito y atributos en un plan de gestión de requisitos independiente. Con todo, es recomendable que
enumere y describa brevemente los atributos de las características que se han elegido. Las subsecciones
siguientes representan un conjunto de los atributos de característica sugeridos.
11.1 Estado: los equipos establecen el estado de la característica después de la negociación y la revisión
llevadas a cabo por el equipo de gestión del proyecto. El estado realiza un seguimiento del progreso en toda
la vida del proyecto. La tabla siguiente ofrece un ejemplo de valores típicos de estado-atributo.
Estado Descripción
Propuesta Describe las características que son objeto de discusión pero que no han sido revisadas ni
aceptadas por un "canal oficial". El canal oficial puede ser un equipo de trabajo que conste de
representantes del equipo de proyecto, la gestión de productos y la comunidad de usuarios o
clientes.
Aprobada Las capacidades que se consideran útiles y factibles y que han sido aprobadas para la
aplicación por parte del canal oficial.
Incorporada Las características que han sido incorporadas en la línea base del producto.
Tabla 3. Ejemplos de valor de estado
11.2 Beneficios: el grupo de marketing, el gestor de productos o el analista de empresa establece los
beneficios de las características. Todos los requisitos no se crean igual. Si se clasifican los requisitos por su
beneficio relativo al usuario se abre un diálogo con los clientes, los analistas y los miembros del equipo de
desarrollo. Utilice los beneficios a la hora de gestionar el alcance del proyecto y determinar la prioridad de
desarrollo. La tabla siguiente ofrece un ejemplo de valores de atributo de beneficio o prioridad típicos.
Prioridad Descripción
Crítica Características esenciales. La imposibilidad de aplicar una característica crítica significa que el
sistema no satisfará las necesidades del usuario. Todas las características críticas deben ser
aplicadas en el release o ello afectará a la planificación.
Importante Características importantes para la eficacia y la eficiencia del sistema en la mayoría de

aplicaciones. Las funciones no pueden proporcionarse fácilmente de algún otro modo. La
omisión de una característica importante puede afectar a la satisfacción del cliente o usuario,
o incluso a los ingresos. Con todo, el release no se retrasará porque no se haya incluido una
característica importante.
Útil Las características que son útiles en aplicaciones menos típicas se utilizan con menos
frecuencia o pueden satisfacerse con soluciones razonablemente eficaces. No se puede
esperar ninguna repercusión significativa en la satisfacción del cliente o en los ingresos si dicho
elemento no se incluye en un release.
Tabla 4. Ejemplos de prioridad de beneficio
11.3 Esfuerzo: el equipo de desarrollo estima el esfuerzo necesario para implementar las características.
Algunas características requieren más tiempo y recursos que otras. La estimación del tiempo, el código
necesario o las funciones ayuda a determinar la complejidad y a establecer expectativas de lo que puede
lograrse en un determinado periodo de tiempo. Utilice la estimación para gestionar el alcance y determinar
la prioridad de desarrollo.
11.4 Riesgo: el equipo de desarrollo establece los niveles de riesgos, según la probabilidad de que el proyecto
experimente eventos no deseables, como sobrecostes, retrasos en la planificación o incluso cancelaciones. La
mayoría de gestores de proyectos opinan que categorizar los riesgos como altos, medios y bajos no es
suficiente, aunque es posible especificar graduaciones más sutiles. Con frecuencia, el riesgo puede evaluarse
indirectamente midiendo la incertidumbre (rango) de la estimación de la planificación del equipo del
proyecto.
11.5 Estabilidad: el analista y el equipo de desarrollo establecen la estabilidad de la característica según la

probabilidad de que la característica cambio o la comprensión, por parte del equipo, de que la característica
vaya a cambiar. La estabilidad se utiliza para ayudar a establecer prioridades de desarrollo y determinar los
elementos para los cuales la explicitación resulta la siguiente acción adecuada a realizar.
11.6 Release destino: los equipos registran la primera versión del producto que incluirá la característica.
Puede utilizar este campo para asignar características de un documento de visión en un release de línea base
particular. Al combinarse con el campo de estado, el equipo puede proponer, registrar y debatir varias
características del release sin comprometer su desarrollo. Sólo las características cuyo estado se establezca
en "incorporada" y cuyo release destino se haya definido se aplicarán. Con la gestión de alcance, se puede
incrementar el número de la versión del release destino y el elemento permanece en el documento de visión
pero se planifica para un release posterior.
11.7 Asignado a: en muchos proyectos, las características se asignan a equipos de características que son
responsables de explicitaciones en el futuro, la redacción de requisitos de software y la aplicación. El proceso
ayuda a todo el equipo del proyecto a comprender mejor las responsabilidades.
11.8 Razón: los equipos utilizan este campo de texto para realizar un seguimiento del origen de la
característica solicitada. Los requisitos existen por razones específicas. Este campo registra una explicación o
una referencia a una explicación. Por ejemplo, la referencia puede señalar a una página y un número de línea
de una especificación de requisito de producto o señalar a un marcador de minuto en el vídeo de entrevista
del cliente.

Documentos de Requisitos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Documentos de Requisitos

Cargado por

Copyright:

Formatos disponibles

IEEE Std 1233, Edición 1998 (incluye IEEE Std 1233–1996 e IEEE Std 1233a-1998)

GUI ́A PARA EL DESARROLLO DE ESPECIFICACIONES DE

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

Un miembro de la comunidad técnica (ingenieros en sistemas o analistas de negocios, que

3.3 Li ́nea base

3.6 Requerimientos derivados

Es un requerimiento derivado o inferido del conjunto de los requerimientos en una configuración y

Un componente de un sistema; puede incluir equipo, un programa de computadora o un humano.

3.8 Usuario final

La persona o personas quienes al final usarán el sistema para el propósito deseado.

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

Una representación de un proceso, dispositivo o concepto del mundo real.

3.13 Requerimiento sin estructura

1. a) Una condición o capacidad requerida por un usuario para resolver un problema o

Un grupo interdependiente de personas, objetos y procedimientos constituido para alcanzar

3.17 Especificación de los requerimientos del sistema (SyRS)

3.18 Capacidad de ser sometido a pruebas

El proceso de evaluación de un sistema o componente para determinar si el sistema de una fase

3.22 Requerimiento bien formado

4. Especificación de Requerimientos del Sistema

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

El conjunto de requerimientos deberi ́a tener las siguientes propiedades:

otros requerimientos ni a las capacidades de otros requerimientos).

requerimientos individuales para mostrar cómo los requerimientos están relacionados

formar el sistema completo.

aquellos requerimientos necesarios para la definición del sistema.

nivel de detalle, estilo de la declaración de los requerimientos y en la presentación del

7. g) Modificable. La SyRS deberi ́a ser modificable. Requerimientos claros y sin

traslapamientos contribuyen a lograrlo.

4.3.1 Organizando los requerimientos

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

Mientras se organizan las declaraciones no estructuradas del usuario en un conjunto estructurado

1. a) Identificar requerimientos derivados de otros requerimientos.

7. g) Identificar requerimientos que completarán la SyRS.

4.3.2 Comunición con dos audiencias

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

4.3.2.2 Comunidad Técnica

4.4 Uso recomendado

c) Durante la fase de implementación, los procedimientos de prueba serán definidos a partir de la

d) Durante el proceso de validación, los procedimientos de validación basados en la SyRS serán

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

h) Incrementa la protección en contra de los malentendidos entre el cliente y la comunidad

4.6 Dinamismo de los requerimientos del sistema

Los requerimientos son raramente estáticos. Aunque es deseable congelar un conjunto de

5. Descripción del proceso de desarrollo de la SyRS

objetivos, necesidades y problemas

Representación para el cliente restricciones / influencia

Obtención del conjunto de requerimientos del sistema

Figura 1 - Contexto de desarrollo de SyRS

5.1.1 Requerimientos sin estructura

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

1. a) Concepto de operaciones. Este tipo de documento se enfoca en las metas, objetivos y

5.1.2 Representación para el cliente

Retroalimenta al cliente, incluye representaciones de SyRS e intercambio técnico o comunicación

Incluye información actualizada de los objetivos, problemas o necesidades del cliente;

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

5.2.1 Influencia Poli ́tica

Agencias gubernamentales internacionales, federales, estatales y locales tienen leyes y

5.2.2 Influencia del mercado

La tercera influencia del mercado es la competencia. Conociendo los sistemas de la competencia

IEEE Desarrollo de Especificaciones de Requerimientos de Sistemas Std 1233, Edición 1998

Durabilidad Funcionamiento Mantenimiento Seguridad del sistema

5.2.3 Influencia de los estándares y reglamentos técnicos