5 ms·

Completely, totally, 100% disagree. A user story is a concept of operation and it is an essential part of requirements analysis. If you throw the user story i

Completely, totally, 100% disagree. A user story is a concept of operation and it is an essential part of requirements analysis. If you throw the user story in the garbage, you can throw your software in the garbage along with it.

nuclearnice1 4y ago
You’re quite passionate about it. Could you explain some of your reasons?
- jschveibinz 4y ago
  Hi, yes I would be happy to provide detail. An important part of any software development project (not prototypes, of course) is the establishment of a solid set of requirements. To do that, an engineer needs to understand the following things: 1. The context of the software. Where does the software “live” in the world? A context diagram is very useful. 2. The major interfaces. What are the channels, formats, data structures, etc. Interface control documents are very helpful tools, as are any number of diagrams depending upon the application. 3. The concept of operation and “user story.” This is a top-level description of what happens when, why, and how to whom? This involves timing, aesthetic, user inputs, safety/security, other usability factors, outputs/results, etc. When you try to describe how people use the software, salient requirements can be discovered. It also helps to create a wireframe that can be shared with the customer to uncover more details or steer the requirements in a different direction. 4. Develop a draft set of requirements. I won’t go into detail, but this is the culmination of the preceding steps. Good luck.
pleb_nz 4y ago
I wouldn't go as far as saying your software will end in the garbage. There must be good software that exists that didn't use user stories some now or I'm the past
- tcmart14 4y ago
  Maybe we need another way to express user stories. So I am sure most all features do have some 'user story,' it is whether or not it is formal or looks like one. Where I work, we don't have 'user stories,' but when I and others on the team work on a ticket, we all essentially create our own user story in our head. The issue with this, does the user story I imagine, sometimes even unknowingly, match up with what was expected without it being implicitly stated? I imagine we all, regardless of how the requirements are laid out, design and code things in our mind with some thought as to the perspective of the user. Sometimes it turns out good, sometimes not so much. Some of us are good at it, some of us are dogshit at it.

nuclearnice1 4y ago

You’re quite passionate about it. Could you explain some of your reasons?

jschveibinz 4y ago
Hi, yes I would be happy to provide detail. An important part of any software development project (not prototypes, of course) is the establishment of a solid set of requirements. To do that, an engineer needs to understand the following things: 1. The context of the software. Where does the software “live” in the world? A context diagram is very useful. 2. The major interfaces. What are the channels, formats, data structures, etc. Interface control documents are very helpful tools, as are any number of diagrams depending upon the application. 3. The concept of operation and “user story.” This is a top-level description of what happens when, why, and how to whom? This involves timing, aesthetic, user inputs, safety/security, other usability factors, outputs/results, etc. When you try to describe how people use the software, salient requirements can be discovered. It also helps to create a wireframe that can be shared with the customer to uncover more details or steer the requirements in a different direction. 4. Develop a draft set of requirements. I won’t go into detail, but this is the culmination of the preceding steps. Good luck.

pleb_nz 4y ago

I wouldn't go as far as saying your software will end in the garbage. There must be good software that exists that didn't use user stories some now or I'm the past

tcmart14 4y ago
Maybe we need another way to express user stories. So I am sure most all features do have some 'user story,' it is whether or not it is formal or looks like one. Where I work, we don't have 'user stories,' but when I and others on the team work on a ticket, we all essentially create our own user story in our head. The issue with this, does the user story I imagine, sometimes even unknowingly, match up with what was expected without it being implicitly stated? I imagine we all, regardless of how the requirements are laid out, design and code things in our mind with some thought as to the perspective of the user. Sometimes it turns out good, sometimes not so much. Some of us are good at it, some of us are dogshit at it.