Modellazione di requisiti aziendali altamente specifici

L'opzione mi sembra soddisfacente se fornisci qualche sorta di impostazione di configurazione da qualche parte nel sistema in modo che tu possa modificare gli indirizzi Email.

L'opzione due sembra un eccesso per ciò che sembra essere un requisito aziendale relativamente semplice. Implementalo solo se sembra che risolverà più problemi rispetto a questo specifico requisito.

Ti suggerisco di prendere entrambe le opzioni.

Passaggio 1: introduce il concetto di una categoria Alertable che può essere applicata ai progetti. Per ogni istanza di Alertable , consenti l'allegato di uno o più utenti (che hanno indirizzi email). Introduci il concetto di Condition che può essere associato a ogni Alertable che contiene un predicato generalizzabile. Quindi modellerai questi concetti sulla tua lavagna fino al punto in cui puoi vedere chiaramente la maggior parte del codice.

Passaggio 2: Ora, prendi il tuo codice esistente e usa la terminologia dei concetti che hai creato nel paragrafo precedente, implementa la capacità. Collegherai con forza il progetto Y per far finta che abbia un'istanza Alertable , hard wire il rilevamento Condition e quindi esegua il processo di avviso con il filo rigido.

Il tuo codice potrebbe essere simile a questo:

In Project oggetto:

Boolean isAlertable() {
   return projectNumber == MAGICNUMBER;
}

Nell'oggetto PurchaseOrder , controlla il progetto per isAlertable() . Filo rigido controllare la condizione in questo momento, perché l'implementazione di un predicato generalizzato è prematura. Quindi, chiedi a Project di inviare le email di avviso.

Il punto del primo passo è vedere se capisci veramente il concetto. Mette anche le basi per lo sviluppo futuro. Il punto del secondo passo è portare a termine il lavoro. Vi è una buona possibilità che, in futuro, riceverai tipi simili di richieste di requisiti di avviso "dispari". In tal caso, puoi essere pronto con un disegno che puoi applicare.

This requirement supplements other requirements surrounding purchase orders, but comes in at a much later date in response to some ongoing problem elsewhere in the business.

Sembra che tu pensi che, una volta risolto questo problema, il tuo cliente non avrà più alcun problema in corso altrove nella bussiness . L'esperienza dimostra che avranno.

E dovresti pianificare di conseguenza un sistema che sia estensibile. In effetti, IM (ns) HO avrebbe dovuto essere fatto fin dall'inizio; pensare che le regole di convalida di un acquisto possono cambiare nel tempo non è qualcosa, e avrebbe aiutato a implementare le regole che conoscevi in anticipo (rendendole più modulari).

Comunque per me non è una domanda di programmazione ma una domanda di gestione del progetto. Dal momento che non era contemplato nel progetto iniziale perché nessuno chiedeva di questa possibilità, potrebbe essere il momento di chiamare gli stakeholder e lasciarli decidere: una soluzione veloce e sporca che richiederà modifiche al codice per ogni cambiamento o una più flessibile soluzione che verrà consegnata in seguito (e probabilmente con alcuni costi aggiuntivi).

Sono gli stakeholder che sanno davvero cosa c'è nella bilancia (quanti di questi cambiamenti possono accadere, quali sono i costi di implementazione del progetto in ritardo, anche se quel controllo è davvero così importante che non può essere fatto da fare in modo che qualcuno riveda i dati in un rapporto).

Puoi fare un'ipotesi istruita sull'importanza di tali cambiamenti, ma in realtà non puoi esserne sicuro. Inoltre, coinvolgendo le parti interessate e facendole decidere, puoi sperare di educarle a realizzare i costi delle specifiche incomplete / tardive in modo che nel prossimo progetto facciano un lavoro migliore.