Please wait...

Formulation of software requirements in the Novtehprom Co

Here you should pay attention to two things:

  • It is impossible to perform this part of the work satisfactorily without the active participation of the customer.
  • Mistakes at this stage are too expensive in the literal sense.

We have developed a certain procedure for setting requirements, which we try to adhere to.

For relatively small projects, we simply write down the requirements from the customer's words.

For some projects, it may take several such meetings with different representatives of the customer.

Then we analyze, clarify and formalize this either as part of the contract, or as an Appendix to it.

For some projects, you may need to create special documentation.

The main result of the formulation of the requirements is:

  • Answer to the question, What is the main goal of the project?
  • List and brief description of stakeholders. (That is, everyone who has something to do with the program). And also:
    • The location of program users.
    • The environment in which users will work.
    • The equipment they will use.
    • Answers to questions about how much of their daily responsibilities will be taken up by working with the program, what work in addition to working with the program they should perform.
  • Understanding use cases the program.
  • In which hardware and software environment you plan to deploy the software you are creating.

Documentation related to requirements may include the following artefacts:

  • Descriptions and diagrams of business processes.
  • Tables of business rules and special terms.
  • Vision. This document describes various important aspects related to the development of the project. This can be a list and a brief description of stakeholders, a brief analysis of analogs of the program on the market, an assessment of monetary costs, time for development, an argument for the justification of development (or, conversely, inexpediency).
  • The initial version of the list of all use cases of the program or the use case diagram.
  • Full, detailed description of 10% of the most significant precedents. Which contains a set of scripts in the format:
    • User action
    • System response
    • User action
    • System response
    • ..
    • and non-functional requirements related to this case.
  • Initial version of the additional requirements specification. This section describes non-functional requirements for the program that apply to the entire program and are not included in the case descriptions.
  • The General plan of development.

For large projects, in the next phase (the elaboration phase), when work on the code is already beginning, the initial requirements are subject to evolutionary changes, sometimes significant. Adjustments to requirements are also allowed during the construction phase, but to a much lesser extent.