Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt.
De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
3 comments
Requirements Management 
3 comments
"check all the links manually after posting" Hmmm… that doesn’t sound like test-driven writing to me 🙂
Erno
I liked the mentioned article. Not only the part about Time, but also about using whitebox use cases and a rules dictionary to precisely specify the inner working. Is this a technique you see used often? Because it seems to fill in a missing link for me…
Raimond
Use cases mostly show blackbox behaviour, but sometimes it is wise to show some more details of the inner working (whitebox behaviour) in order for all the parties that make use of the use case to understand what it is all about.
Factoring out information to other artifacts is a good idea if the factored-out information is not valuable for the tester, the user and the technical writer (especially if you do not want to argue with them about the way your program will offer a solution to a problem).
In the case described in the article, the information that the Payroll is not run immediately but later at a given time is essential information to both the tester, the user and the technical writer, so it should be included in the use case.
Harry Nieboer