Business Requirements

There are many tools to help form requirements. But, since each project is unique by definition, they are not much more useful than pencil and paper. The main thing is that the person who formulates the task has a bright head.

The FSD can be considered acceptable if it clearly and unambiguously prescribes the scope and criteria for acceptance of work.

The FSD can be considered acceptable if it clearly and unambiguously prescribes the scope and criteria for acceptance of work. If you paint in more detail, then it is desirable to mention the following:

  • General description of the automation system being created
  • How many users are planned to be connected to work with the system, what they will do, so far without detailing.
  • Description of business processes As Is (before planned automation)
  • Description of business processes To Be (after the introduction of a new solution)
  • Feasibility study of automation. The document is not mandatory, but it will help understand the client better.
  • Role model (who is responsible for what, what rights to access data and algorithms has, etc.)
  • Enumeration of entities used in automation: products, orders, customers, cash flows, etc.
  • Classification of entities into input and output parameters.
  • Description of systems containing input/output entities.
  • Which input data is generated directly by users.

  • What data is received from external systems via the API.
  • The number of transactions created by users in the system
  • A list and description of user input forms, if there are design requirements, then also with pictures.
  • A list and description of "fool protection" for data entered by users.
  • A list of checks for data supplied by other systems.
  • A list of specifications (including internationally accepted ones) of messages to which input and output data streams must correspond.
  • Requirements for integration with other automation systems. For an online store, this is, for example, integration with CRM, IP telephony, downloading orders from partner systems, tracking the stages of order processing in a courier company, etc.
  • Requirements for the composition of reports with a description of report attributes and algorithms for obtaining them from source systems, as well as other calculation algorithms.
  • Requirements for data sources for reporting: consistency, availability time, data acquisition API, etc.
  • Requirements for the speed of building reports or the time windows in which reports should be run and calculated.
  • Acceptance criteria (test cases or test program and methodology) - for each specific task. It is according to test cases that work will be submitted and accepted