Вы находитесь на странице: 1из 19

Ingeniera de Software

Docente: I.S.C Jess Muiz Blanco (M.C.A)

Equipo:
Mar Rendn Claudia Estefany
Rodrguez Martnez Patricio
Castillo Rojas Gerardo

3/1/17
Unidad 1:
Anlisis
1.1 REVISIN DE ESPECIFICACIN DE
REQUISITOS.

3/1/17
Especificacin de requisitos: proceso de redaccin o
registro de los requisitos. Se pueden utilizar tanto el
lenguaje natural, como modelos grficos.

El anlisis de requisitos es una de las tareas ms


importantes en el ciclo de vida del desarrollo de software,
puesto que en ella se determinan los planos de la
nueva aplicacin.

3/1/17
Caractersticas de una
buena ERS
1. Correcta: La ERS es correcta si y slo si todo requisito
que figura en ella refleja alguna necesidad real. La
correccin de la ERS implica que el sistema
implementado ser el sistema deseado.
2. No ambigua: Un documento es no ambiguo si y solo
si cada requisito descrito tiene una nica
interpretacin. Cada caracterstica del producto final
debe ser descrita utilizando un trmino nico.
3. Completa:
1. Incluye todos los requisitos significativos del software
(relacionados con la funcionalidad, ejecucin, diseo,
atributos de calidad o interfaces externas).
2. Cumple con el estndar utilizado.
3. Aparecen etiquetadas todas las figuras, tablas, diagramas,
3/1/17 etc., as como definidos todos los trminos y unidades de
4. Verificable: Se dice que es verificable si existe algn
proceso no excesivamente costoso por el cual una
persona o una mquina pueda chequear que el
software satisface dicho requerimiento.
5. Consistente: Una ERS es consistente si y slo si
ningn conjunto de requisitos descritos en ella son
contradictorios o entran en conflicto.
6. Clasificada: Los requisitos pueden clasificarse por
diversos criterios:
1. Importancia: Pueden ser esenciales, condicionales u
opcionales.
2. Estabilidad: Cambios que pueden afectar al requisito
7. Modificable: Una ERS es modificable si cualquier
cambio puede realizarse de manera fcil, completa y
3/1/17
consistente.
8. Explorable: Una ERS es explorable si el origen de cada
requerimiento es claro tanto hacia atrs (origen que
puede ser un documento, una persona etc.) como hacia
delante (componentes del sistema que realizan dicho
requisito).
9. Utilizable durante las tareas de mantenimiento y
uso: En la ERS tambin se deben tener en cuenta las
necesidades de mantenimiento. El personal que no ha
intervenido directamente en el desarrollo debe ser capaz
de encargarse de su mantenimiento. As, dicha ERS acta
a modo de plano de la aplicacin, permitiendo incluso
modificaciones que no requieran un cambio en el diseo.

3/1/17
1.1.1 Norma IEEE830
A continuacin se muestra la estructura de la ERS
propuesta por el IEEE en su estndar 830

3/1/17
1 Introduccin
1.1 Propsito
1.2 mbito del Sistema
1.3 Definiciones, Acrnimos y Abreviaturas
1.4 Referencias
1.5 Visin general del documento
2 Descripcin General
2.1 Perspectiva del Producto
2.2 Funciones del Producto
2.3 Caractersticas de los usuarios
2.4 Restricciones
2.5 Suposiciones y Dependencias
2.6 Requisitos Futuros
3 Requisitos Especficos
3.1 Interfaces Externas
3.2 Funciones
3.3 Requisitos de Rendimiento
3.4 Restricciones de Diseo
3.5 Atributos del Sistema
3.6 Otros Requisitos
4 Apndices
5 ndice
3/1/17
1. Introduccin
En esta seccin se proporcionar una introduccin a todo
el documento de Especificacin de Requisitos Software.
1.1 Propsito
Se definir el propsito del documento ERS y se especificar
a quin va dirigido el documento.
1.2 mbito del Sistema
En esta subseccin se pondr nombre al futuro sistema, se
explicar lo que el sistema har y lo que no har, se
describirn los beneficios, objetivos y metas que se espera
alcanzar con el futuro sistema.
1.3 Definiciones, Acrnimos y Abreviaturas
Se definirn aqu todos los trminos, acrnimos y
abreviaturas utilizadas en el desarrollo de la ERS.

3/1/17
1.4 Referencias
Se presentar una lista completa de todos los documentos
referenciados en la ERS.
1.5 Visin General del Producto
Esta subseccin describir brevemente los contenidos y la
organizacin del resto de la ERS.

3/1/17
2. Descripcin General
En esta seccin se describen todos aquellos factores que
afectan al producto y a sus requisitos. En esta seccin no
se describen los requisitos, sino su contexto.
2.1 Perspectiva del Producto
Esta subseccin debe relacionar el futuro sistema (producto
software) con otros productos. Si el producto es totalmente
independiente de otros productos, tambin debe
especificarse aqu
2.2 Funciones del Producto
Se debe proporcionar un resumen de las funciones principales
que el software debe llevar a cabo. Las funciones deben estar
organizadas de manera que el cliente o cualquier otra
persona lo entienda perfectamente.

3/1/17
2.3 Caractersticas de los usuarios
Se indica aqu el tipo de usuario al que se dirige la aplicacin, as
como su experiencia tcnica, nivel de conocimientos, etc.
2.4 Restricciones
Se debe indicar aqu cualquier tipo de limitacin como pueden ser
polticas de la empresa, limitaciones hardware, seguridad,
protocolos de comunicacin, interfaces con otras aplicaciones,
estndares de la empresa en cuanto a interfaces, etc.
2.5 Suposiciones y Dependencias
En este apartado aparecer cualquier factor, que si cambia puede
afectar a los requerimientos.
2.6 Requisitos Futuros
Se indican aqu posibles mejoras del sistema en el futuro.

3/1/17
3. Requisitos
Especficos
Esta seccin contiene todos los requerimientos hasta un nivel de
detalle suficiente para permitir a los diseadores disear un
sistema que satisfaga dichos requisitos, y que permita disear
las pruebas que ratifiquen que el sistema cumple con las
necesidades requeridas.
3.1 Interfaces Externas
Se definirn los requisitos que afecten a la interfaz de usuario e
interfaz con otros sistemas (hardware y software), as como a
interfaces de comunicaciones.
3.2 Funciones
Se deben especificar todas aquellas acciones o funciones que deber
llevar a cabo el sistema a desarrollar. Las acciones que se indican
como el sistema deber ... son las que deben incluirse en este
apartado.

3/1/17
3.3 Requisitos de Rendimiento
incluyen los requisitos relacionados con la carga que se
espera que tenga que soportar el sistema (nmero de
usuarios simultneos, nmero de terminales ...).
3.4 Restricciones de Diseo
Se incluyen todas las restricciones que afecten al diseo de la
aplicacin, como pueden ser estndares internos de la
organizacin, limitaciones hardware, etc.
3.5 Atributos del Sistema
Se detallan atributos como la fiabilidad, mantenibilidad,
seguridad, mecanismos de acceso restringido, usuarios
autorizados.
3.6 Otros requisitos
Aquellos requerimientos que no se hayan podido incluir en
ninguna de las secciones anteriormente especificadas.
3/1/17
4. Apndices
Se incluir aqu cualquier tipo de informacin relacionada
con la ERS, pero que no forme parte de la misma. Por
ejemplo, se incluiran los resultados del anlisis de costes,
restricciones especiales acerca del lenguaje de
programacin, etc.

3/1/17
5. ndice
Se proporciona un ndice para poder tener un acceso
rpido a la documentacin presentada en la ERS.

3/1/17
1.1.2Trazabilidad de
requisitos
La trazabilidad en la Ingeniera de Software es una
prctica de control que ayuda a obtener el producto en el
dominio de la solucin lo ms exacto y fiable posible a las
necesidades expresadas por el cliente en el dominio del
problema.
Segn el estndar IEEE 830-1998, la trazabilidad es la
habilidad para seguir la vida de un requerimiento en
ambos sentidos, hacia sus orgenes o hacia su
implementacin a travs de las especificaciones
generadas durante el proceso de desarrollo. Es un factor
de calidad.

3/1/17
Referencias
Hernndez Reyes, J. M., & Enrquez Ramrez, C. (2013).
Sistema de control de trazabilidad de requerimientos en
ambientes giles de desarrollo de software. Abril,
Tulancingo, Hidalgo, Mxico: Universidad Politcnica de
Tulancingo. Recuperado el 04 de Febrero de 2017
Monferrer Agut, R. (2001). Especificacin de Requisitos
Software segn el estndar de IEEE 830. Recuperado el 05
de Febrero de 2017

3/1/17
GRACIAS POR SU ATENCIN

3/1/17

Вам также может понравиться