Andy,
Frankly, my eyes started glazing over after I read the first few sentences. I can understand how the developer may be stumped. When it is difficult to describe the requirement in its entirety you can certainly use pseduo code. However, here is a suggestion to help you break down the requirement; it has worked well for me time and again.
Take a real world example of your search situation. Really this A and B example is confusing, stick with your first name, last name example. Start putting together the process steps of how the application would implement the search algorithm like so:
System shall compare the value input by the user in field 1 with the value input in field 2 and if they match....
The above could be your high level use case which could be broken down further into what happens if field 1 exhibits xyz criteria...
What are the end results of your search? Keep going with the above exercise until all pathways to achieve those results are defined. I find that visual representation of the scenario greatly helps in resolving the requirements. Once you define a use case, run it by your developer to check whether he/she understands it.
Good luck!
Kay
Hi Andy,
I worked on a data analytics project last year dealing with this stuff.
Try a user story or use case with business rules attached. User story is something like:
As a researcher (or whatever your actor is) I want to search on XXXX (whatever A and B are in business terms) so that I can XXX (business reason for searching on them)
Then in the acceptance criteria put in the scenarios you talk about. Remember to put positives and negatives. One negative will be to handle the case of not searching on that field when nothing is entered.
Using something structured like a user story or use case will take away the ambiguity you see in writing sentences.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: