Nei miei occhi semplicistici, ci sono 2 tipi generali di "artefatti" dettagliati che circondano "requisiti" e "ambito" di un progetto o una parte di un progetto.
- Elementi necessari: ciò di cui il cliente ha bisogno / vuole. I requisiti sono in genere abbastanza utopici e cresceranno e cambiano man mano che l'attività del cliente cambia. User Story, output delle sessioni JAD, Use Case Models, wireframe delle schermate e altra documentazione focalizzata sul punto di vista del cliente, tutto in ordine, IMO. La dicitura è in genere nel dominio del cliente o degli utenti del sistema.
- Manufatti relativi alle specifiche del contratto - "definizioni" stabili e dettagliate di tutti gli articoli che devono essere consegnati nell'ambito di un contratto. Questi includono sia "specifiche" funzionali che non funzionali (cioè qualità quali prestazioni, sicurezza, robustezza, scelta della tecnologia, ecc.). Una specifica non promette di soddisfare tutti i requisiti dei clienti, e spesso una specifica è limitata a un pezzo parziale del sistema (ad esempio una "generazione" o una iterazione RUP, ma probabilmente un po 'più di una Agile Sprint). Le specifiche sono di natura molto più tecnica (ad esempio includeranno definizioni di interfaccia, impegni di performance e possibilmente schermate "scollegate"). E come hai eluso, un contratto è spesso indicato come ciò che NON è incluso nella fornitura. Qualsiasi venditore sa che ai clienti odiano viene detto cosa non otterranno.
In un progetto a prezzo fisso, è una scelta suicida per lo sviluppatore essere d'accordo a livello di requisiti, ma allo stesso tempo, può essere molto difficile per uno sviluppatore recuperare il costo di una specifica, e spesso ti spaventerai clienti non sofisticati con specifiche - spesso lo guardano con scetticismo a causa del gergo tecnico e dell'angolo legale del documento. Ma con clienti sofisticati (ad esempio quelli utilizzati per gestire progetti altamente tecnici, ad esempio NASA, ESA, ecc.) Questo livello di definizione non è affatto un problema. Ma la formalità aggiuntiva ha un costo - i ritardi sono spesso sostenuti mentre la documentazione va avanti e indietro finché non viene finalizzata.
Di conseguenza, credo che l'idea generale sia quella di spostare gli impegni con la maggior parte dei clienti lontano dal prezzo fisso e verso una base di sviluppo del progetto a pagamento, utilizzando strumenti come Agile e Scrum per garantire che il team stia offrendo al massimo efficienza e trasparenza, e il team di solito è strettamente integrato con il cliente, ad es nei locali del cliente e / o con le risorse del cliente nel team. In questo modo, il cliente può 'vedere' che tutti stanno tirando il loro peso, il cliente ha la capacità di cambiare la direzione del progetto tra gli sprint e il software tangibile e testabile viene consegnato a intervalli regolari. In questo modo entrambe le parti possono eludere completamente le "Specifiche del contratto" e lavorare su una base di fiducia reciproca.