Cap 6

novenoa.cis@unl.edu.
ec
Requerimientos del software
Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 6
Slide 1
Objetivos
Introducir los conceptos de requerimientos del usuario y sistema Describir los requerimientos funcionales y no funcionales Explicar la forma en que los requerimientos de software pueden ser organizados en un documento de requerimientos de software
Slide 2
T picos expuestos

I! Requerimientos funcionales y no funcionales II! Requerimientos del usuario III! Requerimientos del sistema I"! Especificaci n de la interfaz "! El documento de requerimientos de software
Slide 3
Ingenier#a de requerimientos $RE%
&os requerimientos son la descripci n de los servicios del sistema y las limitaciones $restricciones% que se generan durante el proceso de ingenier#a de requerimientos! 'roceso de( Descubrir, analizar, documentar y verificar los servicios y restricciones, se denomina (RE)
Slide 4
)u* es un requerimiento+

,na necesidad de los clientes-usuarios 'uede ir desde una declaraci n de un servicio con un alto nivel de abstracci n o de una limitaci n de *sta abstracci n $Requerimientos del ,suario% .asta( una definici n detallada y formal de una funci n del sistema $Requerimientos del /istema% &os requerimientos pueden servir una doble funci n 0 'uede ser la base para una oferta para un contrato por lo tanto debe estar abierto a la interpretaci n1 0 'uede ser la base del contrato en s# - por lo tanto2 debe definirse en detalle1 0 3mbas declaraciones pueden llamarse requerimientos!
Software Engineering, 7th edition. Chapter 6 Slide 5
3bstracci n de requerimientos $Davis%
Slide 6
Tipos de requerimientos
Requerimientos de usuario 0 Declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y sus limitaciones o restricciones! Escrito para los clientes! Requerimientos del sistema 0 ,n documento estructurado que establece la descripci n detallada de las funciones del sistema2 los servicios y las limitaciones operacionales! Define exactamente que es lo que se va a implementar2 de manera que puede ser parte de un contrato entre el cliente y el contratista!
Slide 7
Tipos de requerimientos
Slide 8
Definiciones y especificaciones
Slide 9
Requisitos de los lectores
Slide 10
Requerimientos funcionales y no funcionales

&os requerimientos se clasifican en(
&os requerimientos funcionales 0 Declaraciones de los servicios que debe proporcionar el sistema2 la forma en que el sistema debe reaccionar a las entradas y la forma en que el sistema debe comportarse en situaciones particulares! (Describe lo que el sistema debe hacer) Requerimientos no funcionales 0 limitaciones o Restricciones en los servicios o funciones ofrecidas por el sistema como de tiempo2 limitaciones en el proceso de desarrollo2 normas2 etc Los requerimientos no funcionales ponen lmites y
restricciones al sistema.
Requerimientos del dominio 0 Requerimientos que se derivan del dominio de aplicaci n del sistema y que reflejan las caracter#sticas de ese dominio!
Requerimientos funcionales y no funcionales
Slide 12
&os requerimientos funcionales

Describir las funciones o servicios del sistema! Depender4 del tipo de software2 de los posibles usuarios y del enfoque para redactar los requerimientos &os requerimientos funcionales de los usuarios se5alan a un alto nivel de abstracci n lo que el sistema debe 6acer2 pero los requerimientos funcionales del sistema deben describir los servicios del sistema de forma detallada!
Slide 13
El sistema &I7/8/
,n sistema de bibliotecas que proporciona una 9nica interfaz para una serie de bases de datos de art#culos en diferentes bibliotecas! &os usuarios pueden buscar2 descargar e imprimir estos art#culos para su estudio personal!
Slide 14
Ejemplos de requerimientos funcionales

:!El usuario ser4 capaz de buscar2 ya sea la totalidad de la serie inicial de las bases de datos o seleccionar un subconjunto de ella! ;! El sistema deber4 proporcionar vistas apropiadas para que el usuario pueda leer los documentos en la tienda de documentos! <! 3 cada orden se le asignar4 un identificador 9nico $ORDE=>ID% que el usuario ser4 capaz de copiar a la cuenta del 4rea de almacenamiento permanente!
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 15
Imprecisi n de los requerimientos
&os problemas surgen cuando los requerimientos no son declarados con precisi n! Requerimientos ambiguos pueden interpretarse de diferentes maneras por los desarrolladores y usuarios! ?onsiderar el t*rmino @visores apropiadosA Req ;
0 0 Intenci n del usuario - visor de prop sito especial para cada tipo de documento diferente1 Interpretaci n del desarrollador - 'roporcionar un visor de texto que muestra el contenido del documento! $'uede
afirmar que 6a cumplido con el requerimiento%
Slide 16
Integridad de requerimientos y consistencia
En principio2 los requerimientos deben estar completos y ser consistentes! ?ompletitud 0 Todos los servicios solicitados por el usuario deben estar definidos! ?onsistencia 0 =o deber#a 6aber conflictos o contradicciones en las descripciones de los requerimientos del sistema! En la pr4ctica2 es imposible producir un documento de requerimientos completo y consistente!
Slide 17
Requerimientos no funcionales
Estos definen las propiedades emergentes del sistema y las limitaciones2 por ejemplo fiabilidad2 tiempo de respuesta y los requerimientos de almacenamiento! &as limitaciones son2 capacidad de dispositivos de E B /2 representaciones del sistema2 etc! Relacionados con las propiedades emergentes( Rendimiento2 protecci n2 disponibilidad2 etc /on mas cr#ticos que los requerimientos funcionales2 es decir se puede trabajar con una funci n q no cumple sus necesidades2 pero el incumplimiento de un requer! =o funcional puede 6acer q el sistema sea inutilizable!
Slide 18
Requerimientos no funcionales
&os req no funcionales tambi*n intervienen en el 'RO?E/O de desarrollo( 'or ejemplo(

0 0 Especificaci n de est4ndares de calidad Especificaci n que el dise5o debe producir una ?3/E
&os req no funcionales surgen de las necesidades del usuario2 como( prepuesto2 pol#ticas de la organizaci n2 interoperabilidad con otros sistemas de /B.2 factores externos como regulaciones de seguridad o legislaciones sobre privacidad!
Slide 19
Tipos de requerimientos no funcionales
Requerimientos del producto

0 Requerimientos que especifican que el producto entregado debe comportarse de una manera particular2 por ejemplo la velocidad de ejecuci n2 la fiabilidad2 etc Requerimientos que son consecuencia de las pol#ticas de la organizaci n y procedimientos como2 por ejemplo2 est4ndares de procesos utilizados2 requerimientos de implementaci n2 etc! Requisitos que derivan de factores que son externos al sistema y su proceso de desarrollo2 por ejemplo2 los requerimientos de interoperabilidad2 los requerimientos legislativos2 etc
Requerimientos organizacionales
0
Requerimientos externos
0
Slide 20
Tipos de requerimientos no funcionales
Slide 21
Ejemplos de requerimientos no funcionales
Requerimientos del producto

C!: &a interfaz de usuario para &I7/8/ se ejecutar4 como .TD& simple sin marcos o applets de Eava!
Requerimientos organizacionales
F!<!; El proceso de desarrollo del sistema y la entrega de documentos se ajustar4 conforme al proceso y entregas definidos en G8H?o-/'/T3=-FI!
Requerimientos externos
J!K!I El sistema no podr4 divulgar cualquier informaci n personal sobre los clientes2 aparte de su nombre y n9mero de referencia a los operadores del sistema!
Slide 22
Detas y requerimientos
&os requerimientos no funcionales pueden ser muy dif#ciles de precisar y requerimientos imprecisos pueden ser dif#ciles de verificar! &os usuarios o clientes declaran a estos requerimientos como metas Deta
0 ?omo la facilidad de uso del sistema2 capacidad para recuperarse a fallos2 respuestas2 etc!
&as metas son provec6osas para los desarrolladores pues transportan las intenciones de los usuarios del sistema!
Slide 23
Ejemplo $/ist! De ?ontrol de tr4fico 3*reo%
Una meta del sistema

0 El sistema deber#a ser f4cil de utilizar por los controladores con experiencia2 y debe organizarse de tal manera que se reduzcan al m#nimo los errores de usuario! ?ontroladores experimentados deber4n ser capaces de utilizar todas las funciones del sistema despu*s de un total de dos 6oras de formaci n! Despu*s de esta formaci n2 el n9mero promedio de errores cometidos por los usuarios experimentados no deber4 exceder de dos por d#a!
Un requerimiento no funcional verificable

0
Slide 24
D*tricas para especificar requerimientos no funcionales
Slide 25
Requerimientos del dominio
/e derivan del dominio de la aplicaci n del sistema y reflejan los fundamentos del dominio de la aplicaci n! 'ueden ser requerimientos funcionales nuevos2 restringir los existentes o establecer c mo se deben ejecutar c4lculos particulares! /i los requerimientos del dominio no se satisfacen2 puede ser imposible 6acer que el sistema funcione de forma satisfactoria!
Requerimientos del dominio de un sistema de biblioteca
/e establece un est4ndar de interfaz de usuario para todas las bases de datos que se basar4 en la norma H<F!IL! Debido a restricciones de derec6os de autor2 algunos de los documentos deber4n suprimirse de inmediato a su llegada! Dependiendo de las exigencias del usuario2 estos documentos se imprimir4n localmente en el servidor del sistema para su distribuci n manual al usuario o enviarse a una impresora de red!
Slide 27
/istema de protecci n del tren
&a desaceleraci n del tren se calcular4 como(

0 Dtren M Dcontrol N Dgradiente
Donde Dgradiente M F!C:ms; O gradiente compensado B alfa y donde los valores de F!C:ms; B alfa son conocidos para los diferentes tipos de tren!
Slide 28
'roblemas de los requerimientos del dominio
?omprensibilidad
0 0 &os requerimientos son expresados en el lenguaje del dominio de la aplicaci n1 Esto a menudo no es entendido por los ingenieros de software que desarrollan el sistema! &os expertos en el dominio pueden dejar fuera de un requerimiento informaci n2 sencillamente porque para ellos es obvia2 por lo que no piensan en 6acer expl#citos los requerimientos del dominio!
&o impl#cito
0
Slide 29
Slide 30
II Requerimientos del usuario
Deben describir los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no tienen conocimientos t*cnicos detallados! /e especifican el comportamiento externo del sistema2 evitando las caracter#sticas del dise5o del sistema! &os requerimientos del usuarios se definen utilizando lenguaje natural2 tablas y diagramas que puedan ser comprendidas por todos los usuarios!
Slide 31
'roblemas con el lenguaje natural
Palta de claridad
0 Es dif#cil utilizar el lenguaje de forma precisa sin 6acer el documento poco conciso y dif#cil de leer! &os requerimientos funcionales y no funcionales tienden a ser mezclados! "arios requerimientos diferentes2 pueden expresarse de manera conjunta!
?onfusi n de requerimientos
0
?onjunci n de requerimientos
0
Slide 32
Requerimiento de usuario para un sistema de compatibilidad &I7/8/

EJEMPLO: 4 .. 5 LIBSYS presentar un sistema de contabilidad financiera, que mantiene registros de todos los pagos efectuados por los usuarios del sistema. Los administradores del sistema pueden configurar el sistema para que los usuarios habituales puedan recibir tarifas de descuento. Problema: El requerimiento incluye tanto informacin conceptual como detallada
Slide 33
Requerimiento de usuario para un editor de cuadr#cula

Ejemplo de Confusin de requerimientos: Requerimientos para una herramienta CASE de modelos de diseo de software
2.6 Recursos de la cuadrcula. Para ayudar a la ubicacin de entidades en un diagrama, el usuario puede activar una cuadrcula en centmetros o pulgadas, a travs de una opcin en el panel de control. Inicialmente, la cuadrcula est desactivada. La cuadrcula se puede activar y desactivar en cualquier momento durante una sesin de edicin y poner en pulgadas y centmetros. La opcin de cuadrcula se proporcionar en vista de reduccin de ajuste, pero el nmero de lneas de la cuadrcula a mostrar se reducir para evitar saturar el diagrama ms pequeo con lneas de cuadrcula.
MAL
'roblemas de requerimientos
&os requerimientos para con la cuadr#cula mezcla tres tipos de requerimientos

0 0 0 ,n requerimiento funcional conceptual $la necesidad de una cuadr#cula%1 ,n requerimiento no funcional $unidades de la cuadr#cula%1 ,n requerimiento de la interfaz de usuario no funcional $activaci n o desactivaci n de la cuadr#cula%!
Porqu MAL
Slide 35
Definici n de recursos
BIEN
Directrices para la redacci n de los requerimientos
Inventar un formato est4ndar y asegurar la ad6erencia al mismo para todos los requerimientos! ,tilizar el lenguaje de manera consistente! 0 Requerimientos obligatorios2 Requerimientos fundamentales 0 Requerimientos deseables2 Requerimientos =o fundamentales Resaltar el texto para distinguir las partes clave del requerimiento! Evite el uso de jerga inform4tica!
III Requerimientos del /istema
Especificaciones m4s detalladas de las funciones del sistema2 los servicios y las limitaciones que con los requerimientos del usuario! /u intenci n es la de ser una base para el dise5o el sistema! 'ueden ser incorporados en el contrato del desarrollo del sistema2 es decir deben tener una especificaci n completa y consistente!
Slide 38
Requerimientos y dise5o
En principio2 los requerimientos deben indicar qu* debe 6acer el sistema y el dise5o debe describir c mo se 6ace esto! En la pr4ctica2 los requerimientos y el dise5o son inseparables
0 0 0 ,na arquitectura de sistema puede ser dise5ada para estructurar los requerimientos1 El sistema puede inter-operar con otros sistemas que generan requerimientos de dise5o1 El uso de un dise5o espec#fico puede ser un requerimiento del dominio!
'roblemas con especificaciones en lenguaje natural
3mbigQedad
0 &os lectores y escritores de los requerimientos deben interpretar las mismas palabras de la misma manera! El lenguaje natural es ambiguo por lo que este2 naturalmente2 es muy dif#cil!
-Sabes?, conozco a un tipo con una pata de palo que se llama Smith... -Y la otra pata cmo se llama?
Slide 40
'roblemas con especificaciones en lenguaje natural
El exceso de flexibilidad
0 &o mismo puede decirse en una serie de diferentes maneras en la especificaci n! Estructuras en lenguaje natural no son suficientes para encontrar todos los requerimientos relacionados
&a falta de modularizaci n

0
Slide 41
3lternativas a la especificaci n en lenguaje natural
Slide 42
Especificaciones en lenguaje estructurado
&a libertad del escritor de los requerimientos est4 limitada por una plantilla predefinida para requerimientos! Todos los requerimientos est4n escritos en una manera est4ndar! &a terminolog#a utilizada en la descripci n puede ser limitada! &a ventaja es que la mayor parte de la expresividad del lenguaje natural es mantenida2 pero un grado de uniformidad se impone en la especificaci n!
Especificaci n basada en formularios $sistema bomba de Insulina%
Slide 44
Especificaciones basadas en formulario

Definici n de la funci n o entidad! Descripci n de las entradas y de d nde vienen! Descripci n de las salidas y 6acia d nde van! Indicaci n de otras entidades requeridas! 're y post condiciones $si es apropiado%! Descripci n de los efectos colaterales $si los 6ubiera% de la operaci n!
Slide 45
'roblema de la Especificaciones basadas en formulario
=o est4 claro2 qu* es lo que ocurre si la precondici n no es satisfec6a( 'ara solucionar el problema2 entoces se debe usar la especificacion tabular
Slide 46
Especificaci n Tabular

,tilizado para complementar el lenguaje natural! 'articularmente es9til cuando usted tiene que definir una serie de posibles cursos de acci n alternativos2 como( ?4lculos2 cambios2 interacciones con los usuarios2 secuencias2 etc
Slide 47
Especificaci n Tabular ?4lculos de la dosis de insulina
Slide 48
Dodelo gr4fico
Dodelos gr4ficos son muy 9tiles cuando se necesita mostrar c mo cambia el Estado o en las necesita describir una secuencia de acciones!
Slide 49
Diagramas de secuencia
Estas muestran la secuencia de los eventos que tienen lugar durante la interacci n del usuario con el sistema! ,sted lee de arriba a abajo para ver el orden de las acciones que se llevan a cabo! Retiro de efectivo de un cajero autom4tico2 con < subsecuencias b4sicas1
0 0 0 "alidar la tarjeta1 Tratar la petici n1 ?ompletar la transacci n!
Slide 50
Diagrama de secuencia de retiro en cajeros autom4ticos
Slide 51
EEER?I?IO
Slide 52
E ercicio ! ,n sistema autom4tico de expedici n de billetes vende billetes de tren! &os usuarios seleccionan su destino e introducen una tarjeta de cr*dito y un n9mero de identificaci n personal! El billete de tren se expide y se carga a su cuenta de la tarjeta de cr*dito! ?uando el usuario presiona el bot n de inicio2 se activa un men9 que muestra los posibles destinos2 junto con un mensaje para el usuario que le indica que seleccione el destino! ,na vez que se 6a seleccionado el destino2 se pide a los usuarios que introduzcan su tarjeta de cr*dito! /e comprueba su validez y entonces se le pide introducir un identificador personal! ?uando la transacci n de cr*dito se 6aya validado2 se le expide el billete! /e pide( :!Identificar requisitos funcionales para el sistema expendedor de billetes! ;!Identificar requisitos no funcionales para el sistema expendedor de billetes! Indicando su tipo! <!Identificar los requisitos de dominio para el sistema expendedor de billetes!
Slide 53
I" Especificaci n de la interfaz
&a mayor#a de los sistemas deben funcionar con otros sistemas y las interfaces operativas deben ser especificadas como parte de los requerimientos! Tres tipos de interfaz puede que tengan que ser definidas
0 0 0 Interfaces de procedimientos1 Estructuras de datos que se intercambian1 Representaciones de datos!
&as notaciones formales son una t*cnica eficaz para la especificaci n de la interfaz!
Slide 54
I" Especificaci n de la interfaz
Interfaces de procedimientos1
0 'ermiten acceder a los servicios que ofrecen los subsistemas existentes 2Interfaz de 'rogramaci n de 3plicaciones$3'Is%
Estructuras de datos que se intercambian de un subsistema a otro

0 &os modelos gr4ficos de datos
Representaciones de datos!
Explicaci n de la estructura de datos a nivel de grupo de bits
Slide 55
" El documento de requerimientos
El documento de requerimientos $/R/% es la declaraci n oficial de que deben implementar los desarrolladores del sistema! Incluyen tanto requerimientos de usuario2 como especificaci n detallada de los requerimientos del sistema! ?asos de documentos(
0 0 0 &os ; tipos de requerimientos pueden integrarse en una 9nica descripci n &os req de usuario se describen como una introduccion /i los requer son muc6os los ; tipos de req se presentan por separado
Slide 56
&os usuarios de un documento de requerimientos
Slide 57
Requisitos est4ndar IEEE /td C<L
Define una estructura gen*rica para un documento de requerimientos que debe ser instanciada para cada sistema espec#fico!
0 0 0 0 0 Introducci n! Descripci n general! Requerimientos espec#ficos! 3p*ndices! Rndice!
Slide 58
Estructura de un documento de requerimientos

'refacio Introducci n Slosario Definici n de requerimientos del usuario 3rquitectura del sistema Especificaci n de requerimientos del sistema Dodelos del sistema Evoluci n del sistema 3p*ndices Indice
Slide 59
Estructura de un Doc de Req modificado

La informacin que se incluya en el Documento de Req depende de: Tipo de Software a desarrollar El enfoque de desarrollo utilizado Si se toma el enfoque evolutivo El doc. Contendr reque del usuario y del sistema NO funcionales de alto nivel Utilizando el enfoque XP Los req del usuario deben ser recopilados incrementalmente y escritos en tarjetas.
Slide 60
Estructura de un Doc de Req modificado
Slide 61

Cap 6

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cap 6

Загружено:

Авторское право:

Доступные форматы

novenoa.cis@unl.edu.

Requerimientos del software

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ingenier#a de requerimientos $RE%

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

3bstracci n de requerimientos $Davis%

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Requisitos de los lectores

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Requerimientos funcionales y no funcionales

Ian Sommerville 2004

Requerimientos funcionales y no funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

&os requerimientos funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ejemplos de requerimientos funcionales

Imprecisi n de los requerimientos

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Integridad de requerimientos y consistencia

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

&os req no funcionales tambi*n intervienen en el 'RO?E/O de desarrollo( 'or ejemplo(

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Tipos de requerimientos no funcionales

Requerimientos del producto

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Tipos de requerimientos no funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ejemplos de requerimientos no funcionales

Requerimientos del producto

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Ejemplo $/ist! De ?ontrol de tr4fico 3*reo%

Una meta del sistema

Un requerimiento no funcional verificable

Ian Sommerville 2004