Vragen m.b.t. inhoud functioneel ontwerp

[Verwijderd]

Ik ben bezig met een functioneel ontwerp voor een website. Dit (dan aangepaste) FO moet later ook gebruikt worden voor andere soortgelijke websites.

Ik heb het volgende in gedachten om in het functioneel ontwerp te zetten:

- algemene beschrijving van de website

- beschrijving projectteam (naam, rol, contactgegevens)

- beperkte technische specificaties (serverinformatie, browser vereisten, schermresolutie, domeinnaam)

- schema navigatiestructuur (grove + fijne indeling met logo, header, banner,
menu, advertenties, main, nieuws)

- beschrijving alle menu-items + werking navigatie (wat gebeurt er als ik hier op klik e.d.)

- juridische voorwaarden

- aanmelding bij zoekmachines

- statistieken

- opleveringsinformatie

- terminologie (beschrijving moeilijke woorden)

Weten jullie nog iets wat er uit kan of juist er nog in moet?

En moeten afspraken m.b.t. de vormgeving ook in het FO staan? Of komen deze in het plan van aanpak die nog voor het FO wordt opgesteld?

De planning wordt trouwens beschreven in een apart excelbestand.

[ Voor 15% gewijzigd door Verwijderd op 23-06-2004 16:47 . Reden: Volgorde aangepast ]

[Willem]

Ga je het in deze volgorde presenteren?

[Bosmonster]

Wat ik mis is de bron: wensen, eisen, probleemstelling, doelstelling

Verder valt interaction design onder functioneel ontwerp. Schetsen/schermopzet kan hier dus best bij en maakt het voor een klant bovendien wat realistischer ipv alleen tekstuele omschrijvingen

[ Voor 60% gewijzigd door Bosmonster op 23-06-2004 17:06 ]

[Verwijderd]

Bosmonster schreef op 23 juni 2004 @ 17:05:
Wat ik mis is de bron: wensen, eisen, probleemstelling, doelstelling

Dit wil ik beschrijven in het plan van aanpak. Dan lijkt het me een beetje overdreven om dit ook in het FO op te nemen.

In het plan van aanpak neem ik op wat het doel is van het project en wat ermee bereikt dient te worden. Verder worden hierin de wensen, eisen, kosten, risico's, planning in verwerkt.

Bosmonster schreef op 23 juni 2004 @ 17:05:
Verder valt interaction design onder functioneel ontwerp. Schetsen/schermopzet kan hier dus best bij en maakt het voor een klant bovendien wat realistischer ipv alleen tekstuele omschrijvingen

Ik neem een schema in het FO op met de navigatiestructuur, hierin verwerk ik de interactie binnen de site.

[ Voor 12% gewijzigd door Verwijderd op 24-06-2004 09:00 ]

[Bosmonster]

De interactie is veel meer dan navigatie. Schetsen en navigatie gaan juist hand in hand. Tenzij je van te voren al voor jezelf bepaald hebt dat er gewoon weer het zoveelste standaard menuutje in komt natuurlijk...

In het functioneel ontwerp is het handig om middels schetsen (en dat hoeft niet meer te zijn dan grove vlakverdelingen in bijvoorbeeld een Word-tekeningetje) hoe het functioneel concept eruit komt te zien.

Dit is een van de belangrijkste onderdelen imho en helaas een stap die te vaak overgeslagen wordt. Er wordt maar een navigatie-schemaatje gemaakt en daarna gaan we met Photoshop aan de slag... een duidelijk concept ontbreekt.

Als het zou gaan om een pitch waar je te concurreren hebt met anderen is het functioneel concept vaak waar het om draait.

[ Voor 61% gewijzigd door Bosmonster op 24-06-2004 09:30 ]

[Verwijderd]

Hieronder mijn huidige indeling. Misschien heeft iemand er nog aanvullingen op of opmerking over.

Waar kan ik trouwens de vormgeving bespreken, in het FO?

• [b]Plan van aanpak[/b][b][/b]
• doel van het project
  o probleemstelling (huidige situatie van het systeem)
  o doelstelling (gewenste/nieuwe situatie van het systeem)
• eisen
• kosten
• risico's en voorwaarden voor succesvol project
• planning (link naar excelbestand)
  
  
  Functioneel ontwerp (FO)
• Ontwerpen van functiestructuur
  o overzicht van de verschillende functies
  o uitleg van iedere functie
  o boomstructuur met hoe de functies zijn verbonden.
• Ontwerpen van dialogen
  o beschrijving bestelprocedure
  o beschrijving van af te handelen gebeurtenissen
  - feedback bestelling (bevestigingsmailtjes e.d.)
  - pre- en postcondities van alle "events" / functies
• Ontwerpen van interfaces
  o beschrijving interface
  o richtlijnen
  o beschrijving navigatie
  o beschrijving volgorde schermen
  o grove schets met vlakverdeling
  o beeldschermindelingen (weergave pagina’s)
• Algemeen
  o waarborging kwaliteit van het project
  o beschrijving projectgroep
  - samenstelling
  - rolverdeling
  - verantwoordelijkheden
  o opleveringsinformatie
  - website opgeleverd op internet, cd, zip enz.
  - presentatie
  o juridische voorwaarden
  o testplan
  - let op de validiteit (bruikbaarheid, waarde)
  - consistentie (samenhang) van alle producten
  o terminologie (beschrijving moeilijke woorden)
  o aanmelding bij zoekmachines
  o statistieken
  o overige aandachtspunten
  
  
  Technische ontwerp (TO)
• Ontwerp van gegevensstructuur
  o beschrijving gegevensopslag
  o beschrijving soort database
  o beschrijving ontwerp database
  o serverinformatie
  o browser vereisten
  o schermresolutie
  o domeinnaam
  o programmeertaal
  o benodigde hard- en software
  o hardware configuratie

[ Voor 3% gewijzigd door Verwijderd op 24-06-2004 11:08 ]

[Bosmonster]

Vormgeving is in principe een stap later, maar hangt heel erg van de verwachting van de klant af (soms verwachten ze gewoon al alles in een).

Grafische ontwerpen doen we zelf meestal via internet, omdat je dan ook animatie-concepten kunt laten zien e.d.

[Verwijderd]

'Algemeen' hoort volgens mij onder Plan van Aanpak.

[Verwijderd]

Verwijderd schreef op 24 juni 2004 @ 11:49:
'Algemeen' hoort volgens mij onder Plan van Aanpak.

Ok, dit heb ik nu verplaatst.

Ik vraag me nu af of ik de structuur in diagrammen moet gaan plaatsen. Ik heb enige informatie over UML, Usecase en Sequence diagrammen gelezen, maar weet niet zeker of ik dit moet gaan gebruiken.

Gebruiken jullie diagrammen in FO's? Zo ja, welke?

[Bosmonster]

Hangt van het formaat en type project af imho. Bedenk dat het er in de eerste plaats om gaat dat het duidelijk is en niet dat je allerlei mooi-genaamde technieken gebruikt. Daar heb je niks aan als het erg geforceerd is en niemand het goed kan lezen

Gebruik diagrammen e.d. dus als je denkt dat het handig is een schematische weergave ergens van te hebben. Je doet dit nu zelf al bijvoorbeeld bij het navigatieschema. Als je bijvoorbeeld processen gaat automatiseren is het handig om een taakanalyse te maken met een taakdiagram, etc.

UML hoort overigens meer thuis in een technisch ontwerp, maar wederom alleen handig als je er goed bekend mee bent en het dus een meerwaarde heeft.

[Verwijderd]

Bosmonster schreef op 24 juni 2004 @ 15:54:
Gebruik diagrammen e.d. dus als je denkt dat het handig is een schematische weergave ergens van te hebben. Je doet dit nu zelf al bijvoorbeeld bij het navigatieschema. Als je bijvoorbeeld processen gaat automatiseren is het handig om een taakanalyse te maken met een taakdiagram, etc.

UML hoort overigens meer thuis in een technisch ontwerp, maar wederom alleen handig als je er goed bekend mee bent en het dus een meerwaarde heeft.

Ok, dank je voor je (vele) reactie(s)!

Er komt ook een shop op de site. Ik ga in het FO helemaal beschrijven hoe de bestelprocedure gaat en hoe zaken afgewikkeld worden e.d. Dit kan ik dan mooi in een schema/diagram stap-voor-stap verwerken. Dit wordt een onderdeel van m'n flowchart waarin alle specifieke beslissingspaden en keuzepunten vermeld staan.

Of kan ik dit toch beter in m'n TO opnemen?

[Verwijderd]

Beschrijven jullie het Use scenario en User profile (RAO-model) ook in het FO of al in het plan van aanpak?

[Verwijderd]

Zowiezo is je FO te technisch nog. Een FO is niets anders als een omschrijving van het project. Boomstructuren van technische functies kun je beter kwijt in het TO, Object Model. Use Case Requirements zijn onderdeel van het TO, het zijn ook zaken die je naderhand gebruikt om je project op te controleren.

[Verwijderd]

Verwijderd schreef op 28 juni 2004 @ 12:36:
Zowiezo is je FO te technisch nog. Een FO is niets anders als een omschrijving van het project. Boomstructuren van technische functies kun je beter kwijt in het TO, Object Model. Use Case Requirements zijn onderdeel van het TO, het zijn ook zaken die je naderhand gebruikt om je project op te controleren.

Maar onder andere uit het Use Scenario (US) en User Profile (UP) worden toch de requirements gehaald? Dan moeten de US en UP toch in het plan van aanpak beschreven worden?

Een minimale soort sitemap/boomstructuur van de website kan toch wel in het FO?

P.s. Is het TO hetzelfde als het Object Model? En bedoel je met Use Case Requirements het US en UP?

[alienfruit]

Hmm. volgens mij doe ik dan wat verkeerd
Ik heb altijd een interactief model, technisch ontwerp en projectplan/plan van aanpak.
Waarbij ik in het interactief model dingen beschrijf als de navigatie en andere interactivteit, manier hoe we de bezoeker/gebruiker geprikkeld krijgen. Technisch ontwerp beschrijvijng van het technische gedeelte en projectplan zit bij dit in:

Projectnaam;
Projectleden, rollen en afspraken;
Doelstellingen;
Orientatie op het onderwerp;
Overzicht opsomming te maken producten (en tussenproducten);
Eissen waar aan het product moet voldoen;
Milestones/Deadlines;
Planning en taakverdeling;
Controle momenten/voortgang controle;
Risicoanalyse
Evaluatie (evaulaties na: conceptfase, realisatie fase etc.);

Tot heden vond met dit altijd wel genoeg.

[Verwijderd]

Ik zoek meer informatie over FO's en TO's. Ik heb het boek 'Webdesign van concept tot realisatie' van Hedwyg van den Elzen, maar daarin staat te veel basisinformatie naar mijn idee.
Ik zoek dus een boek die er dieper op in gaat. Iemand een idee?