> The role of systems analyst (nowadays confusingly called business analyst)
Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers.
> seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role.
I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers.
> seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role.
I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.