Nesma homepage Forums Sizing Sizing – FPA Transaction and selection

Tagged: , , ,

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #2234
    Ye olde Phorum
    Participant

    An issue that I encounter regularly is the situation of a transaction (EI/EQ/EO) that is preceded by a selection that either results in an unambiguous result or in a list of results. An example is the functionality to change personal data (EI).

    • When the selection of the person is unambiguous, the selection is part of the EI (and the DET for selection are part of that EI).
    • When the selection of the person to be changed is not unambiguous then a list of all search results is displayed. This is an additional EO and the DET for selection are not part of the EI, but of the EO.

    If both options are required by the user, so with an unambiguous result the change functionality is displayed directly and otherwise a list of all matching search results is displayed, then according to my interpretation the following functions should be counted:

    • EO (search results)
    • EI (from the search results, excluding the DET for selection)
    • EI (from an unambiguous selection, including the DET for selection)

    The two EI are different in number of DET and are therefore unique. This is according to the letter of the Counting Guideline, but to me it seems to be contrary to the logical perspective to count two EI for what a user would not consider to be two different functions. I would like to count only 1 EI and 1 EO, but to my knowledge the Counting Guideline does not allow for that.

    Originally posted in Dutch by Andreas Schuderer.
    Nog een issue dat volgens mij vaker optredt is de situatie van een transactie (IF/OF/UF) waarvoor een selectie gemaakt kan worden die of eenduidig of niet eenduidig kan zijn. Een voorbeeld is een functionaliteit om persoonsgegevens te wijzigen (IF). Als de selectie van de te wijzigen persoon eenduidig is, dan is deze selectie onderdeel van de IF (en de selectie-DET(s) horen ook bij de IF).
    Als de selectie van de te wijzigen persoon echter niet eenduidig is en een selectielijst met alle zoekresultaten getoond wordt, dan is dat een extra UF. De ingevoerde selectie-DET(s) horen dan niet bij de IF, maar bij de UF.
    Indien beide mogelijkheden door de gebruiker vereist zijn, dus bij een eenduidig zoekresultaat rechtsreeks de invoerscherm getoond wordt, en bij een niet eenduidig zoekresultaat een selectielijst getoond wordt, dan moeten volgens mijn interpretatie van de huidige richtlijn de volgende functies geteld worden:
    UF (selectielijst)
    IF (voor het geval dat een selectielijst wordt getoond. Exclusief ingevoerde selectie-DET)
    IF (voor het geval dat er geen selectielijst wordt getoond. Inclusief ingevoerde selectie-DET)

    De twee IF’s verschillen dus qua samenstelling DET en zijn derhalve uniek.
    Volgens de letters van de telrichtlijn is dit wel redeneerbaar, maar mij lijkt het toch tegen de geest van de richtlijn om dezelfde IF uiteindelijk in twee varianten te tellen die de gebruiker zeker niet als twee aparte functies zou beschouwen. Ik zou hier maar 1 IF en 1 UF willen tellen, maar de richtlijn laat dit volgens mij niet toe.

    #2494
    Jolijn Onvlee
    Participant

    I do not see the two seperate EI’s. When you start the EI from the search results by selecting the right person (unambiguous) you have in my opinion the same EI as selecting the person by his/her unique number.

    #2573
    Martin Jacobs
    Participant

    I also do not see two Eis. The EI is triggered by the unique person id. This is provided directly or indirectly as a search result. The process to get to the unique person id is an EO (selection list). The selection DETs are part of the EO and not of the EI. So there is no difference in the number of functions identified at global or detailed level.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.