Timeline for Where can I find requirements specification for Open Source software?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 21, 2021 at 4:45 | comment | added | corsiKa | @ThomasOwens To be fair, I've seen plenty of projects experience significant delays specifically because people decided not to share the why. Add in a dash of "There's no way I didn't cover every use case" and a pinch of "Those stupid people in IT keep coming up with weird scenarios that will never happen, except a few times they actually did happen" and all of a sudden the why would have been really, really useful... This doesn't change your statement, you're still absolutely right, but is some food for thought. | |
| Jan 20, 2021 at 15:16 | comment | added | mmmmmm | @Voo Yes and it is the systems analysts/developers job to work that out from user requirements. The users often do not know the rationale, they just do the work every day. | |
| Jan 20, 2021 at 13:05 | comment | added | Voo | @mmmm The problem with that is, that if you don't understand the rationale behind some behavior it's impossible to safely adapt the feature. Figuring out the why is what makes one a subject matter expert and gets one paid better than the average user. Raymond Chen put it nicely as Good advice comes with a rationale so you can tell when it becomes bad advice. | |
| Jan 20, 2021 at 12:24 | comment | added | mmmmmm | @Voo users often can't explain why but just tell you that if X happens then do Y. ie they only know how | |
| Jan 20, 2021 at 10:58 | comment | added | Voo | Ah yes fair enough. Not a fan of of shall statements either for the same reason, but yeah it's a way of doing them. Use cases can be fine, since there you get at least some understanding of the rationale behind the feature (if the use cases are well written). +1 in any case. | |
| Jan 20, 2021 at 10:54 | comment | added | Thomas Owens♦ | @Voo Consider other, more traditional forms of requirements, like shall statements and use cases. They don't explain why. They only describe the intended behavior or attributes of a system. | |
| Jan 20, 2021 at 10:31 | comment | added | Voo | "They can be captured in tests". A test in itself only shows how something works, but doesn't explain why. So I wouldn't really count those. Agreed on the rest though. | |
| Jan 19, 2021 at 12:39 | history | answered | Thomas Owens♦ | CC BY-SA 4.0 |