García Delgado María José Ingeniería de Software No. Contr ntrol: 1432!"" Ing. ng. Castro tro García María Nanc# nc# 1$: % 1":
TAREA 1 1.1 REVISIÓN DE ESPECIFICACIÓN ESPECIFICACIÓN DE REQUISITO REQUISITOS S ¿QUÉ ES LA REVISIÓN DE ESPECIFICACIÓN DE REQUISITOS? REQUISITOS? Una revisión de requisitos es un proceso manual que involucra a personas tanto de la organización del cliente como de la del contratista. La Especifi Especificació cación n es un documento documento que define, define, de forma forma completa, completa, precisa precisa y verificab verificable, le, los requisitos, el diseño y el comportamiento u otras características, de un sistema o componente de un sistema. La especificación de requisitos de software E!"# es una descripción completa del comportamiento del sistema que se va a desarrollar. $ncluye un con%unto de casos de uso que describe todas las interacciones que tendr&n los usuarios con el software. Los casos de uso tambi'n son conocidos como requisitos funcionales. (dem&s de los casos de uso, la E!" tambi'n contiene requisitos no funcio funcional nales es o comple complemen mentar tarios ios#. #. Los requis requisito itos s no funcio funcional nales es son requis requisito itos s que impon imponen en restricciones en el diseño o la implementación, como, por e%emplo, restricciones en el diseño o est&ndares de calidad. Est& dirigida tanto al cliente como al equipo de desarrollo. El lengua%e utilizado para su redacción debe ser informal, de forma que sea f&cilmente comprensible para todas las partes involucradas en el desarrollo.
¿QUÉ ES LA REVISIÓN ESPECIFICA DE REQUISITOS? Los requerimientos para un sistema son descripciones de lo que el sistema debe )acer* el servicio que ofrece y las restricciones en su operación. +ales +ales requerimientos refle%an las necesidades de los clientes por un sistema que atienda cierto p ropósito, como sería controlar un dispositivo, colocar un pedido pedido o buscar información. información. (l proceso de descubrir descubrir,, analizar analizar,, documentar documentar y verificar verificar estos servicios y restricciones se le llama ingeniería de requerimientos $!#. El t'rmino requerimiento- no se usa de manera continua en la industria del software. En algunos casos, un requerimiento es simplemente un enunciado abstracto de alto nivel en un servicio que d ebe proporcionar un sistema, o bien, una restricción sobre un sistema. En el otro etremo, consiste en una definición detallada y formal de una función del sistema. /avis 0112# Los requerimientos del usuario y los requerimientos del sistema se definen del siguiente modo* 0. Los requerimientos del usuario son enunciados, en un lengua%e natural %unto con diagramas, acerca de qu' servicios esperan los usuarios del sistema, y de las restricciones con las cuales 'ste debe operar. 3. Los requerimientos del sistema son descripciones m&s detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requerimientos del sistema llamado en ocasiones especificación funcional# tiene que definir con eactitud lo que se impl implem emen enta tar& r&.. 4ued 4uede e form formar ar part parte e del del cont contra rato to entr entre e el comp compra rado dorr del del sist sistem ema a y los los desarrolladores del software.
TIPOS DE ESPECIFICACIONES: ESPECIFICACIONES:
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1": Los requerimientos de software pueden ser analizados de varias formas diferentes. Las t'cnicas de an&lisis pueden conducir a una especificación en papel que contenga las descripciones gr&ficas y el lengua%e natural de los requerimientos del software. La construcción de prototipos conduce a una especificación e%ecutable, esto es, el prototipo sirve como una representación de los requerimientos. Los lengua%es de especificación formal conducen a representaciones formales de los requerimientos que pueden ser verificados o analizados.
¿Para qué sir! "a r!isi#$ %! !s&!'i(i'a'i#$ %! r!quisi)*s? ¿Qué '*+&ru!,a? ¿C#+* s! ""!a a 'a,*? ¿QUÉ ES UN REQUERI-IENTO CUALES SON SUS CARACTER/STICAS? •
•
Un requerimiento es una condición o capacidad a la que el sistema siendo construido# debe conformar. Un requerimiento de software puede ser d efinido como* o Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un ob%etivo Una capacidad del software que debe ser reunida o poseída por un sistema o o componente del sistema para satisfacer un contrato, especificación, est&ndar, u otra documentación formal.
TIPOS DE REQUISITOS Los tipos de requisitos pueden dividirse en* •
•
•
•
•
R!quisi)*s %! usuari*: "on frases en lengua%e natural o descripciones gr&ficas diagramas# de los servicios que se espera que ofrezca el sistema y de sus restricciones. R!quisi)*s %! sis)!+a: Una descripción m&s detallada de los servicios eactos que se proporcionar&n y sus restricciones. Estos requisitos sirven como contrato con el cliente. ( su vez los requisitos de sistema pueden dividirse en requisitos funcionales, no funcionales y de dominio. R!quisi)*s (u$'i*$a"!s: Especifican lo que debe )acer o los servicios que debe proporcionar el sistema. E%emplo* en un software de gestión de una biblioteca podrían ser requisitos funcionales dar de alta un cliente, alquilar un libro, devolver un libro, comprar un libro, etc. Los requisitos funcionales deben describir tambi'n cómo responder& el sistema ante estas distintas entradas, y su comportamiento frente a situaciones particulares. R!quisi)*s $* (u$'i*$a"!s: "on restricciones de los servicios del sistema o funciones que ofrece. E%emplo* en un software de gestión de compras de una tienda podrían ser requisitos no funcionales un tpv para pagar con tar%eta, un 45 con memoria y espacio en disco para almacenar la base de datos de ventas, que sea capaz de atender a la vez a varios clientes, que no tarde m&s de 6 tiempo en gestionar una venta, etc. R!quisi)*s %! %*+i$i*: Estos requisitos refle%an características del dominio de la aplicación. E%emplo* la forma en la que se comunicar&n distintas partes de la aplicación, el tipo de datos con los que traba%ar&, etc.
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1":
¿CO-Ó SE CLASIFICAN LOS REQUERI-IENTOS? REQUERI-IENTOS FUNCIONALES:
•
Los requerimientos funcionales describen una interacción entre el sistema y su ambiente, describen cómo debe comportarse el sistema ante determinado estímulo. "on declaraciones de los servicios que debe proporcionar el sistema, de la manera en que 'ste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, tambi'n pueden declarar eplícitamente lo que el sistema no debe )acer. Los requerimientos funcionales de un sistema describen lo que el sistema debe )acer.
¿Qué 0a'!$ "*s r!quisi)*s (u$'i*$a"!s? 7 /escriben la funcionalidad del sistema 7 /ependen del tipo de software, del sistema a desarrollar y de los usuarios finales. 7 Los requisitos funcionales del usuario* 8 pueden ser sentencias muy generales sobre lo que el sistema debería )acer. 7 Los requisitos funcionales del sistema* 8 deben describir los servicios que se deben proporcionar con todo detalle.
S! '"asi(i'a$: •
Usuario
•
"istema
E!+&"*s %! r!quisi)*s (u$'i*$a"!s. 7 "e deben poder realizar b9squedas en base a diferentes criterios usuario#. 7 "e deben proporcionar diferentes visores para que el usuario lea los documentos recuperados sistema#. 7 5ada pedido tendr& un identificador 9nico sistema#.
REQUERI-IENTOS FUNCIONALES: Requerimientos funcionales "on enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos funcionales tambi'n eplican lo que no debe )acer el sistema.
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1": Los requerimientos funcionales para un sistema refieren lo que el sistema debe )acer. +ales requerimientos dependen del tipo de software que se est' desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requerimientos. (l epresarse como requerimientos del usuario, los requerimientos funcionales se describen por lo general de forma abstracta que entiendan los usuarios del sistema. "in embargo, requerimientos funcionales m&s específicos del sistema detallan las funciones del sistema, sus entradas y salidas, sus ecepciones, etc'tera. Los requerimientos funcionales del sistema varían desde requerimientos generales que cubren lo que tiene que )acer el sistema, )asta requerimientos muy específicos que refle%an maneras locales de traba%ar o los sistemas eistentes de una organización.
•
REQUERI-IENTOS NO FUNCIONALES:
Los requerimientos no funcionales* describen una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. !estringen los servicios o funciones ofrecidas por el sistema. $ncluyen restricciones de tiempo, el tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Los requerimientos no funcionales ponen límites y restricciones al sistema.
Ti&*s %! R!qu!ri+i!$)*s N* Fu$'i*$a"!s: :"ommerville, 3;;<= desglosa en la figura los tipos de requerimientos no funcionales. Los tres grupos generales son* requerimientos del producto, organizacionales y eternos, de cada grupo se derivan los particulares. •
R!qu!ri+i!$)*s %!" Pr*%u')*: Especifican el comportamiento del producto. E%emplos* rapidez de la e%ecución, capacidad de memoria, fiabilidad, etc.
•
R!qu!ri+i!$)*s Or2a$i3a'i*$a"!s:
/erivan de políticas y procedimientos eistentes en la organización del cliente y del desarrollador. E%emplos* Est&ndares de procesos, m'todos de diseño, lengua%es de programación, m'todos de entrega, etc.
R!qu!ri+i!$)*s E4)!r$*s: "e derivan de factores eternos al sistema y de sus procesos de desarrollo. E%emplos* !equisitos de interoperatividad, legislativos, 'ticos, etc.
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1":
REQUERI-IENTOS NO FUNCIONALES: Un requisito que especifica criterios que pueden usarse para %uzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que 'stos corresponden a los requisitos funcionales. 4or tanto, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar, sino características de funcionamiento. (lgunos e%emplos de requisitos no funcionales típicos son los siguientes* •
!endimiento
•
/isponibilidad
•
(ccesibilidad
•
Usabilidad
•
Estabilidad
•
4ortabilidad
•
5osto
•
>peratividad
•
$nteroperabilidad
•
Escalabilidad
•
5oncurrencia
•
?antenibilidad
•
$nterfaz
•
"eguridad
¿Qué 0a'!$ "*s r!quisi)*s (u$'i*$a"!s? /efinen propiedades emergentes del sistema* 8 El tiempo de respuesta. 8 Las necesidades de almacenamiento. 8 La fiabilidad... 7 4ueden indicar la necesidad del uso de )erramientas 5("E, de un determinado lengua%e de programación o de un m'todo de desarrollo. 7 Los requisitos no funcionales puede ser m&s críticos que los funcionales* 8 "i un requisito funcional no se cumple, el sistema se degrada. 8 "i un requisito no funcional no se cumple el sistema se inutiliza.
C"asi(i'a'i#$
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1": 7 !equisitos del producto 8 Especifican el comportamiento del producto obtenido* velocidad de e%ecución, memoria requerida, porcenta%e de fallos aceptables... 7 !equisitos organizacionales 8 "on una consecuencia de las políticas y procedimientos eistentes en la organización* procesos est&ndar utilizados de fec)as de entrega, documentación a entregar... 7 !equisitos eternos 8 4resentan factores eternos al sistema y a su proceso de desarrollo* interoperabilidad del sistema con o tros, requisitos legales, 'ticos...
E!+&"*s %! r!quisi)*s $* (u$'i*$a"!s: 7 !equisitos del producto 8 @.5.A. El sistema deber& tener tiempos de acceso a la base de datos inferiores a los 0< milisegundos. 7 !equisitos organizacionales 8 1.2.3 El sistema se debe desarrollar de acuerdo con el proceso est&ndar 6BC5oD"4D"+(D1<. 7 !equisitos eternos 8 F.G.<. El sistema no divulgar& a los operadores ninguna información personal sobre los clientes a parte de su nombre y su n9mero de referencia.
REQUERI-IENTOS DE DO-INIO: "e derivan del dominio de la aplicación del sistema m&s que de las necesidades específicas del usuario. ormalmente incluyen terminología especializada del dominio o referencias a conceptos de dominio. Los requerimientos de dominio son importantes debido a que a menudo refle%an los fundamentos del dominio de la aplicación. "i estos requerimientos no se satisfacen, puede ser imposible que el sistema funcione de forma satisfactoria. E%emplo en un "istema de Hiblioteca, este deber& proveer visores para que el usuario lea documentos en el almac'n de documentos. Los requerimientos del dominio son importantes debido a que a menudo refle%an los funcionamientos del dominio de aplicación. "i estos requerimientos no se satisfacen., puede ser imposible )acer que el sistema funcione .de forma satisfactoria. El sistema L$H"B" incluye varios requerimientos del dominio* 0.
/eber& eistir una interfaz de usuario est&ndar para todas las bases de datos que estar& basada en el est&ndar C21.<;. 3. /ebido a las restricciones en los derec)os de autos, algunos documentos deber&n borrarse inmediatamente despu's de su llegada. /ependiendo 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 se enviaran a la impresora de la red. El primer requerimiento es una restricción de diseño. Establece que la interfaz de usuario para la base de datos debe implementarse seg9n un est&ndar bibliotecario especifico. Los desarrolladores. 4or lo tanto, tienen que informarse sobre el est&ndar antes de empezar el diseño de la interfaz. El segundo requerimiento se introduce debido a las leyes de derec)o de autor que se aplican a los materiales utilizados en las bibliotecas. Establece que el sistema debe incluir un recurso autom&tico para borrar algunas clases de documentos al ser impresos. Esto significa que los usuarios del sistema de biblioteca no pueden tener su propia copia electrónica del documento. 4ara ilustrar los requerimientos del dominio que especifican como se lleva a cabo en la figura que a continuación se presentar&, tomada de la especificación de un sistema de protección automatizada
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1": de trenes. Este sistema detiene de forma autom&tica un tren si pasa por una señal ro%a. Este requerimiento establece la manera la manera en que dic)o sistema calcula la desaceleración del tren. La terminología utilizada es especifica del dominio. 4ara entenderla se necesita una cierta comprensión del funcionamiento del sistema ferroviario y las características de los trenes.
REQUISITOS DE DO-INIO * Estos requisitos refle%an características del dominio de la aplicación. E%emplo* la forma en la que se comunicar&n distintas partes de la aplicación, el tipo de datos con los que traba%ar&, etc. "e derivan del dominio del sistema m&s que de las necesidades específicas de los usuarios. 4ueden ser requerimientos funcionales nuevos, restringir los eistentes o establecer cómo se deben e%ecutar c&lculos particulares . 7 Los requerimientos del dominio son importantes debido a que a menudo refle%an los fundamentos del dominio de aplicación. 7 "i estos requerimientos no se satisfacen, es imposible )acer que el sistema traba%e de forma satisfactoria.
!equisitos que provienen del dominio de especificación del sistema y que refle%an las características y restricciones de ese dominio no tienen por qu' derivarse de las especificaciones del usuario#. 4ueden ser funcionales o no funcionales* restringir alg9n requisito eistente, o establecer cómo se deben e%ecutar c&lculos particulares. • • •
El dominio tiene su propio vocabularioIlengua%e. Es importante comprenderlo para comprender a los usuarios y clientes. (ntes de entrar de lleno a especificar, con los usuarios y clientes, )ay que traba%ar para conocer el dominio del sistema.
Estos requisitos plantean un problema especial a los ingenieros del software porque )an de comprender un dominio que en ocasiones se escapa de nuestro conocimiento )abitual. El grado de dificultad lo marca el dominio, no requiere el mismo esfuerzo adaptarse a un dominio para desarrollar el sistema de epedición de billetes de tren que un HróJerD>nline. "e derivan del dominio del sistema m&s que de las necesidades específicas del usuario. "on importantes debido a que a menudo refle%an los fundamentos del d ominio de la aplicación. "i estos no se satisfacen es imposible que el sistema traba%e de forma satisfactoria. Estos se epresan utilizando un lengua%e específico del dominio de la aplicación que a menudo es difícil de comprender. E%.* operación para calcular desaceleración del tren, para un sistema de control de trenes. Estos van enfocados a la interacción que tendr& el sistema con otros sistemas, ya sea, para obtener datos, o la comunicación que tendr&n los distintos módulos de este, con datos recibidos y enviados que traba%ar&.
5i,"i*2ra(6a
García Delgado María José Ingeniería de Software No. Control: 1432!"" Ing. Castro García María Nanc# 1$: % 1":
:0= (n&lisis de requerimientos 0era. Edición, (ño* 3;00, /ra. ?aría del 5armen Kómez uentes, 4ublidisa ?eicana ".(. de 5.M., 5apitulo $$$* Especificación de !equerimientos, 4agina* 30 de 003. )ttp*IIwww.cua.uam.mIpdfsIconoceIlibroselecIotasN(nalisisN!equerimiento.pdf :3= $ngeniería de "oftware FO Edición, (ño* 3;;<, $an "ommerville, (ddison Pesley, 4arte $$ !equerimientos, 4agina* 0;F a 00<, 0@< de F03. )ttp*IIzeus.inf.ucv.clIQbcrawfordI?odeladoR3;U?LI$ngenieriaR3;delR3;"oftwareR3;Fma. R3;Ed.R3;DR3;$anR3;"ommerville.pdf :2= (n&lisis de !equerimientos )ttp*IIes.slides)are.netImarfonlineIanalisisDdeDrequerimientosDingenieriaDdeDsoftware
:@= "ommerville, $an SS$ngeniería de "oftwareTT, ovena edición, capítulo @ $ngeniería de requerimientos, pagina A2. :<= !oger 4ressman SS$ngeniería del software un enfoque pr&cticoTT s'ptima edición, capitulo G, ?odelo de los requerimientos, p&ginas de la 03G a la 02;
