Anda di halaman 1dari 61

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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)

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

3bstracci n de requerimientos $Davis%

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 7

Tipos de requerimientos

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 8

Definiciones y especificaciones

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 9

Requisitos de los lectores

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!
Software Engineering, 7th edition. Chapter 6 Slide 11

Ian Sommerville 2004

Requerimientos funcionales y no funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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%

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 20

Tipos de requerimientos no funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 24

D*tricas para especificar requerimientos no funcionales

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!
Software Engineering, 7th edition. Chapter 6 Slide 26

Ian Sommerville 2004

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 29

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 34

'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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 35

Definici n de recursos

BIEN
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 36

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!
Software Engineering, 7th edition. Chapter 6 Slide 37

Ian Sommerville 2004

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!
Software Engineering, 7th edition. Chapter 6 Slide 39

Ian Sommerville 2004

'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?

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 41

3lternativas a la especificaci n en lenguaje natural

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!
Software Engineering, 7th edition. Chapter 6 Slide 43

Ian Sommerville 2004

Especificaci n basada en formularios $sistema bomba de Insulina%

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 47

Especificaci n Tabular ?4lculos de la dosis de insulina

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 50

Diagrama de secuencia de retiro en cajeros autom4ticos

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 51

EEER?I?IO

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 56

&os usuarios de un documento de requerimientos

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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!

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

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.

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 60

Estructura de un Doc de Req modificado

Ian Sommerville 2004

Software Engineering, 7th edition. Chapter 6

Slide 61