Requerimientos funcionales y no funcionales de la empresa.

ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE ACTIVIDAD N°:

5

TEMA:

Profundizar la investigación sobre los requerimientos funcionales y no funcionales de la empresa.

UNIDAD N° 2:

Metodologías de Administración y Gestión de Proyectos de Software

OBJETIVO:

etallar los requisitos funcionales y no funcionales de la empresa.

PROBEMA:

FECHA ENVIO:

14/05/2015

FECHA ENTREGA:

15/05/2015

!ecesidad saber cu"les son los requisitos funcionales y no funcionales de la empresa.

INDICADOR DE EVAUACION: EVAUACION:

-

-

CAIFICACIÓN

#abilidad para aplicar el conocimiento de las ciencias b"sicas de la profesión e ingeniería en sistemas. $omprender la responsabilidad %tica y profesional.

CRITERIOS DE EVAUACIÓN: EVAUACIÓN: CAPACIDAD CAPACIDAD DE COMUNICACIÓN! EN IMPRESOS -ntrega documentación impresa y digital. &Siguien &Siguiendo do las normas normas y convencion convenciones es para la escritura y sin falta de ortografía(. a redacción del documento debe ser clara. ebe incluir todas las

Siempre &'(

A veces veces &)(

•

fuentes de donde tomó la información.

$umple con el formato+ normas y estructura para la elaboración del documento . APICACIÓN DE VAORES! Puntualidad. -ntrega de traba/o a tiempo 0esponsabilidad %tica. -l traba/o es in%dito y respeta la propiedad intelectual 0esponsabilidad profesional. $umple con las normas t%cnicas. USO DE RECURSOS: 0ecursos bibliogr"ficos fidedignos y con valide z científica 0ecursos tecnológicos adecuados CAPACIDAD DE REFE"IÓN! 1ncluye e/emplos claros que permiten un me/or entendimiento del tema. CONOCIMIENTO T#CNICO! estreza con las 2erramientas inform"ticas. •

• • •

• •

•

•

TIPO DE ACTIVIDAD FORMA

UGAR ACANCE 3 1ntraclase 3 1ndividual 3 5aller 3 Síntesis+ esquemas 3 3 Grupal 3 $aso de estudio -4traclase

3 1nvestigativa 3 6inculación con la colectividad

3 Pr"ctica en laboratorio 3 Pr"ctica en clase 3 0esolución de problemas+ e/ercicios 3 -nsayo+ artículo 3 1nforme de e4posición

ROES Y RESPONSABIIDADES DE OS PARTICIPANTES EN A TAREA: NOMBRE ESTUDIANTE RO DESCRIPCIÓN 7eld 7eldum uma a -dwi -dwin n -stu -studi dian ante te esa esarr rrol olla la la tare tarea a prop propue uest sta a Palacios Sandra Anabel -studiante esarrolla la tarea propuesta Gonzales 8orge uis -studiante esarrolla la tarea propuesta INTRODUCCION

!unca &*+,(

Trusted by over 1 million members

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.









a mayor parte de los proyectos de software que no llegan al sumo %4ito o la satisfacción por parte de cliente se debe a la falta de toma de los requisitos de la empresa+ estos requisitos ayudan a la realización de las siguientes etapas de la metodología que se 2aya escogido. !ormalmente+ un tema de la 1ngeniería de Software tiene diferentes significados seg9n el tipo de metodología que mane/emos para el desarrollo del software+ en ciertos casos la conocemos como la necesidad de un usuario para resolver un problema o alcanzar un ob/etivo predeterminados y en otros casos la condición o capacidad que debe estar presente en un sistema o los componentes de sistema para para satisf satisface acerr un contra contrato to realiz realizado ado del admini administr strado adorr del proye proyecto cto 2acia 2acia el gerente de la empresa. a defi defini nici ción ón de cada cada proc proces eso o que que real realiz izar ara a el sist sistem ema a para para sati satisf sfac acer er las las nece necesi sida dade dess de la empr empres esa a se lo defin define e como como requ requis isititos os func funcio iona nale les+ s+ esto estoss requisitos son muy importantes para el desarrollo del sistema ya que la mayor parte de casos en los que los sistemas fracasan es que no sabes especificar qu% es lo que realmente realizara el sistema para la empresa+ debido a este problema los usuarios tienen a tener que/arse al final del desarrollo del sistema. Por otro lado lo que tienen que ver con las características y limitaciones del sistema se lo denomina requerimientos no funcionales estos requerimientos ayudan a que el usuario entienda las limitaciones que tiene el sistema referente a cualquier otro cambio que se presente en la empresa. -n el desarrollo de este documento se detallara de manera clara y precisa los requerimientos funcionales del software a realizar tomando en cuenta la resolución de las necesidades de la empresa para el desarrollo y las limitaciones que tendr" el sistema cuando se lo implemente.









GENERA •

1nvestigar y definir a fondo cada uno de los requisitos funcionales y no funcionales de donde la empresa que se va a desarrollar el proyecto.

ESPECIFICO • • • •

-ntender cu"les son los requisitos de la empresa. efinir los requisitos funcionales de la empresa. $onocer los requisitos no funcionales de la empresa. efi efini nirr el ob/e ob/etiv tivo o inno innova vado dorr que que se va apli aplica carr en el proy proyec ecto to para para la empresa.

MARCO TEORICO METODOOG$A ICONI" Seg9n &8M(+ dice que: ;-s una metodología metodología pesadaP &e>treme Programming(+ unifica un con/unto de m%todos de orientación a ob/etos con el ob/etivo de tener un control estricto sobre todo el ciclo de vida del producto a realizar.? -n otras palabras 1$@!1> es un proceso simplificado que nos ayudar" de una manera m"s simplificada y ordenada al desarrollo del proyecto+ abarcando los m%todos de orientación a ob/etos con el ob/etivo de obtener todo el ciclo de vida del proyecto.

PASOS PASOS A SEGUIR EN A  A METODOOGIA ICONI" PARA PARA E DESARROO DE SOFTWARE A%&'()() *+ ,+-.()() ). Mode Modelo lo de de domi domini nio o '. Prot Protot otipa ipaci ción ón r"p r"pid ida a . Mode Modelo lo de de cas casos os de de uso uso A%&'()()  *()+ 3,+'((%, ). escri escripci pción ón de de caso casoss de de uso uso '. iag iagra rama ma de de robu robust stez ez D()+ ). iag iagra rama ma de de secu secuen enci cia a '. $omple $ompletar tar el mod modelo elo est"ti est"tico co I3'++%6(7% ). =tiliz =tilizar ar un diagr diagrama ama de de compon componen entes tes









Seg9n &García(+ dice que: ;5odo proyecto nace con la necesidad de satisfacer alguna carencia por parte de los interesados+ saber identificar con la mayor e4actitud posible las carencias que se van a atender es la base primordial para comenzar un proyecto.? Por lo tanto la recopilación de requisitos+ cosiste en documentar las necesidades+ deseos y e4pectativas y documentarlas de los interesados para convertirlas en requisitos del Proyecto.

1! ESP ESPECIF ECIFICAC ICACIÓN IÓN DE RE8U RE8UERI ERIMIE MIENT NTOS OS









BITÁCORA Fecha de elaboración: REQ  !"

10/05/2015

Versión del documento:

RE#I$TRO %E A%Q&$ICI'( %E ART)C&*O$+ 10/05/2015 Fecha Res,onsable

Obseracione s:

&suario

V.1.0

Sandra Palacios

Requerimientos funcionales de las historias: En la reposicin de mercader!a el responsa"le de in#entario $enera una orden de pedido solicitando los productos que le hacen falta dentro del almac%n& con los si$uientes datos: - '(mero de del pe pedido - )echa del pedido - *di$o de del pr producto - +esc +escri ripc pci in n del del prod produc ucto to - ,nidad de medida - *antidad sol solicitada El n(mero de pedido de"er tener un dato correlati#o se$uido por por un $uio $uion n sepa separa rado dorr  dos dos d!$it !$itos os adic adicio iona nale less que que identican el local que hace el pedido  lue$o es en#iado al almac%n central. En la orde orden n de pedi pedido do de"e de"e con constar star el tota totall de !tem !temss solicitados  la respecti#a rma  sello. a reposicin de mercader!a permitir realiar lo si$uiente: REQ-!"+" REQ-!"+" permite in$resar los datos solicitados del para el pedido que se #a a realiar en el local central. REQ-!"+. REQ-!"+. permite permite modicar modicar los los datos datos del pedido pedido que que se quiere realiar. REQ-!"+/ permite REQ-!"+/ permite eliminar los datos de la orden del pedido que se quiere realiar. REQ-!"+0 permita "uscar un pedido en "ase a su n(mero o por la fecha realiada. erente









RE8019 REPOSICIÓN DE MERCADER$A

1!1!1! A*(%(),6(7% *+ P+*(*) Se encarga de realizar el pedido+ el responsable de 2acerlo en este caso es el gerente+ permitiendo realizar la orden de pedido por medio de la cual se solicita los productos+ así como tambi%n tendr" acceso a modificar+ buscar las órdenes+ pero solo el gerente puede eliminarlas. No. R

Tipo

Descripción

Datos

NumPedido

Restricciones – Observaciones

Prioridad

Debe ser número correlativo seguido por un guion donde los dos últimos dígitos identifcan el local.

Ingreso de

REQ-!"+" Inserción datos del pedido

FechaPedido

"odigoProducto, Descripcion, #nidad, "antidad

Día, mes  a!o

Alta

$stos valores son de una tabla producto

RE3-01.2

%odifcación %odifcaci de los datos Datos &'().) ón del pedido

*raba+a con &'().)

Alta

RE3-01.4

$liminación $liminació de Datos del Datos &'().) n pedido

Para eliminar se necesita el NumPedido.

-a+a

RE3-01.

-uscar

*raba+a con &'().)

%edia

"onsulta de de "onsultar NumPedido, FechaPedido los Datos del





No. R

Tipo

Descripción

Datos


Prioridad

pedido

1!1!1! A*(%(),6(7% *+ P,*.6) Permite el ingreso de los productos+ con/untamente con sus características+ modificación+ eliminación y consulta. -l Gerente podr" realizar estas operaciones. No. R

RE301.5

Tipo

Inserción

Descripción

Ingreso de datos del producto

Datos


Id Producto

Debe tener un numero entero autoincrementar, autoincrementar, no debe ser valor nulo

Prioridad

Id"ategoria

Debe tener un numero entero no debe ser valor nulo este código proviene de la tabla "ategoría.

Idproveedor

Debe tener un numero entero no debe ser valor nulo este código Alta proviene de la tabla Proveedor. Proveedor. $n caso de venta se disminuiría el stoc/ de productos.

toc/ Actual $n caso de recepción de producto se incrementa el stoc/ Nombres ,#nidad %edida, Precio Proveedor, Proveedor, "osto I0A, Precio 0enta, #tilidad,, toc/ %ínimo

RE3-

%odifc %odifcaci ació ó %odifc %odifcaci ación ón Datos Datos RE3-01.5

No deben ser nulos *raba+a con RE3-01.5

Alta





No. R

Tipo

Descripción

Datos

01.6

n

de los datos del producto

RE301.7

$liminación $liminación de los datos Datos RE3-01.5 del producto

RE301.8

"onsulta

"onsulta de los datos del Nombre , "ategoría, Proveedor producto


Prioridad

Para eliminar se necesita el IdProducto.

-a+a

1os datos pueden ser consultados por nombre, categoría, proveedor. proveedor.

%edia





1!1!1! A*(%(),6(7% *+ C+,;) Permite ingresar nuevas categorías+ así tambi%n modificar+ eliminar+ consultarC estas categorías ser"n las que clasifiquen a los productos. e la misma forma tendr"n acceso el gerente+ siendo el primero no podr" eliminar ninguna categoría. No. R

Tipo

Descripción

Datos

Id"ategoría

RE301.9

Inserción

Ingreso de datos de la categoría



Nombre, Detalle

No deben ser nulos

Prioridad

Alta

RE301.10

%odifcación %odifcació de los datos n de la categoría

Datos RE3-01.9

*raba+a con RE3-01.9

RE301.11

$liminación de los datos $liminación de la categoría

Datos RE3-01.9

Para eliminar se necesita el Id"ategoría.

-a+a

RE301.12

"onsulta

1os datos pueden ser consultados por Nombre, Id"ategoría.

%edia

"onsulta de los datos de la Nombre , Id"ategoría categoría

Alta





1!1!1! A*(%(),6(7% *+ P,<++*, Permite la gestión de los proveedores de los productos: insertar+ modificar+ eliminar+ consulta. -l responsable de realizar estas operaciones es el departamento de compras+ el cual tiene los permisos de insertar+ modificar y consultar m"s no eliminar ya que este privilegio lo tiene el Gerente. No. R

RE301.14

Tipo

Inserción

Descripción

Ingreso de datos del proveedor

Datos


Id Proveedor


"ódigo proveedor

No debe ser nulo  debe ser la cedula del Proveedor

Nomb Nombre res, s, &epr &epres esen enta tant nte, e, Dire Direcc cció ión, n, "iud "iudad ad,, *el23 el23on ono. o.

No debe deben n ser ser nulo nulos s

RE301.1

%odifcación %odifcaci de los datos Datos RE3-01.14 ón del proveedor

*raba+a con RE3-01.14

RE301.15

$liminación $liminació de los datos Datos RE3-01.14 n del proveedor

Para eliminar se necesita el IdProveedor.

RE301.16

"onsulta

"onsulta de los datos del proveedor

Nombre , Id Proveedor, "ódigo Proveedor, "iudad

Prioridad

Alta

Alta

-a+a

1os datos pueden ser %edia cons consul ulta tado dos s por por Nombr Nombre, e, Id Proveedor Proveedor,, "ódigo Proveedor Proveedor,,





No. R

Tipo

Descripción

Datos


"iudad.

Prioridad







1!2!

RE8902

BITÁCORA Fecha de elaboración: REQ  !.

10/05/2015

Versión del

V.1.0

documento:

VE(TA %E 1ERCA%ER)A %E$%E E* *OCA* 2ACIA &( &$&ARIO+ 10/05/2015 Sandra Palacios Fecha Res,onsable

Obseracione s:

Requerimientos funcionales de las historias: En el despacho de mercader!a el almac%n reci"e la orden de pedidos pedidos&& lue$o re#isa re#isa su stoc de producto productoss  $enera $enera una u!a de Remisin de los productos que tiene a disposicin&  aquellos productos que no se encuentren en stoc $enera una orden de compra  es en#iada al departamento de compra  #ent #enta a para para que que reali ealice ce la $esti estin n de comp compra rass de los los productos solicitados. El despacho de mercader!a permitir realiar lo si$uiente: a $u!a de remisin de"er contener lo si$uiente :  !umero de Guía de 0emisión  !umero de pedido al cual se despac2a  Dec2a de salida 5otal de Etems despac2ados  5otal  $ódigo de Producto









RE8029 REPOSICIÓN DE MERCADER$A 1!2!1! A*(%(),6(7% *+ G.;)

Permite la gestión de los guías de remisión: inserción+ modificación+ eliminación y b9squeda. -l responsable de realizar estas operaciones es el despac2o de mercadería+ que recibe la orden de pedido y su stocF+ de acuerdo a esto genera la orden de remisión con los productos que tiene. No. R

Tipo

Descripción

Ingreso de RE3-02.1 Inserción datos del pedido

Datos


Id4uia

Debe tener un numero entero autoincrementar, no debe ser un valor nulo.

Id1ocal

Debe tener un número entero, no debe ser valor nulo, este código proviene de la tabla 1ocal. REQ-!"+"3.

IdProducto

Debe tener un número entero, no debe ser valor nulo, este código proviene de la tabla Producto. REQ-!"+4

IdNumPedido

Debe tener un número entero, no debe ser valor nulo, este código proviene de la tabla Pedido. REQ-!"+"

3ech 3echa aal alida ida,, P0P P0P, "ant "antid idad ad

No debe deben n ser ser nulo nulos. s.

%odifcació %odifcaci n de los RE3-02.2 Datos &'(5.) ón datos del pedido

RE3-02.4

$liminación $liminació de Datos Datos &'(5.) n del pedido

Prioridad

Alta

*raba+a con &'(5.)

Alta

Para eliminar se necesita el Id4uia

-a+a







No. R

Tipo

RE3-02. -uscar

Descripción

Datos

"onsulta de "onsultar IdNumPedido, los Datos Id4uia. del pedido


Prioridad


%edia







1!=!

RE890=

BITÁCORA Fecha de elaboración: REQ  !/

"!5!45.!"4

Versión de del

V+"+!

documento:

$O*ICIT&% %E 1ERCA%ER)A A &( 6ROVEE%OR 10/05/2015 Responsa"le Sandra Palacios Fecha Obseracione s:

Requerimientos funcionales de las historias: En la solicitud de mercader!a cuando un almac%n detecta un "a;o ni#el de in#entario o poco stoc de al$(n producto& el $ere $erent nte e $ene $enera rara ra una una orde orden n de comp compra ra  es en#i en#iad ado o al departamento de *ompras  este departamento se comunica con los Pro#e Pro#eed edor ores es para para ne$o ne$ocia ciarr los preci precios os de los producto. a








RE80=9 SOICITUD DE MERCADER$A A UN PROVEEDOR 1!4!1! 1!4 !1! A* A*(% (%() (),6 ,6(7% (7% *+ O,*+% O,*+%

Permite la gestión de órdenes de compra permitiendo la inserción+ modificación+ eliminación y b9squeda. -l responsable de realizar estas operaciones es el despac2o de mercadería+ que recibe la orden de pedido y su stocF+ de acuerdo a esto genera la orden de $ompra con los productos que no tiene con el fin de adquirirlos. No. R

T ipo Ti

Descripción

RE304.1

Inserción Inserción Ingreso Ingreso de datos de 6rden

Datos


Id6rden

Debe tener un numero entero autoincrementar, no debe ser valor nulo

IdProveedor

Debe tener un numero entero no debe ser valor nulo este código proviene de la tabla Proveedor.

REQ-!"+"/

Fecha$ntrada, Fecha6rden

Debe ser un dato tipo Date, no debe ser valor nulo, Día, mes  a!.

IdProducto

Debe tener un numero entero no debe ser valor nulo este código proviene de la tabla Producto.

REQ-!"+4 "antidad olicitada "antidad &ecibida

Deben ser valores enteros enteros cuando se genere la orden de compra. Deben ser valores enteros n ul ulos cuando se genere la orden de compra, el departamento de compras ser7 la encargada de llenar estos campos.

Priorid ad

Alta









No. R

T ipo Ti

Descripción

Datos

Precio"ompra


Priorid ad

Deben ser tipos de datos decimal, el precio de compra debe estar vacío al momento de generar la orden de compra, el departamento de compras ser7 la encargada de llenar estos campos.

$stado

Debe ser un valor tipo cadena, puede ser agotado o entregado, este campo es llenado por el departamento de compras

Datos &'(8.)


Alta

RE304.2

%odifca %odifcación de ción 6rden

RE304.4

$liminaci $liminación de 6rden Datos &' &'(8.) ón

Para eliminar se necesita el Id6rden.

-a+a

RE304.

-uscar


%edia

"onsulta de 6rden

"onsultar Id6rden, IdProveedor









1!5!

RE8904

BITÁCORA Fecha de

"!5!45.!"4

elaboración: REQ  !0

Versión de del

V.1.0

documento:

RE*EP*>?' E' =@=*A' +E = RE*>B>+= P
Obseracione s:

10/05/2015

Res,onsable

Sandra Palacios

Requerimientos funcionales de las historias: En la recepci recepcin n de me merc rcade ader!a r!a el pro#eed pro#eedor or reci"e reci"e los productos productos con la respecti#a orden de recepcin recepcin  la cantidad de los productos reci"idos  el estado actual del producto El $erente reci"e la mercader!a con la papeleta de recepcin









2! RE8U RE8UIS ISIT ITO OS NO FUN FUNCI CION ONA AES ES 2!1! 2! 1! R+ R+-. -.() ()( () ) *+ ,+ ,+%* %*( ((+ (+% %  •

•

a aplica aplicació ción n garant garantiza izara ra que los usuari usuarios os tendr" tendr"n n una eficie eficienci ncia a &rapidez+ e/ecución( de un ,H al usar la aplicación. -l tiempo de respuesta a los l os usuarios ser" de ) a ' segundos. S+.,(**

•

• •

•

Gara Garant ntiz izar ar la conf confia iabi bililida dad+ d+ la segu seguri rida dad d y el dese desemp mpeI eIo o del del sist sistem ema a info inform rm"t "tic ico o a los los dife difere rent ntes es usua usuari rios os.. -n este este sent sentid ido o la info inform rmac ació ión n almacenada o registros realizados podr"n ser consultados y actualizados permanente y simult"neamente+ simult"neamente+ sin que se afecte el tiempo de respuesta. Se utilizara una metodología de Se implementara una base de datos normalizada para la integridad de la información. Garantizar la seguridad del sistema con respecto a la información y datos que se mane/an tales sean documentos+ arc2ivos y contraseIas.









CONCUSIONES •

Se concluye que: o

o

o

o

-s importante investigar los requisitos de una empresa para poder desarrollar el proyecto. -s necesario tener en cuenta cuales son los requisitos funcionales de la empresa. -s importante cual es diferencia entre requisitos funcionales con no funcionales. !ecesario tener el modelo innovador que se va aplicar dentro del proyecto.

Requerimientos funcionales y no funcionales de la empresa.

Recommend Documents