Screen

A screen represents a part of the user interface that displays content to the user. It could be a desktop application window, a webpage, a mobile application screen, or even the screen of an embedded system such as an ATM or a cashier system. It could also represent a screen fragment that is shared among multiple screens, typically menus, headers, or footers. The screen can be an analytical artifact created to verify behavior during analysis, but it can also represent the final design documenting a 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 misinterpretation, as everyone forms different 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 just great for visualizing requirements; they can 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 a table with those two columns? The only downside is that you need to agree with stakeholders on which aspects of the screen are requirements and which are just design choices. The goal is to prevent stakeholders from arguing that the background must be red instead of blue. Of course, there are projects where the final design is crucial, but this is not the case for most business applications.

Documenting

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