P. 1
Requerimientos Funcionales y No Funcionales

Requerimientos Funcionales y No Funcionales

|Views: 801|Likes:
Publicado porNoe Gonzalez

More info:

Published by: Noe Gonzalez on Feb 15, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/15/2013

pdf

text

original

Requerimientos del Software

Definición
Tipos
Requerimientos no funcionales

Requerimientos
Requerimientos del software
(del sistema software)
Requerimientos del sistema basado en
computadoras
(requerimientos del sistema)

Requerimientos del Software
Definición:
Propiedad o restricción, determinada con
precisión, que un producto software debe
satisfacer

¿Qué es un requerimiento?
• Puede variar desde una declaración abstracta de alto
nivel de un servicio o de la restricción de un sistema,
hasta una especificación funcional matemática detallada.
Esto es inevitable ya que los requerimientos tienen doble
función
• Puede ser la base de un intento de contrato
Puede ser la base para el contrato en sí - entonces debe ser
definido con detalle
Ambas declaraciones deben ser llamadas requerimientos
!!:>Jan Soltlltlervtlle 2004 Sollwarp [nginPPring, 7th OOition. ChaptPr 6 Sl!de 5

Abstracción de los requerimientos
(O avis)
· una compañía desea establecer un contrato para el desarrollo de un proyecto de software. debe de±itúr sus
· de una fonna suficientemente abstracta como para establecer a partir de ella una solución. Los
req¡uemJlllentcls deben redactarse de tal forma que varios contratistas puedan licitar el contrato, ofi·eciendo,
formas diferentes de cumplir las necesidades de los clientes en la orgatúzación. Una vez que el
conttralto se asigna, el contratista debe redactar una definición de sistema para el cliente de forma que éste
cot:nprencla y pueda validar lo que hará el software. Ambos docmnentos se denonúnan el "el documento de
req¡ueríntúentcls para el sistema"

Imprecisión de requerimientos
• Los problemas surgen cuando los
requerimientos no se exponen detalladamente.
• Los requerimientos ambiguos pueden ser
interpretados de diferentes formas por
promotores y usuarios.
• Considera el término' espectador apropiado'
• Intención del usuario - Espectador con un propósito
especial para cada tipo de documento diferente
• Interpretación del promotor- Proporciona un visor de
texto que muestra los contenidos del documento.
©Jan Sonunerville 2(04 Software Engineering, 7th edition. Chapter 6 Slide 14

(software)
(de alto nivel)

Defi nición de requerimientos del usuario
1. lEI software debe proveer un medio para representar y acceder a
archivos externos creados por otras herramientas
Especificación de los requerimientos del sistema
1.1 Al usuario se le proveerá con los recursos para definir el tipo de
Cl rt:.hivos externos
1.2 Cada tipo de archivo externo tendrá una herramienta asociada que
~ ; e : - á aplicada al archivo
1.31.3 Cada tipo de archivo externo se representará como un icono
esi)ecífico sobre la pantalla del usuario
1.4 Se proveerán recursos para que el usuario defina el icono que
re9resenta un tipo de archivo externo
1.5 Cuando un usuario selecciona un icono que representa un archivo
eJ<\erno, el efecto de esa selección es aplicar la herramienta asociada con
t!:>(e t ipo de archivo al archivo representado por el icono seleccionado

Requerimientos del Software
Tipos:
Funcionales
No funcionales

Requerimientos funcionales y no funcionales
Requerimientos funcionales
• Declaración de servicios que el sistema debería proporcionar,
como debería reaccionar el sistema a determinadas entradas y
cómo debería comportarse en situaciones particulares.
Requerimientos no funcionales
• Restricciones de los servicios o funciones ofrecidas por el
sistema como restricciones de encendido, restricciones en el
proceso de desarrollo, estándares, etc.
Requerimientos del dominio
• Restricciones que provienen del dominio de aplicación del
sistema y que reflejan las características del dominio .
©Ian SonuneiVille 2004 Software Engineering, 7th edition. Chapter 6 Slide 10

Requerimientos funcionales
expresan la esencia del sitema software:
interacción con el entorno
estados posibles
evolución

Requerimientos funcionales
• Describen la funcionalidad o los servicios del
sistema
• Depende del tipo de software, Los usuarios
esperados y el tipo de sistema en que el
software se va a usarse.
• Los requerimientos del usuario funcional pueden
ser declaraciones de muy alto nivel sobre lo que
el sistema debería hacer, pero los
requerimientos funcionales del sistema deberían
describir los servicios del sistema con detalle.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 11

Requerimientos no funcionales
restringen el espacio de posibles soluciones


Ejemplos de requerimientos funcionales
.-.- . .· -·
• El usuario debe ser capaz de buscar o todos los
conjuntos iniciales de bases de datos, o seleccionar un
subconjunto de él.
• El sistema debe proporcionar visores para que el usuario
lea los documentos el el depósito de documentos.
• A cada orden se le debe asignar un único identificador
(ORDER_ID) que el usuario debe ser capaz de copiar en
el área de almacenamiento permanente de la cuenta.
©Ian rville 2004 Software Engineering, 7th edition. Chapter 6 Slide 13

Requerimientos no funcionales
• Estos definen las propiedades y restricciones del
sistema, p.Ej .: confiabilidad, tiempo de respuesta y
requerimientos de almacenamiento. Las restricciones
son la capacidad del mecanismo Entrada/Salida,
representaciones del sistema, etc.
• Los requerimientos también pueden ser especificados
asignando sistemas CASE particulares, programando un
lenguaje o desarrollando un método.
• Los requerimientos no funcionales pueden ser más
críticos que los funcionales. Si estos no se cumplen, el
sistema es inservible.
©Ian SommeiVille 2004 Software Engineering, 7th edition. Cbapter 6 Slide 16

Requerimientos no funcionales
relativos a la interface
de desempeño y seguridad
Desarrollo
Operación
políticos

Requerimientos no funcionales
relativos a la interface
entorno operativo: hardware, sistema
operativo, de red, ...
ergonómicos
formatos intercambio información

Requerimientos no funcionales
de desempeño y seguridad
tiempos de respuesta,
capacidad de proceso,
espacio de almacenamiento
fiabilidad
seguridad
tolerancia a fallos
supervivencia

Requerimientos no funcionales
Desarrollo
producto
mantenibilidad
flexibilidad
reusabilidad
compatibilidad
integración
proceso
tiempo de desarrollo
disponibilidad de recursos
estándares de desarrollo

Requerimientos no funcionales
Operación
nivel preparación usuarios
accesibilidad para mantenimiento
distribución espacial de componentes

Requerimientos no funcionales
Políticos
Sin otra justificación que la voluntad de las
personas

Clasificaciones no funcionales
Requerimientos del producto
• Requerimientos que especifican que el producto entregado
debe comportarse de una manera determinada. P.Ej .:
Velocidad de ejecución, confiabilidad, etc.
Requerimientos organizacionales
• Requerimientos que son una consecuencia de las políticas y
procedimientos organizacionales. P.Ej.: estándares de proceso
usados, requerimientos de implementación, etc.
Requerimientos externos
• Los requerimientos que surgen de los factores que son
externos al sistema y su proceso de desarrollo. P.Ej. :
interoperabilidad, requerimientos, requerimientos legislativos,
etc.
©Ian SommeiVille 2004 Software Engineering, 7th edition. Chapter 6 Slide 17

Tipos de requerimientos no
funcionales
Requerimientos
No funcionales
Requerimientos
Requerimientos Requerimiento
Del producto
organizacionale s externos
Requerimientos
Requerimiento
~
Requerimlen} Requerimientos
de fiabilidad e pOitabilidad de
éticos
1
Requerimientos Requerimiento Requerimientos Requerimient Requerimientos
de utilidaj de entrega de s de legislativos
. . .
Requerimientos
Requerimientos Requerimientos e Requerimientos d
de desempleo
-
de espacio privacidad eguridad

Ejemplos de requerimientos no
funcionales
Requerimiento del producto
8.1 La interfaz del usuario para LIBSYS deberá ser implementada como
HTML simple sin marcos o applets java.
Requerimiento organizativo
9.3.2 El proceso de desarrollo del sistema y los documentos a entregar
debe ajustarse al proceso y a los productos a entregar definidos en
el XYZCo-SP-STAN-95
Requerimiento externo
7.6.5 El sistema no deberá revelar a sus operadores alguna información
personal de los clientes excepto su nombre y su número de
referencia
©13ll So lle 2004 Soflwarl' Enginf.>t'ring, 7th Edition. Chaptt>r 6 Shde 19

Metas y requerimientos
• Puede ser muy difícil plantear los requerimientos no
funcionales de forma precisa, y puede ser muy difícil
verificar los requerimientos imprecisos.
meta
• Es una intención general del usuario como facilidad de uso.
Requerimiento verificable no funcional
• Una instrucción que utiliza alguna medida que puede ser
probada objetivamente
Las metas son útiles para los desarrolladores ya que
transmiten las intenciones de los usuarios del sistema.
©Jan 2(04 Software Engineering, 7th Mition. Chapter 6 Sl!de 20


Propiedad
Velocidad
Tamaño
F aeilidad de. uso
Confi abilidad
Robustez
Portabilidad
transacciones procesadas por segundo
Tiempo de respuesta al usuario y a eventos
Tiempo de actualización de la pantalla
M Bytes
Número de chipsde ROM
Tiempo de formación
Número de marcos de ayuda
Tiempo medio entre fallos
Probabilidad de no disponibilidad
Tasa de oeurrenc.ia de fallos
disponibilidad
tiempo de reinicio después de fallo
Porcentaje de eventos que causan fallos
Probabilidad de com1pción de datos después de t Ul
fallo
Porcentaje de declaraciones dependientes de
objetivo

Interacción de los requerimientos
• Conflictos entre diferentes requerimientos no
funcionales son comunes en sistemas complejos
• Sistema de nave espacial
• Para minimizar el peso, el número de chips
separados en el sistema debería ser minimizado.
• Para minimizar el consumo de energía, se deberían
usar chips de baja potencia.
• No obstante, usar chips de baja potencia puede
implicar tener que usar más chips. ¿Cuál es el
requerimiento más importante?
©Jan Sonunerville 2C04 Software Engineering, 7th edition. Chapter 6 Slide 23

Requerimientos del dominio
• Se derivan del dominio de la aplicación y
describen características y rasgos del sistema
que reflejan el dominio.
• Los requerimientos del dominio son nuevos
requerimientos funcionales, restricciones de
requerimientos existentes o bien definen
computaciones específicas.
• Si los requerimientos del dominio no se
satisfacen, es sistema puede ser impracticable.
©Ian SommeiVille 2C04 Software Engineering, 7th edition. Chapter 6 Slide 24

Requerimientos del dominio del
sistema de biblioteca
• Deberá existir una interfaz del usuario estándar para
todas las bases de datos, la cual tome como referencia
el estándar Z39.50
• Debido a las restricciones en los derechos de autor,
algunos documentos deberán borrarse inmediatamente
después de su llegada. Dependiendo de los
requerimientos del usuario, estos documentos se
imprimirán de forma local en el servidor del sistema para
ser distribuidos de forma manual al usuario o enviarse a
la impresora de la red.
©Jan Sonunerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 25

Sistema de protección de trenes
• La deceleración del tren se calculará como:
• O =O +O
tren control pendiente
donde O pendiente es 9.81 ms
2
* pendiente
compensada/alfa y donde los valores de 9.8
ms
2
arta se conocen para diferentes tipos de
trenes.
Clan So e 2004 Software Engineering, 7th edition. Cbapter 6
Shde 26

Requerimientos del Software

Definición Tipos Requerimientos no funcionales

Requerimientos
Requerimientos del software
(del sistema software)

Requerimientos del sistema basado en computadoras
(requerimientos del sistema)

Requerimientos del Software Definición: Propiedad o restricción. determinada con precisión. que un producto software debe satisfacer .

ChaptPr 6 Sl!de 5 . 7th OOition.entonces debe ser definido con detalle Ambas declaraciones deben ser llamadas requerimientos !!:>Jan Soltlltlervtlle 2004 Sollwarp [nginPPring.¿Qué es un requerimiento? • Puede variar desde una declaración abstracta de alto nivel de un servicio o de la restricción de un sistema. hasta una especificación funcional matemática detallada. Esto es inevitable ya que los requerimientos tienen doble función • Puede ser la base de un intento de contrato Puede ser la base para el contrato en sí .

Ambos docmnentos se denonúnan el "el documento de req¡uerínt entcls para el sistema" ú . Los req¡uemJlllentcls deben redactarse de tal forma que varios contratistas puedan licitar el contrato. el contratista debe redactar una definición de sistema para el cliente de forma que éste cot:nprencla y pueda validar lo que hará el software.~ . ofi·eciendo. debe de±itúr sus · de una fonna suficientemente abstracta como para establecer a partir de ella una solución. formas diferentes de cumplir las necesidades de los clientes en la orgatúzación. quJtLa. Una vez que el conttralto se asigna.Abstracción de los requerimientos (O avis) · una compañía desea establecer un contrato para el desarrollo de un proyecto de software.

Chapter 6 Slide 14 . 7th edition. • ©Jan Sonunerville 2(04 Software Engineering.Espectador con un propósito especial para cada tipo de documento diferente Interpretación del promotor.Proporciona un visor de texto que muestra los contenidos del documento. Considera el término' espectador apropiado' • • Intención del usuario . Los requerimientos ambiguos pueden ser interpretados de diferentes formas por promotores y usuarios.Imprecisión de requerimientos • • Los problemas surgen cuando los requerimientos no se exponen detalladamente.

(de alto nivel) (software) .

Definición de requerimientos del usuario 1.hivos externos 1.4 Se proveerán recursos para que el usuario defina el icono que re9resenta un tipo de archivo externo 1.e:-á aplicada al archivo 1. el efecto de esa selección es aplicar la herramienta asociada con t!:>(e t ipo de arch ivo al archivo representado por el icono seleccionado . lEI software debe proveer un medio pa ra representar y acceder a archivos externos creados por otras herramientas Especificación de los requerimientos del sistema 1.5 Cuando un usuario selecciona un icono que representa un archivo eJ<\erno.1 A l usuario se le proveerá con los recursos para defin ir el tipo de Clrt:.31.2 Cada tipo de archivo externo tendrá una herramienta asociada que ~.3 Cada tipo de archivo externo se representará como un icono esi)ecífico sobre la pantalla del usuario 1.

Requerimientos del Software Tipos: Funcionales No funcionales .

como debería reaccionar el sistema a determinadas entradas y cómo debería comportarse en situaciones particulares.Requerimientos funcionales y no funcionales Requerimientos funcionales • Declaración de servicios que el sistema debería proporcionar. 7th edition. restricciones en el proceso de desarrollo. Restricciones de los servicios o funciones ofrecidas por el sistema como restricciones de encendido. Chapter 6 Slide 10 . Requerimientos no funcionales • Requerimientos del dominio • ©Ian SonuneiVille 2004 Software Engineering. Restricciones que provienen del dominio de aplicación del sistema y que reflejan las características del dominio . estándares. etc.

Requerimientos funcionales expresan la esencia del sitema software: interacción con el entorno estados posibles evolución .

Los usuarios esperados y el tipo de sistema en que el software se va a usarse. 7th edition. Chapter 6 Slide 11 .Requerimientos funcionales • • Describen la funcionalidad o los servicios del sistema Depende del tipo de software. pero los requerimientos funcionales del sistema deberían describir los servicios del sistema con detalle. Los requerimientos del usuario funcional pueden ser declaraciones de muy alto nivel sobre lo que el sistema debería hacer. • ©Ian Sommerville 2004 Software Engineering.

Requerimientos no funcionales restringen el espacio de posibles soluciones .

.

. .Ejemplos de requerimientos funcionales . A cada orden se le debe asignar un único identificador (ORDER_ID) que el usuario debe ser capaz de copiar en el área de almacenamiento permanente de la cuenta. Chapter 6 Slide 13 .-. El sistema debe proporcionar visores para que el usuario lea los documentos el el depósito de documentos. • • ©Ian rville 2004 Software Engineering. 7th edition.·-· • El usuario debe ser capaz de buscar o todos los conjuntos iniciales de bases de datos.. o seleccionar un subconjunto de él.

Cbapter 6 Slide 16 . etc. tiempo de respuesta y requerimientos de almacenamiento.: confiabilidad. Los requerimientos también pueden ser especificados asignando sistemas CASE particulares. el sistema es inservible. representaciones del sistema.Requerimientos no funcionales • Estos definen las propiedades y restricciones del sistema. programando un lenguaje o desarrollando un método. 7th edition.Ej . p. Si estos no se cumplen . • • ©Ian SommeiVille 2004 Software Engineering. Las restricciones son la capacidad del mecanismo Entrada/Salida. Los requerimientos no funcionales pueden ser más críticos que los funcionales.

Requerimientos no funcionales relativos a la interface de desempeño y seguridad Desarrollo Operación políticos .

de red. ergonómicos formatos intercambio información .. ..Requerimientos no funcionales relativos a la interface entorno operativo: hardware. sistema operativo.

espacio de almacenamiento fiabilidad seguridad tolerancia a fallos supervivencia .Requerimientos no funcionales de desempeño y seguridad tiempos de respuesta. capacidad de proceso.

Requerimientos no funcionales Desarrollo producto mantenibilidad flexibilidad reusabilidad compatibilidad integración proceso tiempo de desarrollo disponibilidad de recursos estándares de desarrollo .

Requerimientos no funcionales Operación nivel preparación usuarios accesibilidad para mantenimiento distribución espacial de componentes .

Requerimientos no funcionales Políticos Sin otra justificación que la voluntad de las personas .

Los requerimientos que surgen de los factores que son externos al sistema y su proceso de desarrollo. etc.: estándares de proceso usados. P. : interoperabilidad.: Velocidad de ejecución.Ej. Requerimientos organizacionales • Requerimientos externos • ©Ian SommeiVille 2004 Software Engineering. requerimientos. etc. etc. Requerimientos que son una consecuencia de las políticas y procedimientos organizacionales.Clasificaciones no funcionales Requerimientos del producto • Requerimientos que especifican que el producto entregado debe comportarse de una manera determinada. 7th edition. Chapter 6 Slide 17 . requerimientos legislativos. P.Ej. requerimientos de implementación.Ej. confiabilidad. P.

Requerimientos legislativos Requerimientos de desempleo Requerimientos . Requerimient s de .de espacio Requerimientos e Requerimientos d privacidad eguridad ..Tipos de requerimientos no funcionales Requerimientos No funcionales Requerimientos Del producto Requerimientos organizacionale Requerimiento s externos ~ Requerimientos de utilidaj Requerimlen} de fiabilidad R equerimientos e pOitabilidad Requerimientos de Requerimiento éticos 1 Requerimiento de entrega Requerimientos de .

>t'ring. Requerimiento organizativo 9.3.6.1 La interfaz del usuario para LIBSYS deberá ser implementada como HTML simple sin marcos o applets java.5 El sistema no deberá revelar a sus operadores alguna información personal de los clientes excepto su nombre y su número de referencia ©13ll So lle 2004 Soflwarl' Enginf. 7th Edition. Chaptt>r 6 Shde 19 .Ejemplos de requerimientos no funcionales Requerimiento del producto 8.2 El proceso de desarrollo del sistema y los documentos a entregar debe ajustarse al proceso y a los productos a entregar definidos en el XYZCo-SP-STAN-95 Requerimiento externo 7.

7th Mition. Una instrucción que utiliza alguna medida que puede ser probada objetivamente Requerimiento verificable no funcional Las metas son útiles para los desarrolladores ya que transmiten las intenciones de los usuarios del sistema.Metas y requerimientos • Puede ser muy difícil plantear los requerimientos no funcionales de forma precisa. Chapter 6 Sl!de 20 . meta • • Es una intención general del usuario como facilidad de uso. ©Jan S~ommeJVille 2(04 Software En gineering. y puede ser muy difícil verificar los requerimientos imprecisos.

.

Propiedad Velocidad transacciones procesadas por segundo Tiempo de respuesta al usuario y a eventos Tiempo de actualización de la panta lla M Bytes Número de chipsde ROM Tiempo de formación Número de marcos de ayuda Tiempo medio entre fallos Probabilidad de no disponibilidad Tasa de oeurrenc.ia de fallos disponibilidad tiempo de reinicio después de fallo Porcentaje de eventos que causan fallos Probabilidad de com1pción de datos después de fallo Porcentaje objetivo de declaraciones dependientes Tamaño Faeilidad de. uso Confiabilidad Robustez tUl Portabilidad de .

Para minimizar el consumo de energía. 7th edition. ¿Cuál es el requerimiento más importante? ©Jan Sonunerville 2C04 Software Engineering. No obstante. se deberían usar chips de baja potencia. Chapter 6 Slide 23 .Interacción de los requerimientos • Conflictos entre diferentes requerimientos no funcionales son comunes en sistemas complejos • Sistema de nave espacial • • • Para minimizar el peso. usar chips de baja potencia puede implicar tener que usar más chips. el número de chips separados en el sistema debería ser minimizado.

Si los requerimientos del dominio no se satisfacen. Los requerimientos del dominio son nuevos requerimientos funcionales. restricciones de requerimientos existentes o bien definen computaciones específicas. • • ©Ian SommeiVille 2C04 Software Engineering.Requerimientos del dominio • Se derivan del dominio de la aplicación y describen características y rasgos del sistema que reflejan el dominio. 7th edition. es sistema puede ser impracticable. Chapter 6 Slide 24 .

la cual tome como referencia el estándar Z39. 7th edition. Chapter 6 Slide 25 . Dependiendo de los requerimientos del usuario. • ©Jan Sonunerville 2004 Software Engineering.Requerimientos del dominio del sistema de biblioteca • Deberá existir una interfaz del usuario estándar para todas las bases de datos.50 Debido a las restricciones en los derechos de autor. estos documentos se imprimirán de forma local en el servidor del sistema para ser distribuidos de forma manual al usuario o enviarse a la impresora de la red. algunos documentos deberán borrarse inmediatamente después de su llegada.

81 ms2 * pendiente compensada/alfa y donde los valores de 9. 7th edition.Sistema de protección de trenes • La deceleración del tren se calculará como: • Otren =Ocontrol +Opendiente donde Opendiente es 9.8 ms2 arta se conocen para diferentes tipos de trenes. Cbapter 6 Shde 26 . Clan So e 2004 Software Engineering.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->