Requirements

SISp 2.5 Vaststellen requirements valkuilen en samenvatting

Selectie van standaard software

Valkuilen requirements * Gebruikers begrijpen niet wat ze willen of kunnen dat niet goed onder woorden brengen. * Gebruikers willen niet toezeggen dat de geschreven requirements juist zijn. * Gebruikers eisen nieuwe requirements als de kosten en uitvoering al vast staan. * Communicatie met de gebruikers verloopt traag. * Gebruikers nemen vaak niet deel aan de… lees verder »

SISp 2.4 Mijlpaalproducten Requirements analyse en Best practices

Selectie van standaard software

Mijlpaalproducten requirements Document met Business requirements Overzicht met doelstellingen van de opdrachtgever. SMART gepresenteerd. Document met User  requirements Een overzicht met gebruikerseisen. Document met Software  requirements Een verder uitwerking van de gebruikerseisen opgesplitst in opgesplitst in functionele en niet functionele eisen. Document Randvoorwaarden Een technisch kader waarbinnen de software moet kunnen draaien. Overzicht stakeholders Hier… lees verder »

SISp 2.3 Activiteiten vaststellen requirements

Selectie van standaard software

Iedere fase binnen de SISP methode bestaat uit een aantal activiteiten. De fase ‘Vaststellen requirements’  bevat de volgende activiteiten. Activiteiten: 1. Verzamel bestaande informatie. 2. Breng structuur aan. 3. Verzamel nieuwe informatie & leg vast. 4. Check op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid 5. Evalueer & maak definitief  Activiteit 1: Verzamel bestaande informatie Een… lees verder »

SISp 2.2 Soorten requirements

Selectie van standaard software

In de SISp methode verdelen we de requirements in een aantal categorieën.  Deze categorieën hebben we nodig om later een goede keuze te kunnen maken. De categorieën: * Business requirements, De wens van de organisatie is de start van het project. Definieer deze wens(en) duidelijk en ondubbelzinnig. * User requirements, Welke wensen heeft de gebruikersorganisatie, de mensen die… lees verder »

SISp 2.1 De requirements fase

Selectie van standaard software

Inleiding requirements fase Nu het projectplan definitief is starten we in SISp2 met het vaststellen van de exacte eisen en wensen die aan het standaard software pakket worden gesteld. In deze fase zullen de eisen en wensen van zowel de opdrachtgever als alle verdere belanghebbende,  ondubbelzinnig worden beschreven. Deze eisen en wensen worden ook wel requirements… lees verder »

Waterval versus cyclisch projectmanagement

Het 6-fasenmodel is een watervalmodel. Dat wil zeggen dat de fases na elkaar plaatsvinden. Net zoals je niet omhoog kan zwemmen tegen een waterval in, kan je in het pure watervalmodel na het doorlopen van een fase ook niet meer terug. Het is niet wenselijk als in de realisatiefase besloten wordt om het ontwerp aan… lees verder »

Waarom Requirementsmanagement

Requirements inventariseren, ontwikkelen, opstellen is al enige jaren een soort nieuwe ‘sport’ of ‘hype’, maar waarvoor zijn die eigenlijk nodig. In de praktijk is vaak niet duidelijk waar een bepaalde requirement vandaan komt of wat er precies mee bedoeld wordt. Onderstaand een korte uitzetting van… – wat zijn requirements? – wie is verantwoordelijk voor requirements? –… lees verder »

De projectorganisatie: stuurgroep, projectgroep, werkgroep

De fase Informatie Analyse aan het begin van een project is de belangrijkste fase. Veel gebruikers beseffen dit echter niet omdat de opleverdatum nog ver weg is en er slechts enkele personen met de Informatie Analyse bezig zijn die voornamelijk lastige vragen stellen. Tenslotte komen van deze personen allerlei fraaie documenten over zaken die de… lees verder »

Reduce Complexity: State Key Business Requirements (KBR’s)!

Steven van het Veld, a well-known Dutch independent principal (enterprise) information architect, claims that companies spend more on their website than on their enterprise architecture. This statement seems to be in line with something else I recently heard: Organizations spend much more on their website than on business process improvement, while the Return On Investment… lees verder »

Eisen aan applicaties

De kwaliteit van een applicatie wordt afgeleid van de mate waarin de applicatie aan de eisen voldoet. Tijdens de informatieanalyse en het ontwerp ligt de nadruk vooral bij de functionele eisen. Wat moet de applicatie allemaal kunnen. Er zijn echter ook algemene eisen die aan iedere applicatie gesteld kunnen worden maar wel per applicatie kunnen verschillen. [Klik op de titel voor het gehele artikel]

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

OmschrijvingVragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Taakverdeling bij calamiteiten op: 2017-04-25 21:08 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

Sidebar