Il presente documento è una guida per una procedure di raccolta e gestione dei requisiti per progetti di realizzazione su commessa di nuovo software (requirements engineering).
Per una corretta organizzazione del progetto occorre identificare le seguenti figure (ruoli)
Come per ogni realizzazione su commessa, l'aspetto cruciale per la riuscita del processo è una corretta comunicazione lungo la catena delle figure coinvolte. Una delle maggiori criticità è la verticalizzazioni delle competenze: i progettisti conoscono il loro ambiente di sviluppo, gli operatori conoscono le loro procedure. I loro ambiti di conoscenza sono totalmente distinti.
Per piccole organizzazioni, le figure coinvolte sono spesso incorporate tra loro: dall'estremo in cui l'utente si fa il suo applicativo, alla piccola software house specializzata nel settore in cui ogni addetto, che magari ha esperienze lavorative nel settore dell'azienda cliente, segue ogni passo del progetto e impersona di volta in volta tutti i ruoli suddetti. Queste strutture organizzative semplificate hanno l'indubbio vantaggio di ridurre al minimo i conflitti tra quello che il cliente si aspetta e quello che gli viene dato. Gli svantaggi invece sono quelli della mancata divisione del lavoro:
All'evolversi della struttura organizzativa, aumenta la verticalizzazione delle competenze e di conseguenza la necessità di una corretta e formale trasmissione delle informazioni da una persona all'altra (documentazione).
Le cause di insuccesso nel progetto per nuovo software sono le medesime di ogni altro progetto ma si sottolineano in particolare la mancata iterazione cliente-fornitore:
C'è poi la tendenza dell'operatore a pensare che il fornitore di software soddisferà nell'ambito del progetto in corso tutti i suoi desideri presenti e futuri, espressi o inespressi, a carico del fornitore; va fatto presente fin dall'inizio che:
E' fondamentale riuscire ad anticipare il più possibile la formalizzazione dei requisiti. Per una buona riuscita del progetto occorre da parte del PM: