Requisitos de Negócio - Apresentação de Projectos de Programação - Portugal-a-Programar
Por M6, 26 de Setembro de 2006 em Apresentação de Projectos de Programação
Publicado 26 de Setembro de 2006
KISQueanos,
estamos com alguns problemas técnicos e não temos wiki para editar os requisitos.
Ora sendo o meu papel o de "mau da fita", tenho de vos melgar a dizer que "lá por não termos condições para trabalhar isso não quer dizer que não façamos o nosso trabalho"!
E como tal, enquanto não há wiki, vou dar aqui o kick off dos requisitos de negócio para o KISC. O que se segue abaixo tem apenas a ver com a minha ideia do projecto e serve apenas como ponto de partida para a discussão. Vão acontecer várias "teimas", algumas fortes e feias, e tal deve ser encarado como um processo criativo normal onde várias visões e ideias são batidas, rebatidas e debatidas. Não levem estas discussões a peito, ou seja, não as encarem como nada de pessoal, são normais, extremamente úteis e vão ver que o resultado final será muito melhor do que qualquer das ideias que originaram a discussão.
Nomenclatura: vamos acordar que o identificador único dos requisitos é constituído por um número (sequencial e único) e uma letra identificadora do tipo de requisito. Se um requisito morrer, o seu número perde-se e não mais será usado. O requisito tem de ter um nome e uma descrição, opcionalmente pode ter uma nota de relação com outros requisitos. Ver N8 e N9.
N1 - Línguas - Sistema disponível nas seguintes línguas: português, inglês, francês, espanhol.
N2 - Plataforma - Sistema disponível para as seguintes plataformas: Windows, Linux, Mac OS X.
N3 - Relatórios - O sistema disponibiliza os seguintes relatórios: lista de produtos com preço máximo, médio, mínimo e mediano. Os cálculos dos relatórios podem levar em conta, ou não, os produtos promocionais. Levando em conta os produtos promocionais a custo zero, os mesmos influenciam os valores estatísiticos, caso contrário, apenas o stock aumenta e as estatísticas são construídas excluindo estes produtos.
N4 - Lista de Compras - O sistema constrói uma lista de compras com os produtos considerados em falta ou abaixo de um valor limite indentificado pelo utilizador e mais tarde ajustado pelo proprio sistema (a partir do momento que comece a haver dados suficientes para tal)
N5 - Entrada em Stock - O sistema permite a entrada de produtos constantes numa lista de compras em menos de um segundo. Colocando por defeito dados retirados da lista de compras (N4), bastanto assim, confirmar/corrigir as entradas.
N6 - Medidas - O sistema suporta produtos nas seguintes medidas: Kg e Unidades.
N7 - Formatos de Relatórios - Todos os relatórios devem estar disponibilizados em: papel, pdf e folha de cálculo. Ver N3.
N8 - Entrada de produtos - Todos os produtos podem ser registados como uma compra normal ou promocial. O tipo de entrada de produto influencia os relatórios. Ver N3 e N9.
N9 Produtos promocionais - Produtos promocionais são aqueles que foram adquiridos de forma promocional: - custo zero; - desconto;. Ver N3.
N10 - Selecção de produtos a gerir - A selecção dos produtos que cada utilizador vai gerir é feita por intremédio de uma lista comum, pré criada, com todo o tipo de produtos/acondicionamentos/unidades de medida (N6) possiveis. Cada utilizador vai dessa BD comum selecionar as que lhe intereçam usar.
N11 - Geração de receitas - O sistema sugere uma ou mais receitas possiveis com o stock que há na altura. Opção de sugestão também aplicada a meia-receita, onde se sugerem receitas para as quais as quantidades dos produtos existem em valores iguais ou superiores a 50% dos valores da receita completa.
N12 - Gestão de listas de compras - O sistema pode guardar listas de compras efectuadas (N4) sendo possível a sua reutilização.
Em N4 adicionava um outro ponto em que não é falta de produto, nem propriamente stock em baixo.
Leito xpto, gasta-se normalmente á volta de 10 litros por mes, e o preco mais baixo comprado é 0,42€
(Há 12 Litros em stock)
No caso de o preço ser inferior ou igual a 0,42 'mandar' comprar mais 20 Litros.
(porque a validade do produto o permite e para aproveitar o preço porque REALMENTE é bom)
Em N1 convem que as linguas sejam obtidas atraves de um ficheiro externo facilmente editável com um editor de texto, para ser facilmente actualizável e adicionadas novas linguas.
Mas onde vais buscar o preço para saber se o mesmo é bom?
Calma jovem, estás a falar de requisitos de implementação e isso ainda não é agora.
Mas podes fazer essa anotação na wiki, que já está a funfar: http://kisc.info
Pelos ultimos preços de compra. Neste caso em concreto pelo preço mais baixo (por exmeplo) dos ultimos 3 meses
Mas os preços flutuam bastante, mesmo durante um mês.
Os preços podem e variam muito, mas nunca fogem muito. (não estamos a falar de couves nem alfaces, que isso sim,.. varia muito)
A variação dos preços nas lojas normalmente é por uma questão ocmercial (a tal hitória do 'roubar aqui e "dar" dali' A ideia é apanhar sempre e só os bons preços.
Sim, mas por exemplo, entre o dia 15 e 20 de cada mês, os hipers têm imensas promoções, tipo pague 2 leve 3, nesses casos como se faz? É mesmo um à borla? Ou contabiliza-se o preço a dividir pelos 3?
Em relação a esse tipo de promoções ainda nem tinha pensado nisso.
Vou pensar agora.
Penso que em relação a isso não vá causar problema algum, uma ves que a introdução é feita pelo nº de embalagem e preço total, ou seja vai registar o preço medio.
Será? Acho que este é um daqueles casos em que qualquer das opções tem pontos bons e maus... É que depois isso vai influenciar o valor do preço médio e até a mediana, e a verdade
é que esses valores, em especial os da mediana, não vão ser correctos.
Acho que isto requer mais meditação. Se calhar temos de pensar num esquema mais "evoluido" para contemplar este tipo de situações...
Acho que isto requer mais meditação. Se calhar temos de pensar num esquema mais "evoluido"
O que eu estou aqui a dizer não é nenhuma escritura!!! isto até foi o que me lembrei assim de repente em 5 minutos. A segredo MESMO do fundo da questão é mesmo isso! elaborar/estudar/inventar o melhor metodo de rentabilizar ao maximo!
No caso dos leve 3 pague 2 vai inflacionar o preço médio, pois o cliente vai registar apenas 2 itens comprados apesar de trazer 3, etodos sabemos que funciona assim:
Preço unitário : 1,00€ (antes da promoção)
Leve 3 pague 2 : 2,50€
logo o preço unitário vai-se cifrar em 1,25€ -
Publicado 27 de Setembro de 2006
Em relaçao as promoçoes pode-se e fazer uma cena so para promoçoes k vai afectar a msm o stock mas esse stock vai com outra referencia digamos assim, aquele leite xpto que e do lote X foi comprado em promoçao, logo nao ia mexer mto com o preço medio...
Também estive a "meditar" sobre o assunto e parece que começamos a ter algum alinhamento de ideias.
Acho que se devia marcar a compra como sendo uma promoção mas que, no caso de oferta de produtos (como é o caso de pague 3 leve 2) o produto oferecido não deve entrar para a contabilidade, ou seja, não deve afectar o preço médio nem a mediana.
Esta abordagem permite duas coisas:
- manter os valores dos produtos registados "correctamente", ou seja, o preço introduzido foi mesmo o preço de compra e não "poluido/destorcido", assim o produto extra é um bónus, o qual não pagámos, não sabemos se vamos voltar a ter hipótese de adquirir de forma gratuíta e como tal não deve ser registado como uma compra real;
- gerar relatórios que permitam inferir qual a melhor altura para ir às compras se estamos numa de sacar mais promoções;
Ena bem,... voçes vão-me matar! lool
Discordo disso tudo, axo precisamente o contrario.
- manter os valores dos produtos registados "correctamente", ou seja, o preço introduzido foi mesmo o preço de compra e não "poluido/destorcido",
O ideal seria ter o registo do preço REAL (destrocido) porque é nas tais destroções é que vai o engano normal das pessoas que vai na volta pensam que é barato mas é caro.
Por exemplo, normalmente dá para comprar o tal produto a 1€ mas que consegue-se apanhar muita vez a leve 3 pague 2 por 1,25 cada (2,5 os 3) O preço registado nao deveria de ser 1,25, por assim quando voltar a ir comprar vamos pensar que 1,10€ é um preço muito bom, quando na realidade o preço razoavel é 1€.
´(já comento mais,.. tou no escritorio a fazer compras nao tenho muito tempo....)
Ora cá está a primeira teimazinha!
Mas a "verdade" é que se te oferecem um, os outros dois sairam a 1,25€ cada um, até porque se levasses as embalagens individuais, apenas uma ou até duas soltas sem aproveitares a promoção, o preço é mesmo 1,25€. E 1,25€ é 25% mais caro do que o normal.
Talvez uma forma de não influenciar a mediana (estou mais interessado nesta medida do que na média) seja inserir o produto extra como sendo uma oferta, a custo zero.
Se estás a fazer compras então está atento a mais requisitos.
O que disses-teestá tudo muito certo, mas há ai 2 pequenas lacunas!
Mas a "verdade" é que se te oferecem um
Nop,.. ninguem oferece nada a ninguem, e é mesmo a ideia de contemplar essa ideia, que parecendo que não há muita gente que ainda vai na canção do bandido.
inserir o produto extra como sendo uma oferta, a custo zero.
Ou seja,.. vai entrar:
2 unidades a 1,25 = 2,5
1 unidade a 0 = 0
3 unidades a 2,5
Vai dar ao mesmo, fica é mais especificado, talvez,... mas na minha opinião só vai dar mais trabalho na introdução dos dados por arte do utilizador.
(sai mais 1 camiao de batata pro CD do sul!! LOL)
É pá, não venhas com "ther's no such thing as a free lunch", sei isso muito bem...
Mas a verdade é que efectivamente o terceiro produto é gratuito, pois eu posso muito bem levar as enbalagens em separado, pagando o preço individual de cada uma, sem levar o grátis.
Não obrigatoriamente. Seria mais:
1 unidade a 1,25 = 0 (marcada como oferta)
As contas podem ser feitas excluindo as promoções. Ou seja, o utilizador poderá ter ao seu dispor:
- um relatório que lhe mostre o custo dos produtos que trouxe para casa, e se aqui a média é 0,8(3)€, a mediana vai ser 1,25€
- um relatório que lhe mostre o custo dos produtos que comprou, ou seja, que não foram oferecido, e aqui a média é igual à mediana, ou seja, 1,25€.
- um relatório de que mostre os qual o "ganho" no valor das promoções, e no caso acima, sendo 1 produto a 1,25€ seria 1,25€ de ganho.
Não é a mesma coisa, há uma granularidade diferente no detalhe do produto, que permite o KISC trabalhar de forma mais "real".
Sim.. é certo que isso vai levar a uma maior realismo, mas na minha ideia, como eu estou a imaginar 'a coisa' axo que a "complicação" que isso vai gerar, não compença no que diz respeito á eficiencia Vs facilidade de uso.
Mas é assim,.. estes promenores é que são os tais que temos de evoluir com o tmepo,... feito de uma forma ou de outra ao testar 'no campo' é que se vai ver ao certo se é melhor de uma ou de outra forma.
Conclusão, por mim aprovo esse sistema desde que não traga 'trabalheira' maior significativa no introduzir os dados por parte do utilizador.
Não é complicar, antes pelo contrário, é ter uma boa base que permite flexibilidade e não é limitante.
Não pode ser assim, pois "empurrar o problema com a barriga" leva a más decisões que se pagam caro mais à frente. Se optarmos por uma coisa mais limitada, vamos ficar de mãos atadas quando quizermos evoluir. Mesmo que não tenhamos toda a funcionalidade agora, podemos, e devemos, deixar uma boa base montada.
Uma coisa é o que o sistema suporta, outra coisa é a forma como o utilizador usa esse suporte. Se ele quizer pode meter 3 yogurtes a 2,5€, embora me parece que isso deva ser desencorajado no manual de utilização, ou pelo menos explicar quas as consequências de usar uma ou outra abordagem e, pior, qual a consequência de misturar as abordagens.
Por mim, está escalrecido esse ponto, siga....
Publicado 28 de Setembro de 2006
Fiquei sem preceber... tanta conta :s ..... Vai afectar o preço e a quantidade de stock ou nao ???
sorry mas nao precebi msm....
Outra cena que me lembrei que se custuma trabalhar com comida e os lotes... imagimenos que vamos para uma cozinha industrial onde vem lotes completos, axo que devias ter a possibilidade de intrudizir isso... no meu ver ou estou enganado ???