ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

Definiciones de “calidad” “Conformidad con los requisitos y confianza en el funcionamiento”, Deming “Adecuación para su uso”, Juran “Hacerlo bien a la primera”, Crosby

Según estándares internacionales: *La calidad es la suma de todos aquellos aspectos o características de un producto o

servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o implícitas” (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)

Estándares de Software IEEE

Importancia

• Según su uso:

Mejoramiento del producto-Protección al comprador-Protección al negocio-Incrementa la disciplina profesional-Introducción de tecnología-Mejoramiento del Producto

• Estándares IEEE son voluntarios.

• La organización que los adoptan lo hace para mejorar sus productos o mejora la percepción de sus productos en el mercado

• Los estándares pueden mejorar los procesos de negocios permitiendo desarrollar sus productos con costos mas apropiados.

Protección al comprador• Con muchos productos disponibles el comprador toma decisiones basadas en propaganda,

folletos, experiencias anteriores con el vendedor o examinación directa.• La creciente complejidad de productos tecnológicos causa inevitablemente la imposibilidad de

examinar muchos aspectos que se mantiene ocultos hasta después de ser adquiridos.• Los estándares pueden jugar un rol cuando proveen información precisa acerca de la

adecuación de los productos para usos específicos.

Protección al negocio

• Litigios

– Estándares pueden respaldar la defensa en casos en que se pretende demostrar negligencia.

• Respaldo

– El adherirse voluntariamente a estándares respalda la seriedad y confiabilidad de la empresa que así lo hace.

• Contratos

– En situaciones contractuales la aplicación adecuada de estándares protegen a ambas partes divide responsabilidades, clarifica terminología y define procedimientos esperados.Incrementa la Disciplina Profesional

• La existencia de estándares y uso de los mismos es un paso importante en la formalización de la Ingeniería de Software.

• Define los métodos esperados en la práctica responsable de la ingeniería de software.Introducción de Tecnología

• Según SEI, los estándares juegan un rol vital en la transición tecnológica.

Standards IEEE SESC(Software Engineering Standards Comitee)

• Alrededor de 50

• 4 volúmenes, 2,300 paginas

• Cada uno de estos estándares toma de 2 a 4 años en ser elaborados.

• Costo 2,000 a 10,000 US$ por página

• Precio de venta 300-400 US$, para miembros de IEEEObjetivos Organizacionales

• Diferentes motivos por los cuales una organización adopta estos estándares:

– Mejorar y evaluar su capacidad tomado en cuanta estos aspectos:• Calidad• Satisfacción del Cliente• Productividad• Madurez de los procesos• TecnologíaObjetivos Organizacionales– Proveer el marco y terminología para un contrato de dos partes.• Proceso de adquisición• Proceso de provisión• Proceso de ciclo de vida• Documentos (entregas) durante el ciclo de vida– Evaluar los productos de la Ingeniería de SW• Mediciones externas (producto final)• Mediciones internas (productos incompletos, intermedios)Objetivos Organizacionales– Asegurar niveles altos para el software• Planificación• Desempeño• EvaluaciónOrganización

• Organización orientada a objetos de la IS

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

1. DefinicionesEn general las definiciones de los términos usados en estas especificaciones.

1.1 Contrato:Un documento es legalmente obligatorio y en el estarán 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 actúan recíprocamente directamente con el producto. 2. Las consideraciones para producir un buen SRS.

Estas cláusulas proporcionan información 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 Características de un buen SRS; d) La preparación de los Joins del SRS; e) La evolución de SRS; f) Prototipos; g) Generando el diseño en el SRS; h) Generando los requisitos del proyecto en el SRS.

2.1 Naturaleza del SRSEl SRS son especificaciones para un producto del software en particular, programa, o juego de programas que realizan ciertas funciones en un ambiente específico. El SRS puede escribirse por uno o más representantes del proveedor, uno o más representantes del cliente, o por ambos. Los problemas básicos 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. ¿Cómo el software actúa recíprocamente con las personas, el hardware de los sistemas, otro hardware, y otro software?c) La Actuación: ¿Cuál es la velocidad, la disponibilidad, tiempo de la contestación, tiempo de la recuperación de varias funciones del software, etc.?d) Los Atributos ¿Qué portabilidad tiene, exactitud, el mantenimiento, la seguridad, las consideraciones etc.?e) Las restricciones del diseño que impusieron en una aplicación. ¿Hay algún requerimiento Standard, idioma de aplicación, las políticas para la integridad del banco de datos, los límites de los recursos, operando en que ambiente (s) etc.?

2.2 Ambiente del SRSEl software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema más grande. En el último caso habrá un SRS que declarará las interfaces entre el sistema y su software modular, y pondrá que función externa y requisitos de funcionalidad tiene con el software modular.

2.3 Características de un buen SRS.Un SRS debe ser:a) Correcto; b) Inequívoco; c) Completo; d) Consistente; e) Delinear que tiene importancia y/o estabilidad; f) Comprobable; g) Modificable; h) Identificable.2.3.1 CorrectoUn SRS es correcto si, y sólo si, cada requisito declarado se encuentra en el software.2.3.2 InequívocoUn SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una interpretación.2.3.3 CompletoUn SRS está completo si, y sólo si, incluye los elementos siguientes:a) Los requisitos están relacionados a la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas. En particular debe reconocerse cualquier requisito externo impuesto por una especificación del sistema y debe tratarse.b) La definición 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 válidas e inválidas a ciertos valores.c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en el SRS y definición de todas las condiciones y unidades de medida.2.3.4 ConsistenteLa consistencia se refiere a la consistencia interior. Si un SRS no está de acuerdo con algún documento del superior-nivel, como una especificación de requisitos de sistema, entonces no es correcto.2.3.5 Delinear que tiene importancia y/o estabilidadUn 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. Típicamente, 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 crítica, mientras otros

pueden ser deseables. Cada requisito en el SRS debe identificarse para representar estas diferencias, aclarar y ser explícito.2.3.6 ComprobableUn SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Un requisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con que una persona o la máquina puede verificar que el producto del software reúne el requisito. En general cualquier requisito ambiguo no es comprobable.2.3.7 ModificableUn SRS es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo. 2.3.8 IdentificableUn 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 documentación del mismo.

2.4 Preparación de los JOIN del SRSEl 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 Evolución de SRSEl 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 características de un sistema, ser creado muy rápidamente y fácilmente.

2.7 Generando el diseño en el SRSUn diseño describe un subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes.

2.8 Requisitos del proyecto generados en el SRSEl SRS debe dirigir el producto del software, no el proceso de producir el producto del software. Los requisitos del proyecto representan una comprensión entre el cliente y el proveedor sobre materias contractuales que pertenecen a la producción de software y así no deben ser incluidos en el SRS.

3. Las partes de un SRSEstas partes se colocan en Figura 1 en un contorno que puede servir como un ejemplo por escribir un SRS.Tabla de Contenidos1. Introducción-1.1 Propósito-1.2 Alcance-1.3 Definiciones, siglas, y abreviaciones-1.4 Referencias-1.5 Apreciación global2. Descripción global-2.1 Perspectiva del producto-2.2 Funciones del producto-2.3 Características del usuario-2.4 Restricciones-2.5 Atención y dependencias-2.6 Prorratear los requisitos3. Los requisitos específicosApéndicesÍndice

Figura 1 - el Prototipo el contorno de SRS3.1 Introducción (Sección 1 del SRS)La introducción del SRS debe proporcionar una apreciación global del SRS completo.Debe contener las subdivisiones siguientes:a) El Propósito; b) El Alcance; c) Las Definiciones, siglas, y abreviaciones; d) Las Referencias; e) La Apreciación global.3.1.1 Propósito (1.1 del SRS)Esta subdivisión debe:

a) Delinear el propósito del SRS;b) Especifique a que público intencional va dirigido el SRS.

3.1.2 Alcance (1.2 del SRS)Esta subdivisión debe:

a) Identifique el producto (s) del software para ser diseñado por el nombre (por ejemplo, Anfitrión DBMS, el Generador del Reporte, etc.);b) Explique eso que el producto (s) del software que hará y que no hará.c) Describe la aplicación del software especificándose 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 subdivisión 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 subdivisión 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 título, número del reporte (si es aplicable), fecha, y publicación de la organización;c) Especifique las fuentes de las referencias de donde se obtuvieron.

3.1.5 Apreciación global (1.5 del SRS)En esta subdivisión debe:

a) Describa lo que el resto del SRS contiene;b) Explica cómo el SRS es organizado.

3.2 Descripción global (Sección 2 del SRS)Esta sección del SRS debe describir los factores generales que afectan el producto y sus requisitos. Esta sección normalmente consiste en seis subdivisiones, como sigue:

a) La perspectiva del Producto;b) Las funciones del Producto;c) Las características del Usuario;d) Las restricciones;e) Las Asunciones y dependencias;

3.2.1 Perspectiva del producto (2.1 del SRS)Esta subdivisión del SRS debe poner el producto en la perspectiva con otros productos relacionados. Si el producto es independiente y totalmente autónomo, debe declararse que así es. Si el SRS define un producto que es un componente de un sistema más grande, como frecuentemente ocurre, entonces esta subdivisión debe relacionar los requisitos de ese sistema más 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 subdivisión del SRS debe proporcionar un resumen de las funciones mayores que el software realizará.3.2.3 Características del usuario (2.3 del SRS)Esta subdivisión del SRS debe describir esas características generales de los usuarios intencionales del producto que incluye nivel educativo, experiencia, y la especialización técnica.3.2.4 Restricciones (2.4 del SRS)

Esta subdivisión del SRS debe proporcionar una descripción general de cualquier otro punto que limitará las opciones de los diseñadores. 3.2.5 Atenciones y dependencias (2.5 del SRS)Esta subdivisión del SRS debe listar cada uno de los factores que afectan los requisitos declarados en el SRS. Estos factores no son las restricciones del diseño en el software pero son, más bien, cualquier cambio a ellos eso puede afectar los requisitos en el SRS. 3.2.6 Prorratear los requisitos (2.6 del SRS)Esta subdivisión del SRS debe identificar requisitos que pueden tardarse hasta las versiones futuras del sistema.

3.3 Requisitos específicos (Sección 3 del SRS)Esta sección del SRS debe contener todos los requisitos del software a un nivel de detalle suficiente para permitirles a los diseñadores diseñar un sistema para satisfacer esos requisitos, y a los auditores a probar que el sistema satisface esos requisitos.

3.4 Información de apoyoLa información de apoyo hace más fácil al SRS para usarse. Incluye a lo siguiente:a) Tabla de contenidos;b) Índice;c) Apéndice.3.4.1 Tabla de contenidos e índiceLa tabla de contenidos e índice es bastante importante y debe seguir las prácticas de las composiciones generales.3.4.2 ApéndicesLos apéndices 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 análisis del costo que se estudiaron o resultados de estudios del usuario;b) Apoyando o dando información a fondo que puede ayudar a los lectores del SRS;c) Una descripción de los problemas a ser resuelto por el software;d) las instrucciones del empaquetamiento especiales para el código y los medios de comunicación para reunir la seguridad, exportar la carga inicial u otros requisitos.

IEEE Std 1233, Edición 1998

Guía para el desarrollo de Especificaciones de Requerimientos de Sistemas

1. Descripción

1.1 AlcanceEsta guía nos de la pauta para el desarrollo de un conjunto de requerimientos que satisfarán una necesidad específica. En esta guía, a ese conjunto de requerimientos se le denomina Especificación de Requerimientos del Sistema (System Requirements Specification, SyRS). El desarrollo de una SyRS incluye la identificación, organización, presentación y modificación de los requerimientos.Esta guía trata las condiciones necesarias para incorporar conceptos operacionales, restricciones de diseño, y requerimientos de la configuración del diseño en la especificación. Además, trata las características y cualidades necesarias de los requerimientos individuales y del conjunto de todos los requerimientos.

2. Referencias

IEEE Std 100-1996IEEE Std 610.12-1990IEEE Std 730-1998

IEEE Std 828-1998IEEE Std 830-1998IEEE Std 1074-1997

IEEE Std 1220-1998ISO 9000-1:1994ISO 9126:1991

MIL-STD-490A

3. DefinicionesLas definiciones listadas a continuación tienen un significado en el contexto de esta guía. Los términos que no están definidos en esta guía están incluidos en IEEE Std 610.12-1990.3.1 AnalistaUn miembro de la comunidad técnica (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 AnotaciónDocumentación adicional que acompaña a un requerimiento, tal como antecedentes y/o material descriptivo.3.3 Línea baseUna especificación o sistema que ha sido formalmente revisado y aprobado, que sirve como base para un desarrollo posterior y que puede ser modificado sólo a través de procedimientos formales de control de cambios (EEEE Std 610.12-1990).3.4 RestricciónUn enunciado que expresa límites medibles para un elemento o función del sistema. Esto es, una restricción es un factor impuesto a la solución que puede limitar o modificar el diseño.3.5 ClienteLa 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 organización dentro de la misma compañía desarrolladora, una compañía o entidad externa a la compañía desarrolladora, o una combinación 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 derivadosEs un requerimiento derivado o inferido del conjunto de los requerimientos en una configuración y solución particular del sistema.3.7 ElementoUn componente de un sistema; puede incluir equipo, un programa de computadora o un humano.3.8 Usuario finalLa persona o personas quienes al final usarán el sistema para el propósito deseado.3.9 AmbienteLas circunstancias, objetos, y condiciones que influenciarán el sistema terminado; éstas incluyen influencias políticas, de mercado, culturales, organizacionales así como estándares y políticas que afectarán lo que el sistema debe hacer y cómo debe hacerlo.3.10 FunciónUna tarea, acción o actividad que debe ser realizada para alcanzar el resultado deseado.3.11 ModeloUna representación de un proceso, dispositivo o concepto del mundo real.3.12 PrototipoUn modelo experimental del sistema o parte del sistema, ya sea funcional o no funcional. Un prototipo es usado para obtener retroalimentació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.

4. Especificación de Requerimientos del Sistema

Una SyRS tradicionalmente ha sido vista como un documento que comunica los requerimientos del cliente a la comunidad técnica que especificarán y construirán el sistema. La colección de requerimientos que constituyen la especificación y su representación actúan como el puente entre

los dos grupos y debe ser entendible tanto por el cliente como por la comunidad técnica. Una de las tareas más difíciles en la creación de un sistema, es aquella de comunicar a todos los subgrupos, especialmente en un solo documento. Este tipo de comunicación usualmente requiere diferentes formalismos y lenguajes.4.1 DefiniciónLa SyRS presenta los resultados de la definición de necesidades, los conceptos de operación y las tareas de análisis de sistema. Como tal, es una descripción de lo que los clientes del sistema esperan de éste, el ambiente del sistema, el perfil de uso del sistema, sus parámetros de desempeño, y la calidad y efectividad deseados. 4.2 PropiedadesEl conjunto de requerimientos debería tener las siguientes propiedades:a) Conjunto Único. Cada requerimiento debe ser declarado sólo 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 explícitamente 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 límites, alcance y el contexto de los requerimientos del sistema deben ser identificados.g) Modificable. La SyRS debería ser modificable. Requerimientos claros y sin traslapamientos contribuyen a lograrlo.h) Configurable. Las versiones deberían ser mantenidas a través del tiempo.i) Granular. Éste debe ser el nivel de abstracción para el sistema que está siendo definido 4.3 PropósitoEl propósito de la SyRS es proveer una descripción tipo caja negra de lo que el sistema debe hacer, en términos de las interacciones del sistema o las interfaces con su ambiente externo.4.3.1 Organizando los requerimientosEl propósito de la SyRS puede ser logrado mas fácilmente organizando los requerimientos en categorías conceptuales. Estos requerimientos deberían ser comunicados de manera estructurada para asegurar que el cliente y la comunidad técnica 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 común con el cliente del propósito y los objetivos del conjunto de requerimientos.g) Identificar requerimientos que completará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. 4.3.2 Comunición con dos audienciasLa SyRS tiene dos audiencias principales y esencialmente sirve para documentar un acuerdo entre el cliente y la comunidad técnica.4.3.2.1 ClienteCliente es un término colectivo que puede incluir al cliente del sistema propuesto, la persona que aceptará y firmará la entrega, y los encargados quienes serán los responsables de vigilar la implementación, operación y mantenimiento del sistema.4.3.2.2 Comunidad TécnicaLa SyRS debería también comunicar los requerimientos del cliente a la comunidad técnica. La comunidad técnica incluye analistas, estimadores, diseñadores, desarrolladores, auditores de aseguramiento de calidad, ingenieros, personal de integración, de pruebas, de mantenimiento y de manufactura. 4.4 Uso recomendadoLos usos recomendados de la SyRS pueden variar conforme el ciclo de desarrollo progrese, son los siguientes:

a) Durante el diseñ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. c) Durante la fase de implementación, los procedimientos de prueba serán definidos a partir de la SyRS.d) Durante el proceso de validación, los procedimientos de validación basados en la SyRS serán usados para darle al cliente las bases para aceptar el sistema.4.5 BeneficiosUna SyRS apropiadamente escrita beneficia todas las subsecuentes fases del ciclo de vida de varias maneras. 4.6 Dinamismo de los requerimientos del sistemaLos requerimientos son raramente está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 técnica como al cliente.

5. Descripción del proceso de desarrollo de la SyRS

Esta cláusula proporciona una descripció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 técnica) Cada uno de estos agentes es descrito en la figura siguiente:

Figura 1 - Contexto de desarrollo de SyRS

6. Requerimientos bien formados

Esta cláusula explica las propiedades de un requerimiento bien formado. Provee un ejemplo de un requerimiento bien formado, y señala los errores comunes en los requerimientos.6.1 Definición de un requerimiento bien formadoUn requerimiento bien formado es una declaración de la funcionalidad del sistema que puede ser validada, y que debe ser poseído 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 definición ayuda en la clasificación de los requerimientos generales del cliente. Éstos pueden ser tomados de las necesidades del cliente y pueden ser derivados del análisis técnico. La definició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 restricción no funcional podría ser que el sistema sea pintado con un tono particular de azul solamente para propósitos decorativos.6.2 Propiedades de un requerimientoCada requerimiento debe poseer las siguientes propiedades:a) Abstracto. Cada requerimiento debe ser independiente de su implementación.

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 relación 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 ClasificaciónLos 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 técnica;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 requerimientosMientras 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 extraídos desde los documentos iniciales hasta ejercicios analí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 sólo una vez y que no falta ninguno.7.2 Construir requerimientos bien formadosEl analista realiza esta subfase haciendo lo siguiente:a) Se asegura de que cada requerimiento es una declaración 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 especificación.d) Se asegura de la legilibilidad de los requerimientos.e) Se asegura de que los requerimientos puedan ser probados.7.3 Organizar los requerimientos7.4 Presentar la SyRS7.5 Métodos de representaciónLos métodos de representación pueden incluir uno o una combinación de los siguientes:a) Textuala. Papelb. Electrónicob) Modelos

a. Físicob. Simbólicoc. Graficod. Prototipo

Plantilla para Especificación de Requerimientos de SistemasEsta guía reconoce que existen una gran cantidad de técnicas y formas de comunicar los requerimientos, incluyendo texto y modelos. El propósito de esta plantilla es ayudar a esclarecer el contenido técnico de una SyRS. La representación y contenido puede ser expandido o comprimido para el cliente o la comunidad técnica. Existen muchas representaciones posibles de una SyRS y la siguiente es simplemente un ejemplo.

Tabla de contenidoLista de figurasLista de tablas1. Introducción1.1 Propósito del sistema1.2 Alcance del sistema

1.3 Definiciones, acrónimos y abreviaturas1.4 Referencias1.5 Panorama general2 Descripción general del sistema2.1 Contexto del sistema2.2 Modos y estados del sistema

2.3 Principales capacidades del sistema2.4 Principales condiciones del sistema2.5 Principales restricciones del sistema2.6 Características de los usuarios2.7 Suposiciones y dependencias2.8 Escenarios de operación3. Capacidades, condiciones y restricciones del sistema3.1 Condiciones físicas3.1.1 Construcción3.1.2 Durabilidad3.1.3 Adaptabilidad

3.1.4 Condiciones ambientales3.2 Características de desempeño del sistema3.3 Seguridad3.4 Administración de la información3.5 Operaciones del sistema3.5.1 Factores humanos3.5.2 Mantenibilidad3.5.3 Confiabilidad3.6 Políticas y regulaciones3.7 Ciclo de vida del sistema4. Interfaces del sistema

ISO/IEC 12119-1194

Aplicable a los paquetes de software. Establece requisitos para paquetes de software e instrucciones sobre cómo probar un paquete de software en comparación con estos requisitos. Se las arregla solamente con paquetes de software como brindar y repartir. No se las arregla con su proceso de producción. El sistema de calidad de un proveedor está fuera del alcance de este patrón.

Este tema está preocupado por la estructura, calidad y verificabilidad de los requisitos de documentación. Esto puede tomar la forma de dos documentos, o dos partes de lo mismo documentan con lectores diferentes y propósitos: la especificación de requisitos. El tema hace hincapié en que documentar los requisitos es la condición previa más fundamental para requisitos prósperos responder.

3.4.1 El documento de definición 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 relación con el dominio. Debe poner en una lista los requisitos de sistema al mismo tiempo que la información de fondo sobre los objetivos en conjunto para el sistema, su ambiente de meta y una declaración de las restricciones, suposiciones y requisitos no- funcional. Podría incluir modelos conceptuales diseñados ilustrado el contexto de sistema, los guiones de uso, las entidades de dominio principales, y los datos, la información 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 técnicos, el SRS es acompañado por los requisitos que las definiciones documentan a menudo.

* Esta es una fuerza, una valoración rigurosa de requisitos antes de que diseñe pueda comenzar y reduce rediseño 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 validación y verificación más 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 estándares

Varios recomendaron a guías y los estándares que existen para ayudar definir la estructura de requisitos la documentación. Éstos incluyen a guía de IEEEP1233 / D3, guía 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 padrón reciente para uno documento de definición de requisitos.

3.4.4 La calidad de documento

Esto es un área donde las medidas pueden estar útilmente empleadas en lo requisitos crear ingeniería. Hay atributos tangibles que pueden ser medidos. Además, la calidad del documento de requisitos puede afectar la calidad del producto dramáticamente.

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 aprobación, los rendimiento, programa, reproducibilidad etc. Los indicadores de calidad para SRS, declaraciones individuales incluyen los imperativos, las directivas las frases débiles, las opciones y los aplazamientos. Los indicadores para el SRS documento entero incluyen el tamaño, aprendizaje, la profundidad de especificación y la estructura de texto

Hay una coincidencia de posibilidades con 3.5.1 (la conducción de requisitos repasa) que el Cuadro 5 indica que la calidad de documento vincula con temas de común en otros KAs.

Se vincula a trabajos comunes

Calidad La calidad del análisis afecta la calidad de producto directamente. En principio, el más riguroso el análisis, más confianza poder ser dada a la calidad de software.La calidad de los documentos de requisitos afecta la calidad del producto dramáticamente

Medición Parte del propósito del análisis 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 negociación de vinculaciones a otros KAs.