.png)
One of the key activities in business analysis, or to be more precise, in requirements engineering, is the identification and documentation of requirements. Very often, even notoriously, I encounter the term "writing requirements". This term perpetuates one of the fatal myths regarding requirements engineering.
Requirements are not written. Requirements are specified.
Requirements form the basis for making various decisions. Depending on the type of requirements, these decisions may concern the organization's strategy in specific areas, approaches to solutions, or choice of architecture. Do we make such decisions based on the results of "writing"? The term "writing" simply implies presenting information in written form in any way. Specification means presenting information in a precise and accurate manner.
Referring to requirements and their significance in organizational and project contexts, which phrasing is more appropriate – "writing requirements" or specifying them?
Setting aside semantic issues, the term "writing requirements" also implies that requirements can be "written" in any form and may contain any content. This is one of the most entrenched misunderstandings among business analysts.
High-quality requirements are actionable – meaning we know what they refer to, what their expected outcomes are, and we have the basis to assess whether the requirements are properly fulfilled.
How does this relate to typical "written" requirements, such as: "the system enables route search"?
On what basis do we want to determine whether this requirement has been properly implemented, since we do not know what the outcome of this search should be? Perhaps the outcome should be: "A list of routes meeting specific criteria"… The problem is that we do not know what criteria, because we do not know how the search is to be conducted and by whom – whether the system randomly searches for a route based on specific parameters or whether the search is initiated by the user after entering search criteria? We do not know this.
We also do not know who uses this requirement, nor do we know what the outcome is. Stating that the outcome should be a searched route is almost worthless.
Requirements, especially functional ones in this case, should specify what the input and output are, just like the definition of a function. In this case, we do not know either the input (what information needs to be entered to execute the search) or the output, i.e., the information we would like to obtain after executing the search function.
We also do not know any constraints. In this example, we are talking about searching for a route, probably from point A to point B. Is it possible to search for a route to a point 100,000 km away? In what time frame would we like to obtain the search results? We do not know this either.
A well-specified requirement would clarify these issues. A requirement written in this way does not contain such information.
As a result, the development team has no idea how to implement the requirements, the testing team has no clue what to test, and the business stakeholders, from whom this requirement probably originates, do not know what to expect from the implementation. The situation can be compared to trying to place an order at a florist by formulating your need as follows: "I need a nice, big bouquet for a birthday." No professional florist would accept such an order – so why do we expect that our requirements, written in a similar way, will be accepted by the development team or understood by the business?
Requirements are specified. To ensure that this specification is of adequate quality, it is necessary to ensure that the content of the requirement or supplementary attributes explain:
Who does what.
What is the measurable result of implementing the requirement.
In the case of quality requirements, what parameter we measure, what the measurement scale is, and what the measurement procedure is.
What the limitations are.
What the initial conditions are.
What data/information we process.
Comments