Recently I read a very interesting book on requirements analysis “Mastering the Requirements Process: Getting Requirements Right” by Suzanne Robertson and James Robertson. They wrote a practical book that lead to a template for such a document
They advocate to spend enough time on requirements analysis, which can be described shortly as “getting to know what the user wants”. The idea is that a project should be based upon the users’ requirements. If one understands these requirements, one knows the scope of the project. Moreover, the priority within the project can be set better as it is based on user’ sensitivities.
Formulating the requirements is fundamentally different from writing a design. A design provides a solution and is formulated in technical terms. Requirements provides a list of user wants and it is formulated in business terms. Hence a discussion on databases doesn’t belong in a requirements document as it is part of a solution. The same holds for a user interface; this is part of a solution; it is not a requirement.
The requirements fall into three groups:
- Functional requirements that indicate what functionalities (data, business logic) is delivered by the system. It indicates what the system must do.
- Non-functional requirements that indicate how the data/ business logic is delivered. One may include security requirements here, performance requirements. This indicates a property of the system.
- Constraints that indicate to which rules a project must comply. An example is the toolset that might be used to implement the solution.
The requirements must comply to a certain format:
- They must be numbered as to make them traceable.
- They must be testable. Hence they must be formulated in a quantified way. Examples of requirements that are formulated wrong are: “The application must generate an exciting user experience. ” Any experience may be labelled as exciting. Hence it is not testable. Better is: the application can be understood by a user within 30 seconds, or the report must be generated in 30 seconds.
The requirements should fall within the scope of the project. This scope is identified with a context diagramme. See my other post. A requirement falls within the circle that in shown in the context diagramme and which describes the project. This context diagramme also provides a nice starting point for further requirements analysis. The context diagramme displays dataflows to and fro the system. These dataflows are indicated by arrows. For each of these arrows, logic must be created in the systems that handles these input- and output flows. This logic is derived from business requirements.