Spécifica*on des besoins d affaires

Transcription

1 MTI820 Entrepôts de données et intelligence d affaires Spécifica*on des besoins d affaires Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 1

2 Le cycle de vie d un projet en BI Diagramme de flux de travail: Concep<on de l architecture technique Sélec<on et installa<on des produits Croissance Planifica<on de projet / programme Défini<on des besoins d affaires Modélisa<on des données Concep<on physique Concep<on et développement du système ETL Déploiement Concep<on des applica<on de BI Développement des applica<ons de BI Maintenance Ges<on de projet / programme Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 2

3 Ques*ons À quoi sert la spécifica*on des besoins? Que peut- il arriver si ceve étape est mal faite? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 3

4 «The most difficult part of requirements gathering is not documen*ng what the users want ; it is the effort of helping users figure out what they need that can be successfully provided» Steve McConnell (So#ware Project Survival Guide, Microso# Press) Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 4

5 Ques*ons Quelle est la différence entre les types suivants de besoins? : Besoins d affaires Besoins fonc*onnels Besoin non- fonc*onnels Besoins techniques Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 5

6 Spécifica*on des besoins Besoins d affaires: Représentent des objec*fs haut niveau d une entreprise qui jus*fient la valeur d entreprendre un certain projet; Ex: augmenter le taux de réponse aux campagnes de marke*ng ciblées. Besoins fonc*onnels: Dérivent des besoins d affaires; Expriment une ac*on que doit effectuer le système en réponse à une demande; Ex: produire automa*quement un rapport de synthèse des ventes hebdomadaires. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 6

7 Spécifica*on des besoins Besoins non fonc*onnels: Décrivent des qualités que le système doivent avoir; Ex: u*lisabilité, performance, disponibilité/fiabilité, sécurité, etc. Besoins techniques: Dérivent des besoins fonc*onnels et non- fonc*onnels Ex: Ou*l de forage de données, portail Web, cube de données, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 7

8 Deux niveaux d analyse des besoins [2/3] Processus d analyse (Kimball): Analyse niveau programme BP: processus d affaires (business process) Besoins d affaires regroupés par BP Sélec*on du BP (matrice en bus, diagramme de priorisa*on) BP prioritaire Analyse niveau projet Besoins fonc*onnels, non fonc*onnels, techniques Développement datamart Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 8

9 Ques*ons Comment la spécifica*on des besoins diffère- t- elle entre les niveaux programme et projet? Comment la spécifica*on des besoins diffère- t- elle entre le personnel d affaires et le personnel des TI? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 9

10 Deux niveaux d analyse des besoins [1/3] Niveau programme: Comprendre les besoins d affaires dans une perspec*ve englobant toute l entreprise; Surtout les besoins de la haute direc*on; Normalement fait une seule fois au début. Niveau projet: Analyse plus détaillée des besoins, concentrée sur un projet (sujet) bien défini; Surtout les besoins des cadres intermédiaires et des analystes d affaires; Fait pour chacun des projets. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 10

11 Deux niveaux d analyse des besoins [2/2] Tableau compara*f: Composante Niveau programme Niveau projet Prépara*on Recherche plus large sur l entreprise. Recherche concentrée sur un processus d affaire spécifique. Par*cipants Ques*ons Audit des données Documenta*on Représenta*on interfonc*onnelle horizontale; Proviennent surtout de la haute direc*on. Compréhension de haut niveau des principaux objec*fs, opportunités et processus d affaires. Évalua*on de faisabilité préliminaire de plusieurs sources poten*elles. Descrip*on des processus d affaires et des besoins correspondants; Version préliminaire de la matrice de données en bus. Représenta*on ver*cale centrée sur le processus d affaires concerné; Surtout des cadres intermédiaires et des analystes d affaires. Informa*ons et besoins d analyse plus spécifiques et détaillés; Rapports et analyses existants. Profilage préliminaire de 1-2 sources primaires de données. Descrip*on détaillée des besoins portant sur le modèle de données, les applica*ons de BI et l architecture technique. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 11

12 Personnel d affaires versus des TI Personnel d affaires: : Ne pas demander ce qu ils veulent avoir dans l entrepôt de données; : Discuter plutôt des éléments suivants: Leur travail au quo*dien; Leur objec*fs; Leur défis, etc. Personnel des TI: Permet de déterminer la disponibilité et la qualité des données supportant les besoins des u*lisateurs d affaires (audit des données); Permet d iden*fier les défis / limita*ons techniques poten*els du projet. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 12

13 Guide d entrevue (tiré du livre de Ralph Kimball) Introduction Discuter des objectifs du projet d entrepôt de données et de son statut; Discuter des objectifs de l entrevue; Présenter les différents membres de l équipe; Confirmer la durée de l entrevue; Décrire brièvement les étapes qui suivront l entrevue. Responsabilités Décrivez votre département et votre projet Quelles sont vos principales responsabilités? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 13

14 Objectifs d'affaire et défis (haute direction) Quels sont les objectifs de votre organisation? Qu est ce que l'entreprise tente d'accomplir? Quels sont vos principaux objectifs d'affaires? Comment identifiez-vous les attentes reliées à votre domaine d'affaire? Comment fixez-vous les attentes de votre entreprise? Comment mesurez-vous le succès de l'entreprise? Quelles métriques utilisez-vous? Dans quelle mesure êtes-vous capable de savoir que vous avez obtenu les résultats escomptés? Que vous allez dans la bonne direction? A quelle fréquence mesurez-vous votre performance? Quels sont les fonctions et départements au sein de votre organisation qui sont primordiaux dans l'atteinte de vos objectifs? Quels rôles jouent-ils? Comment collaborent-ils pour assurer le succès de l'organisation? Quels sont les principaux défis auxquels vous faites présentement face? Selon vous, qu'est ce qui pourrait vous empêcher de surmonter ces défis et d'atteindre vos objectifs? Quel serait l'impact de ne pas être en mesure de surmonter ces défis sur l'entreprise? Voyez vous présentement ou dans le future de votre organisation des opportunités de profits qui ne sont pas adressées aujourd'hui? Comment vous comparez vous a la compétition sur le plan de l'utilisation des technologies de l'information sur le plan global et sur le plan décisionnel? Êtes-vous en mesure de réagir rapidement aux conditions changeantes du marché? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 14

15 Objectifs d'affaire et défis (gestionnaires & analystes ) Quels sont les objectifs de votre organisation? Qu'est ce que l'entreprise tente d'accomplir? Quels sont vos principaux objectifs d'affaire? Comment identifiez-vous les attentes reliées à votre domaine d'affaire? Comment fixez-vous les attentes de votre entreprise? Quels sont les principaux défis auxquels vous faites présentement face? Selon vous, qu'est ce qui pourrait vous empêcher de surmonter ces défis et d'atteindre vos objectifs? Quel serait l'impact de ne pas être en mesure de surmonter ces défis sur l'entreprise? Comment identifiez-vous les problèmes et les exceptions? Dans quelle mesure êtes-vous capable de dire que des problèmes pointent à l horizon? Décrivez vos Produits? Comment distinguez entre vos différents produits? Comment les catégorisez-vous? Si nous assumons que le volume de votre catalogue nous empêche de passer en revue l'ensemble de vos produits lors de la recherche d'un produit spécifique, comment faite vous pour cibler votre recherche précisément? Ces différentes catégories sont-elles stables ou sont-elles appelées à changer fréquemment? Dans la mesure où elles sont appelées à changer, quel est l impact de ce changement sur vos processus d analyse? Recommencez l exercice précédent pour l ensemble des axes d analyse important: clients, fournisseurs, territoires. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 15

16 Besoins d'analyse (haute direction) Quelle est l'importance qu'occupe l'analyse des données au niveau des décisions que vous et vos principaux gestionnaires prenez pour gérer les opérations de votre organisation? Quelle information est jugée primordiale pour prendre et supporter les décisions au sein de votre organisation? Comment obtenez-vous cette information aujourd'hui? A votre connaissance, il y a de l'information qui ne vous est pas disponible ou qui n'est pas accessible aujourd'hui mais qui aurait un impact important sur l'atteinte de vos objectifs? Quels rapports utilisez-vous aujourd'hui? Quelle est l'information importante sur ces rapports? Comment utilisezvous cette information? Si ces rapports étaient dynamiques, que feraient-ils de différent? Quelles sont les opportunités qui s'offriraient à vous si vous étiez en mesure de bénéficier d'un meilleur accès à votre information? Quel en serait l'impact financier? Quel en serait l'impact sur l'organisation? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 16

17 Besoins d'analyse (gestionnaires & analystes ) Quelles sont les données utilisées? Comment obtenez-vous présentement ces données? Que faites-vous avec ces données une fois obtenues? Devez vous les manipuler? Quel type d'analyse voudriez-vous être en mesure d'effectuer? Voyez-vous des potentielles améliorations possibles aux méthodes/processus que vous utilisez actuellement? Quel sont les types d'analyse ad-hoc que vous effectuez de façon régulière? Qui sont les membres de votre équipe qui typiquement effectuent ou demandent ce genre d'analyse? Quel est le but de ces analyses? Quel est le niveau de satisfaction face au temps requis pour obtenir les résultats de ces analyses? Les membres de votre équipe ont ils le temps de pousser plus à fond ces analyses? En vous basant sur la qualité et sur le niveau de détail des données avec lequel vous devez traiter, quel pourcentage de temps passez-vous à manipuler les données et quel pourcentage de votre temps passez-vous à les analyser? Quels sont les types d analyses prédéfinies (rapports) que vous effectuez le plus souvent? Quelle est l'information importante sur ces rapports? Comment utilisez-vous cette information? Si ces rapports étaient dynamiques, que feraient-ils de différent? Devez vous retravailler ces rapports? Quelles informations aimeriez-vous voir ajoutées aux rapports? Quelles informations sont inutiles et pourrait être retirées? Quelles sont les capacités analytiques que vous aimeriez avoir? Existe-il aujourd hui des goulots d étranglement important qui nuisent à l accès à l information? Quel horizon de données historique avez-vous besoin dans le système? Quelles sont les opportunités qui s'offriraient à vous si vous étiez en mesure de bénéficier d'un meilleur accès à votre information? Quel en serait l'impact financier? Quel en serait l'impact sur l'organisation? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 17

18 Entrevues avec le personnel des TI Audit de données: Détermine la faisabilité du projet en termes de la disponibilité de données de qualité suffisante. Entrevue de conformité / sécurité: Détermine les direc*ves, standards et mandats règlementaires de l entreprise par rapport à l accès et l u*lisa*on des données; Ex: poli*ques de purge/réten*on de données, vie privée (privacy), etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 18

19 Ques*ons Comment préparer les entrevues? Comment faire les entrevues? Quoi faire avec l informa*on recueillie lors des entrevues? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 19

20 Prépara*on des entrevues Recherches préalables: Se renseigner sur l entreprise et le domaine d affaires ciblé. Sélec*on des personnes à interviewer: Impossible de s entretenir avec tout le monde; Choisir les personnes clés: influentes, ouvertes, etc. Demander l avis du ou des sponsors du projet; U*liser l organigramme; Ne pas considérer la disponibilité comme critère de sélec*on. Prépara*on des ques*onnaires: Doit être faite d avance; Varie selon la fonc*on et le niveau hiérarchique de la personne interrogée. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 20

21 Entrevues versus séances animées Entrevues: Faites individuellement ou en pe*ts groupes; Ne durent pas très longtemps (facilite la par*cipa*on des u*lisateurs); Nombreuses mais plus faciles à gérer; Assurent d avoir le point de vue de tout le monde. Séances animées: Faites en groupe de moyenne ou de grande taille; Discussions contrôlées par un animateur / modérateur; Encouragent la créa*on d idées (brainstorming); Peuvent accélérer la collecte des données; Normalement faites après avoir une vue d ensemble des besoins (niveau projet). Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 21

22 Équipe d entrevue Intervieweur principal: Dirige l entrevue en posant les ques*ons appropriées; Doit connaître le domaine des affaires et être un bon communicateur; Les analystes d affaires sont de bons candidats pour ce rôle. Rapporteur: Prend des notes détaillées sur les réponses obtenues; Sert de «filet de chute» en cas de besoins (ex: points mal compris par l intervieweur, tensions ou frustra*ons, etc.). Observateur: Rôle op*onnel. Ex: architecte de données, développeur d applica*ons BI, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 22

23 Synthèse des besoins recueillis [1/3] Une fois les entrevues terminées, on regroupe les besoins par processus d affaires (approche Kimball). Livrables: 1. Rapport d entrevues; 2. Document de spécifica*on des besoins; 3. Matrice de données en bus; 4. Diagramme de priorisa*on des processus. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 23

24 Synthèse des besoins recueillis [2/3] Rapports d entrevue: Descrip*on des responsabilités de la personne interrogée; Processus et besoins iden*fiés lors de l entrevue: Descrip*on sommaire des besoins; Obstacles analy*ques présents; Besoins spécifiques en termes d analyses et de données; Impact d affaires poten*els. Critères de succès. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 24

25 Synthèse des besoins recueillis [2/2] Document de spécifica*on des besoins: Vue d ensemble de l entreprise; Descrip*on détaillée du projet; Besoins regroupés par processus d affaires; Évalua*on préliminaire de la faisabilité en termes de données; Matrice en bus de données, au niveau de l entreprise; Critères de succès. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 25

26 Matrice en bus de données Processus / dimension Date Client Magasin Vendeur Produit Région Vente et Marke<ng X X X X X X Fournisseur Finance et comptabilité X X X X X X Approvisionnement X X X X X Inventaire X X X Ressources Humaines X X X Décrit les dimensions d analyse requises pour chaque processus d affaires. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 26

27 Diagramme de priorisa*on des processus impact poten*el BP4 BP2 BP1 BP3 BP5 BP6 faisabilité Permet d iden*fier les processus d affaires faisables ayant le plus grand impact pour l entreprise. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 27

28 Ques*on Comment fait- on pour évaluer la faisabilité et l impact d un projet centré sur un certain processus d affaires? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 28

29 Critères de succès du projet À demander à la fin de l entrevue; Permet de mieux comprendre les a}tudes et aventes des u*lisateurs; Exemple (ques*on): «Quelle sont les principales fonc*onnalités et caractéris*ques devant se retrouver dans le système afin de pouvoir le considérer comme un succès?» La réponse doit être un critère quan*fiable et mesurable; Exemple (réponse): «Le temps de réponse à une requête X doit être inférieur à 10 secondes» AVen*on aux les aventes irréalistes des u*lisateurs. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 29

30 U*lisateurs de BI Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 30

31 Ques*on Comment dis*nguer les différents types d u*lisateurs d une solu*on de BI? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 31

32 Connaître les u*lisateurs [1/3] Capacités techniques: Percep*on biaisée de leur niveau d exper*se (environ 10% à 15% des u*lisateurs le sont); Ne pas leur demander directement; Détermine la complexité technologique des applica*ons de BI. Temps disponible à l analyse: Varie beaucoup d un u*lisateur à l autre (ex: VP versus analyste); La plupart des u*lisateurs ont peu de temps; Détermine la complexité fonc<onnelle des applica*ons de BI; Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 32

33 Connaître les u*lisateurs [2/3] Type de ques*ons/analyses: État courant de l entreprise: Rapports, tableaux de bord, scorecards. Inves*ga*on ad hoc: Requêtes ad hoc, rapports paramétrables; Explora*on dynamique et détaillée: Drill- down cubes OLAP. Découverte de rela*ons/patrons/tendances: Forage de données, analyse prédic*ve. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 33

34 Connaître les u*lisateurs [3/3] Capacité technique versus temps: Temps Foreurs (requêtes ad- hoc, forage de données) Explorateurs (analyse OLAP, requêtes ad- hoc) Cul<vateurs (rapports paramétrables, analyse OLAP) Opérateurs (rapports paramétrables, tableaux de bord) Visiteurs (rapports, scorecards, tableaux de bord) Capacité technique Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 34

35 Visiteurs: Types d u*lisateurs [1/3] Cadres supérieurs ayant peu de temps à consacrer à l u*lisa*on de la solu*on BI; Besoins: Connaître le statut des indicateurs de performance à intervalles réguliers; Iden*fier des items d intérêt sans difficulté; Sélec*onner de l informa*on sans avoir à naviguer dans l interface; Opérateurs: Ges*onnaires départementaux, superviseurs, etc.; Besoins: Obtenir des réponses immédiates basées sur des données actuelles et fiables; Connaître l état courant des métriques de performance; Avoir un accès rapide à de l informa*on détaillée; Interface simple permevant des analyses rapides des données. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 35

36 Types d u*lisateurs [2/3] Cul*vateurs: Analystes d affaires en marke*ng, vente, finance, etc.; Besoins: Avoir un accès à des données de qualité, intégrées de diverses sources; Définir facilement des requêtes simples à l entrepôt de données; Comparer les données actuelles avec les données historiques. Explorateurs: Chercheurs et analystes techniques avancés; Besoins: Lancer des requêtes ad hoc et imprévisibles; Obtenir de grandes quan*tés de données servant à des analyses complexes; Longues sessions d analyse en rafale (i.e., pas à intervalle régulier). Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 36

37 Types d u*lisateurs [3/3] Foreurs: Analystes spécialisés en forage de données ou consultants externes; Besoins: Accès à une très grande quan*té de données historiques couvrant une période de plusieurs années; Appliquer des ou*ls de forage de données pour iden*fier des corréla*ons et des patrons u*les à la prise de décision; Pouvoir interpréter les résultats obtenus. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 37

38 Analyse des besoins [1/10] Sert à iden*fier: Processus d affaires; Indicateurs de performance; Dimensions d analyse et leur hiérarchies; Les faits et leur granularité; Historique requis de données; Qualité requise des données; Fréquence de mise à jour des données; Accès souhaité aux données. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 38

39 Ques*ons Qu est- ce qu un processus d affaires? Qu est- ce qu un indicateur clé de performance (KPI)? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 39

40 Analyse des besoins [2/10] Processus d affaires (business process / subject area): Ensemble de faits observables (métriques) représentant des ac*vités de l entreprise Ex: vente, factura*on, livraison, commande, etc. Typiquement supportés par un système opéra*onnel Ex: système de factura*on, système CRM, etc. Fournissent des indicateurs clés de performance (key performance indicator - KPI) Ex: profits (vente), taux de réten*on (CRM), délai moyen de livraison (livraison), etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 40

41 Exemples: Analyse des besoins [3/10] Domaine Processus / subject area Faits Automobile Tourisme Ventes Maintenance Occupa*on hôtelière Vols Prix de vente Prix suggéré du manufacturier Prix des op*ons Crédits du concessionnaire... Chambres occupées Chambres vacantes Vacantes non- disponibles Nombre d occupants ReceVes... Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 41

42 Analyse des besoins [4/10] Dimensions d analyse: Descripteurs servant à filtrer, grouper et é*queter un ensemble de données; S ob*ennent des ques*ons formulées par les u*lisateurs; Exemples: Fonc<on VP marke*ng Manager marke*ng Contrôleur financier Exemple de ques<on Combien de revenus notre nouveau produit génère- t- il par: mois, division, démographique de clients, bureau de vente, comparagvement au produit précédent, etc.? Quelles sont les sta*s*ques de vente par: produit ou catégorie de produit, semaine ou mois, canal de distribugon? Quelles sont les dépenses par: valeurs actuelles vs budget, mois ou trimestre, poste, district ou division, etc.? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 42

43 Analyse des besoins [5/10] Catégorie Processus Dimensions Chaîne de supermarché Entreprise manufacturière Compagnie d assurances Transporteur aérien Ventes Livraisons Réclama*ons Vols Temps Promo*on Produit Magasin Temps Envoyé- à Envoyé- par Produit Entente (deal) Temps Agent Type Police Statut En*té assurée Temps Client Vol Aéroport Classe de tarif Statut Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 43

44 Analyse des besoins [6/10] Hiérarchies dimensionnelles: Précisent les différents niveaux de détail de l analyse le long d une certaine dimension; Les niveaux sont souvent «emboîtés» les uns dans les autres, mais pas toujours; Les niveaux sont parcourus à l aide des opéra*ons de drill- down et roll- up; Exemples: Dimension Temps Région Ressource Produit Hiérarchie jour < mois < année < succursale < ville < région < province < pays < employé < équipe < département < division < no série < code < marque < catégorie < famille < Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 44

45 Analyse des besoins [7/10] Naviga*on dans une hiérarchie: Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 45

46 Analyse des besoins [8/10] Granularité des faits: Le niveau de détail le plus fin d une mesure ou métrique; Découle du processus d affaire; A un impact sur la faisabilité du projet. Exemple: Transac*on: (ID client, code produit, date, montant); Analyses possibles Ventes par code /marque/catégorie de produits; Ventes par jour/mois/année; Analyses impossibles Ventes par heure/période de la journée; Ventes par magasin/région/province; Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 46

47 Analyse des besoins [9/10] Historique des données: La période en nombre de jours/mois/années couverte par les données; Le nombre de données (faits) disponibles durant ceve période; Certaines analyses requièrent une historique minimale pour être menée (ex: modèles de prédic*on); Les systèmes sources doivent être en mesure de fournir ces données. Qualité des données: A un impact direct sur la faisabilité et la complexité de la solu*on; Se détermine à par*r des audits de données (personnel en TI) et du profilage de données; À vérifier: données manquantes/invalides, granularité, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 47

48 Analyse des besoins [10/10] Fréquence des mises à jour: Faites en lot, sur demande ou en temps- réel; Selon les besoins des u*lisateurs; A un impact sur l architecture technique (ex: serveurs, réseau, etc.). Accès aux données: L informa*on doit- elle être accédée de n importe où?; L accès aux donné doit- il être sécurisé/contrôlé?; Technologies: plateformes mobiles, portail Web, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 48

49 Ques*on Comment peut- on s assurer que notre compréhension d un requis correspond bien à ce qui a été formulé par l u*lisateur? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 49

50 Prototypage de la solu*on Incer*tudes: L u*lisateur ne sait pas toujours ce qu il veut; L u*lisateur ne sait pas toujours communiquer ses besoins; L impact de la solu*on est difficile à prévoir; La qualité des données n est pas certaine. Prototypage: Philosophie de développement agile; Solu*on rapide et non coûteuse; Réduit le risque de ne pas répondre aux besoins; Approche itéra*ve; L effort inves* sera capitalisé dans les prochaines étapes. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 50

51 Consignes pour la spécifica*on des besoins [1/2] 1. Ne pas confondre les besoins d une solu*on BI avec ceux d un système d informa*ons transac*onnelles: Besoins BI sont centrés sur les processus et valeurs d affaires, non pas sur les données ou les technologies; Besoins BI sont plus complexes et diversifiés. 2. Ne pas confondre les besoins au niveau programme et au niveau projet: Besoins généraux de l entreprise vs spécifiques à un processus par*culier; Les personnes à interroger diffèrent. 3. Bien séparer les besoins d affaires, fonc*onnels et techniques: Les besoins fonc*onnels découlent des besoins d affaires; Les besoins techniques découlent des deux précédents. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 51

52 Consignes pour la spécifica*on des besoins [2/2] 4. U*liser l approche «elicit, specify and test»: Elicit: aider l u*lisateur à iden*fier leurs besoins; Specify: documenter les besoins; Test: s assurer que les besoins sont clairs, complets, cohérents, nécessaires et faisables. 5. Avoir un processus clair pour gérer les besoins: Le processus doit comprendre les éléments suivantes: Iden*fica*on ex: code unique; Enregistrement ex: patron de descrip*on; Traçage ex: technique! fonc*onnel! d affaires; Changement ex: date et heure de modifica*on; Classifica*on ex: affaires vs fonc*onnel vs technique; Vérifica*on ex: clarté, nécessité, faisabilité, etc.; Priorité ex: faible vs moyenne vs élevée. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaGi, C. Desrosiers 52