1. 9
    1. 1

      I totally agree, but how then should we track requirements? How have people seen that work successfully? I have my ideas in theory, but all of my professional life has been in a world where user stories are the status quo.

      1. 4

        “track requirements” does not make a lot of sense to me, but I will take a stab at, “How to set requirements without relying on user stories”:

        1. Pick an achievable thing
        2. Summarize the thing by a) starting your summary with a verb and b) not including any hints to implementation (“how” to do the thing)
        3. Write statements describing what the environment will look like with the achievable thing, achieved: again without hinting at implementation or the “how” of achieving - using words like “should, should not, may, may not, must, must not”

        Your statements in step 3 are requirements. Your story does not exist (or can be whatever marketing/your manager/your spin doctor wants it to be), and how you go about satisfying those requirements is fair game to anyone that wants to do the work.

      2. 1

        Sphinx Needs is the fancy new thing at my work. However, I’m in a regulated field so maybe something more lightweight is good enough for you already.

        More important is to write them well (e.g. clear, testable, independent). I don’t know any tools for that though.