IT Management blog

In questi giorni mi sono passate sotto gli occhi alcuni testi con delle critiche su ITIL, ne parliamo in questo post.

Le critiche maggiori sono le seguenti:

• La tendenza di ITIL di essere considerato quasi una religione (e quindi non discutibile)
• La diffusa percezione di esso come un framework, una metodologia olistica per la governance dell'IT

ITIL in realta' non e' altro che un insieme di best practices, messe insieme per facilitarne l'implementazione da parte dei professionisti IT. Non e' una metodologia formale e scientifica per cui discostarsi vuole necessariamente dire sbagliare. La stessa OGC, editrice di ITIL, non dice che le best practices di ITIL siano puri processi. L'OGC sottolinea anche che l'ITIL non e' un modello olistico e fortemente coerente, ma un insieme di indicazioni.

Lasciamo perdere ITIL dunque come un'altra "buzzword" dell'IT che ha fatto il suo tempo? Niente affatto. ITIL e' un insieme di indicazioni fondamentali sia per chi gestisce l'IT sia per chi ci lavora. Queste critiche servono solo a fare riflettere che non e' sufficiente abbandonarsi ad una dottrina salvifica per essere salvi (perdonatemi la metafora mistica...) ma occorre applicare criticamente quello che di questa dottrina e' applicabile ed utile nella nostra organizzazione IT.

Questa consapevolezza ci permettera' di avvantaggiarci realmente di tutte le possibilita' offerte dall'ITIL.

Il Project Management Body of Knowledge (PMBOK®),  descrive, dal punto di vista del Project Management Institute (PMI), niente meno che la somma della conoscenza ("sum of knowledge") nella professione del Project Management. Il PMI ha sintetizzato nella propria Guida al PMBOK® il sottoinsieme "generalmente accettato" dalla somma della conoscenza e delle pratiche di project management. Pratica o conoscenza "generalmente accettata" va intesa come applicabile alla maggior parte dei progetti la maggior parte delle volte.

La definizione di progetto nella Guida al PMBOK® e' la seguente: "un progetto e' una impresa (sforzo) temporanea che mira a creare un prodotto o servizio unico". Questa definizione suggerisce le seguenti cose:

• Sforzo temporaneo, con un'inizio ed una fine ben definiti
• Prodotto o servizio unico, che non e' mai stato creato in precedenza

Il Project Management, per il PMI, non e' altro che l'applicazione di conoscenza, skills, strumenti e tecniche alle attivita' di progetto al fine di raggiungere gli obiettivi del progetto (il prodotto o servizio in questione). Vi sono conoscenze relative al management in generale (general management) e conoscenze relative all'area tecnica specifica (application areas) che non sono incluse nella guida al PMBoK, nonostante siano necessarie per la gestione di un progetto.

Il framework della guida al PMBOK® si divide in:

• Gruppi di processi (process groups)
• Aree di conoscenza (knowledge areas)
• Processi (project processes)

I process groups organizzano i processi secondo la loro posizione relativa nel ciclo di vita. Essi sono i seguenti:

• Initiating processes, orientati all'autorizzazione del progetto o della fase di progetto
• Planning processes, orientati a definire e raffinare gli obiettivi del progetto e le attivita' da eseguire.
• Executing processes, orientati al coordinamento delle attivita', risorse umane e non.
• Controlling processes, orientati alla misurazione ed al controllo del raggiungimento dei varii obiettivi
• Closing processes, orientati a formalizzare l'accettazione da parte del cliente a alla chiusura del progetto

Le Knowledge areas, accorpano i diversi processi in aree di conoscenza omogenee. Queste sono:

• Project integration management, orientato a mantenere una visione olistica nella pianificazione, esecuzione e controllo dell'intero progetto
• Scope management, orientato alla gestione dei requirements di progetto
• Time Management, orientato alla gestione dei tempi
• Cost Management, orientato alla pianificazione e controllo dei costi
• Quality management, orientato alla pianificazione, gestione e controllo della qualita'
• Human Resources management, orientato alla pianificazione e gestione delle risorse umane
• Communication management, orientato alla pianificazione, gestione e controllo della comunicazione
• Risk management, orientato alla pianificazione e controllo dei rischi
• Procurement management, orientato alla pianificazione, gestione e controllo degli acquisti e dei contratti

I 39 processi identificati nel PMI si situano in una matrice che incrocia i process groups con le knowledge areas. Ne diremo piu' in dettaglio in post successivi...

Frustrati perche' non trovate le informazioni che cercate nella vostra azienda/organizzazione?....

Molte organizzazioni potrebbero risparmiare milioni di euro se implementassero progetti di Knowledge management che rendano le informazioni e best practices disponibili in tutta l'organizzazione. Dal 25% al 50% (ed in molti casi molti di piu') dei documenti presenti nelle intranet aziendali non sono indicizzati e sono quindi difficili da cercare.

I problemi causati dalla mancanza di accesso a queste informazioni includono i seguenti:

• Decisioni sbagliate prese sulla base di informazioni insufficienti
• Duplicazione delle attivita' dovuta alla mancanza di informazioni relative alle attivita' svolte da altre business units
• Produttivita' persa a causa di informazioni non trovate dallo staff che deve quindi perdere tempo a cercarle o far perdere tempo a colleghi in richieste di aiuto
• Vendite mancate a causa di clienti che non riescono a trovare le informazioni necessarie su un prodotto e rinunciano ad un acquisto.

Si stima che in un azienda con 1000 dipendenti possa sprecare $48,000 alla settimana (circa 2,5 milioni di dollari all'anno) a causa di tali lacune. Si stima anche che il ROI su i progetti di knowledge management che migliorano la ricerca e reperibilita' delle informazioni va dal 38% al 600%.

Da TechRepublic, Marzo 2005

L'esame di certificazione ITIL si divide in tre livelli:

• ITIL Foundations
• ITIL Practitioner
• ITIL Service Management

La qualifica ITIL Foundations certifica un livello base di conoscenze sull'IT Service Management ed e' orientata a tutte le persone che desiderino imparare le best practices per l'IT Service Management cosi' come definite in ITIL. La certificazione  ITIL Foundations, in particolare, permette alle persone di capire i concetti e le terminologie utilizzate in ITIL. L’esame di certificazione ITIL Foundations può essere sostenuto ovunque (negli stessi centri Prometric ove si sostengono gli esami microsoft, Cisco, etc..) e non e' necessario seguire un corso.

La certificazione ITIL Practitioner e' orientata alle persone responsabili di specifici processi all'interno dell'IT Service Management nella propria organizzazione. L'esame ITIL Pracitioner si focalizza su specifiche aree e richiede la partecipazione ad un corso da parte di enti abilitati. Per la certificazione Practitioner, sono disponibili i seguenti esami:

• ITIL Practitioner Service Desk/Incident Management/Problem Management

• ITIL Practitioner Configuration/Change/Release Management

La Certificazione ITIL Service Management (Manager's Certificate) e' quella di livello piu' alto. E' orientata alle persone che dimostrano capacita' di gestire soluzioni basate su ITIL su tutti i processi relativi. Il programma per la certificazione ITIL Service Management prevede i due corsi sulle aree ITIL, Service Support e Service Delivery, e un corso della durata di due giorni dedicato alla revisione dei contenuti e alla preparazione dell’esame ITIL Service Management. Mentre gli esami di livello piu' basso prevedono solo domande di tipo multiple choice, in questo esame vi sono open questions ove viene misurata anche l'esperienza nel risolvere casi reali, e non il solo nozionismo.

Il MOF e' stato citato in un post precendente e ne parliamo un po' piu in dettaglio nel post di oggi.

Il MOF e’ una raccolta di best practice, principi e modelli studiata da Microsoft per gestire/supportare ambienti mission-critical al fine di raggiungere  livelli adeguati di reliability, availability, supportability, e manageability per le soluzioni e i servizi basati sulla tecnologia Microsoft. Il MOF combina gli standard definiti da ITIL con guidelines spedifiche relative all’implementazione e alla gestione di sistemi basati su tecnologie Microsoft.

Rispetto ad ITIL il MOF e' ottimizzato pensando alla piattaforma MS, ma applicabile ad ogni altra. Oltre a cio' il MOF da' prescrizioni piu' dettagliate. ITIL, al contrario di MOF e'completamente indipendente dalla piattaforma e da' solo indicazioni descrittive (non prescrittive).

Il MOF definisce tre modelli:

• il "Process Model"
• il "Team Model"
• ed il "Risk Management Model".

Il Process Model descrive i processi che i vanno eseguiti per gestire e manutenere i sistemi e servizi IT. Il MOF schematizza il Process Model in quattro aree (quadranti):

• Il "Changing Quadrant" include i processi ITIL di Change Management, Configuration Management e Release Management. Il quadrante Modifica di MOF contribuisce a migliorare i processi di gestione dei servizi IT in tutte le fasi del loro ciclo di vita.
• L' "Operating Quadrant" include processi descritti da ITIL (anche se non nel proprio framework di Service Management, ma nella parte di ICT Insfrastructure Management) quali System Administration,  Directory Administration,  Security Administration,  Service Monitoring and Control, Job Scheduling, Network Administration, Storage Management. Il quadrante Supporto di MOF mira a rendere l'infrastruttura più robusta e capace di soddisfare le esigenze di disponibilità e sicurezza. Le verifiche periodiche dell'operatività promuovono un continuo miglioramento dei processi operativi.
• Il "Supporting Quadrant" include i processi ITIL di Service Desk, Incident Management, Problem Management. Il quadrante Supporto di MOF descrive le procedure e i processi necessari per supportare in modo completo un utilizzo efficiente dell'infrastruttura IT. L'obiettivo dei ruoli definiti in questo quadrante è identificare, analizzare e risolvere un'ampia varietà di problemi IT dei clienti
• L' "Optimizing Quadrant" include i processi ITIL di Service Level Management, Financial Management, Availability Management, Capacity Management, Service Continuity Management, Security Management ed aggiunge a questi i processi di Workforce Management e Infrastructure Engineering, non esplicitamente presenti in ITIL. Le linee guida per l'ottimizzazione fornite da MOF offrono l'assistenza necessaria per una gestione più efficace dei livelli di servizio, una migliore pianificazione della capacità e altre attività di programmazione a lungo termine

Il Team Model supporta il Process Model fornendo guidelines per organizzare le risorse umane in team operativi (definiti anche "role clusters") e descrive le attivita' chiaveper ogni role cluster. Il Team Model e' stato sviluppato per poter gestire la complessita di team distribuiti che gestiscono sistem distribuiti. Pur mantenendo un alto grado di flessibilita', il Team Model riconosce specifiche responsabilita' ai vari ruoli nei team.

Il Team Model, come detto, individua specifici role clusters: individui o gruppi che si occupano di attivita' correlate relative a determinati componenti del servizio IT. Questi role clusters sono basati su best practices nella strutturazione dei team di IT operations.

I role clusters del Team Model sono organizzati in sette categorie generali, ognuna con i propri obiettivi. Le descrizioni dei ruoli nel role cluster sono focalizzate alle attivita' diretta a raggiungere gli obiettivi.

Le sette categorie sono le seguenti: 

• Infrastructure (manutenzione dell'infrastruttura ed evoluzioni della stessa, inclusa la gestione degli asset)
• Operations (amministrazioni di sistemi, processi ripetitivi -backups, etc-)
• Partner (relazioni con altre entita')
• Release (Change/Release e Configuration Management)
• Security (Definizione di Security policies ad enforcement delle stesse)
• Service (Allineamento del servizio alle necessita' del business, relazioni con i clienti, service improvement)
• Support (Supporto tecnico)

Il role clusters del Team Model si allineano in qualche modo con i quattro quadranti del Process model anche se piu' ruoli possono essere coinvolti in processi su un solo quadrante e lo stesso ruole puo' essere coinvolto in processi su piu' quadranti.

Il Risk Management Model integra tecniche di risk-management con il resto del framework. In pratica applica tecniche esistenti di risk-management ai problemi di IT operations applicandone i principi chiave e processi di analisi e valutazione di rischi nei vari processi.

Il MOF puo' essere, in sostanza, considerato come un'interpretazione dell'ITIL a quindi non alternativo ma sinergico ad esso.

E' molto utile analizzare il MOF quando si desidera dare corpo e sostanza ad una implementazione di Service Management. Non necessariamente bisognera' adottarlo "in toto", ma puo' dare valide indicazioni di dettaglio su come applicare certi concetti in pratica.

Quando abbiamo parlato di ITSM abbiamo citato il COBIT come uno dei framework disponibili, ne parliamo in questo post.

Il COBIT (Control Objectives for Information and related Technology ) e' un set (freamework) di best practices per il management dell'IT creato dall'ISACA Information Systems Audit and Control Association ), e dall'ITGI (IT Governance Institute) nel 1992. E' stato successivamente aggiornato nel 1996, 1998, 2000 e Dicembre 2005 (COBIT 4.0).

Il framework COBIT fornisce ai manager, utenti IT ed auditors un insieme di metriche, indicatori, processi e best practices per assisterli ad utilizzare al massimo i benefici derivanti dall'uso dell'information technology nelle organizzazioni e a sviluppare opportuni meccanismi di IT governance e controllo.

Il COBIT consiste di sei pubblicazioni:

• Executive Summary
• Framework
• Control Objectives
• Audit Guidelines
• Implementation Tool Set
• Management Guidelines

L'Executive Summary sostanzialmente e' un riassunto dell'intero framework orientato ai senior executives ed ai manager. In esso sono descritti i concetti chiave e vi e' inclusa una schematizzazione del framework.

Il Framework dettaglia come i processi IT forniscono le informazioni necessarie al business per raggiungere i proprio obiettivi. Questi processi informativo sono controllati attraverso 34 "control objectives" di alto livello, uno per ogni processo IT nei quattro domini identificati (Planning and Organization, Acquisition and Implementation, Delivery and Support, Monitoring). Il framework identifica sia quale dei sette criteri informativi (efficacia, efficienza, confidenzialita', integrita', disponibilita', compliance e affidabilita') sia quale risorsa IT (persone, applicazioni, tecnologie, facilities e dati) risulti essere importante per i processi IT per poter supportare gli obiettivi di Business.

I "control objectives" in COBIT forniscono i criteri per delineare chiare policies e buone pratiche per il controllo dell'IT. VI sono inclusi 215 "control objectives" di dettaglio nei 34 processi IT per cui nel framework erano stati definiti 34 "control objectives" di alto livello.

Le Audit Guidelines suggeriscono le attivita' da eseguire per ognuno dei 34 "control objectives" di alto livello.

L'Implementation Tool Set include informazioni (FAQs, case studies, etc...) da organizzazioni che implementatno COBIT, and slides (presentazioni) che possono essere usate per introdurre COBIT nelle organizzazioni

Le Management Guidelines sono composte da Maturity Models, per aiutare a determinare gli stadi e le aspettative; Critical Success Factors, per identificare le azioni piu' importanti per avere controllo sui processi IT; Key Goal Indicators, per definire target di performance; e Key Performance Indicators, per misurare se un processo di controllo IT sta raggiungendo i propri obiettivi.

Il Framework ITIL di cui abbiamo gia' parlato, non e' necessariamente un'alternativa, ma puo' essere considerato per certi aspetti un'integrazione al COBIT, ma di questo diremo di piu' in un post successivo...

Il "CIO magazine" ha pubblicato qualche mese fa i risultati di una survey: "The State of CIO 2006". Tra le altre cose questa survey ha evidenziato che il 55% degli IT executives ha pianificato di assumere IT staff durante l'anno.

Il personale piu' richiesto da questi IT executives sono i Project Managers. Uno skill abbastanza richiesto risulta anche essere il Business Process Management. Dal survey risulta che le conoscenze tecniche, un tempo ritenute fondamentali, non lo sono piu' per i professionisti dell'IT.

In ordine decrescente, i seguenti sono risultati sgli skill piu' richiesti dai responsabili IT contattati nel survey:

54% - Project Management
51% - Application Development
39% - Business Process Management
37% - Security
36% - Database Management
33% - Networking
33% - Help Desk and User support
31% - Architecture development or Management
27% - Web Services
27% - Business- or Industry-specific knowledge
27% - Infrastructure Management
22% - Web site development
19% - Emering technologies

Il Project Management e' una disciplina relativamente giovane, come tale non vi sono molti corsi universitari o scuole di formazione specifiche. Come sempre, le soluzioni nascono nel mondo anglosassone, e ve ne sono diverse.

La certificazione piu' accreditate nel project management (come al solito vi sono opinioni diverse in merito) sembra essere quella elaborata dal Project Management Institute (PMI). Il PMI offre due livelli di certificazione:

• Certified Associate in Project Management (CAPM®)
• Project Management Professional (PMP®).

La Certificazione CAPM e' indirizzato e membri di team di progetto ed a giovani project managers o aspiranti tali. Per sostenere l'esame CAPM occorre avere un minimo di esperienza sul campo (1500 ore) documentabili o 23 ore di lezioni sull'argomento. L'esame e' composto da 150 domande di tipo multiple choice.

La Certificazione PMP, di livello piu elevato, e' indirizzato a project managers. L’esame per la Certificazione PMP può essere sostenuto da persone con almeno tre anni di esperienza. La certificazione PMP, che testimonia la padronanza delle competenze e delle tecniche di project management, ha una validità di 3 anni e, per essere mantenuta, richiede la dimostrazione di un costante aggiornamento professionale.
Per poter ottenere la certificazione è necessario che i candidati soddisfino i requisiti stabiliti dal PMI e dimostrino un accettabile e valido livello di comprensione e conoscenza del Project Management: Laureati -  4500 ore di attività nel ruolo con almeno 3 anni di esperienza negli ultimi 6 anni, 36 mesi non sovrapposti; Non laureati -  7500 ore di attività nel ruolo con almeno 5 anni di esperienza negli ultimi 8 anni, 60 mesi non sovrapposti.  E’ necessario inoltre che i candidati dimostrino la propria preparazione con almeno 35 ore di formazione nel Project Management effettuata presso i REP (Registred Education Provider).

Entrambe le certificazioni si basano sulla codifica della disciplina del Project management elaborata dal PMI che e' pubblicata nel PMBoK (Project Management Body of Knowledge). Il PMBoK sara' oggetto di post successivi.

La risposta europea al PMI e' la certificazione su Prince2 (PRojects IN Controlled Environments), edita dal CCTA, adesso OGC (lo stesso padre di ITIL).

Esistono due livelli di certificazione Prince2:

• PRINCE2 Foundations
• PRINCE2 Practitioner

L'esame di livello foundations consiste di 75 domande a risposta multipla. La durata dell’esame è di un’ora. I candidati devono rispondere correttamente al 50% delle domande per superare l’esame.

L'esame di livello practitioner consiste di 3 domande che richiedono l’applicazione della metodologia ad uno scenario dato. La durata dell’esame è di 3 ore. I punti a disposizione dei candidati sono 150. E’ necessario raggiungere 75 punti per superare l’esame.

La metodologia alla base di PRINCE2 sara' oggetto di un post successivo.

Entrambe le opzioni discusse sopra (PMI e PRINCE2) sono indipendenti dall'IT, ma si possono agevolmente applicare ai progetti IT.

Esiste un'altra opzione, orientata all'IT e che segue in qualche modo le metodologie del PMI, offerta dalla CompTIA, la certificazione IT Project + . 

Qual'e' la migliore? Ovviamente non posso fare altro che dire salomonicamente di approfondire tutte e tre le opzioni e trovare quella che piu' fa per voi.

Come promesso in un post precedente, ecco di seguito alcune informazioni su ITIL, uno dei framework di ITSM citati.

Il framework ITIL (IT Infrastructure Library) si evolve dal 1989, anno in cui le prime pubblicazioni furono rilasciate dal CCTA (Central Computer and Telecommunication Agency del governo inglese). Questo framework e' basato fondamentalmente su best practices nel service management, non e' cioe' un modello teorico, ma una collezione di pratiche che hanno dato prova sul campo di essere funzionali ad una solida implementazione di IT Service Management di alto livello.

Secondo ITIL i tre obiettivi dell'IT Service Management (ITSM) sono i seguenti:

• allineare i servizi IT con i bisogni correnti e futuri del business e dei clienti
• migliorare la qualita' dei servizi IT  erogati
• ridurre i costi fissi di erogazione dei servizi

La filosofia ITIL adotta un approcio process-driven che si puo' utilizzare in organizzazioni sia grandi che piccole. L'IT service management e' scomposto in una serie di processi integrati e correlati tra loro.

I processi di ITSM in ITIL sono divisi in due aree principali:

• Service Support
• Service Delivery

Nell'area di Service Support vi sono i seguenti processi:

•  Service Desk (in realta' e' una funzione e non un processo)
•  Incident management
•  Problem Management
•  Configuration Management
•  Change Management
•  Release Management

Nell'area di Service Delivery vi sono i seguenti processi:

• Service Level Management
• Financial Management for IT services
• Capacity Management
• IT Service Continuity Management
• Availability Management

Analizzeremo i vari processi in dettaglio  in post successivi.

ITIL suggerisce sia implementato il proprio framework di service management (e che hanno valore anche oltre l'ITIL) secondo una successione ben definita di passi (process improvement model) che portano ad uno stato in cui il miglioramento del processo e' costruito all'interno del processo stesso. I passi sono:

• Definizione della Visione e degli obiettivi di business (chiedersi dove si vuole arrivare)
• Assesment della situazione corrente (chiedersi dove si e' adesso)
• Definizione del percorso di implementazione (chiedersi come arrivare fino alla realizzazione della visione e degli obiettivi di business)
• Definizione dei criteri di misura e di metriche (chiedersi come definire i punti di arrivo in termini quantitativi)

Esistono in commercio tool di assessment e planning per l'implementazione di ITIL nella propria organizzazione (alcuni sono gratuiti --> ITIL Service Management Self Assessment) .

Vi siete mai trovati a scrivere specifiche per progetti software e non sapevate da dove iniziare? Non siete i soli. In questi giorni mi sono ritrovato a scrivere qualcosa del genere dopo qualche anno che non lo facevo piu' e quindi colgo l'occasione per fare un post sull'argomento.

Il primo e' piu' prezioso consiglio che mi sento di dare e': riferitevi a degli standard (meglio se riconosciuti a livello mondiale) per stilare il prezioso documento. Esistono diversi standard in giro: IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998), etc... Verificate se nella vostra organizzazione si usino degli standard interni.

Qualsiasi standard andrete ad usare senz'altro varra' la pena avere chiaro cosa il documento dovra' coprire (come minimo...):

• Funzionalita': quali funzioni dovra' fornire?
• Interfacce esterne: come interagira' con le persone, con'l'hardware e con altri software?
• Performance: quale dovra' essere la velocita', disponibilita', etc.. del sistema?
• Attributi: Vi sono considerazioni da fare relativamente alla portabilita', sicurezza, manutenibilita' del sistema?
• Constraints architetturali imposti: vi sono standard da seguire sul linguaggio, policies, risorse, implementazioni, sistemi operativi?

Le specifiche hanno un ruolo preciso nell processo di sviluppo software, chi le scrive deve essere attento a non andare oltre i limiti di questo ruolo. Questo vuol dire che dovra' definire correttamente tutti i requisiti del software ma non dovra' descriverne l'architettura o dettagli dell'implementazionie; questi fanno parte di uno stadio successivo di progetto, descriverli qui potrebbe limitare innaturalmente le possibilita' di evoluzione successiva.

Idealmente il documento dovrebbe avere le seguenti caratteristiche (solo le piu' importanti sono riportate):

• Corretto: un documento e' corretto se e solo so ogni requisito ivi descritto e' richiesto nel software in oggetto(sembra banale? meglio ricordarlo).
• Chiaro: un documento e' chiaro (non ambiguo) se e solo se ogni requisito ivi descritto ha una sola interpretazione possibile (e' utile a questo scopo usare i termini in modo univoco e definirli in un glossario a corredo)
• Completo: un documento e' completo se e solo se include tutti i requisiti necessari a descrivere il software in oggetto
• Consistente: un documento e' consistente se e solo se: a) non e' in contraddizione con nessun documento ufficiale di piu' alto livello che descrive il software, b) le varie parti non sono in contraddizione tra di loro.
• Verificabile: un documento e' verificabile se e solo se tutti i requisiti ivi descritti sono posti in modo da poter verificare in modo non ambiguo la corretta realizzazione di essi nel prodotto finale.

Possibile tavola dei contenuti di un documento descrivente specifiche software:

 Tavola dei Contenuti
 1. Introduzione
  1.1 Scopo (illustra lo scopo del documento e specifica l'audience del documento)
  1.2 Ambito del progetto (illustra ad alto livello cosa il software fara' - e cosa non fara')
  1.3 Definizioni (il glossario di cui dicevamo sopra)
  1.4 Riferimenti (eventuali riferimenti ad altri documenti)
  1.5 Overview (una descrizione del contenuto del documento)
 2. Descrizione
  2.1 Prospettiva di prodotto (il prodotto viene messo nel contesto di prodotti correlati)
  2.2 Funzioni del prodotto (descrizione ad alto livello delle funzioni)
  2.3 Utenti (descrizione delle classi di utenti che useranno il prodotto)
  2.4 Constraints architetturali (descrizione di eventuali limitazioni di disegno e spiegazioni di esse)
 3. Requisiti di sistema
  3.1 Interfacce esterne
   3.1.1 Interfaccia utente
   3.1.2 Interfacce hardware
   3.1.3 Interfacce software
  3.2 Requisiti
   3.2.1 Classe utente 1
    3.2.1.1 Requisito funzionale 1.1
    .
    .
    .
    3.2.1.n Requisito funzionale 1.n
   3.2.2 Classe utente 2
   .
   .
   .
   3.2.m Classe utente M
    3.2.m.1 Requisito funzionale m.1
    .
    .
    .
    3.2.m.n Requisito funzionale m.n
  3.3 Requisiti di performance
  3.4 Constraints architetturali
  3.5 Attributi di sistema
 Appendici
 Indice

La tavola dei contenuti e' consistente con quanto consigliato nello standard IEEE citato sopra (questo standard da' diverse opzioni per organizzare il capitolo 3, ne ho scelto una piu' generale).

Il tempo dedicato a questa parte di progetto non va mai sprecato, non conosco progetti falliti per eccesso di tempo dedicato alle specifiche, ne ho visti diversi falliti per il motivo opposto...