"User" requirements vs "system" requirements

Question

I'm taking Software Engineering class and my professor is absolutely terrible at explaining anything. It's only the 3rd week and me and my group mates are already deeply confused.

We were given a script for the software of a parking lot and were also given a template with a grid. This grid has 3 columns: requirement number/id, type of requirement (functional or quality, or restriction), and the requirement itself. The title of this template is "User Requirements" and according to the theory classes, this is:

High level description, high level declaration. Declarations in natural language, along with diagrams of the services of the system and its restrictions. Written for the client.

I looked up these "User requirements" in the chosen bibliography and couldn't find anything by that name. What I did find was "High level description" and something in these lines, with the same definition as the quoted one.

At first I thought there were the parts of the software that were related to the user input and user interaction because later we will have to do something called "System requirements". According to the theory class:

Detailed description of each function, inputs and outputs, and operational exceptions. [whatever this means] Defines details of the implementation and can be part of a contract between the client and the provider. Written for the development team but the client may still be able to understand them.

The examples given here were pretty much in the same lines as the ones given for the "user requirements" except that they started with "The system must do xyz" and the others start with "The client should be able to xyz".

Then we were given another template, called "Document of Specification of Requirements" with a bunch of bullet points where we are supposed to write an introduction about this "system", the "User's functional requirements" (which I assume are the "User requirements" that fit under the "functional" type)) organized by "themes", the external interfaces of the system, the quality requirements and the restrictions, the user interfaces of the system, and lastly the "Detailed requirements" (I assume these are the "system requirements") and the "Distribution of requirements by theme".

We've asked the professor and we were given a very long winded explanation of what we asked and many other things we didn't ask, and ended up even more confused. What I did get was that "User requirements" are "for the client" and the "System requirements" are for the engineers, even though the examples in the theory are nearly identical. I suppose the latter involve technical details and such. The professor also told us that the "User requirements" are supposed to be "converted" into "System requirements". Most if not all my group except for me are repeating this class and judging by the level of confusion, I'm having a pretty bad feeling.

Can someone explain to me what my professor may be trying to do here and what these "user requirements" and supposed to be, as opposed to "System requirements", and why do we have to organize the requirements by theme twice, and what are the "Detailed Requirements"?

Honestly I don't even know what I am doing anymore. If anyone could explain to me briefly what I am supposed to be doing so I can have an idea of what my professor is trying to do, that'd be great.

Thanks.

Answer 1

While it's hard to know precisely what your professor wants, it sounds like a big picture overview would be more helpful than precision in this case.

When working as a software engineer, someone is going to ask you to do some work. While you might be getting the request through a chain of people talking to each other and then to you, the request will either come from a user, or from someone imagining what the user wants, and how that interacts with business needs.

Quite often, the person making the request will not know one or more of the following:

• How computers/software work in general
• How the current state of the existing software system helps or hinders adding that feature
• How long it can be expected to take given the above

This is expected. It's not their job, it's the software engineer's job to know how that stuff works.

All that means that the requirements (facts about how the software should behave) coming from users, or people imagining what users would want, are not usually in terms that lend themselves well to directly programming in. These are the User Requirements.

Here's an example:

The user should be able to upload a profile picture to the website.

That leaves a lot of things underspecified, and implicit. And to do that requires several discrete tasks to be done. This is not unusual among user requirements. Because you and I both know what a profile picture is it's easy to know what to do in this case, but often user requirements involve knowledge in a domain outside of software engineering.

Some things may be obvious to the person(s) who came up with the requirement but utterly non-obvious to you. But, you'll need to sort out that confusion so that the program can get written. Often there's no better way of sorting out the confusion than writing your best guess and showing it to the source of the requirements, in an iterative fashion.

Even assuming you understand the requirements perfectly, like in the profile picture example, you still need to break it down into steps that correspond to actually writing the software. This can be in your head as you are doing it if it is simple, or on metaphorical paper if it is sufficiently complex.

Here's a way to breakdown the profile picture example:

• We need a way of storing and retrieving the profile picture, once we have the image.
• We need to add a button in the UI to upload the image
• We need to load and display the image where appropriate
• We need to deal with the fact that the current profile code is hard to work with. We should fix it up first.

These are closer to System Requirements. Each of those can be further broken down, and more technical detail added, as needed. For example, the storage requirement could be refined down to which DB table needs a column added to it, and whether the files are in the DB or on disk somewhere else.

You are done breaking things down when you are confident you'll know what to do in front of a code editor. One can view the act of writing software as breaking the problem down into steps so specific that a pile of rocks can do it. (Computers are made of silicon, that is, sand.) That said, you will still learn things about the requirements in the act of writing the code. And sometimes it's better to jump into the code earlier than other times. It depends on the particular problem.