{"id":2514,"date":"2020-12-09T11:40:33","date_gmt":"2020-12-09T10:40:33","guid":{"rendered":"https:\/\/www.evertop.pl\/how-to-prepare-a-good-specification-of-requirements-for-it-projects\/"},"modified":"2021-04-25T21:58:42","modified_gmt":"2021-04-25T19:58:42","slug":"how-to-prepare-a-good-specification-of-requirements-for-it-projects","status":"publish","type":"post","link":"https:\/\/www.evertop.pl\/en\/how-to-prepare-a-good-specification-of-requirements-for-it-projects\/","title":{"rendered":"How To Prepare a Good Specification Of Requirements For IT Projects"},"content":{"rendered":"

In the previous article you could read about how to find appropriate software company, which carries out the project of your idea. When you finally make a decision you will face another challenge. You probably already have a vision of your own project, however, the problem arises when you need to describe it on paper. How to start, what such a document should include, what should be avoided? This means writing a good specification of requirements, which aims to cover all the necessary functionalities of the new system in one document.<\/p>\n


\n\"...\"
\n<\/span><\/p>\n
\n

Read also: What Shall We Pay Attention To When Choosing Software Development Company?<\/a><\/h4>\n<\/div>\n<\/div>\n

How to start?<\/h2>\n
    \n
  1. Start with a brief description of your company\/organisation. Try to define what type of organisation it is and how it performs.<\/li>\n
  2. Define the scope for which the system will be dedicated to. Will it be designed for the internal use or will it serve the external users.<\/li>\n
  3. Describe the business processes, which will be implemented in your company. The business processes are the repeated actions carried out within a specific organisation. Such processes will be converted into system functionalities.<\/li>\n
  4. Think about the objective of the system. You need to know the answers to the following questions: what the target is, which areas need to be assisted, what processes need to be improved. Then you should present the requirements of specific functionalities, which are to be introduced into the system. You can do it through the user stories, which describe the necessary functionalities in a simple way, from the users perspective. It will help the developer to visualise how you want to use the system. You can draw the plan step by step or present it in a graphic form. Please find the example below:<\/li>\n<\/ol>\n
    \"Use
    Use cases<\/figcaption><\/figure>\n

    It is worthwhile to include in the graph the responsibilities of the system\u2019s users as well as the initial entry matrix for the users of the specific functionalities.<\/p>\n

    Precious hint:<\/strong> Describe everything in a very specified way, the more details the better.<\/p>\n

    What do you need to remember about?<\/strong><\/h2>\n

    \"An<\/p>\n

    Do not disregard the non-functional requirements, such as: safety, productivity, responsiveness, availability (WCAG). It is crucial as it all makes the whole system work, and it translates into users perception. Therefore, we need to take into account the non-functional requirements from the very beginning when creating the system.<\/p>\n

    Do not assume that you will obtain something that you consider relevant without mentioning it in the document. Be precise when setting out your expectations. Explain the terminology, specification of your sector and your company.<\/p>\n

    Which mistakes to avoid?<\/strong><\/h2>\n

    Try to avoid the general descriptions, which may be in interpreted in a wrong way or taken out of context. It often happens that the client is not able to visualise the system and not sure what exactly the system should cover. For example, they need the system to generate the reports but they are not sure how it should work.<\/p>\n

    If you happen to be in a similar position, do not hesitate to express that you are not sure about certain aspects. Provide a general information and request the support from the Analyst. You will discuss the details then, and the team may suggest a solution and present how it should all work.<\/p>\n

    If you happen to have already the system and need to process it again from the start do not consider looking at or comparing it to the existing one. Do not create the descriptions of the same functionalities. Concentrate on defining how each function works, not on the design of the system.<\/p>\n

    Prioritization of requirements<\/strong><\/h2>\n

    The prioritization of requirements is helpful when you need the fastest activation of the system in MVP. Think which elements should be included in initial version of the system. Some functionalities \u2013 the less important ones \u2013 may be added at a later stage. It may also help to obtain financial resources necessary to further software development.<\/p>\n


    \n\"...\"
    \n<\/span><\/p>\n
    \n

    Read also: MVP \u2013 How To Start?<\/a><\/h4>\n<\/div>\n<\/div>\n

    The specification of requirements should include:<\/strong><\/h2>\n

    \"Man<\/p>\n