Come conciliare questi due requisiti?

Question

Come conciliare questi due requisiti?

#1 da (8 voti)
#2 da (1 voti)

4

Sto sviluppando un sistema su cui ci sono due requisiti che sembra essere in conflitto. Poiché questa sembra essere una situazione che può essere più generale, ho pensato che fosse valido chiedere qui.

Il sistema in questione è destinato alla gestione delle finanze di un'azienda.

Nel sistema i clienti sono registrati e nei dati del cliente è possibile specificare i servizi che l'azienda sta fornendo per loro.

Il sistema ha anche un modulo di fatturazione, in cui l'azienda registra i suoi servizi e invia fatture ai clienti selezionando il servizio che hanno registrato.

I due requisiti in conflitto sono:

Nel modulo di registrazione del cliente, i servizi sono predefiniti. Si scelgono i servizi forniti per ciascun cliente e le proprietà del servizio corrispondente, che ottimizzano la modalità di fornitura del servizio. Il punto è che ogni servizio ha alcune proprietà di definizione. Inoltre, in altre aree del sistema, esiste una logica aziendale che deve conoscere tali servizi e proprietà. Questo rende i servizi terminati con hardcoded.
Nel modulo di fatturazione, l'utente finale desidera registrare i servizi autonomamente. Vogliono essere in grado di registrare i servizi e categorizzare i servizi che fatturano a modo loro.

Ora, questi due sono in conflitto perché è richiesta l'integrazione. Nel senso che quando un servizio viene fornito a un cliente, l'utente finale desidera che la fattura venga emessa automaticamente.

Un esempio: se c'è un servizio di supporto, sulla registrazione del cliente potrebbe esserci una classe che rappresenta il servizio o una proprietà del Cliente, indicante se il servizio è fornito o meno. Ciò consentirà al sistema di prendere decisioni e svolgere una logica di business correlata al Supporto fornito a questo Cliente.

D'altra parte, sulla parte di fatturazione del sistema, l'utente finale ha aggiunto manualmente un registro "Supporto". Ora, se abbiamo bisogno di automatizzare, non c'è modo in cui il sistema possa automaticamente sapere che il "Supporto" che è hardcoded lì, in una classe o in una proprietà, corrisponde alla voce "Supporto" sul database.

Secondo me, il modo corretto di risolvere questo problema è quello di rimuovere la possibilità per l'utente finale di registrare i servizi stessi. Ma poi c'è il problema: cosa succede se l'utente finale non vuole sentirlo e lo vuole in quel modo, non importa quale?

Come posso conciliare questi due requisiti? Come posso affrontare la situazione in cui in due parti del sistema appare lo stesso concetto, in uno deve essere effettivamente codificato e nell'altro l'utente vuole avere la libertà di registrarlo da solo? Credo che i contesti del DDD possano aiutare qui, ma non so ancora come.

domain-driven-design object-oriented-design domain-model modeling

posta user1620696 28.10.2016 - 17:08

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design object-oriented-design domain-model modeling

Come progettare il mio codice in modo che possa utilizzare informazioni alternative per aiutare a creare un oggetto E 'giustificato evitare l'identificatore di accesso privato in PHP?

score 8 · Answer 1

Sembra che tu non abbia due requisiti in conflitto; hai un requisito del cliente che è in conflitto con un'implementazione esistente.

Solo il requisito 2 sembra descrivere qualcosa che il cliente vuole davvero. Il requisito 1 descrive come qualcosa è stato già implementato e lo giustifica perché diverse parti del sistema "hanno bisogno" di qualcosa.

Questo sembra un caso di un problema molto comune: le decisioni tecniche stanno guidando in modo inappropriato le scelte progettuali e limitando ciò che è considerato possibile.

Le decisioni di implementazione che hanno portato a questo punto devono essere riviste.

Probabilmente l'implementazione che ha portato alla situazione in # 1 deve essere modificata in modo che sia possibile soddisfare le esigenze del cliente.
In alcuni casi, un requisito del cliente potrebbe non essere praticabile per motivi di business . Ad esempio, le funzionalità che desiderano non sono nel contratto o il loro budget o pianificazione non lo consentirebbero. Se è così, questa discussione deve essere riformulata nel contesto di ciò che è possibile da un business perpsective.
Occasionalmente, un requisito del cliente potrebbe essere effettivamente impossibile, a causa di una limitazione della tecnologia intrinseca. Ma questo è piuttosto raro, e il tuo caso non mi colpisce in quanto tale.

score 1 · Answer 2

Dal tuo commento:

Who decides what services must be provided in the system is the end user. The point is that by the way the end user told the requirements, it seems they want a predefined set of services on the customer registration, while they want to actually be free to type in the services at the billing part. The question is how do I deal with the fact that the service they typed in is the same as the predefined one. Actually I don't know why they want to type in any services. I edited the question trying to focus more on the requirement itself.

Sembra che tu stia confondendo un requisito utente e un requisito di sistema che esiste semplicemente a causa delle scelte di implementazione. Il sistema non è responsabile. Non ottiene un voto.

Hai sollevato un problema di input. È un classico: menu vs campo modulo libero. I menu assicurano che le scelte siano valide ma diventano rapidamente dolorose man mano che aumenta il numero di scelte.

I campi modulo libero gestiscono un gran numero di scelte, guarda google. Ma la forma libera si basa sull'utente che conosce il nome della cosa che desidera e che è in grado di scriverlo, motivo per cui Google ha investito così tanto nel controllo ortografico.

Ci sono due modi per colmare questa lacuna. Un menu che ti consente di digitare rende più tollerabile un gran numero di opzioni. E un campo di forma libera che ti guarda digita e dà suggerimenti può impedirti di entrare senza senso.

È lo stesso problema di interfaccia utente, indipendentemente dal fatto che si tratti di fatturazione o configurazione. Quindi il fatto che il tuo sistema lo faccia in modo diverso in posti diversi non è importante.

Dove questo diventa interessante (l'antico tipo cinese di maledizione interessante) è se è necessario aggiungere un nuovo servizio. Hai intenzione di lasciare che l'utente lo faccia? Vuoi che lo facciano senza sapere che questo è un nuovo servizio? Come far sapere loro che è nuovo? Come fai a impedire loro di creare un nuovo modo di scrivere un vecchio servizio?

Ci sono trucchi per affrontare tutto questo. E se questo è davvero quello che stai chiedendo su ux.stackexchange.com è probabile che tu voglia essere.