Definición de Requerimientos de

Negocio (BRD)

SISTEMA POS PARA TELEFONIA

Preparado por: Fecha: Revisado por: Fecha: Aprobado por: Fecha:

Sergio Carlos 10/10/18
Loarca
Sergio Carlos
Loarca 03/10/18

1
 Sistema POS

Índice
1. Requerimiento General (*)............................................................................................................... 3
2. Proceso de Negocio Asociado y Funcionalidad Actual.....................................................................3
2.1 Situación Actual......................................................................................................................... 3
2.2 Condiciones de Seguridad Actual.............................................................................................3
2.3 Auditoria y Control de Operaciones y Procedimientos..............................................................3
3. Entradas para Nueva Funcionalidad................................................................................................3
4. Proceso de Negocio Asociado y Funcionalidad Requerida (*)..........................................................3
4.1 Situación Requerida..................................................................................................................3
4.2 Seguridad en los Requerimientos.............................................................................................5
4.3 Requerimientos no Funcionales................................................................................................6
4.4 Planificar Entregables............................................................................................................... 6
4.5 Criterios de Aceptación............................................................................................................. 6
4.6 Otros......................................................................................................................................... 7
5. Riesgos, supuestos, restricciones y dependencias..........................................................................7
6. Visión a Futuro................................................................................................................................. 7

(*) Los temas marcados están orientados a especificaciones originadas para mantenimientos.

2
1. Requerimiento General (*)

2.

- Necesidad del Negocio

- Surge en primera instancia de conocer el mercado y el grupo objetivo al cual le están dirigiendo la iniciativa,
se requiere de un control automatizado de las transacciones de ventas diarias.

3. Estamos en un momento en el que podemos aprovechar estos recursos y potencializar ideas

innovadoras con la construcción de la solución para el cliente , se precisa que sea en un mediano
tiempo pues lo recursos generales del stakeholder inicialmente serán básicos, sin embargo se deja
abierto un abanico de posibilidades para poder evolucionar el software de la mano con el negocio,

4. Realizar el inventario correspondiente, controlando los ingresos y los egresos de los equipos y
chips que se adquieren físicamente, también se pretende llevar el control de la validación y el estado de
los equipos

- Riesgos al no atender la Necesidad del Negocio

- Los principales riesgos a NO atender la necesidad del negocio son varios factores y por ende
repercusiones , pues al no atender en tiempo y forma las necesidades del stakeholder puede detonar
en que declinemos la propuesta, en atrasarnos con las ideas, incremento de tiempo, de los
recursos que el cliente nos proporcione como un abono, de informacion o de dinero, poder
desfarzarnos en todo eso que no es deseable por un buen seguimiento formal para el cliente y su
negocio,

- Beneficios al atender la Necesidad de Negocio

5. Se beneficiara al cliente cubriendo las necesidades de su sistema.

6.

7. Descripción 8. Parámetro 9. Parámetro

Actual Meta

10. Modulo Clientes 11. Existe 12.

13. Modulo Articulos 14. Existe 15.

3
 7. Descripción 8. Parámetro 9. Parámetro
Actual Meta

16. Modulo Ventas 17. Existe 18.

19. Modulo Reportes 20. Existe 21.

22. Modulo Pedidos 23. Desarrollo 24.

25.

26. <Se deberán incluir todas las áreas y personas relacionadas con la necesidad del negocio, en
forma directa o indirecta.>

27. Area 28. Nombre usuario 29. Rol

Contacto

30. IT 31. Sergio Carlos 32. Ing Sistemas

Loarca

33. Ventas 34. Elizabeth Villar 35. Vendedor/Caja

36. Inventários 37. Andrés 38. Almacenes

Calamaro

39. Edgar Rojas 40. Administracion 41. Administracion

42. 43. 44.

45. 46. 47.

48. 49. 50.

51. Proceso de Negocio Asociado y Funcionalidad Actual

52.
53. Se requieren hacer para los modulos :
54. Ventas: Identificar los métodos de venta que se procesaran en el sistema.

4
55. Artículos: Elaborar una base de datos de los artículos que se van a gestionar en el sistema en Excel
56. Clientes: Elaborar una base de datos de clientes en Excel .
57. Reportes: Estos se van a ir construyendo
58.
2.1 Situación Actual

59.

60. Diagrama de Procesos.

61.

62.

63.

64.

65. Descripción de Funciones.

66. El sistema da inicio cuando el cliente llega a la tienda , y a continuación un ejecutivo de

ventas lo aborda para escuchar sus necesidades, así mismo le ofrece las promociones existentes , si
el cliente está de acuerdo entonces compra o bien o el servicio , si no se le invita a que regrese en
días sucesivos para invitarlo a realizar su compra.

67. Detallar formulas y cálculos.

5
 68. No existen pues son variables, tal vez algún calculo pudiera ser el tipo de impuesto a los
artículos que es un valor constante.

69. Volúmenes y Periodos máximos Actuales.

70. <Volúmenes de información manejada actualmente por el proceso así como los periodos
máximos y mínimos para identificar estacionalidad en la información>.

71.

72. Formatos, Código, Datos proporcionados.

73. *Reportes de ventas

74. *Reporte de Clientes

75. *Reportes de Existencias en inventario

76. Acceso a Usuarios

77. Usuario Ventas

78. Usuario Sistemas

79. Usuario Supervisor

80. Usuario Gerente

81.
2.2 Condiciones de Seguridad Actual

82.

83. Mediante cartas normativas y autorizadas por firmas de stakeholder.

84.
2.3 Auditoria y Control de Operaciones y Procedimientos

85.

86. Se hará una auditoria de sistemas previa para la detección de sus necesidades de hardware y
software requerido para el funcionamiento del sistema POS

87.

88.

6
89. Entradas para Nueva Funcionalidad
90.
91.

- Detallar Fórmulas y Cálculos

92. Solo habrá un cálculo que será al precio de lista del ítem agregarle el tipo de impuesto IVA
que equivale al 16%, y el calculo es Precio de Lista * 1.16= Precio Total

- Formatos, Código, Datos proporcionados.

93. Se van a incluir formatos de capturas de clientes, de artículos así como los diferentes
accesos a sus módulos de reportes

- Proceso de corrección del error del flujo.

94. Mediante las evaluaciones y seguimientos en los avances estos serán reportados a el
departamento de desarrollo para sus ajustes.

95.

96.

97.

98.

99. Proceso de Negocio Asociado y Funcionalidad Requerida (*)

100.
4.1 Situación Requerida

101.

102. Integrar información y datos que se requiere en el nuevo proceso. Deberá ser elaborado por el
equipo usuario e IT asignados por los Líderes de Proyecto.

103. Diagrama de Procesos.

7
 8
104.
105. Descripción de Procesos Funciones y Reglas de Negocio.

106.

107. Descripción de Requerimientos por Proceso/Función.

108. <Basándose en el Diagrama, describir cada uno de los requerimientos involucrados en el

Diagrama de Proceso, tanto nuevos, como cambios, detallando: identificador proceso-función (el
identificador de la función debe tener la siguiente nomenclatura: RFcsc), relaciones; dependencias con
otras; Tipo.

109. En el caso de que el requerimiento involucre una pantalla, reporte, archivo, etc, el detalle se
deberá incluir en los cuadros correpondientes, relacionando con el identificador del requerimiento.>

110. Tipo: N=Nueva / C=Cambio/B=Baja Prioridad: E=Esencial / C=Condicional / O=Opcional

111. Complejidad: A=Alta / M=Media / B=Baja Clase: R = Proceso / P = Pantalla / R = Reporte / I = Interfase

112. Id 113. N 114. N 115. 116. Descripción 117. P 118. 119. C

entificador ombre del ombre de la Tipo Funcionalidad Requerida y rioridad Clase omplejidad
Proceso Función reglas de negocio aplicables
120. R 121. P 122. P 123. 124. TOMA DE PEDIDO 125. E 126. 127. A
F001 EDIDO EDIDO N P
128. R 129. C 130. C 131. 132. COMPRA A 133. C 134. 135. M
F002 OMPRA OMPRA C PROVEEDOR P
136. R 137. A 138. A 139. 140. CONTROL DE 141. C 142. 143. M
F003 LMACEN LMACEN C ALMACEN E INVENTARIOS P
144. R 145. R 146. R 147. 148. REPORTES 149. A 150. 151. M
F004 EPORTE EPORTES N VARIOS R
S
152. 153. 154. 155. 156. 157. 158. 159.

9
 112. Id 113. N 114. N 115. 116. Descripción 117. P 118. 119. C
entificador ombre del ombre de la Tipo Funcionalidad Requerida y rioridad Clase omplejidad
Proceso Función reglas de negocio aplicables
160. 161. 162. 163. 164. 165. 166. 167.
168. 169. 170. 171. 172. 173. 174. 175.
176.

177.

178.

179.

180.

181. Descripción de Reportes / Documentos

182.

183.

184.

185. Identificador: ____VENTAS_ Título del Reporte/Documento: ____VENTAS__

186. Prioridad: E Prioridad: E = Esencial / C = Condicional / O = Opcional

187. Para Totales / Subtotales, indique el nivel al que se requiere hacer el corte y los datos a totalizar.
188. Salida del Reporte / Documento (P = Pantalla / I = Impreso / A = Archivo – En caso de archivo, indique formato: Texto /
PDF / Otro)

10
 189. 190. Datos que deberá contener el 191. Criter 192. Totale 193. S
Csc reporte ios de s / Subtotales alida
Selección datos)
194. 195. FECHA 198. I
01
196. X 197. □
199. 200. NOMBRE DE CLIENTE 203. I
02
201. X 202. □
204. 205. NUMERO DE VENTA 208. I
03
206. □ 207. □
209. 210. TOTAL 213. I
04
211. □ 212. X
214.

215. Identificador: ____INVENTARIOS Título del Reporte/Documento: ____EXISTENCIAS__

216. Prioridad: E Prioridad: E = Esencial / C = Condicional / O = Opcional

217. Para Totales / Subtotales, indique el nivel al que se requiere hacer el corte y los datos a totalizar.
218. Salida del Reporte / Documento (P = Pantalla / I = Impreso / A = Archivo – En caso de archivo, indique formato: Texto /
PDF / Otro)

219. 220. Datos que deberá contener el 221. Criter 222. Totale 223. S
Csc reporte ios de s / Subtotales alida
Selección datos)
224. 225. FECHA 228. I
01
226. X 227. □
229. 230. NOMBRE DE ARTICULO 233. I
02
231. X 232. □
234. 235. NUMERO DE EXISTENCIA 238. I
03
236. □ 237. □
239. 240. TOTAL 243. I
04
241. □ 242. X
244.

245.

246. Identificador: ____TOP 20_ Título del Reporte/Documento: ____TOP 20 ITEMS__

247. Prioridad: E Prioridad: E = Esencial / C = Condicional / O = Opcional

248. Para Totales / Subtotales, indique el nivel al que se requiere hacer el corte y los datos a totalizar.
249. Salida del Reporte / Documento (P = Pantalla / I = Impreso / A = Archivo – En caso de archivo, indique formato: Texto /
PDF / Otro)

11
250. 251. Datos que deberá contener el 252. Criter 253. Totale 254. S
Csc reporte ios de s / Subtotales alida
Selección datos)
255. 256. FECHA DE LA VENTA 259. I
01
257. X 258. □
260. 261. NOMBRE DE ARTICULO 264. I
02
262. X 263. □
265. 266. NUMERO DE VENTA 269. I
03
267. □ 268. □
270. 271. TOTAL 274. I
04
272. □ 273. X

275.

276.

277.

278.

279.

280.

281.

282.

283.

284.

285.

286.

287.

12
288. Descripción de Pantallas

289.

Identi
ficador: ___RV001______ Título de la Pantalla: REPORTE DE VENTAS

290. Prioridad: ___ Prioridad: E = Esencial / C = Condicional / O = Opcional

291. Tipo Pantalla: C = Consulta / A = Alta / B = Baja / Ca = Cambio/ M = Mantenimiento (incluye: Consulta, Alta, Baja y
Cambio)

292.294. Datos que deberá contener la Pantalla 295. Criterios 296. Ti

C de Búsqueda de po
Datos
293.
297. 298. NOMBRE DE LA EMPRESA 300.
299. □
301. 302. FECHA DEL DOCUMENTO 304.
303. □
305. 306. CLAVE DEL ARTICULO 308.
307. □

13
 292.294. Datos que deberá contener la Pantalla 295. Criterios 296. Ti
C de Búsqueda de po
Datos
293.

309. 310. DESCRIPCION DEL ARTICULO 312.

311. □
313. 314. PRECIO UNITARIO DEL ARTICULO 316.
315.
317. 318. CANTIDAD DE PIEZAS VENDIDAS 320.
319. □
321. 322. TOTAL DE VENTA 324.
323. □
325.
326.
4.2 Requerimientos no Funcionales

327.

328. Los requerimientos no funcionales son aquellos que no están asociados directamente con la
funcionalidad del sistema pero que pueden tener efecto en la aceptación del sistema como:

 Desempeño <Tiempo de respuesta esperado en línea, Tiempo de proceso esperado, etc>

 Escalabilidad

 Disponibilidad < horarios y días de acceso con soporte>

 Usabilidad

 Volúmenes y Periodos máximos.

329.

330. Prioridad: E = Esencial / C = Cndicional / O = Opcional Complejidad: A=Alta / M=Media / B=Baja

331. Identif 332. Requerimiento de negocio no funcional 333. P 334. Co

icador rioridad mplejidad

335. RNF0 336. El sistema debe ser capaz de operar 337. O 338. A
01 adecuadamente con hasta 100.000 usuarios con
sesiones concurrentes.

14
 339. RNF0 340. Los datos modificados en la base de datos 341. C 342. M
02 deben ser actualizados para todos los usuarios que
acceden en menos de 2 segundos

343. RF00 344. El tiempo de aprendizaje del sistema por 345. E 346. B
3 un usuario deberá ser menor a 4 horas.

347. RF00 348. El sistema debe poseer interfaces gráficas 349. E 350. A
4 bien formadas.

351. RF00 352. El sistema debe contar con un módulo de 353. E 354. A
5 ayuda en línea.

355.
356.
4.3 Planificar Entregables

357.

358. SE VA A ENTREGA POR MEDIO DE LAS DIFERENTES FASES , AL SER UN PROYECTO

MODULAR QUE DEPENDE DE EL MODULO ANTERIOR LOS SUCESIVOS SE TENDRAN QUE IR
LIBERANDO POR MODULO Y DESARROLLO.

359.
360. Etapa 361. Entregable
362. Inicio  Plan de Proyecto
363.
364. Análisis  Business Requirement Definition (BRD)
 Functional Requeriment Diseño functional (FRD)
365. Diseño  Casos de Uso
 Diseño Técnico
 Casos de Prueba
366. Construcción y Pruebas  Bitácora de Pruebas.
 Documento de Aceptación de Pruebas(Unitarias,
ETE, UAT)
367.
368. Transición  Aceptación de cierre de Proyecto
 Actualización de Plan de Proyecto
369.

370.
371.
4.4 Criterios de Aceptación

372.

373. Requerimientos Funcionales

15
 374.

375. Definir los criterios de aceptación para cada requerimiento

376.
378.Método de
377.Ide 382.Responsa
Aceptación
ntifi 380.Criterio ble de
379.(Pruebas,
cad 381.(Definición del Criterio) Aceptació
Inspección.
or n
Análisis)
385. El sistema enviará un correo
electrónico cuando se registre
alguna de las siguientes
383. Req transacciones: pedido de venta 386. EDGAR
384. PRUEBA
ID 1 de cliente, despacho de ROJAS
mercancía al cliente, emisión de
factura a cliente y registro de
pago de cliente.
389. El sistema permitirá manejar un
maestro de materiales y
productos, en el cual se
387. Req 388. PRUEBA Y 390. EDGAR
registrarán todos los ítems que
ID 2 ANALISIS ROJAS
se pueden vender. Cada item
debe tener al menos su nombre,
unidad de medida y descripción
393. En todo momento, el pedido se
podrá registrar en borrador,
391. Req 394. EDGAR
392. PRUEBA pudiendo ser modificado y
ID 3 ROJAS
registrado en definitivo
posteriormente
395.

396. Requerimientos No Funcionales

397.

398. Indique los criterios de aceptación para requerimientos de: desempeño (tiempos de
respuesta aceptables de las funciones); Escalabilidad (xxx); Disponibilidad (horarios en que el
sistema deberá estar accesible a los usuarios con soporte de infraestructura, BSA´s, otros);
Necesidad de DRP. Se deberá asignar un nuevo identificador.

400.Método de
399.Ide 404.Responsa
Aceptación
ntifi 402.Criterio ble de
401.(Pruebas,
cad 403.(Definición del Criterio) Aceptació
Inspección.
or n
Análisis)
408. <Persona(s)
407. <Definir las condiciones
responsable
405. Req necesarias que debe cumplir el
406. de aceptar el
ID 1 requerimiento para ser
requerimient
aceptada su entrega>
o>
409.
4.5 Otros
410.
411. <Detallar cualquier otra consideración>

412.

413. Nota: Estos requerimientos de diseño de negocio son importantes para entender el flujo de operación del negocio y
no reflejan necesariamente el diseño de desarrollo de TI.

414.

16
415. Riesgos, supuestos, restricciones y dependencias
416.
1. Riesgos
2. Supuestos
3. Restricciones
4. Dependencias
417.
418. Los eventos posibles para afectación del proyecto son retrasos de recursos, (monetarios y de
datos)
419. <Detallar eventos posibles que afecten al proyecto en términos de Tiempo, Costo o Alcance y la
estrategia para su mitigación o acciones a tomar. >
420. <Si aplica, incluir una breve narración de supuestos, restricciones y dependencias que impacten el
requerimiento.>

421. Visión a Futuro

422.
423. Se deben definir los requisitos generales y comenzar a especificar los casos de uso del
sistema en su versión inicial. Conforme avance el proceso de ingeniería de requisitos, los requisitos
generales se irán detallando en requisitos más específicos y los casos de uso que se considere
oportuno irán evolucionando hacia su forma detallada.

424. Si se considera oportuno por la complejidad del sistema, los requisitos generales pueden
organizarse de forma jerárquica e, incluso, representarse gráficamente.

425. Desarrollar la visión general del sistema es una de las actividades que forman parte del
proceso.
426.

17
427.
428. Checklist de Verificación de Requerimientos
429.<Utiliza este checklist cuando revise documentos de requerimientos durante sesión de Revisión entre Colegas>
430. Nombre del 431. Id Documento.: ...................
Documento: .......................................................
432. Revisado 433. Fecha: ........./........./.........
Por: ..............................................................
434. ¿Los requerimientos cumplen los siguientes criterios? 435. 436. 437.
S N N

438. Correctos, claros y concisos 439. 440. 441.

442. Libres de error 443. 444. 445.
446. Fácil de leer 447. 448. 449.
450. Redactados de forma clara, en términos apropiados para la audiencia 451. 452. 453.
454. No usa palabras susceptibles de interpretarse de forma diferente como 455. 456. 457.
claramente, seguramente
458. No usa palabras vagas como a veces, seguido, usualmente, por lo general, 459. 460. 461.
igual a,
462. Las palabras clave están descritas claramente como manejado, procesado, 463. 464. 465.
rechazado, etc.
466. En el caso de funciones lógicas se usan brackets o paréntesis para evitar 467. 468. 469.
ambigüedades ejemplo: "If (A and B) or (C and D), then E"
470. En el caso de funciones lógicas con negación se usan brackets o 471. 472. 473.
paréntesis para evitar ambigüedades ejemplo: "If not (A and B), then C"
474. Los términos y unidades de medida son definidos 475. 476. 477.
478. Existe una sola interpretación del requerimiento documentado 479. 480. 481.
482. Administrables 483. 484. 485.
486. Son definidos de modo que puedan ser modificados con poco impacto a 487. 488. 489.
otros requerimientos
490. Consistentes entre ellos 491. 492. 493.
494. El requerimiento no tiene conflicto con otros requerimientos 495. 496. 497.
498. Relevantes 499. 500. 501.
502. Son pertinentes con la situación y la solución específica (objetivos y 503. 504. 505.
alcance)
506. Pueden ser probados y rastreados 507. 508. 509.
510. Los criterios de aceptación son apropiados y las pruebas de aceptación 511. 512. 513.
pueden determinar si el requerimiento fue satisfecho
514. No existen requerimientos superfluos 515. 516. 517.

18
430. Nombre del 431. Id Documento.: ...................
Documento: .......................................................
432. Revisado 433. Fecha: ........./........./.........
Por: ..............................................................
518. La fuente del requerimiento es conocida (de documentación del usuario, de 519. 520. 521.
una solicitud de cambio, de una solicitud de servicio, de un reporte de problema)
522. Factibles 523. 524. 525.
526. El requerimiento puede ser implementado con los recursos disponibles: 527. 528. 529.
herramientas, personal, tecnología, etc.
530. El requerimiento puede ser implementado con los costos y calendarios 531. 532. 533.
especificados
534. Redactado como requerimiento y no como solución propuesta 535. 536. 537.
538. Completos 539. 540. 541.
542. La redacción de la necesidad está completa y documentada con suficiente 543. 544. 545.
detalle para su implementación
546. No hay ningún requerimiento perdido o no tomado en cuenta 547. 548. 549.
550.

19
551. Control Requerimientos

552.

553. Requerimientos Funcionales

554. Requerimie 555. 556. 557. 558. Tot

nto/Complejidad Alta Media Baja al

559. Procesos 560. 561. 562. 563.

564. Pantallas 565. 566. 567. 568.

569. Reportes 570. 571. 572. 573.

574. Interfases 575. 576. 577. 578.

579. Total 580. 581. 582. 583.

584.

585. Requerimientos No Funcionales (tomando el peso de pantallas)

586. Requerimie 587. 588. 589. 590. Tot

nto/Complejidad Alta Media Baja al

591. No 592. 593. 594. 595.

Funcional

596.

597.

598.
599.

20