ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE

Definiciones de calidad
Conformidad con los requisitos y confianza en el funcionamiento, Deming
Adecuacin para su uso, Juran
Hacerlo bien a la primera, Crosby
Segn estndares internacionales:
*La calidad es la suma de todos aquellos aspectos o caractersticas de un producto o
servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o
implcitas (ISO 8402)
*Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas
(IEEE 729-83)
*Capacidad del producto software para satisfacer los requisitos establecidos (DoD 2168)
Estndares de Software IEEE
Importancia

Segn su uso:

Mejoramiento del producto-Proteccin al comprador-Proteccin al negocio-Incrementa la

disciplina profesional-Introduccin de tecnologa-Mejoramiento del Producto

Estndares IEEE son voluntarios.

Los estndares pueden mejorar los procesos de negocios permitiendo desarrollar sus
productos con costos mas apropiados.

La organizacin que los adoptan lo hace para mejorar sus productos o mejora la percepcin
de sus productos en el mercado

Proteccin al comprador
Con muchos productos disponibles el comprador toma decisiones basadas en propaganda,
folletos, experiencias anteriores con el vendedor o examinacin directa.
La creciente complejidad de productos tecnolgicos causa inevitablemente la imposibilidad de
examinar muchos aspectos que se mantiene ocultos hasta despus de ser adquiridos.
Los estndares pueden jugar un rol cuando proveen informacin precisa acerca de la
adecuacin de los productos para usos especficos.
Proteccin al negocio

Litigios

Estndares pueden respaldar la defensa en casos en que se pretende demostrar

negligencia.

Respaldo
El adherirse voluntariamente a estndares respalda la seriedad y confiabilidad de la
empresa que as lo hace.

Contratos
En situaciones contractuales la aplicacin adecuada de estndares protegen a ambas
partes divide responsabilidades, clarifica terminologa y define procedimientos esperados.
Incrementa la Disciplina Profesional

La existencia de estndares y uso de los mismos es un paso importante en la formalizacin

de la Ingeniera de Software.

Define los mtodos esperados en la prctica responsable de la ingeniera de software.

Introduccin de Tecnologa

Segn SEI, los estndares juegan un rol vital en la transicin tecnolgica.

Standards IEEE SESC(Software Engineering Standards Comitee)

Alrededor de 50
4 volmenes, 2,300 paginas
Cada uno de estos estndares toma de 2 a 4 aos en ser elaborados.
Costo 2,000 a 10,000 US$ por pgina

Precio de venta 300-400 US$, para miembros de IEEE

Objetivos Organizacionales

Diferentes motivos por los cuales una organizacin adopta estos estndares:

Mejorar y evaluar su capacidad tomado en cuanta estos aspectos:

Calidad

Satisfaccin del Cliente

Productividad

Madurez de los procesos

Tecnologa
Objetivos Organizacionales

Proveer el marco y terminologa para un contrato de dos partes.

Proceso de adquisicin

Proceso de provisin

Proceso de ciclo de vida

Documentos (entregas) durante el ciclo de vida

Evaluar los productos de la Ingeniera de SW

Mediciones externas (producto final)

Mediciones internas (productos incompletos, intermedios)

Objetivos Organizacionales

Asegurar niveles altos para el software

Planificacin

Desempeo

Evaluacin
Organizacin

Organizacin orientada a objetos de la IS

IEEE-STD-830-1998: ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE

1. Definiciones
En general las definiciones de los trminos usados en estas especificaciones.
1.1 Contrato:
Un documento es legalmente obligatorio y en el estarn de acuerdo las partes del cliente y
proveedor.
1.2 Cliente:
La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los
requisitos.
1.3 Proveedor:
La persona (s) que producen un producto para un cliente.
1.4 Usuario:

La persona (s) que operan o actan recprocamente directamente con el producto.

2. Las consideraciones para producir un buen SRS.
Estas clusulas proporcionan informacin a fondo que deben ser consideradas al momento de
producir un SRS. Esto incluye lo siguiente:
a) La Naturaleza del SRS; b) El Ambiente del SRS; c) Las Caractersticas de un buen SRS; d) La
preparacin de los Joins del SRS; e) La evolucin de SRS; f) Prototipos; g) Generando el diseo en
el SRS; h) Generando los requisitos del proyecto en el SRS.
2.1 Naturaleza del SRS
El SRS son especificaciones para un producto del software en particular, programa, o juego de
programas que realizan ciertas funciones en un ambiente especfico. El SRS puede escribirse por
uno o ms representantes del proveedor, uno o ms representantes del cliente, o por ambos.
Los problemas bsicos que se presentan al escribir un SRS van dirigidos a lo siguiente:
a) La Funcionalidad.: Qu se supone va hacer el software?
b) Las interfaces Externas. Cmo el software acta recprocamente con las personas, el
hardware de los sistemas, otro hardware, y otro software?
c) La Actuacin: Cul es la velocidad, la disponibilidad, tiempo de la contestacin, tiempo
de la recuperacin de varias funciones del software, etc.?
d) Los Atributos Qu portabilidad tiene, exactitud, el mantenimiento, la seguridad, las
consideraciones etc.?
e) Las restricciones del diseo que impusieron en una aplicacin. Hay algn
requerimiento Standard, idioma de aplicacin, las polticas para la integridad del banco de
datos, los lmites de los recursos, operando en que ambiente (s) etc.?
2.2 Ambiente del SRS
El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de
un sistema ms grande. En el ltimo caso habr un SRS que declarar las interfaces entre el
sistema y su software modular, y pondr que funcin externa y requisitos de funcionalidad tiene con
el software modular.
2.3 Caractersticas de un buen SRS.
Un SRS debe ser:
a) Correcto; b) Inequvoco; c) Completo; d) Consistente; e) Delinear que tiene importancia y/o
estabilidad; f) Comprobable; g) Modificable; h) Identificable.
2.3.1 Correcto
Un SRS es correcto si, y slo si, cada requisito declarado se encuentra en el software.
2.3.2 Inequvoco
Un SRS es inequvoco si, y slo si, cada requisito declarado tiene slo una interpretacin.
2.3.3 Completo
Un SRS est completo si, y slo si, incluye los elementos siguientes:
a) Los requisitos estn relacionados a la funcionalidad, el desarrollo, las restricciones del diseo,
los atributos y las interfaces externas. En particular debe reconocerse cualquier requisito externo
impuesto por una especificacin del sistema y debe tratarse.
b) La definicin de las respuestas del software a todos los posibles datos de la entrada del sistema
y a toda clase de situaciones. Una nota que es importante especificar son las contestaciones a las
entradas vlidas e invlidas a ciertos valores.
c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en el SRS y
definicin de todas las condiciones y unidades de medida.
2.3.4 Consistente
La consistencia se refiere a la consistencia interior. Si un SRS no est de acuerdo con algn
documento del superior-nivel, como una especificacin de requisitos de sistema, entonces no es
correcto.
2.3.5 Delinear que tiene importancia y/o estabilidad
Un SRS debe delinear la importancia y/o estabilidad si cada requisito en l tiene un identificador
para indicar la importancia o estabilidad de ese requisito en particular. Tpicamente, todos los
requisitos que relacionan a un producto del software no son igualmente importantes. Algunos

requisitos pueden ser esenciales, sobre todo para las aplicaciones de vida crtica, mientras otros
pueden ser deseables. Cada requisito en el SRS debe identificarse para representar estas
diferencias, aclarar y ser explcito.
2.3.6 Comprobable
Un SRS es comprobable si, y slo si, cada requisito declarado es comprobable. Un requisito es
comprobable si, y slo si, all existe algn proceso rentable finito con que una persona o la mquina
puede verificar que el producto del software rene el requisito. En general cualquier requisito
ambiguo no es comprobable.
2.3.7 Modificable
Un SRS es modificable si, y slo si, su estructura y estilo son tales que puede hacerse cualquier
cambio a los requisitos fcilmente, completamente y de forma consistente mientras conserva la
estructura y estilo.
2.3.8 Identificable
Un SRS es identificable si el origen de cada uno de sus requisitos est claro y si facilita las
referencias de cada requisito en el desarrollo futuro o documentacin del mismo.
2.4 Preparacin de los JOIN del SRS
El proceso de desarrollo de software debe empezar con el proveedor y con el acuerdo del cliente
en lo que el software completado debe hacer. Este acuerdo, en la forma de un SRS, debe
prepararse juntamente. Esto es importante porque ni el cliente ni el proveedor son calificables para
escribir exclusivamente un buen SRS.
Por consiguiente, el cliente y el proveedor deben trabajar para producir juntos un buen escrito y
completamente entendible SRS.
2.5 Evolucin de SRS
El SRS puede necesitar evolucionar as como el desarrollo de las actualizaciones del producto de
software. Puede ser imposible de especificar un poco a detalle en el momento que el proyecto se
inicia (por ejemplo, puede ser imposible de definir toda la estructura de la pantalla para un
programa interactivo durante la fase de requisitos).
2.6 Prototipos.
Los prototipos frecuentemente se usan durante una fase de los requisitos de un proyecto. Muchas
herramientas existen para generar un prototipo para exhibir algunas caractersticas de un sistema,
ser creado muy rpidamente y fcilmente.
2.7 Generando el diseo en el SRS
Un diseo describe un subcomponente particular de un sistema y/o sus interfaces con otros
subcomponentes.
2.8 Requisitos del proyecto generados en el SRS
El SRS debe dirigir el producto del software, no el proceso de producir el producto del software.
Los requisitos del proyecto representan una comprensin entre el cliente y el proveedor sobre
materias contractuales que pertenecen a la produccin de software y as no deben ser incluidos en
el SRS.
3. Las partes de un SRS
Estas partes se colocan en Figura 1 en un contorno que puede servir como un ejemplo por escribir
un SRS.
Tabla de Contenidos
1. Introduccin-1.1 Propsito-1.2 Alcance-1.3 Definiciones, siglas, y abreviaciones-1.4 Referencias-1.5
Apreciacin global
2. Descripcin global-2.1 Perspectiva del producto-2.2 Funciones del producto-2.3 Caractersticas del
usuario-2.4 Restricciones-2.5 Atencin y dependencias-2.6 Prorratear los requisitos
3. Los requisitos especficos

Apndices
ndice

Figura 1 - el Prototipo el contorno de SRS

3.1 Introduccin (Seccin 1 del SRS)
La introduccin del SRS debe proporcionar una apreciacin global del SRS completo.
Debe contener las subdivisiones siguientes:
a) El Propsito; b) El Alcance; c) Las Definiciones, siglas, y abreviaciones; d) Las Referencias; e)
La Apreciacin global.
3.1.1 Propsito (1.1 del SRS)
Esta subdivisin debe:
a) Delinear el propsito del SRS;
b) Especifique a que pblico intencional va dirigido el SRS.
3.1.2 Alcance (1.2 del SRS)
Esta subdivisin debe:
a) Identifique el producto (s) del software para ser diseado por el nombre (por ejemplo,
Anfitrin DBMS, el Generador del Reporte, etc.);
b) Explique eso que el producto (s) del software que har y que no har.
c) Describe la aplicacin del software especificndose los beneficios pertinentes, objetivos,
y metas;
d) Sea consistente con las declaraciones similares en las especificaciones de niveles
superiores (por ejemplo, las especificaciones de los requisitos del sistema), si ellos existen.
3.1.3 Definiciones, siglas, y abreviaciones (1.3 del SRS)
Esta subdivisin debe proporcionar las definiciones de todas las condiciones, las siglas, y
abreviaciones que exigen interpretar el SRS propiamente.
3.1.4 Referencias (1.4 del SRS)
En esta subdivisin debe:
a) Proporcione una lista completa de todas las referencias de los documentos en otra parte
en el SRS;
b) Identifique cada documento por el ttulo, nmero del reporte (si es aplicable), fecha, y
publicacin de la organizacin;
c) Especifique las fuentes de las referencias de donde se obtuvieron.
3.1.5 Apreciacin global (1.5 del SRS)
En esta subdivisin debe:
a) Describa lo que el resto del SRS contiene;
b) Explica cmo el SRS es organizado.
3.2 Descripcin global (Seccin 2 del SRS)
Esta seccin del SRS debe describir los factores generales que afectan el producto y sus
requisitos. Esta seccin normalmente consiste en seis subdivisiones, como sigue:
a) La perspectiva del Producto;
b) Las funciones del Producto;
c) Las caractersticas del Usuario;
d) Las restricciones;
e) Las Asunciones y dependencias;
3.2.1 Perspectiva del producto (2.1 del SRS)
Esta subdivisin del SRS debe poner el producto en la perspectiva con otros productos
relacionados. Si el producto es independiente y totalmente autnomo, debe declararse que as es.
Si el SRS define un producto que es un componente de un sistema ms grande, como
frecuentemente ocurre, entonces esta subdivisin debe relacionar los requisitos de ese sistema
ms grande a la funcionalidad del software y debe identificar las interfaces entre ese sistema y el
software.
3.2.2 Funciones del Producto (2.2 del SRS)
Esta subdivisin del SRS debe proporcionar un resumen de las funciones mayores que el software
realizar.
3.2.3 Caractersticas del usuario (2.3 del SRS)

Esta subdivisin del SRS debe describir esas caractersticas generales de los usuarios
intencionales del producto que incluye nivel educativo, experiencia, y la especializacin tcnica.
3.2.4 Restricciones (2.4 del SRS)
Esta subdivisin del SRS debe proporcionar una descripcin general de cualquier otro punto que
limitar las opciones de los diseadores.
3.2.5 Atenciones y dependencias (2.5 del SRS)
Esta subdivisin del SRS debe listar cada uno de los factores que afectan los requisitos declarados
en el SRS. Estos factores no son las restricciones del diseo en el software pero son, ms bien,
cualquier cambio a ellos eso puede afectar los requisitos en el SRS.
3.2.6 Prorratear los requisitos (2.6 del SRS)
Esta subdivisin del SRS debe identificar requisitos que pueden tardarse hasta las versiones
futuras del sistema.
3.3 Requisitos especficos (Seccin 3 del SRS)
Esta seccin del SRS debe contener todos los requisitos del software a un nivel de detalle
suficiente para permitirles a los diseadores disear un sistema para satisfacer esos requisitos, y a
los auditores a probar que el sistema satisface esos requisitos.
3.4 Informacin de apoyo
La informacin de apoyo hace ms fcil al SRS para usarse. Incluye a lo siguiente:
a) Tabla de contenidos;
b) ndice;
c) Apndice.
3.4.1 Tabla de contenidos e ndice
La tabla de contenidos e ndice es bastante importante y debe seguir las prcticas de las
composiciones generales.
3.4.2 Apndices
Los apndices no siempre son considerados parte del SRS real y no siempre son necesarios. Ellos
pueden incluir:
a) Ejemplos de formatos de las entradas/salidas, las descripciones del anlisis del costo que se
estudiaron o resultados de estudios del usuario;
b) Apoyando o dando informacin a fondo que puede ayudar a los lectores del SRS;
c) Una descripcin de los problemas a ser resuelto por el software;
d) las instrucciones del empaquetamiento especiales para el cdigo y los medios de comunicacin
para reunir la seguridad, exportar la carga inicial u otros requisitos.

IEEE Std 1233, Edicin 1998

Gua para el desarrollo
Requerimientos de Sistemas

de

Especificaciones

de

1. Descripcin
1.1 Alcance
Esta gua nos de la pauta para el desarrollo de un conjunto de requerimientos que satisfarn una
necesidad especfica. En esta gua, a ese conjunto de requerimientos se le denomina
Especificacin de Requerimientos del Sistema (System Requirements Specification, SyRS). El
desarrollo de una SyRS incluye la identificacin, organizacin, presentacin y modificacin de los
requerimientos.
Esta gua trata las condiciones necesarias para incorporar conceptos operacionales, restricciones
de diseo, y requerimientos de la configuracin del diseo en la especificacin. Adems, trata las

caractersticas 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
MIL-STD-490A

IEEE Std 828-1998

IEEE Std 830-1998
IEEE Std 1074-1997

IEEE Std 1220-1998

ISO 9000-1:1994
ISO 9126:1991

3. Definiciones
Las definiciones listadas a continuacin tienen un significado en el contexto de esta gua. Los
trminos que no estn definidos en esta gua estn incluidos en IEEE Std 610.12-1990.
3.1 Analista
Un miembro de la comunidad tcnica (ingenieros en sistemas o analistas de negocios, que
desarrollan los requerimientos del sistema) que est capacitado para definir problemas y analizar,
desarrollar y expresar algoritmos.
3.2 Anotacin
Documentacin adicional que acompaa a un requerimiento, tal como antecedentes y/o material
descriptivo.
3.3 Lnea base
Una especificacin o sistema que ha sido formalmente revisado y aprobado, que sirve como base
para un desarrollo posterior y que puede ser modificado slo a travs de procedimientos formales
de control de cambios (EEEE Std 610.12-1990).
3.4 Restriccin
Un enunciado que expresa lmites medibles para un elemento o funcin del sistema. Esto es, una
restriccin es un factor impuesto a la solucin que puede limitar o modificar el diseo.
3.5 Cliente
La entidad o entidades para los cuales los requerimientos deben ser satisfechos en el sistema que
est siendo definido y desarrollado. ste puede ser el usuario final de un sistema terminado, una
organizacin dentro de la misma compaa desarrolladora, una compaa o entidad externa a la
compaa desarrolladora, o una combinacin de las anteriores. 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 configuracin y
solucin 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 usarn el sistema para el propsito deseado.
3.9 Ambiente
Las circunstancias, objetos, y condiciones que influenciarn el sistema terminado; stas incluyen
influencias polticas, de mercado, culturales, organizacionales as como estndares y polticas que
afectarn lo que el sistema debe hacer y cmo debe hacerlo.
3.10 Funcin
Una tarea, accin o actividad que debe ser realizada para alcanzar el resultado deseado.
3.11 Modelo
Una representacin 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 retroalimentacin de los usuarios, para ser capaces de mejorar y
especificar una interfaz de usuario compleja, para realizar estudios de factibilidad, o para identificar
requerimientos.
4. Especificacin de Requerimientos del Sistema

Una SyRS tradicionalmente ha sido vista como un documento que comunica los requerimientos del
cliente a la comunidad tcnica que especificarn y construirn el sistema. La coleccin de
requerimientos que constituyen la especificacin y su representacin actan como el puente entre
los dos grupos y debe ser entendible tanto por el cliente como por la comunidad tcnica. Una de
las tareas ms difciles en la creacin de un sistema, es aquella de comunicar a todos los
subgrupos, especialmente en un solo documento. Este tipo de comunicacin usualmente requiere
diferentes formalismos y lenguajes.
4.1 Definicin
La SyRS presenta los resultados de la definicin de necesidades, los conceptos de operacin y las
tareas de anlisis de sistema. Como tal, es una descripcin de lo que los clientes del sistema
esperan de ste, el ambiente del sistema, el perfil de uso del sistema, sus parmetros de
desempeo, y la calidad y efectividad deseados.
4.2 Propiedades
El conjunto de requerimientos debera tener las siguientes propiedades:
a) Conjunto nico. Cada requerimiento debe ser declarado slo una vez.
b) Normalizado. Los requerimientos no se deben traslapar (Por ejemplo, no se deben referir a otros
requerimientos ni a las capacidades de otros requerimientos).
c) Conjunto interdependiente. Se deben definir explcitamente las relaciones entre los
requerimientos.
d) Completo. Una SyRS debe incluir todos los requerimientos dados por el cliente.
e) Consistente. El contenido de una SyRS debe ser consistente y sin contradicciones.
f) Acotado. Los lmites, alcance y el contexto de los requerimientos del sistema deben ser
identificados.
g) Modificable. La SyRS debera ser modificable. Requerimientos claros y sin traslapamientos
contribuyen a lograrlo.
h) Configurable. Las versiones deberan ser mantenidas a travs del tiempo.
i) Granular. ste debe ser el nivel de abstraccin para el sistema que est siendo definido
4.3 Propsito
El propsito de la SyRS es proveer una descripcin tipo caja negra de lo que el sistema debe
hacer, en trminos de las interacciones del sistema o las interfaces con su ambiente externo.
4.3.1 Organizando los requerimientos
El propsito de la SyRS puede ser logrado mas fcilmente organizando los requerimientos en
categoras conceptuales. Estos requerimientos deberan ser comunicados de manera estructurada
para asegurar que el cliente y la comunidad tcnica puedan hacer lo siguiente:
a) Identificar requerimientos derivados de otros requerimientos.
b) Organizar requerimientos en diferentes niveles de detalle en un nivel apropiado.
c) Verificar que el conjunto de requerimientos est completo.
d) Identificar inconsistencias entre los requerimientos.
e) Claramente identificar las capacidades, condiciones, y restricciones de cada requerimiento.
f) Desarrollar un entendimiento comn con el cliente del propsito y los objetivos del conjunto de
requerimientos.
g) Identificar requerimientos que completarn 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.
4.3.2 Comunicin con dos audiencias
La SyRS tiene dos audiencias principales y esencialmente sirve para documentar un acuerdo entre
el cliente y la comunidad tcnica.
4.3.2.1 Cliente
Cliente es un trmino colectivo que puede incluir al cliente del sistema propuesto, la persona que
aceptar y firmar la entrega, y los encargados quienes sern los responsables de vigilar la
implementacin, operacin y mantenimiento del sistema.
4.3.2.2 Comunidad Tcnica
La SyRS debera tambin comunicar los requerimientos del cliente a la comunidad tcnica. La
comunidad tcnica incluye analistas, estimadores, diseadores, desarrolladores, auditores de

aseguramiento de calidad, ingenieros, personal de integracin, de pruebas, de mantenimiento y de

manufactura.
4.4 Uso recomendado
Los usos recomendados de la SyRS pueden variar conforme el ciclo de desarrollo progrese, son
los siguientes:
a) Durante el diseo 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.
c) Durante la fase de implementacin, los procedimientos de prueba sern definidos a partir de la
SyRS.
d) Durante el proceso de validacin, los procedimientos de validacin basados en la SyRS sern
usados para darle al cliente las bases para aceptar el sistema.
4.5 Beneficios
Una SyRS apropiadamente escrita beneficia todas las subsecuentes fases del ciclo de vida de
varias maneras.
4.6 Dinamismo de los requerimientos del sistema
Los requerimientos son raramente estticos. 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 tcnica como
al cliente.
5. Descripcin del proceso de desarrollo de la SyRS
Esta clusula proporciona una descripcin 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 tcnica) Cada uno de estos agentes es descrito en la
figura siguiente:

Figura 1 - Contexto de desarrollo de SyRS

6. Requerimientos bien formados
Esta clusula explica las propiedades de un requerimiento bien formado. Provee un ejemplo de un
requerimiento bien formado, y seala los errores comunes en los requerimientos.
6.1 Definicin de un requerimiento bien formado
Un requerimiento bien formado es una declaracin de la funcionalidad del sistema que puede ser
validada, y que debe ser posedo por el sistema para resolver el problema de un cliente o lograr el
objetivo del cliente, y que est calificado por condiciones medibles y delimitado mediante
restricciones. Esta definicin ayuda en la clasificacin de los requerimientos generales del cliente.
stos pueden ser tomados de las necesidades del cliente y pueden ser derivados del anlisis
tcnico. La definicin 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 restriccin no funcional podra ser que el sistema sea pintado con un tono particular
de azul solamente para propsitos decorativos.
6.2 Propiedades de un requerimiento
Cada requerimiento debe poseer las siguientes propiedades:
a) Abstracto. Cada requerimiento debe ser independiente de su implementacin.
b) No ambiguo. Cada requerimiento debe ser enunciado de tal manera que pueda ser interpretado
de una sola manera.
c) Rastreable. Para cada requerimiento debe ser factible determinar una relacin entre las
declaraciones realizadas por el cliente y los requerimientos especificados en la SyRS, esto como
evidencia del origen del requerimiento.
d) Validable. Para cada requerimiento debe existir la manera de probar que el sistema satisface los
requerimientos.
6.3 Clasificacin
Los requerimientos deben ser clasificados de acuerdo a un identificador, prioridad, criticismo,
factibilidad, riesgo, fuente, y tipo.
7. Desarrollo de la SyRS
El desarrollo de SyRS es un proceso iterativo. Los cuatro subprocesos que incluye son los
siguientes:
a) Identificar requerimientos del usuario, el ambiente y la experiencia de la comunidad tcnica;
b) Construir requerimientos bien formados;
c) Organizar los requerimientos en una SyRS;
d) Presentar la SyRS en varias representaciones para diferentes audiencias.
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 extrados desde los documentos iniciales hasta ejercicios analticos
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 slo una vez y que no falta
ninguno.
7.2 Construir requerimientos bien formados
El analista realiza esta subfase haciendo lo siguiente:
a) Se asegura de que cada requerimiento es una declaracin breve y definitiva de una necesidad.
b) Define las condiciones apropiadas para cada requerimiento (medidas cuantitativas y cualitativas)
y evite adjetivos tal como resistente o aceptado por industria
c) Evite los errores comunes de especificacin.
d) Se asegura de la legilibilidad de los requerimientos.
e) Se asegura de que los requerimientos puedan ser probados.
7.3 Organizar los requerimientos
7.4 Presentar la SyRS
7.5 Mtodos de representacin
Los mtodos de representacin pueden incluir uno o una combinacin de los siguientes:
a) Textual
a. Fsico
a. Papel
b. Simblico
b. Electrnico
c. Grafico
b) Modelos
d. Prototipo
Plantilla para Especificacin de Requerimientos de Sistemas
Esta gua reconoce que existen una gran cantidad de tcnicas y formas de comunicar los
requerimientos, incluyendo texto y modelos. El propsito de esta plantilla es ayudar a esclarecer el
contenido tcnico de una SyRS. La representacin y contenido puede ser expandido o comprimido
para el cliente o la comunidad tcnica. Existen muchas representaciones posibles de una SyRS y
la siguiente es simplemente un ejemplo.
Tabla de contenido

Lista de figuras

Lista de tablas
1. Introduccin
1.1 Propsito del sistema
1.2 Alcance del sistema
1.3 Definiciones, acrnimos y abreviaturas
1.4 Referencias
1.5 Panorama general
2 Descripcin general del sistema
2.1 Contexto del sistema
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 Caractersticas de los usuarios
2.7 Suposiciones y dependencias
2.8 Escenarios de operacin
3. Capacidades, condiciones y restricciones
del sistema

3.1 Condiciones fsicas

3.1.1 Construccin
3.1.2 Durabilidad
3.1.3 Adaptabilidad
3.1.4 Condiciones ambientales
3.2 Caractersticas de desempeo
sistema
3.3 Seguridad
3.4 Administracin de la informacin
3.5 Operaciones del sistema
3.5.1 Factores humanos
3.5.2 Mantenibilidad
3.5.3 Confiabilidad
3.6 Polticas y regulaciones
3.7 Ciclo de vida del sistema
4. Interfaces del sistema

del

ISO/IEC 12119-1194
Aplicable a los paquetes de software. Establece requisitos para paquetes de software e
instrucciones sobre cmo probar un paquete de software en comparacin con estos requisitos. Se
las arregla solamente con paquetes de software como brindar y repartir. No se las arregla con su
proceso de produccin. El sistema de calidad de un proveedor est fuera del alcance de este
patrn.

Este tema est preocupado por la estructura, calidad y verificabilidad de los

requisitos de documentacin. Esto puede tomar la forma de dos documentos, o
dos partes de lo mismo documentan con lectores diferentes y propsitos: la
especificacin de requisitos. El tema hace hincapi en que documentar los
requisitos es la condicin previa ms fundamental para requisitos prsperos
responder.
3.4.1 El documento de definicin de requisitos de sistema
Este documento (sepa como los usuario requisitos documentos o concepto de las
operaciones a veces) graba los requisitos de sistema. Define los requisitos de
sistema de alto nivel de la perspectiva de dominio. Sus lectores incluyen a
representantes de los usuarios / clientes de sistema (la mercadotecnia puede
tener estos papeles para el software impulsado por el mercado) as que debe serlo
expresar en relacin con el dominio. Debe poner en una lista los requisitos de
sistema al mismo tiempo que la informacin de fondo sobre los objetivos en
conjunto para el sistema, su ambiente de meta y una declaracin de las
restricciones, suposiciones y requisitos no- funcional. Podra incluir modelos
conceptuales diseados ilustrado el contexto de sistema, los guiones de uso, las
entidades de dominio principales, y los datos, la informacin y workflows.
3.4.2 Los especificaciones de requisitos de software (SRS)

Los beneficios de SRS incluyen:

*Establece la base para el acuerdo entre los clientes y contratistas o proveedores
(en proyectos impulsados por el mercado, estos papeles pueden ser tenidos por
mercadotecnia y divisiones de desarrollo) en lo que el producto de software es
hacer y tan bien como lo que es no esperar lo hace. Para lectores no tcnicos, el
SRS es acompaado por los requisitos que las definiciones documentan a
menudo.
* Esta es una fuerza, una valoracin rigurosa de requisitos antes de que disee
pueda comenzar y reduce rediseo posterior
* Suministra una base objetiva para calcular gastos de producto, los riesgos y los
programas.
*Las organizaciones pueden usar SRS para que desarrolle sus propios planes de
validacin y verificacin ms productivamente
*Proveer un informe con una base para transferir un producto de software a
nuevos usuarios o a nuevas computadoras.
* Suministra una base para el realce de software
3.4.3 La estructura de documento y los estndares
Varios recomendaron a guas y los estndares que existen para ayudar definir la
estructura de requisitos la documentacin. stos incluyen a gua de IEEEP1233 /
D3, gua de std.1233 de IEEE, IEEE usual. 830-1998, 12119-1994 de la ISO / IEC.
El concepto de std 1362-1998 de IEEE de operaciones (ConOps) es un padrn
reciente para uno documento de definicin de requisitos.
3.4.4 La calidad de documento
Esto es un rea donde las medidas pueden estar tilmente empleadas en lo
requisitos crear ingeniera. Hay atributos tangibles que pueden ser medidos.
Adems, la calidad del documento de requisitos puede afectar la calidad del
producto dramticamente.
Varios indicadores de calidad al haber sido desarrollado puede ser use relacionar
la calidad de uno SRS con otras variables de proyecto como el coste, la
aprobacin, los rendimiento, programa, reproducibilidad etc. Los indicadores de
calidad para SRS, declaraciones individuales incluyen los imperativos, las
directivas las frases dbiles, las opciones y los aplazamientos. Los indicadores
para el SRS documento entero incluyen el tamao, aprendizaje, la profundidad de
especificacin y la estructura de texto

Hay una coincidencia de posibilidades con 3.5.1 (la conduccin de requisitos

repasa) que el Cuadro 5 indica que la calidad de documento vincula con temas de
comn en otros KAs.
Se vincula a trabajos comunes
Calidad

Medicin

La calidad del anlisis afecta la

calidad de producto directamente. En
principio, el ms riguroso el anlisis,
ms confianza poder ser dada a la
calidad de software.
La calidad de los documentos de
requisitos afecta la calidad del
producto dramticamente
Parte del propsito del anlisis es
cuantificar
las
propiedades
requeridas, esto es particularmente
importante para las restricciones
como la confiabilidad o los requisitos
de seguridad donde las medidas
apropiadas
tienen
que
ser
identificadas de permitir que el
requisito sea cuantificado y verificado.
La calidad que los atributos o
requisitos documentan puede ser
identificada y medida.
Tabla de negociacin de vinculaciones a otros KAs.