Project Phases vs. Requirements Structure

In the previous chapters, we introduced how various types of requirements are stored in distinct documents and explained why they should not be mixed together. In this chapter, we clarify a topic that often puzzles analysts: the relationship between these documents and actual project phases.

Solutions are typically analyzed top-down, moving from high-level requirements like "The system shall allow the user to display all contacts" to low-level details such as "The list of contacts shall be sorted alphabetically by surname." Therefore, it is natural to assume that analysis is a linear activity where an analyst first locks down general requirements before moving on to the details:

In reality, analysis is not a linear activity. While it usually begins with high-level requirements elicitation and progresses toward specific details, it is an iterative process. A newly identified, low-level requirement can easily trigger changes to previously established requirements at higher levels.

Additionally, stakeholders do not structure their thoughts in a neat, top-down fashion, so analysts cannot expect requirements to arrive in a predefined order. Stakeholders do not present requirements "in layers"; instead, they tend to bombard analysts with a mix of high-level wishes and low-level technical requests all at once. Experienced analysts must manage this influx, staying at the appropriate level of detail during discussions to avoid getting buried, while ensuring they do not ignore inputs that could impact the system's architecture. Every requirement must be assessed immediately after elicitation to evaluate whether it impacts the underlying solution architecture:

In conclusion, while requirements documents must be structured properly to reflect different types of requirements, you cannot expect the requirements themselves to arrive in the order that matches that structure.