From what I’ve read I believe user requirements are just the system requirements given in lay mans terms, is this correct? I’m specifically referring to the book “Software Engineering” by Ian Sommerville which I am obligated to follow. Given the example below from said book, why is there not a user requirement to match the second system requirement. For example “the user requires the report to be generated after 17.30 on the last working day of the month.” To me that is still in natural language so it is readable by the user. How much detail should be included in a user requirement vs system requirement and where do you draw the line?
User Requirement Definition:
1. The MHC-PMS shall generate monthly management reports showing
the cost of drugs prescribed by each clinic during that month.
System Requirements Specification:
1.1. On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
1.2. The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
10
I’ll speak to your examples.
The first example of a “user requirement” is more like a wish or “feature.” The way you can tell the difference between a feature and a requirement is that there’s enough detail in the requirement to make it testable. Requirement 1 is not testable because, well, it’s a wish. “I wish that the system had some reports for the managers.” How do you know that the requirement has been achieved, that you can declare success?
Requirement 1.1 is testable because you can wait until the last working day of the month, and see if a report is generated on that day (or you can inject dates into the system and observe its behavior).
Requirement 1.2 is testable for the same reasons.
Neither system requirement, however, tells you what the reports should look like, how the data is laid out, or how the calculations are made; they only describe the reports in general terms. In practice, there will be a Software Design Specification of some sort that tells you in detail what these reports will look like.
2
In the sense of Ian Sommerville’s software engineering book:
User requirements talk about the problem domain, the world of the user.
They describe what effects need to be achieved.
These effects are the combined responsibility of the software,
the hardware, and the users (together: the socio-technical system).
System requirements talk about the solution domain, the world
of the software logic.
They describe what the software must do (as opposed to the effects
in the user’s world that this may or may not achieve).
They are the responsibility of the technical system alone (without the socio part).
For instance for a bookkeeping software,
- the user requirement is to compute the correct revenue.
- But the system requirement is only to compute the correct sum
of the partial revenues entered by the user.
If the user enters incorrect partial revenues the software is
not required to magically correct them: The output will
be the correct sum of the inputs, but not the correct overall revenue.
The difference is not overly interesting for most simple information systems.
It can be very important for life-critical software; see for instance the
various accidents involving the issue when or when not the thrust reversal
can be activated on a commercial airplane: The user requirement
“reverse thrust can only be activated if the airplane is on a runway”
has turned out to be surprisingly tricky to turn into system requirements
that reliably lead to the desired effect.
User requirements tell what application must/should do to satisfy user’s needs. It a list of features an application must/should have, and it is used a guidance when you develop an application: then all points are checked, you are (probably) done.
I tend to call this simply the “list of features”.
System requirements tell what system should have to be able to run the program:
- Hardware: CPU, memory, disk space, etc.
- Software: OS, libraries, packages, etc.
There is a bit of confusion:
- In “user requirements” the user is a subject, the one that require, and the program being developed is an object.
- In “system requirements” the program being developed is a subject (and it’s not even mentioned in a phrase), while “system” is an object.
The word “system” can refer to different things:
- software being developed
- physical device which runs the software being developed
- network of such devices
- OS together with execution environment
The thing you’ve called “System Requirements Specification” is probably something like the Software requirements specification – I consider that to be a superset of user requirements.
1
There is not much difference . User requirements describe what the user should do . System requirements describe how will the user achieve user requirements when interacting with the system plus non functional requirements such as “the system should handle 100000 users at the same time”.
So:
User requirement : The user should see their test results.
System requirement : The user navigates to the results page, where they can see their test results .
It’s so simple but as you can see they describe different things.
-
I get into my “fabulously computer-controlled car” and “drive to work.” What is my user requirement? Obvious enough, I think.
-
Little do I know – or care – that the many computers within my car are “doing a zillion things” along the way, just to safely and successfully take me to my parking-place. All of these are the system requirements, and I as a user I don’t care. I’m now at my destination, coffee-cup in hand, and that is enough for me.
-
But, somewhere, there were hardware and software engineers who defined and pored-over every one of those system requirements. So that I would never, ever, have to. ????
User requirement tell what application should do to satisfy users needs
System requirements tell a system should have to be able to run program
1