Throughout this semester my classmates and I had to do the pre-coding(?) phase of a project (requirements and such) as part of our Software Engineering course. The way our professor had us do it seems odd to me and I'd like your input.
First we were given a document with the problem and had to extract requirements from it into a Word document. The project was about the software for a parking lot. That part didn't seem so weird to me, but then we had to fill in a bunch of other things in this Word document which would later be called "report" (at this point it was just called "Component 1"), such as a context that is a grid with this format:
This Word doc also had a "change history" which we never ended up using. This report also described the software, the client, the quality and functional requirements, the restrictions, and the drawings.
These drawings are pencil sketches of some functionalities of the software, ie creating an account, with all the steps. Here are my drawings (the first one is a user profile and the 2nd one is a blueprint of the garage with the sensors and zones):
Then we had to make a "detailed version of the requirements" in an excel document. This contained things like a glossary, actors, objectives of the Organization (ie making money, using SCRUM, expanding to the EU), objectives of the Software (ie functionality), links of real software we took inspiration from, and then the fun part: User Cases, UC scenarios, UC steps, entities and entity attributes.
User Cases: Describes user cases. Its columns are things like the objective it relates to, main actor, other actors, pre-conditions (ie there must be entries in the database, internet connection), post-conditions (ie the printer prints something), priority, importance (idk what the difference is between this and priority), UC scenarios it participates in. We had to fill in, by hand(!) over 50 rows. Most of this was just copy-pasting and changing the name and the description.
UC scenarios: Scenarios wherein the UCs are used. Examples:
- Creating user profile: success
- Creating user profile: cancelling (user clicks the cancel option)
- Creating user profile: exception (incorrect data is inserted)
This particular part had over 100 rows which we had to fill, by hand. Most of this was copy-pasting with little editing. Columns include again pre-conditions (what UC it was part of, basically, which was repetitive), post-condition (ie. UC is cancelled), results (ie an error message is printed. Not much difference from post-condition and as we couldn't figure out the difference we kind of made it up), and UC scenario steps it relates to.
Now the worst part.
UC scenario steps: For every UC scenario (there were around 110) we had to describe the steps. For example:
- User clicks "create account" - Type: System call - next step: 2
- User inserts data - Type: Data introduction - next step: 3
- User clicks "Submit" - Type: Data submission - next step: 4
3b. User clicks "Cancel" - Type: UC cancelling - next step: ... ...
And so on. We filled more than 500 rows of this, by hand. It took a considerable amount of time and most of this was copy pasting.
Then the entities. Our professor told us "Imagine how the data will be inserted in the database, the entities are the tables and the attributes are the columns". And that was basically it, only we couldn't repeat attribute names (ie. the vehicle ID in the User table as it already exists in the Vehicles table) for some reason. Something about it "already existing in another entity".
Me and a group of classmates from the Msc who have already completed this class were talking to a professor of another class and he asked us what we did in this class and we told him what I wrote above (we all had the same experience) and he laughed so hard at us he almost started to cry, which was quite funny to be honest. He said no one does it this way in real life, that this is all automated, and found the part about the pencil sketches particularly funny.
He said that nowadays everybody uses agile methodologies which have nothing to do with this. To be honest through the whole semester I could never understand what methodology we were using. It looks like some variation of RUP, vaguely, sort of? It's agile-ish because we'd go back to earlier steps and complete them in steps afterwards and we could change the requirements, objectives and other things over time (which our professor insisted we did so sometimes we'd just make up stuff) but this doesn't look much like the agile methodologies I've studied in class.
On our last evaluation I told the SE professor this wasn't normally done in real life because there is software that does the excel stuff for us, and she insisted that it was impossible to automate this completely, and that because our requirements were from a problem statement and not interviews we had to do it this way (I assume she meant there were no user stories?), that this is how its done and told me to "get some real life work experience" and then get back to her. She said that requirements engineering is supposed to be repetitive and I said that a lot of the stuff we did could very easily be automated and that it was hard to believe nobody had done so until now, and she insisted that no, it was impossible to fully automate this process and that many things still had to be done by hand, and then told me that when I learned how to sum in school first I had to learn how to do it by hand, to understand, and only then did I learn to use a calculator and this was the exact same thing (so which is it?). I commented that it didn't seem to me that teams used excel and word for requirements in this way irl and mentioned SCRUM and backlogs, and she insisted that while many teams used different methodologies than hers, this process still had to be done and many do it this way.
I felt it was better not to insist and afterwards I got a long winded email from her that one of the reasons our work was so repetitive was that we repeated a lot of the same scenarios and steps in the UC scenarios steps bits and that irl there is "more variety" so it's "less repetitive".
One more thing: In one class our professor told us we could make this more "KANBAN like" by adding a column called "progress" in our excel and writing whether a particular requirement/objective (she said those were different things but the difference was lost to me) had already been finished or was in progress.
My question is, what is this methodology we used? Is this even a thing?
How is this done in real life?