cm0002@lemmy.world to Programmer Humor@programming.dev · 19 days agoJunior Prompt Engineeringlemmy.mlimagemessage-square46fedilinkarrow-up1221arrow-down11
arrow-up1220arrow-down1imageJunior Prompt Engineeringlemmy.mlcm0002@lemmy.world to Programmer Humor@programming.dev · 19 days agomessage-square46fedilink
minus-squaresnooggums@lemmy.worldlinkfedilinkEnglisharrow-up6·edit-219 days agoWhat, like some kind of design requirements? Heresy!
minus-squareBjörn Tantau@swg-empire.delinkfedilinkarrow-up3·19 days agoDesign requirements are too ambiguous.
minus-squareheavydust@sh.itjust.workslinkfedilinkarrow-up3·19 days agoThat’s why you must negotiate or clarify what is being asked. Once it has been accepted, it is not ambiguous anymore as long as you respect it.
minus-squaresnooggums@lemmy.worldlinkfedilinkEnglisharrow-up3·19 days agoDesign requirements are what it should do, not how it does it.
minus-squarepsud@aussie.zonelinkfedilinkEnglisharrow-up2·18 days agoI’m a systems analyst, or in agile terminology “a designer” as I’m responsible for “design artifacts” Our designs are usually unambiguous
What, like some kind of design requirements?
Heresy!
Design requirements are too ambiguous.
That’s why you must negotiate or clarify what is being asked. Once it has been accepted, it is not ambiguous anymore as long as you respect it.
Design requirements are what it should do, not how it does it.
I’m a systems analyst, or in agile terminology “a designer” as I’m responsible for “design artifacts”
Our designs are usually unambiguous