Requirements, user or system prespective?

Question

How to identify when to use an user or a system definition of a requirement?

In the example below:

Use case: List Posts by status

Pre-conditions: The admin is authenticated. There are items registered in the system.

Trigger: The admin wants to list the posts according to its status (published, draft)

Ator: Admin

Main flow:

• The system presents the saved posts and all the list options (published, drafft)

• The admin chooses a list option

• the system list the posts according to the list option chosen by the admin

Post-condition:

• Posts listed according to the status chosen by the admin.

The functional requirements are:

• the system shall present all the registered posts to the admin when he accesses the posts admin page.

• The system shall list the posts according to the status choosen by the admin.

• The system shall present an info message to the admin if there aren´t registered posts.

• The system shall only list the posts if the admin is logged in.

Or

• the admin shall be able to consult all the registered posts when he accesses the posts admin page.

• The admin shall be able to list the posts according to its status.

• The admin shall be notified if there aren´t registered posts.

• The admin shall be logged in to check all the registered posts.

Or none? Or its equal?

Answer 1

Documenting everything as the X shall is overly formal and not human friendly, its easy to miss implementing requirements or not discover assumptions that should be requirements. I'm a fan of using Gherkin style syntax to document requirements, whether you use it to develop automated testing or not. The Given, When, Then syntax gives you a few nice bonuses.

• Its easy to read requirements documented this way.
• It becomes obvious when trying to document too much with a single statement.
• It makes you think about the way the system should behave which can help discover missed requirements or areas that need clarification.
• You get requirements written as acceptance criteria.
• you can use them alongside automated testing to be more confident you have implemented all requirements correctly, and changes haven't broken existing functionality.

If you have to document requirements in such a way as your question because of decisions outside of your control then it doesn't really matter what you choose. Pick whichever way makes people happy that want documents like this, both options are equally irrelevant.