Summary A6-K1.1 De kandidaat kan modellering van vereisten (requirements modelling) en technieken voor behoefteanalyse onderscheiden.

231 Flashcards & Notes
1 Students
  • This summary

  • +380.000 other summaries

  • A unique study tool

  • A rehearsal system for this summary

  • Studycoaching with videos

Remember faster, study better. Scientifically proven.

Summary - A6-K1.1 De kandidaat kan modellering van vereisten (requirements modelling) en technieken voor behoefteanalyse onderscheiden.

  • 1.1 De kandidaat kan modellering van vereisten (requirements modelling) en technieken voor behoefteanalyse onderscheiden

  • Het Requirementsproces bestaat uit twee onderdelen, welke zijn dit?
    De requirementsontwikkeling en de requirementsmanagement
  • Wat zijn de stappen van de requirements ontwikkeling (succes boek) of de requirements engineering (die in het boek software engineering worden beschreven?):
    • Inception
    • Elicitation
    • Elaboration
    • Negotiation
    • Specification
    • Validation

    • Requirements management

    Succes boek:
    Elicitatie
    Analyse
    Specificatie
    Validatie
  • Korte omschrijving stappen SE boek!
    Inception: Inceptioneren: Een basisbegrip van het probleem en de aard van de oplossing vaststellen.

    Elicitatie: De requirements van de stakeholders uittekenen

    Elaboration:
    Creëer een analysemodel dat informatie, functionele en gedragsmatige aspecten van de vereisten weergeeft.


    Negotiation: Afspraken maken over een leverbaar systeem dat realistisch is voor ontwikkelaars en klanten.

    Specificatie: Beschrijf de eisen formeel of informeel

    Validatie: Herziening van de specificatie van de eisen voor fouten, ambiguïteiten, omissies en conflicten

    Requirements management: Beheer veranderende eisen
  • Wat is het doel van requirementsontwikkeling en wat is het doel van requirementsmanagement?

    Het doel van requirementsontwikkeling is het juist en volledig vastleggen van de requirements

    Het doel van requirementsmanagement is dat de requirements juist en volledig worden verwerkt in het systeem.
  • Wat is inception (korte omschrijving)?
    basisbegrip van probleem waarvoor oplossing wordt gezocht
  • Wat is Inception/inceptie (langere omschrijving)?

    ONTSTAAN:
    Wanneer een zakelijke behoefte wordt geïdentificeerd of een nieuwe markt of dienst wordt ontdekt

    WIE DOET DE INCEPTION?
    Stakeholders uit het bedrijfsleven (business-managers, marketing-mensen, productmangers)

    WAT DOEN DE STAKEHOLDERS?
    - identificatie business-case
    - breedte/diepte markt identificeren
    - haalbaarheidsnanalyse
    - identificeren reikwijdte
  • Wat moet er bij de start van het project duidelijk zijn?

    - Wat is het probleem?

    - Om welke gebruikers/klanten gaat het

    - De aard van de oplossing die gewenst is


    - Hoe gaat de communicatie verlopen tussen stakeholders en het ontwikkelteam


    Aan de hand van de bovenstaande vragen moet de requirements engineer de volgende taken uitvoeren:
    - identificeren van de stakeholders
    - herkennen van meerdere standpunten
    - werken naar goede samenwerking
    - het ijs breken en de communicatie op gang brengen.
    Elk van de belanghebbenden zal een andere kijk hebben op wat het softwareproduct moet doen en waar de software-ingenieurs zich op moeten richten. Dit kan zijn op het creëren van "sexy" features (van de marketingafdeling), het binnen de budgetten en deadlines blijven (van managers), onderhoudbaarheid (van support engineers) en ga zo maar door. Uit deze opvattingen moet de requirements engineer bepalen over welke eisen er een consensus is en over welke eisen de stakeholders het niet eens zijn. Het oplossen van meningsverschillen tussen stakeholders vormt de onderhandelingsstap.

    Iets om rekening mee te houden tijdens het begin is de effectiviteit van de communicatie tussen de requirements engineer en de klanten. Dit kan bijvoorbeeld door de klant te vragen of hij/zij het gevoel heeft dat hem/haar de juiste vragen over zijn/haar problemen zijn gesteld en of de persoon die met de requirements engineer communiceert het gevoel heeft dat hij/zij de persoon is (of niet) die de vragen van de engineer zou moeten beantwoorden.
  • Wat is Elicitation (korte omschrijving)
    verhelderen en vaststellen bedrijfsdoelen - inventariseren van requirements


  • Wat is Elicitation/elicitatie boek software engineering?

    elicitatie is letterlijk ontlokken van requirements van belanghebbenden.

    Het lijkt eenvoudig om de klant, de gebruikers en andere stakeholders te vragen:
    • wat de doelstellingen voor het systeem of product zijn,
    • wat er moet worden bereikt, hoe het systeem of product past in de behoeften van het bedrijf, en ten slotte,
    • hoe het systeem of product moet worden gebruikt op een dagelijkse basis.

    Maar het is niet eenvoudig, het is erg moeilijk.

    Een belangrijk onderdeel van de ontlokking is het vaststellen van zakelijke doelen .
    • Het is uw taak om belanghebbenden te betrekken en hen aan te moedigen om hun doelen eerlijk te delen.
    • Zodra de doelstellingen zijn vastgelegd, zou een prioriteringsmechanisme moeten worden vastgesteld,
    • en kan een ontwerprationale voor een potentiële architectuur (die voldoet aan de doelstellingen van de stakeholders) worden gecreëerd.
  • Welke problemen kunnen zich voordoen bij elicitatie?

    Problemen met de reikwijdte. (De grens van het systeem is slecht gedefinieerd)
    Problemen met het begrip. (. De klanten/gebruikers zijn niet volledig zeker van wat nodig is, hebben een slecht begrip van de mogelijkheden en beperkingen van hun computeromgeving)
    Problemen met volatiliteit. (De eisen veranderen in de loop van de tijd)
  • Wat is Elicitation/elicitatie boek succes?

    elicitatie is letterlijk ontlokken van requirements van belanghebbenden. dit geeft aan dat, naast schriftelijke bronnen, de belanghebbenden zelfs een belangrijke bron zijn. Hierbij is het een belangrijke taak van de informatieanalist om de belanghebbenden bewust te maken van hun requirements.

    Elke groep belanghebbenden moet binnen het requirementsontwikkelproces zijn vertegenwoordigd.

    Voorbeelden Belanghebbenden:
    - Lijnmanagers
    - marketingmanagers
    - ICT-managers
    - budgethouders etc

    Na het vaststellen van groepen belanghebbenden en hun vertegenwoordigers worden de eisen en wensen geïnventariseerd.
    Dit is geen passief proces maar een actief proces waarbij de requirements worden ontlokt door prikkelende vragen.

  • Noem enkele elicitatietechnieken voor het ontlokken van requirements?
    Documentstudie
    Analyse bestaand systeem – waarom vraag
    Interviews – laagdrempelig
    Workshops – belanghebbende werken als groep samen om sneller en consistent resultaat te bereiken
    Observatie – dagelijkse praktijk (tijdrovend
    Brainstormen – ideaal voor nieuw requirement
    Taakanalyse – onderverdelen in subtaken -> hierarchie
    Scenario – opeenvolging van stappen

    Prototypen

    Wat is een documentstudie?
    nuttig als requirementsanalist organisatie niet kent of niet op de hoogte is van het te analyseren domein. Hierbij worden er vakdocumenten op na geslagen die geschreven zijn voor de domeinexperts. Een documentstudie kan ook bestaan uit bedrijfsplannen, strategische documenten, financiële rapportages e.d.
    NADEEL: lezen duurt lang +vaak niet actueel

    Wat is analyse bestaand systeem?
    Het stellen van een waarom-vraag (waarom is dit systeem in het verleden gerealiseerd). Door zich met de waarom vraag te richten op het oude systeem kan men systeemrequirements terugvoeren naar gebruikersrequirements en daarna tot businessrequirements

    Wat is een interview?
    Hierbij worden vragen gesteld aan de belanghebbenden. Dit kan open of gesloten zijn. Een open interview is handig als de reuirementsanalist zich nog in een verkennende fase bevindt.
    VOORDEEL: Inkorte tijd kan veel informatie worden verkregen.

    Wat is een workshop?
    Dit is een algemene term voor een gestructureerde sessie waarbij de belanghebbenden als groep samenwerken om zo sneller een consistent resultaat te bereiken.
    Fascilitator (leider)
    Schrijver (noteert)
    Deelnemer
    VOORDEEL: conflicterende reuirements worden sneller onderkend

    Wat zijn observaties?
    het observeren van de belanghebbenden in hun dagelijkse praktijk. Hierbij wordt duidelijk welke activiteiten de belanghebbenden nu echt uitvoert om de taken te vervullen en hoe communicatie met andere personen plaatsvindt.
    NADEEL: tijdrovend

    Wat is brainstormen?
    Is een techniek waarbij het genereren van een heleboel ideeen in korte tijd en met veel creativiteit centraal staat. Ideaal voor het verkrijgen van nieuwe requirements of om belanghebbenden te helpen verder te kijken dan de dagelijkse praktijk.


    wat is taakanalyse?
    dit is een techniek om een hiërarchie van taken en subtaken af te leiden

    Wat zijn scenario's?
    Bij taakanalyse worden de stappen die uitgevoerd worden in kaart gebracht.bij scenario's gaat de requirements analist samen met de belanghebbenden na wat er nu echt gedaan wordt om het doel van een taak te bereiken. Met behulp van scenario's kan de requirements analisten samen met de belanghebbenden het gebruik van het systeem simuleren.
    Voorbeeld scenario
    de gebruikers start het scherm op en klikt op de knop aanmaken order. Het systeem toont een leeg scherm, waarbij automatisch het ordernummer 176 wordt aangemaakt.

    Wat zijn prototypen?
    Een prototype is een simulatie van het te realiseren systeem.
  • Wat gebeurd er tijdens Elicitatie?
    1. Maak een lijst van belanghebbenden voor het project.

    2. Nodig alle belanghebbenden uit voor een informele bijeenkomst.
    3. Vraag elke stakeholder om een lijst met kenmerken te maken en
    functies die nodig zijn.
    4. Bespreek de eisen en stel een definitieve lijst op.
    5. Prioriteit geven aan de eisen.
    6. Let op de gebieden van onzekerheid
  • Wat is horizontale en wat is verticale prototyping (dit hoort bij elicitatie)?

    Horizontale prototyping

    – gehele gebruikersinterface gemaakt zonder achterliggende functionaliteit

    – getoonde gegevens zijn nep.

    DOEL: Om te beoordelen of functionaliteit ontbreekt, overbodig is of aangepast moet worden


    Verticale prototyping

    – proof of concept PoC

    – een deel van de gebruikersinterface, met wel de volledige functionaliteit erachter.

    DOEL: Gebruikt om te toetsen of voldoet aan de gestelde (nietfunctionele) eisen. (Niet echt elicitatietechniek, meer voor risicoreductie)
  • Wat is de analyse stap van het succes boek?
    • In deze stap Evalueert de requirements analist de verzamelde requirements om tot een uiteindelijke verzameling van requirements te komen. De requirements analist veel tijd de requirements door. En die eigenlijk geen ijs of beperking zijn te verwijderen.
    • Daarnaast haalt de requirements analist inconsistenties en overlappingen uit de requirements.
    • de requirements analist overleg met de gebruikers om conflicterende requirements en hiaten op te lossen.
  • Noem enkele analysetechnieken (elaboration en negotiation?)

    • Checklist (helpt om de manier van analyseren te standaardiseren. )Een aantal vragen worden door de requirementsanalist doorgelopen om te kijken of de requirement goed is geformuleerd. Bijvoorbeeld, waarom hoort dit reuirement thuis in de uiteindelijke verzameling requirements?

    • Requirementscategoriën De requirementsanalist deelt de requirements in verschillende categoriën. Bijvoorbeeld, gebruikersinterface, beveiliging en koppeling
    • Requirementsattributen (ondersteunende informatie bij een requirement). Ze helpen om requirements te interpreteren en te beheren.
    • interactiematrix ( zorgt ervoor dat de requirementsanalist geen requirements vergeet in de zoektocht naar overlappingen, inconsistanties en conflicten)
    • probleempatronen (hulpmiddel dat een requirementsanalist helpen om een groot analyseprobleem op te delen in kleinere problemen waarvoor bekende oplossingen bestaan.
    Basis onderdelen van een probleem patroon diagram zijn:
      • de machine
      • het probleem domein
      • de requirements
      • en de specificatie

    Er bestaan vijf basisprobleempatronen:
    1. benodigd gedrag
    2. Opgedragen gedrag
    3. Informatie tonen
    4. Gereedschap
    5. Transformatiepatroon


  • Wat is Elaboration (korte omschrijving)
    verfijnen/ opstellen model van vereisten (requirements model)

  • Wat is Elaboration (lange omschrijving)


    is het verfijnen/opstellen model van vereisten (requirements model).
    Dit kan een scenario-based model zijn (use cases)
    Klasse gebaseerd model (gebaseerd op de scenario's)
    gedragsdiagrammen (TTD diagram)
    Flow georienteerde diagrammen (dataflow)


    1) De informatie die van de klant wordt verkregen tijdens het elicitatieproces wordt uitgebreid en verfijnd/uitgewerkt tijdens de elaboration.




    2) Deze taak richt zich op het ontwikkelen van een uitgewerkt requirementsmodel dat verschillende aspecten van de softwarefunctie, het gedrag en de informatie identificeert.
    3) gebruikersscenario's /users scenarios worden gecreëerd en uitgewerkt/verfijnt die beschrijven hoe de eindgebruiker (en andere actoren) met het systeem zullen omgaan.


    4) De attributen van elke analyseklasse worden gedefinieerd, en de diensten die nodig zijn voor elke klasse worden geïdentificeerd. De relaties en samenwerking tussen de klassen worden geïdentificeerd en er worden diverse aanvullende diagrammen gemaakt.


    De uitwerking wordt gestuurd door het creëren en verfijnen van gebruikersscenario's die beschrijven hoe de eindgebruiker (en andere actoren) met het systeem zullen omgaan. Elk user-scenario wordt ontleed om de analyseklassen (bedrijfsdomein-entiteiten die zichtbaar zijn voor de eindgebruiker) te onttrekken. De attributen van elke analyseklasse worden gedefinieerd, en de diensten die nodig zijn voor elke klasse worden geïdentificeerd. De relaties en samenwerking tussen de klassen worden geïdentificeerd en er worden diverse aanvullende diagrammen gemaakt.
  • Wat is Negotiation (korte omschrijving)
    onderhandelen over mogelijkheden
  • Wat is negotiation (onderhandeling)?

    Negotiation is het onderhandelen over mogelijkheden
    NODIG OMDAT:
    • klanten vragen meer dan er kan worden bereikt.
    • klanten of gebruikers om stellen tegenstrijdige eisen voor


    Klanten, gebruikers en andere belanghebbenden worden gevraagd een rangorde van eisen op te stellen en vervolgens conflicten met voorrang te bespreken. Met behulp van een iteratieve aanpak die prioriteit geeft aan eisen, de kosten en risico's ervan inschat en interne conflicten aanpakt, worden eisen geëlimineerd, gecombineerd en/of aangepast aan de mate van tevredenheid van elke partij.
  • Wat is specification (korte omschrijving)
    Het specificeren van de vereisten.
  • Wat is specificatie? SE boek
    Specificatie. In de context van computergebaseerde systemen (en software) betekent de term specificatie verschillende dingen voor verschillende mensen. Een specificatie kan een geschreven document zijn, een set van grafische modellen, een formeel wiskundig model, een verzameling van gebruiksscenario's, een prototype of een combinatie daarvan.
    Sommigen suggereren dat er een "standaardsjabloon" [Som97] moet worden ontwikkeld en gebruikt voor een specificatie, met als argument dat dit leidt tot eisen die op een consistente en dus meer begrijpelijke manier worden gepresenteerd. Het is echter soms noodzakelijk om flexibel te blijven wanneer een specificatie moet worden ontwikkeld.
    Voor grote systemen kan een geschreven document, waarin beschrijvingen in natuurlijke taal en grafische modellen worden gecombineerd, de beste aanpak zijn. Gebruiksscenario's kunnen echter alles zijn wat nodig is voor kleinere producten of systemen die zich in een goed begrepen technische omgeving bevinden.
  • Wat is specificatie? Succes boek

    Het vastleggen van de geanalyseerde requirements

    Dit bestaat uit de volgende stappen:
    - vastleggen v.d. Eigenlijke requirements
    - Maken van modellen waarin requirements grafisch worden gepresenteerd. (deze modellen komen niet in plaats van het vastleggen van de individuele requirements)

    Een specificatie kan een geschreven document zijn, een set van grafische modellen, een formeel wiskundig model, een verzameling van gebruiksscenario's, een prototype of een combinatie daarvan.
  • Welke modellen worden bij specificatie gebruikt?

    Systeemafbakening (scopemodellen)
    Structuur (structuurmodel)
    Dynamisch gedrag (TTD en stroomschema)
  • Wat is een scopemodel (dit wordt gebruikt bij specificatie) en noem hiervan belangrijke modellen?

    Met een scope model wordt de systeem afbakening vastgesteld. Hierbij wordt vastgesteld welke activiteiten uit de bedrijfsvoering door het systeem moeten worden ondersteund.

    De twee belangrijkste modellen zijn:
    • systeem context diagram
    • use Case model


    Daarnaast:
    • Structuurmodel (Entiteitsdiagram (ERD))
    • Dynamisch gedrag (Toestandtransistiediagram (TTD) /Stroomschema)
  • Wat is een systeem context diagram?
    Dit is een scopemodel dat bij de specificatie wordt gebruikt. Het systeem context diagram(SCD) wordt gesymboliseerd door een cirkel die zich in het midden van het model bevindt. De systemen of domeinen waarmee het te ontwikkelen systeem directe interactie heeft, staan afgebeeld als de rechthoeken. Deze worden terminators genoemd.
  • Is de actor een fysieke persoon?
    De actor is geen fysieke persoon maar een rol, zoals baliemedewerker, systeembeheerder of medewerker verkoop.
  • Wat is een use case model?
    De samenhang tussen use case kan gevisualiseerd worden door middel van een use Case diagram. In het use Case diagram wordt de rol van de gebruiker weergegeven met een poppetje en die use case met een ellips. Het vierkant stelt het systeem voor.
  • Welke structuur modellen bestaan er?
    Gegevens modellen beschrijven de statische structuur van het informatiesysteem meestal wordt hiervoor het entiteit relatie diagram gebruikt.
    Bij entiteit relatie modellering wordt een model gemaakt van het zogeheten universum van discussie (UVD) het uvd is de verzameling van alle objecten die in de requirements zijn beschreven. Het eenvoudigste is het om alle zelfstandige naamwoorden in de requirements als objecten in het model te beschouwen. Dit is een goede eerste stap om tot een erd te komen.
  • Welke schema's bestaan er om dynamisch gedrag binnen de specificatie vast te leggen?

    Toestandstransitiediagram
    Stroomschema
  • Wat is een toestandtransitiediagram ttd?

    Veel systemen hebben te maken met gebeurtenissen waardoor het systeem van toestand verandert. Voorbeelden zijn een ventilator die aan of uitgaat of het vastleggen van een bibliotheek systeem. Een systeem verkeerden zullen korte of langere tijd in een bepaalde toestand, maar deze toestand verandert op een zeker moment. Het Overgaan van de ene toestand naar de andere wordt een transitie genoemd.
  • Wat is dit voor een model
    Systeemcontextdiagram (specificatie->scopemodellen)
  • Wat is dit voor een model?
    Entiteitsrelatiediagram (specificatie -> structuurmodellen)
  • Wat is dit voor een model?
    Een toestandtransitiediagram (specificatie -> dynamisch gedrag modellen)
  • Wat is dit voor een model?
    Een stroomschema (specificatie -> dynamisch gedrag modellen)
  • Wat is dit voor een model?

    Standaardzinsamenstelling
    Deze specificatietechniek is geen model maar een manier om te zorgen dat een requirement alle benodigde elementen bevat. Het is een soort van template/sjabloon. Deze techniek werkt het beste voor systeemrequirements
  • Wat is Validatie SE-boek?
    Validatie. De werkproducten die als gevolg van requirements engineering worden geproduceerd, worden tijdens een validatiestap op kwaliteit beoordeeld. Eisenvalidatie onderzoekt de specificaties om er zeker van te zijn dat alle software-eisen ondubbelzinnig zijn vermeld; dat inconsistenties, omissies en fouten zijn gedetecteerd en gecorrigeerd; en dat de werkproducten voldoen aan de normen die zijn vastgesteld voor het proces, het project en het product.


    Wie zitten in het validatieteam?
    Het beoordelingsteam dat de eisen valideert, bestaat uit software-ingenieurs, klanten, gebruikers en andere belanghebbenden die de specificatie onderzoeken op zoek naar inhoudelijke of interpretatiefouten, gebieden waar verduidelijking nodig kan zijn, ontbrekende informatie, inconsistenties (een groot probleem bij het ontwerpen van grote producten of systemen), tegenstrijdige eisen, of onrealistische (onhaalbare) eisen.
  • Wat is validation (korte omschrijving)
    beoordelen of de vereiste goed is gespecificeerd
  • Wat is validation (validatie) (langere omschrijving)?
    beoordelen of vereiste goed is gespecificeerd
    • Tegenover klant, om ervoor te zorgen dat het juiste systeem wordt gebouwd.
    • Door verschillende belanghebbenden.

    De werkproducten die als gevolg van requirements engineering worden geproduceerd, worden tijdens een validatiestap op kwaliteit beoordeeld.

    Validatie onderzoekt de specificaties om er zeker van te zijn dat alle software-eisen ondubbelzinnig verklaard; dat inconsistenties, omissies en fouten zijn opgespoord en gecorrigeerd; en dat de werkproducten voldoen aan de normen die zijn vastgesteld voor het proces, het project en het product. Het validatiemechanisme voor de primaire eisen is de technische beoordeling.
  • Wat is het doel van de validatie van requirements?

    Er worden een tweetal vragen beantwoord:
    Zijn de requirements op een correcte manier opgeschreven?
    Verwoorden de requirements alle behoeften van de gebruiker?


    De requirementsanalist dient daarbij vast te stellen of de requirements de essentiële behoefte van de belanghebbenden afdekken en of de requirementsdocumenten juist, volledig en consistent zijn.
  • Wat is de invoer en de uitvoer van de validatie?

    Invoer:
    Requirementsdocumenten
    Kennis belanghebbenden
    Standaarden

    uitvoer:
    Issues
    acties
  • Welke eisen worden er met betrekking tot Validatie aan de requirements gesteld?

    De totale set requirements documenten is consistent


    de requirements documenten voldoen aan bedrijfs en industriestandaarden


    de afzonderlijke requirements voldoen aan een aantal eisen:
    • Uniek identificeerbaar
    • atomair
    • eenduidig
    • Grammaticaal correct
    • vrij van implementatie details
    • traceerbaar
    • testbaar/verifiëerbaar
    • voorzien van prioriteit
  • Noem enkele validatie technieken?

    Validatie technieken zijn op te splitsen in :
    • correcte requirements en
    • voldaan aan gebruikers behoefte.


    correcte requirements
    • review en inspectie
    • diagrammen en modellen
    • acceptatietestgevallen opstellen
    • handleidingen maken


    voldaan aan gebruikersbehoeften
    • walkthrough
    • use case scenario's
    • prototype
    • simulatie
  • Welke rollen bevat het validatie-beoordelingsteam?
    Het beoordelingsteam dat de eisen valideert, bestaat uit software-ingenieurs, klanten, gebruikers en andere belanghebbenden die de specificatie onderzoeken.
  • Waarop worden de requirements beoordeeld?

    Het beoordelingsteam gaat op zoek naar
    • inhoudelijke of interpretatiefouten,
    • gebieden waar verduidelijking nodig kan zijn,
    • ontbrekende informatie,
    • inconsistenties (een groot probleem bij het ontwerpen van grote producten of systemen),
    • tegenstrijdige eisen,
    • of onrealistische (onhaalbare) eisen.
  • Wat is Requirements management (korte omschrijving)
    managen van (veranderingen) van vereisten
  • Uit welke taken bestaat de requirements management?

    Intake en identificatie
    traceerbaarheid
    wijzigingenbeheer

    verificatie

    Wat is intake en identificatie?
    Het doel van de intake is ervoor te zorgen dat alle partijen die betrokken zijn bij de realisatie de requirements juist begrijpen en interpreteren.
    Bij requirementsidentificatie wordt aan ieder requirement een uniek label gehangen. Hierdoor is ieder requirement uniek indentificeerbaar
    1. Symbolische identificatie (identificeren van requirements dmv symbolische namen)
    2. databaserecordidentificatie (in een database wordt ieder requirement als een rij in een tabel beschouwd met unieke sleutel)
    3. dynamische nummering (= structuur van het document 2.5.2 = tweede requirement uit de 5e paragraaf van het tweede hoofdstuk)


    Wat is traceerbaarheid?
    Inzicht in de relaties tussen de requirements onderling en de relaties met andere producten die tijdens het project worden gemaakt.

    Wat is wijzigingsbeheer?
    Het gecontroleerd doorvoeren van requirements wijzigingen

    Wat is verificatie?
    Het testen van het eindproduct op basis van de requirements
  • Noem enkele requirements management technieken:
    • Use Case beschrijft hoe systeem reageert op handeling van gebruiker + use case diagram
    • User stories
    • Technieken voor niet-functionele requirements
    • Prioriteringstechniek
  • Wat is een use-case?

    use cases zijn een veelgebruikte techniek (scopemodel, gebruikt bij o.a. Specificatie) voor het vastleggen van gebruikers requirements. Use cases zijn een goede techniek voor requirements ontwikkeling omdat gebruikers een verhaal vorm kunnen vertellen wat ze van het te realiseren systeem kunnen verwachten en hoe ze met dat systeem willen werken.
    Een use case beschrijft hoe het systeem reageert op handelingen van de gebruiker. Daarmee toont een use case het gedrag van het systeem onder verschillende omstandigheden. Use case is beschreven vanuit het oogpunt van de gebruiker. De gebruiker die de interactie met het systeem initieert heet de actor.
  • Wat zijn de verschillende niveaus van detail van een use-case?

    • Cloud – hoogst niveau. representeert vaak groepen van samenhangende bedrijfsprocessen. Voorbeeld: leveren van telecommunicatiediensten aan particulieren
    • Kite - tweede niveau . Hier worden individuele bedrijfsprocessen neergezet, vaak workflowgeoriënteerd. Use cases op kite-niveau worden ook wel business use cases genoemd en beschrijven het gebruik van informatiesystemen op organisatie niveau, bijvoorbeeld het administreren en bewaken van orders.
    • Sea – correspondeert met processtap, bijvoorbeeld registreer order. – meest toegepast
    • Fish - uses cases op fish-niveau worden gebruikt om op zichzelfstaande, maar aan sea niveau ondersteunende functionaliteit te modelleren. Kenmerk van een use case op fish niveau is dat deze meerdere use case is op zie niveau ondersteunen. Use case is op vrees niveau worden ook als ze use case is genoemd. Denk bijvoorbeeld aan ophalen klantengegevens.
    • Clam – te ver doorgegaan. Soms modelleren projecten te ver door, en worden de use case is te klein. Men spreekt dan ook wel over klam niveau bijvoorbeeld invoeren klantnummer.
Read the full summary
This summary. +380.000 other summaries. A unique study tool. A rehearsal system for this summary. Studycoaching with videos.

Latest added flashcards

Uit welke onderdelen bestaat een software diagram / data flow diagram?

Externe entiteiten (rechthoek in het schema)
  • Mensen
  • Andere systemen
  • Microsoft.com
  • enz...


Proces (cirkel in het schema)
  • DLL's
  • EXEs
  • COM-object
  • Onderdelen
  • Diensten
  • Webservices
  • bijeenkomsten
  • en zo verder.


Data flow/gegevensstroom (lijnen in het schema)
  • Netwerkverkeer
  • RPC
  • Enz...
  • Functie-aanroep


Data store/gegevensopslag (twee dikke lijnen boven elkaar)
  • Database
  • Bestand
  • Registratie
  • Gedeelde
  • Geheugen
  • Wachtrij/aanval
  • enz...


Trust boundary's /Vertrouwensgrens (gestippelde lijnen)
  • Integriteitsniveaus
  • Sessie
  • Bestandssysteem
  • Netwerk
Hoe noemen we de databases die voornamelijk ontworpen en geïmplementeerd zijn om operationele gegevens vast te leggen
We noemen databases die voornamelijk ontworpen en geïmplementeerd zijn om operationele gegevens vast te leggen transactie-, operationele of productiedatabases. Navenant
worden de bijbehorende programma’s transactie-, operationele of productieprogramma’s genoemd.
Wat is een Entiteit (wordt ook wel object genoemd)
Een entiteit is een persoon, plaats, een ding of een gebeurtenis waarover we informatie verzamelen.
Een entiteit is een concreet (persoon, artikelen) of abstract (werkwijze, organisatie) begrip, dat van betekenis is voor een organisatie en waarover gegevens (informatie) worden vastgelegd.
Wat is een Referentiële integriteit
Referentiële integriteitsregels zijn regels die ervoor zorgen dat de relaties tussen gekoppelde tabellen consistent blijven.
Wat is een Vreemde sleutel (foreign key)
Een vreemde sleutel is de verbindende schakel tussen twee tabellen. Met een waarde uit een rij van de ene tabel kun je in een andere tabel de juiste rij met gerelateerde gegevens opzoeken. De ene tabel geeft als het ware de sleutel voor de andere, 'vreemde' tabel.
Wat is een Primaire sleutel (primary key)
De primaire sleutel is de unieke identifier voor alle informatie in elke rij van een databaseset.
Wat is een Kandidaat-sleutel

De kandidaat-sleutel is de benaming voor een attribuut, eigenschap, karakteristiek of feit (of een combinatie hiervan) over een entiteit, fysiek object of gebeurtenis die voldoet aan volgende drie eisen:
Uniekheid
de waarde van het attribuut (of een combinatie hiervan) is uniek binnen de tabel en bepaalt dus eenduidig de record, rij of tupel waarin deze attribuut voorkomt. Geen twee rijen in een tabel kunnen dus identiek zijn vanwege het unieke attribuut (of combinatie van) in iedere rij.
• Niet leeg

het attribuut (of een combinatie hiervan) is overal ingevuld. Kan dus niet leeg zijn.
• Minimaal aantal attributen
de combinatie van attributen uit een record, rij of tupel is minimaal. Door het laten vallen van één van de attributen wordt de record, rij of tupel niet langer meer eenduidig bepaald.
In de vele gevallen zullen per tabel meerdere kandidaat-sleutels bestaan. De kandidaat-sleutel die hieruit wordt gekozen ter unieke identificatie van de record noemt men de primaire sleutel.
Wat is een Extensie
De verzameling tupels van een relatie.
Wat is een Domein
Een verzameling van waarden. Een attribuut van een relatie behoort tot een bepaald domein en mag dus ook alleen een waarde uit dat domein hebben. Zo kan een geboortedatum niet in de toekomst liggen, kan een Nederlandse postcode alleen bestaan uit vier cijfers en twee letters en kan het veld/attribuut geslacht over het algemeen geen andere waarden aannemen dan man of vrouw
Wat is een Attribuut
de basiseenheid binnen een database is een veld. Dit is een soort gegeven/begrip/eigenschap en wordt meestal attribuut genoemd. In een weergave in de vorm van een tabel zijn de velden de kolommen. In elk veld/kolom wordt een specifiek gegeven vastgelegd. Bijvoorbeeld achternamen, voorletters, geslacht, postcode, huisnummer, geboortedatum et cetera.