Screen

A screen represents the part of the user interface, which displays some content to the user. It could be a desktop application window, a webpage, a mobile application screen, or even a screen of an embedded system such as ATM or a cashier system. It could also represent a screen fragment which is shared among multiple screens, typically menus, header or footers. The screen can be an analytical artifact created to verify its behavior during analysis but also can represent the final design documenting the released system.

Screens are a great visualization tool during requirements elicitation. It is so much more intuitive to discuss software using visual user interface models, compared to describing just abstract textual requirements. Text leaves a lot of room for misinterpretations, as everyone is forming pictures in their heads, and it is often surprising to see how requirements change when stakeholders are presented with "pictures".

What is more, screens are not great just for visualizing requirements, they could literally be requirements. Instead of writing "The product table shall include Name and Price columns", wouldn't it be more descriptive to sketch a screen containing the table containing the two columns? The only downside is, you need to agree with stakeholders on which aspects of the screen are requirements and which are just design. The goal is to prevent stakeholders from claiming that the background must be red, not blue. Of course, there are projects when the final design is crucial, yet this is not the case for most business applications.

Documenting

User interface descriptions, be it hand-drawn sketches or wireframes, are basically models, so they share the same advantages and disadvantages. They are great to quickly find information that would otherwise require discussions with users or investigating source code, but like any other documentation, it takes time to create and maintain. Documenting user interface shares the same aspects of documenting software, such as documenting stable things, creating overviews not details or not insisting on comprehensive documentation. In some cases, there could be a complicated business logic behind clicking on a button, and it might be worth documenting what is going on to quickly get the answers in the future. Not all scenarios are easy to simulate in the application, and it is then beneficial to have an option to check the documentation to see what happens in the background, without spending hours to simulate it in the real application.