Reading Amy J. Ko's online book "Cooperative Software Development" and she writes:
"There are some approaches to specifying requirements formally. These techniques allow requirements engineers to automatically identify conflicting requirements, so they don’t end up proposing a design that can’t possibly exist. Some even use systems to make requirements traceable, meaning the high level requirement can be linked directly to the code that meets that requirement."
@KFosterMarks The University of Toronto used to have an entire undergrad course on requirements engineering. Students I kept in touch with after graduation said they never saw any of it used in industry. One of the more thoughtful ones once asked me if I thought agile had become popular in part because RE had proven infeasible in practice. I didn't (and still don't) know enough to answer, but outside NASA/nuclear/avionics-level environments, I've never seen it stick.
@KFosterMarks yeah. I think there's a parallel universe close to ours where we came to short-cycle development along a different road and now call people "requirements engineers" instead of "product managers", but what they do is basically still maintain the complex mental model of needs <-> features and handle negotiations around that. Which leads to counter-questions: what tools if any do PMs use to management that mapping, how automated is it, how automated can it be, etc.?
@billseitz I don't know that I would agree with that - my experience doesn't support a blamability hypothesis, anyway. Of course, this is organization- and team-culture dependent - I do think I've been lucky to mostly land on teams with cultures that don't lend themselves to blaming.
I've never been on a software team that made requirements traceable in any methodical, systematic way. Curious if others folks have, and how this was accomplished? Was it worthwhile?
(To be clear, not asking for anyone's opinions on requirements gathering - specifically, I want to know about requirements ▶️ traceability ◀️ methods)
@KFosterMarks I’ve proposed and demoed such systems quite a few times, with most stakeholders agreeing it would be great. It never gets past that point however. As soon as cost comes into the conversation it’s always “we’ll just use Jira and Confluence”.
@KFosterMarks Sort of the minimum here is requirements go in your issue tracker (JIRA or whatever), and then you train devs to make their commit messages include issue #s. A commit-hook adds the message and link to the commit as a note to your issue.
This way you have bidirectional commit<->issue links so you can see which code has been written for X issue or (via commit history) what issue(s) prompted the writing of X code.
@gregtitus Thanks for sharing this, and now I'm face-palming - I have been on a team that did this! I hadn't made the connection between this process and requirements traceability.
@KFosterMarks I had to do bidirectional requirements tracking when working on electronic medical record systems, I believe as part of legal requirements for FDA approval in the US. It was a lot of work and never 100% accurate. Not something I would do again voluntarily. The basic practice of including ticket numbers in commit messages is much less work and more likely to be accurate, altho it makes audits more of an archeological project
@beandreams Oh, interesting use case for bi-directional tracking! Now you've got me thinking about the various instances & contexts in which this sort of requirements traceability is absolutely required...
um also I just looked at your profile and you build Indigenous language revitalization tool!?!?!? SO INTERESTED - where can I learn more?
@beandreams Thank you so much for sharing this! I think I might be about to become an open-source contributor 😍 (For context, I have an M.A. in an applied linguistics subdiscipline which I hesitate to explicitly name in the context of this conversation because...well...it's TEFL/TESL 😆 )
@KFosterMarks
I have seen it done, but it is a huge effort and many just give up - especially because the shift to agile meant that requirements changed and crept a lot over the course of the project.
What it amounted to was a requirements register, and each requirement was given a register # and then was included in the progress reports. So in theory, everyone in a dev team knew which requirement their work was for and completion % was reflected in a requirements dashboard.
@mloxton Oh, interesting - the requirements register sounds like a lot of manual work! From what I'm seeing from folks' responses, it seems like "motivation" is a big factor for establishment and adherence to these traceability systems.
Add comment