IEEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE 1.
Definiciones En general las definiciones de los trminos usados en estas especificaciones estn conforme a las definiciones proporcionadas en IEEE Std 610.12-1990. 1.1 Contrato: Un documento es legalmente obligatorio y en el estarn de acuerdo las partes del cliente y proveedor. Esto incluye los requisitos tcnicos y requerimientos de la organizacin, costo y tiempo para un producto. Un contrato tambin puede contener la informacin informal pero til como los compromisos o expectativas de las partes involucradas. 1.2 Cliente: La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos. En la prctica el cliente y el proveedor pueden ser miembros de la misma organizacin. 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. El usuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s). 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. La Subclausula 2.4 recomienda 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 Es importante considerar la parte que el SRS representa en el diseo del proyecto total que se define en IEEE Std 610.12-1990. 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. Otras normas, relacionan a otras partes del ciclo de vida de software para que pueda complementar los requisitos del software. Desde que el SRS tiene un papel especfico en el proceso de desarrollo de software, el que define el SRS debe tener el cuidado para no ir ms all de los lmites de ese papel. Esto significa que: a) debe definir todos los requisitos del software correctamente. Un requisito del software puede existir debido a la naturaleza de la tarea a ser resuelta o debido a una caracterstica especial del proyecto. b) no debe describir cualquier plan o detalles de aplicacin. stos deben describirse en la fase del diseo del proyecto. c) no debe imponer las restricciones adicionales en el software. stos se especifican propiamente en otros documentos. 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. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente. Identificando los requerimientos hace este procedimiento ms fcil y hay menos probabilidad al error. 2.3.2 Inequvoco Un SRS es inequvoco si, y slo si, cada requisito declarado tiene slo una interpretacin. Como un mnimo, se requiere que cada caracterstica de la ltima versin del producto se describa usando un nico trmino. En casos dnde un trmino en un contexto particular tenga significados mltiples, el trmino debe ser incluido en un glosario dnde su significado es hecho ms especfico. Un SRS es una parte importante del proceso de requisitos del ciclo de vida de software y se usa en el diseo, aplicacin, supervisin, comprobacin, aprobacin y pruebas como est descrito en IEEE Std 1074-1997. El SRS debe ser inequvoco para aqullos que lo crean y para aqullos que lo usan. Sin embargo, estos grupos no tienen a menudo el mismo fondo y por consiguiente no tienden a describir los requisitos del software de la misma manera. Las Subclauses 2.3.2.1 a travs de 2.3.2.3 recomiendan cmo evitar la ambigedad. 2.3.2.1 Trampas del idioma natural. Los requisitos son a menudo escritos en el idioma natural (por ejemplo, ingls) el idioma natural es inherentemente ambiguo. Un idioma natural que SRS podra ser revisado por una parte independiente para identificar el uso ambiguo del idioma para que pueda corregirse.
