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

237 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: Verhelderen en vaststellen bedrijfsdoelen. De requirements van de stakeholders uittekenen

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

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

    Specificatie: specificeren vereisten. Beschrijf de eisen formeel of informeel

    Validatie: Beoordelen of de vereiste goed is gespecificeerd. 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 filtert de requirements door puntEn die eigenlijk geen eis of beperking zijn te verwijderen.
    • Daarnaast haalt de requirements analist inconsistenties en overlappingen uit de requirements.
    • de requirements analist overlegt 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

Welk diagram is dit?
Sequence diagram
Wat zijn WebApp-projectmetingen?
Het doel van alle WebApp projecten is om een combinatie van content en functionaliteit te leveren aan de eindgebruiker. Maatregelen en metrieken die gebruikt worden voor traditionele software engineering projecten zijn moeilijk direct te vertalen naar WebApps. Toch is het mogelijk om een database te ontwikkelen die het mogelijk maakt om interne productiviteits- en kwaliteitsmaatregelen te beoordelen die zijn afgeleid van een aantal projecten.
Het ontwerp van een gebruikersinterface is vaak verdeeld in vier verschillende niveaus, welke zijn dit?

  • Het conceptuele niveau - Het beschrijft de basisentiteiten die rekening houden met de visie van de gebruiker op het systeem en de acties die daarop mogelijk zijn.
  • Het semantische niveau - Het beschrijft de functies die door het systeem worden uitgevoerd, d.w.z. een beschrijving van de functionele eisen van het systeem, maar gaat niet in op de manier waarop de gebruiker de functies zal aanroepen.
  • Het syntactische niveau - Het beschrijft de sequenties van in- en uitgangen die nodig zijn om de beschreven functies aan te roepen.
  • Het lexicale niveau - Het bepaalt hoe de in- en uitgangen daadwerkelijk worden gevormd door primitieve hardwarebewerkingen.

Het ontwerp van de gebruikersinterface is een iteratief proces, waarbij alle iteraties de in de voorgaande stappen ontwikkelde informatie verklaren en verfijnen.
Tot welke gouden regel behoort deze regel? Zorg met het ontwerp voor directe interactie met objecten die op het scherm verschijnen.
Place the user in control
Tot welke gouden regel behoort deze regel?Stroomlijn de interactie naarmate het vaardigheidsniveau hoger is en laat de interactie toe om worden aangepast.
Place the user in control
Tot welke gouden regel behoort deze regel?Definieer snelkoppelingen die intuïtief zijn.
Verminder de geheugenbelasting van gebruikers
Tot welke gouden regel behoort deze regel?Een set van applicaties (of producten) moet allemaal dezelfde ontwerpregels implementeren, zodat de consistentie voor alle interacties behouden blijft.
Maak de interface consistent
Welke regels horen bij verminder de belasting van het geheugen van de gebruiker

Verminder de vraag naar kortetermijngeheugen.
Stel zinvolle standaardwaarden vast.


Definieer snelkoppelingen die intuïtief zijn.

De visuele lay-out van de interface moet gebaseerd zijn op een echte metafoor.
Welke regels horen bij maak de interface consistent?
  • Laat de gebruiker de huidige taak in een zinvolle context plaatsen.
  • Een set van applicaties (of producten) moet allemaal dezelfde ontwerpregels implementeren, zodat de consistentie voor alle interacties behouden blijft.
  • Als er in het verleden interactieve modellen zijn geweest die verwachtingen van de gebruiker hebben gewekt, maak dan geen wijzigingen, tenzij er een dwingende reden is om dat te doen.
Bij welke regel hoort dit?Laat de gebruiker de huidige taak in een zinvolle context plaatsen.veel interfaces implementeren complexe lagen van interacties met tientallen schermafbeeldingen.het is belangrijk om indicatoren te geven (bijvoorbeeld venstertitels, grafische pictogrammen, consis-tent kleurcodering) die de gebruiker in staat stellen om de context van het betreffende werk te kennen.bovendien moet de gebruiker kunnen bepalen waar hij vandaan komt en welke alternatieven er bestaan voor een overgang naar een nieuwe taak.Een set van applicaties (of producten) moet allemaal dezelfde ontwerpregels implementeren, zodat de consistentie voor alle interacties behouden blijft.Als er in het verleden interactieve modellen zijn geweest die verwachtingen van de gebruiker hebben gewekt, maak dan geen wijzigingen, tenzij er een dwingende reden is om dat te doen. Zodra een bepaalde interactieve sequentie een de facto standaard is geworden (bijvoorbeeld het gebruik van alt-S tosave een bestand), verwacht de gebruiker dit in elke applicatie die hij tegenkomt. Een wijziging (bijvoorbeeld het gebruik van alt-S om schaling aan te roepen) zal voor verwarring zorgen. De ontwerpprincipes van de interface die in dit en de voorgaande paragrafen worden besproken, zijn een pro-vide basisrichtlijn voor een software-engineer. In de volgende paragrafen onderzoeken we het interface-ontwerpproces zelf.
Maak de interface consistent