Project Phases vs. Requirements Structure

In the previous chapters, we introduced how various types of requirements are stored in different documents and the reasons why they should not be mixed together. In this chapter, we would like to clarify what analysts are often puzzled about: the relationship between the presented documents and project phases. Solutions are typically analyzed top-dow, from the high-level requirements such as "System shall allow the user to display all contacts" to the low-level ones. For example, "The list of contacts shall be sorted by the surname ascending". Therefore, one would naturally think that the analysis is a linear activity and analyst first finds out the general requirements and then continues to details:

However, analysis is not a linear activity. Even though it usually starts with the high-level requirements elicitation and then continues with specifying the details, it is an iterative process in which a newly identified low-level requirement may trigger changing previously elicited requirements on the higher levels.

Additionally, stakeholders do not structure their thoughts top-down, so analysts cannot expect requirements to come in some predefined order. Stakeholders do not present requirements "in layers", instead they tend to bomb analyst with various wishes and requests of all types at once. Experienced analysts should be able to manage this, stay at the single level of detail to not let themselves get buried in the detail, yet at the same time, they cannot ignore anything which might have an impact on the architecture of the solution. All types of requirements must be therefore assessed right after they were elicited to evaluate whether they impact the solution architecture is some way:

In conclusion, requirements documents should reflect different types of requirements and should be appropriately structured, however, requirements cannot be expected to come in the order that matches that structure.