Episode 3.1: Framing is not suitable for audience

[smangham]

3.1 introduces the concept of software requirements, but does so in a way that's very focused on a clear, industry-style use case where 'Business' and 'Stakeholder' are clearly defined, and uses a pretty specific format of addressing those requirements. Then, the "consider new requirements for..." challenges are very vague and open. I can understand this being in the trials for AstraZeneca, but I think for the actual target audience of 2nd year PhD students, postdocs e.t.c. it's just not accessible. I don't think it teaches you how to identify what the requirements are for a given project and what the implications of those are.

It would probably be better if we approached it from the perspective of how requirements analysis means identifying what it is that the project is actually for.

Business/stakeholder requirements would benefit from being redone to describe requirements in a user stories-style format, e.g. "As a researcher, I want to take data from clinicians and identify trends in patient inflammation"). We could then reference Gherkin-format user stories as a way of formalising this (which also ties into things like e.g. Cucumber. Then we can break those stories down to get the implied functionality (which then leads into the redo of architecture I proposed in #495) .

I'd also advocate for redoing the 'non-functional requirements' section into an intro to/summary of the ISO software product quality standards, getting people to consider whether those things are requirements for their project, and if so what they are (e.g. how performant [i]does[/i] the code need to be?). Plus emphasising understanding the importance of the requirements up-front too (e.g. so you don't sink six months into improving performance when that isn't required, or making sure you check beforehand what file types your code will need to inter-operate with).

The current non-functional requirements section leans heavily on a challenge where most of the text space is spent describing mobile apps and embedded software, which are much more industry-focused than science-focused and lead to a bit of an implication that software requirements stuff is really just an industry thing.