{"id":4339,"date":"2020-03-19T08:41:52","date_gmt":"2020-03-19T06:41:52","guid":{"rendered":"https:\/\/blog.iese.fraunhofer.de\/?p=4339"},"modified":"2024-01-12T14:03:40","modified_gmt":"2024-01-12T13:03:40","slug":"requirements-specification-4-5-containing-document-size-in-agile-requirements-documentation","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-4-5-containing-document-size-in-agile-requirements-documentation\/","title":{"rendered":"Requirements Specification (4\/5): Containing Document Size in Agile Requirements Documentation"},"content":{"rendered":"

The documentation of requirements is an important means within requirements engineering. In projects with few requirements changes over their runtime, good documentation can be achieved with relative ease. For agile projects, however, it is in their nature that their requirements as well as their compositions change continuously. The resulting need to adapt and update requirements in the documentation is often considered unnecessary additional work. How this perception came to be and how documentation can be dealt with in a way that boosts its advantages in Agile is the focus of this five-part series of blog articles.<\/p>\n

In the first part of this series, we investigated why requirements are documented at all. Part 2 addressed how requirements documentation was never meant to be dropped from agile development but remains an integral part of the development approach. However, to make requirements engineering work in agile settings involves tackling particular challenges, which we discussed in part 3. In this fourth part, we assume that requirements are being documented, but one final hurdle still has to be overcome: preventing chaos resulting from a proliferation of documentation.<\/p>\n

Documented requirements are a necessity for fostering communication, especially within the development team, but also with other stakeholders. They help practitioners to better understand the needs of the stakeholders. Furthermore, they are useful for getting early feedback in short feedback cycles and for adapting to changes in stakeholder needs. With optimal verbal communication, where the exchange is intensive and continuous, the requirements documentation could be less formalized, but distributed teams, language barriers, and time restrictions often impair direct verbal communication [6]. As a result, optimal communication should not simply be assumed.<\/p>\n

With respect to the agile value of putting working software over comprehensive documentation, the most suitable amount and degree of detail of documented requirements should be determined for each particular project setting. This can be considered from a bottom-up or a top-down perspective.<\/p>\n