SRS Rafael

8/12/2019 SRS Rafael

http://slidepdf.com/reader/full/srs-rafael 1/11

Especificación deRequerimientos de Software

para

Gestión de Ventas Barraca“Dorians”

Versión 1.0 aprobada

E aborado por Rafae !"e# Sa $atierra

%&S&% 'orp.

1()0*)(01*

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.



Software Requirements Specification para Gesti ó n de Ventas Barraca “Dorians” P á gina ii

Tabla de Contenidos

1. Introducci ón............................................................................................................................. 11.1 Prop ósito............................................................................................................................ ........ 11.2 Referencias................................................................................................................................. 1

2. Descripci ón General................................................................................................................. 12.1 Clases de Usuario y Caracter í sticas............................................................................................ 12.2 Entorno Operativo...................................................................................................................... 12.3 Restricciones de Dise ño e Implementaci ón................................................................................ 22.4 Suposiciones y Dependencias..................................................................................................... 2

3. Requisitos para la Interfaz Externa....................................................................................... 23.1 Interfaces de Usuario.................................................................................................................. 23.2 Interfaces de Hardware............................................................................................................... 33.3 Interfaces de Software................................................................................................................ 33.4 Interfaces de Comunicaciones.................................................................................................... 3

4. Sistema de Casos de Uso.......................................................................................................... 34.1 Nombre e Identificador de Caso de Uso..................................................................................... 44.2 Withdraw money from ATM (U2)............................................................................................. 4

4.3 Deposit money into ATM (U3)................................................................................................. 55. Otros Requisitos No Funcionales............................................................................................ 5

5.1 Requisitos de Desempe ño........................................................................................................... 55.2 Requisitos de Solidez................................................................................................................. 55.3 Requisitos de Seguridad............................................................................................................. 55.4 Atributos de Calidad de Software............................................................................................... 6

6. Otros Requisitos....................................................................................................................... 67. Tabla de Sistema de Requisitos.............................................................................................. 6

Historial de Revisiones

Nombre Fecha Raz ón de los cambios Versi ón

Rafael A ñezSalvatierra

13/04/2014 Primer versi ón del documento



Software Requirements Specification para Gesti ó n de Ventas Barraca “Dorians” P 1

1. Introducci ón

1.1 Prop ósito

El prop ósito del presente documento es definir cu áles son los requisitos necesarios para gestionarlas ventas de la empresa maderera “Dorians”, con el cual se pretende llevar un adecuado control demateriales, pedidos, clientes, proveedores y ventas de la empresa.

1.2 Referencias

Ninguna

2. Descripci ón General

2.1 Clases de Usuario y Caracter í sticas

• Gerente General: Puede realizar alta, baja, modificaci ón, consulta y obtener informes delos pedidos, ventas, clientes y proveedores.

• Encargado de Inventario: Puede insertar datos y hacer consultas de los pedidos, ventas yclientes.

2.2 Entorno Operativo

• COMPUTADORA: Procesador Intel Core i3 2nd Gen. Sistema operativo Windows 7Professional. 2 GB de Memoria RAM.

• IMPRESORA: Canon PIXMA MP280.• CONEXI ÓN A INTERNET: 512 mbps.

2.3 Restricciones de Dise ño e Implementaci ón

• La informaci ón debe ser actualizada en tiempo real y estar disponible inmediatamentedespués de ser modificada.

• La informaci ón debe ser respaldada para evitar posibles p érdidas.• Para los materiales debe utilizar el pie como medida del largo, la pulgada como medida del

ancho y el espesor, y el pie c úbico como medida del volumen.

2.4 Suposiciones y Dependencias

Ninguna.




3. Requisitos para la Interfaz ExternaSKIP ALL OF SECTION 3 for the SRS… We’ll do this as part of the GUI Prototype

3.1 Interfaces de Usuario

<Describe the logical characteristics of each interface between the software product and theusers. This may include sample screen images, any GUI standards or product family style guidesthat are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on e ery screen, !eyboard shortcuts, error message display standards, and so on.Define the software components for which a user interface is needed. Details of the user interfacedesign should be documented in a separate user interface specification."

Thin! about this in terms of standards, not specific features. #or e$ample,- all buttons will ha e a blac! border - all fonts will be %rial - Draw a screen template showing &main area', &menu here', &status bar' and describe each

component. If you ha e multiple screen layouts depending on the user s current tas! settings, describe them

- *hat screen resolutions will you support+- *ill you be ection - / compliant+ %re there any other standards you support+- etc0

3.2 Interfaces de Hardware

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported de ice types, thenature of the data and control interactions between the software and the hardware, and communication protocols to be used."

If you system doesn t include hardware, then you ll ha e none. If it has hardware components,then you should describe (at a high le el) how you interface with that hardware.

3.3 Interfaces de Software

<Describe the connections between this product and other specific software components (nameand ersion), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the ser ices needed and the nature of communications.1efer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must beimplemented in a specific way (for e$ample, use of a global data area in a multitas!ing operating system), specify this as an implementation constraint."

These are internal connections to things li!e databases, web ser ers. 2ou mainly need to e$plainthat you ha e them, but (for 3 456) I don t e$pect detailed information about how you actually connect to them and use them. 7ust e$plain that you do connect to them and use them for storage of customer information, or to process incoming web re8uests, etc0 These are internal components of your system.




3.4 Interfaces de Comunicaciones

<Describe the re8uirements associated with any communications functions re8uired by this product, including e9mail, web browser, networ! ser er communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communicationstandards that will be used, such as #T: or ;TT:. pecify any communication security or encryption issues, data transfer rates, and synchroni ation mechanisms."

These are e$ternal communication mechanisms. Do you connect to a ban! computer to erify credit card information+ That is =>T part of your system, so it is an e$ternal communication youha e. Describe it here. Do you ha e other systems connecting in to yours to perform somefunction+ That would also go here.

4. Sistema de Casos de UsoThe o erall use case diagram should be here.

The te$t description of each use case should follow.

4.1 Nombre e Identificador de Caso de Uso

1. Identificador Único2. Objetivo - What is the ultimate objective of the use-case. What is it trying to achieve? What

was the source of the use-case requirement?3. Prioridad – The overall priority of this use-case (Low, Medium, High)4. Fuente – Who is the main source of this use case. Who cares most about this functionality?

This should be the one person you would ask if there is a question about this use-case.(Make up a name and cite their: John Smith (End-user) here.)

5. Actores - Who is involved in the use-case? Which actors/stakeholders?6. Flujo de Eventos

6.1. Flujo Normal - flow of events normally executed in the use-case6.2. Flujo(s) Alternativo(s) - a secondary flow of events due to infrequent conditions6.3. Flujo(s) de Excepci ón(es) - Exceptions that may happen during the execution of the

use case7. Incluye - other use case IDs that are referenced in steps in the flow of events.8. Pre Condiciones - Any condition that must be satisfied before the use case begins. If the

condition is “User is logged in”, then the first step of the use case is NOT “User logs in”.They are already logged in if that is a pre-condition!

9. Post Condiciones - The conditions that will be satisfied after the use case successfullycompletes

10. Notas/Problemas - Any relevant notes or issues that need to be resolved

4.2 Withdraw money from ATM (U2)

1. U22. Objective – The customer is withdrawing money from the ATM and the system will debit

the customer’s account.3. Priority – High




4. Source – Carl Gnome (marketing)5. Actors – Customer, central bank computer6. Flow of Events

6.1. Basic Flow 6.1.1. Customer chooses the checking option on the ATM6.1.2. Customer chooses the amount of money needed

6.1.3. Customer confirms the choice6.1.4. System validates the amount6.1.5. System asks central bank computer to debit the customer’s account6.1.6. System issues money to the user

6.2. Alternative Flow 1 – At step 5.1.4 the amount is not a multiple of $206.2.1. An error message is displayed telling the customer they must use multiple of $20.6.2.2. Return to step 5.1.2

6.3. Alternative Flow 2 – At any step the user presses “cancel”6.3.1. System returns to the main menu

6.4. Alternative Flow 3 - At step 5.1.5 bank computer returns a failed status,“insufficient funds”

6.4.1. An error message is shown to the user6.4.2. Return to step 5.1.2

6.5. Exception Flow 1 –6.5.1. Database is locked due to backup in progress. System executes use case U57. Includes

7.1. U5 – Exception occurs8. Preconditions – User is logged in9. Post conditions – Money has been returned to the user and their account balance has been

updated.10. Notes/Issues - None

4.3 Deposit money into ATM (U3)

….

5. Otros Requisitos No Funcionales

5.1 Requisitos de Desempe ño

<If there are performance re8uirements for the product under arious circumstances, state themhere and e$plain their rationale, to help the de elopers understand the intent and ma!e suitable

design choices. pecify the timing relationships for real time systems. ?a!e such re8uirements asspecific as possible. 2ou may need to state performance re8uirements for indi idual functional re8uirements or features."

In this section, just say “See section 7 requirements 23-27”. And I’ll assume thoserequirements are Per ormance related.




5.2 Requisitos de Solidez

< pecify those re8uirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be ta!en, as well as actions that must be pre ented. 1efer to any e$ternal policies or regulations that state safety issues that affect the product s design or use. Define any safety certifications that must besatisfied."

In this section, just say “See section 7 requirements 2!-32”. And I’ll assume thoserequirements are Sa ety related.

5.3 Requisitos de Seguridad

< pecify any re8uirements regarding security or pri acy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authenticationre8uirements. 1efer to any e$ternal policies or regulations containing security issues that affect the product. Define any security or pri acy certifications that must be satisfied."

In this section, just say “See section 7 requirements 3!-"2”. And I’ll assume thoserequirements are Security related.

5.4 Atributos de Calidad de Software

< pecify any additional 8uality characteristics for the product that will be important to either thecustomers or the de elopers. ome to consider are@ adaptability, a ailability, correctness,fle$ibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,and usability. *rite these to be specific, 8uantitati e, and erifiable when possible. %t the least,clarify the relati e preferences for arious attributes, such as ease of use o er ease of learning."

In this section, just say “See section 7 requirements !!-#2”. And I’ll assume thoserequirements are So t$are %uality related.

6. Otros Requisitos<Define any other re8uirements not co ered elsewhere in the 1 . This might include databasere8uirements, internationali ation re8uirements, legal re8uirements, reuse obAecti es for the

proAect, and so on. %dd any new sections that are pertinent to the proAect."

2ou may not ha e any.




7. Tabla de Sistema de RequisitosREQUERIMIENTOS User History Condici ón de

Satisfacció

n

Esfuerzo Prioridad

Realizar el alta, baja ymodificaci ón de losclientes de la empresa

Como encargadode ventas quierorealizar alta, baja ymodificaci ón de losclientes paradisponer de unacartera de clientesa la cual ofertar losmateriales de laempresa

-El sistema guarda enbase de datos los datosdel cliente: nombre delcliente, NIT o Carnet deIdentidad, direcci ón,teléfono (m óvil y/ocelular), email y sipermite cr édito. Los datosque no son obligatoriosson: NIT o carnet deidentidad, direcci ón,teléfono y correo

electr ónico

5 1

Realizar el alta, baja ymodificaci ón de losproveedores de laempresa

Como encargadode ventas quierorealizar alta, baja ymodificaci ón de losproveedores parallevar un adecuadocontrol de quienessurten de material ala empresa

-El sistema guarda enbase de datos los datosdel proveedor: nombredel proveedor, nombredel representante legal,NIT o Carnet deIdentidad, direcci ón,teléfono (fijo y/o m óvil),correo electr ónico, tipode madera, si la empresamaderera puedebeneficiarse con cr éditopor parte del proveedor ymonto m áximo de cr éditopermitido por elproveedor.

5 2

Realizar el alta, baja ymodificaci ón de lospedidos de la empresa

Como encargadode ventas quierorealizar alta, baja ymodificaci ón de lospedidos para llevarun adecuadocontrol de lasganancias de laempresa

-El sistema guarda enbase de datos los datosdel pedido: Las piezas demadera que componen elpedido(nombre, largo,ancho, espesor yvolumen) y los serviciosa realizar (corte,cepillado, moldura yclavado). Todos los datosson obligatorios.

5 3




Emitir proformas Como encargadode ventas quieroemitir proformaspara controlarcuando un pedidono ha sido

confirmado peroexiste inter és delcliente en realizarlo

El sistema imprime laproforma. Los datos aimprimir son: n úmero deproforma, pedido al quepertenece, detalle delpedido y fecha de validez

de la proforma.

8 4

Emitir notas de venta Como encargadode ventas quieroemitir notas deventa paracontrolas cuandoun pedido ha sidoconfirmado pero noha sido pagado ensu totalidad

-El sistema imprime lanota de venta. Los datos aimprimir son: N úmero denota de venta, nombre delcliente, fecha de emisi ón,fecha de cumplimiento,detalle del pedido, montode los servicios, monto detransporte, descuentos ymonto total.

8 5

Emitir ordenes de trabajo Como encargadode ventas quieroemitir órdenes detrabajo para dar aconocer alencargado deproducci ón que unpedido tiene queser elaborado

El sistema imprime laorden de trabajo. Losdatos a imprimir son:Número de orden detrabajo, pedido, fecha deentrega del pedido ymateriales necesariospara su elaboraci ón(calculado por elsistema).

8 6

Emitir facturas Como encargadode ventas quieroemitir facturas paratener un respaldolegal de las ventasconfirmadas ypagadas totalmentede la empresa

El sistema imprime lafactura. Los datos aimprimir son: n úmero defactura, c ódigo decontrol, NIT de laempresa, NIT o Carnet deIdentidad del cliente,nombre del cliente, fechade emisi ón de la factura,detalle del pedido, montode los servicios, monto detransporte, descuentos ymonto total.

8 7

Calcular los materialesnecesarios para elaborar

un pedido

Como encargadode ventas quiero

calcular losmaterialesnecesarios paraelaborar un pedidopara obtener lacantidad exacta demateriales a utilizary obtener la mayorganancia posible

-El sistema imprime unahoja con el c álculo de los

materiales necesariospara elaborar el pedido.Los datos a imprimir son:Las piezas que componenel pedido, el materialnecesario para elaboraresa pieza

13 8




Emitir ordenes detransporte

Como encargadode ventas quieroemitir órdenes detransporte para quelos pedidos quehan sido

confirmados ypagados totalmentepuedan serenviados al lugarde construcci ón delcliente

El sistema imprime laorden de transporte. Losdatos a imprimir son:Número de orden detransporte, cliente,pedido, direcci ón de

env í o, fecha de entrega,Nombre de Persona queentrega, Nombre dePersona que recibe.

8 9

Elaboraci ón de informesde los pedidos

Como gerentegeneral quieroobtener informesde los pedidoshechos por laempresa paraconocer qu é

materiales son losmás y menosutilizados

-El sistema muestra enpantalla y/o imprime losinformes de los pedidos.

13 9

Elaboraci ón de informesde los clientes

Como gerentegeneral quieroobtener informesde los clientes y lospedidos que cadauno ha realizadopara determinar aquiénes son losmayores clientes dela empresa


13 10

Elaboraci ón de informesde los ventas

Como gerentegeneral quieroobtener informesde las ventas de laempresa paraconocer el estadofinanciero de laempresa


13 11

Elaboraci ón de informesde los proveedores

Como gerentegeneral quieroobtener informesde los proveedores

de la empresa paradeterminar aquiénes seguircomprandomateriales


13 12




Elaboraci ón de nivelesde autenticaci ón

Como gerentegeneral quierotener niveles deautenticaci ón en elsistema de ventaspara que cada nivel

pueda tener suspropios privilegios

-El sistema muestra lainformaci ón y permiteacciones seg ún el nivel deusuario que se haautenticado. Si esencargado de ventas s ólo

puede realizar consultas einserci ón de datos. Si esgerente general, puederealizar alta, baja,modificaci ón y consultas

13 13

Ap éndice A: Modelos de An á lisis<>ptionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,state9transition diagrams, or entity9relationship diagrams .>

Don+t do an, of t-ese for 'S*(1 SRS. &ou wi create t-ese mode s durin t-e -i - e$edesi n de i$erab e.

Ap éndice B: Lista de elementos a ser determinados<3ollect a numbered list of the TBD (to be determined) references that remain in the 1 so they can be trac!ed to closure."

Cist here any open 8uestions or things you !now still need to be done to the 1 , but ha en t been addressed yet. (It s o!ay to ha e things li!e that, especially in this 3 456 proAect becausewe don t ha e time to do e erything.)

Documents

SRS Rafael