Most Process Automation systems include a Human Machine Interface (HMI) that provides operator access to the functions the system is performing.
Often these have Graphic displays, which show the process and are animated.Typically these show Process Units, Equipment Modules, Control Modules etc.
They also have links to upstream and downstream displays, overviews that show for example the entire plant in a simple view.
Often graphics are based on the P&IDs - but these are not a good basis for graphics.
P&ID's are not designed for operational purposes:
They are full of irrelevant clutter - an operator knows the size of the pipes, and does not worry about reducers etc. These issues do not matter for day to day operation.
They show no dynamics at all.
Often there may graphics that are very similar - for example if a plant has several similar reactors, each will have a similar graphic. In such cases with the better implementations there is in fact a single graphic that is parameterised to make the same display appplicable to all.
(Note that could be a requirement itself, but one relating to the software design)
The URS and FDS in particular should define the contents of the graphics. A good Functional Requirements model can define all the displays and their links
There are also other types of Graphic such as Alarms, message handlers, pop up dispays for Control Modules and so on.
In general a URS should not specify these in detail if the system to be used provides their own standard versions. But it should specify the minimum requirements.
But beware, sometimes what are supposed to be standard turn out otherwise, and some 'standard modules' turn out to be not what you really wanted.