cm0002@lemmy.world to Programmer Humor@programming.dev · 2 years agoJunior Prompt Engineeringlemmy.mlimagemessage-square54linkfedilinkarrow-up1754arrow-down18cross-posted to: [email protected]
arrow-up1746arrow-down1imageJunior Prompt Engineeringlemmy.mlcm0002@lemmy.world to Programmer Humor@programming.dev · 2 years agomessage-square54linkfedilinkcross-posted to: [email protected]
minus-square[deleted]@lemmy.worldlinkfedilinkEnglisharrow-up19·2 years agoWhat, like some kind of design requirements? Heresy!
minus-squareBjörn@swg-empire.delinkfedilinkarrow-up9arrow-down1·2 years agoDesign requirements are too ambiguous.
minus-square[deleted]@lemmy.worldlinkfedilinkEnglisharrow-up9·2 years agoDesign requirements are what it should do, not how it does it.
minus-squareheavydust@sh.itjust.workslinkfedilinkarrow-up4·2 years 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-squarepsud@aussie.zonelinkfedilinkEnglisharrow-up2·2 years 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.
Design requirements are what it should do, not how it does it.
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.
I’m a systems analyst, or in agile terminology “a designer” as I’m responsible for “design artifacts”
Our designs are usually unambiguous