How to prepare a system requirements table with MoSCoW method



The MoSCoW method is a technique that helps categorize and prioritize all requirements that define a “future state”, that should be implemented.  

The method was developed by Dai Clegg in 1994, and dedicated to supporting software development projects (where the “future state” is the shape of an application that should be implemented). Despite the origin, the method is not only limited to software projects, and can include requirements necessary when implementing changes to physical products (cars, buildings, furniture) or organizational changes (eg. changes to the bonus systems, changes to the partnership agreement, etc.). 

Although this is a generic method, it is mainly used when implementing software systems and helps companies define the requested configuration of a future application that is planned to be implemented.  




The MoSCoW term is an acronym inherited from the statuses used in this method to prioritize requirements: Must have, Should have, Could have and Won’t have.  




The priorities used in the MoSCoW method sound self-descriptive, but in practice, they need some additional explanation to use them properly and in a consistent way: 

  • Must Have (MUST) – This is the most obvious priority that represents the critical requirements that must be delivered from day one. The software without these requirements simply can’t be used properly and the project goals will not be achieved without them. 
  • Should Have (SHOULD) – This priority represents the requirements that are almost as important as “Must haves”, but users can live without them. Although it sounds similar to “Could have”, they are closer to “Must haves”. The difference is, that while “Must haves” have to be implemented from day one (software can’t exist without it), software users can live without “Should haves” for some time. The “Should haves” have to be ultimately implemented, but the company can live without it and still benefit from the 1st version of the software solution; these missing requirements will not cause critical security problems or will not bring a lot of additional work – if that happens, it means that they should be classified as “Must haves”. The “Should have” priority is often used to divide a complex project scope into phases, where only “Must haves” are implemented in the current phase, and “Should haves” are planned for the next phases. Sometimes, companies use “Should have” to address the “readiness” for future requirements or improvements (e.g. currently the software is not implemented in the cloud, but it must use the technology that is ready for future cloud deployment). 
  • Could Have (COULD) – This is used to address all the “nice to have” features, that will have a positive impact on the final solution (and then on users’ satisfaction/efficiency), but are not necessary and might never be implemented. Their business value is smaller than “Should haves”. These requirements are useful when comparing software from various software vendors – assuming, that all “Must have” and “Should have” requirements must be identically fulfilled by all short-listed applications, “Could haves” help differentiate these applications and choose the one that offers the most additional features, that will make the use of application more beneficiary for the company.  
  • Won’t have (WON’T) – At first glance, this priority looks unnecessary: Why do we collect and put into evidence the requirements that we don’t want to implement?… In fact, normally when we build a “Requirements table” we don’t include them and this is the correct approach. But there are at least 2 situations, where “Won’t” might be useful. First – imagine that you build the “Requirements table” based on the generic template or you copy it from another project. Your first task will be to review the template and eliminate those requirements that are not applicable in your limited case. And here the “Won’t” status might help, so other people would know, that you deliberately removed the requirement from the current scope. The other case is very pragmatic. In the real world, there is no one person who prepares system requirements, but many stakeholders are involved in this process. All of them might have their own requirements, sometimes these requirements represent very particular interests or they are not well evaluated in terms of the “value to money” factor. These requirements will be eliminated from the solution scope, but instead of deleting them from the requirements table, you should use “Won’t” priority to communicate the classification to the requirement requestor. 

Note: You can find simplified MoSCoW method implementations, where priority names are only limited to the first words: Must, Should, Could, and Won’t.  




The understanding of requirement priorities is obviously not enough to prepare a good “Requirements table” for a planned software solution. When we think about that, we usually think about functional requirements (like “Ability to import bank account balance from the financial system”). But the complete list of requirements can’t be limited to that. Below we shortly present the categories of requirements that define the future configuration of the software: 

  • Functional requirements – business functions/operations supported by the system (e.g. “User can divide customer order line into sub-lines”). When you gather it, don’t forget about the reports offered by the system, automated routines that should run in the background without user interactions or documents that should be printed or imported. 
  • Common capabilities – generic features that should be offered by the system and could support many operations for many users (e.g. “All lists and tables presented in the user interface should be sortable by any column”) 
  • Non-functional requirements – these are also important for business people, but these are not functional requirements that can be easily converted to what is visible on the user interface. Here you can collect requirements like: the ability to configure the solution, flexibility in future development, expected performance (speed) etc.  
  • Integration requirements – this group defines all the necessary integrations supported by the software. This is not only a technical category interesting for the IT department (data exchange protocols that should be implemented), but also very important for people representing business departments – it is important to express what data should be synchronized with other systems (“from” and “to”) and define the exchange frequency. This exercise should be done for internal systems and potentially for external systems (owned by customers, suppliers, or cloud service providers) 
  • Technical requirements – this category defines elements like implementation technology or IT architecture compatibility (e.g. when the company is addicted to Microsoft or Oracle technologies), but it can also define 
  • IT administration requirements – this category belongs to the IT department and covers requirements like installation & configuration, upgrades management, user management, system data supervision, backups  a
Warehouse management system requirements table

Example requirements – Common Capabilities 

If you think that this is quite complex, you should know that this is not all of it. The categories described above only focus on the features of future software. But when you prepare an implementation project, you should also focus on organizational expectations in the following categories: 

  • Project plan – software implementation project is a complex task and requires good organization and schedule. You should define how you want the project to be managed and monitored, what services (phases) you expect in the project (like workshops, user acceptance tests, post-go-live support etc) or your deadlines and budget limitations. 
  • Commercial terms – when you use the Requirements table to compare and choose software product from external vendors, you should specify commercial requirements such as: licensing model (subscription / perpetual), expected software support level (with SLA parameters), expected payment terms & conditions, price levels etc.  
  • Vendor evaluation – when you choose software from an external vendor, you should not only evaluate the factual “piece of software”, but also the vendor: creditability, experience and potential to offer support in the future 
Warehouse management system requirements table

Example requirements – Project Plan/methodology 



A Requirements table might be used when developing software internally or as bespoke software delivered by a separate software house. Companies also often use it to evaluate ready-made systems from various software vendors. But how to objectively compare various software when you have 100 requirements divided into 10 categories, and each of the requirements has a different priority (Must, Should etc.)?… 

The easiest way to handle it is to calculate a global score that particular software gains by evaluating requirements fulfillment. We propose to do that in the following steps: 

  1. Assign weights to all priorities – e.g. Must – weight 10, Should – weight 8, Could – weight 3, Won’t – weight 0 (of course!) 
  2. Evaluate each requirement fulfillment – we suggest using [0-5] fulfillment scale, where 0 means “completely not fulfilled” and 5 – the requirement is completely met by the solution. 
  3. Multiply weights by evaluated value 
  4. Summarize all the multiplication results for all the requirements. 

After you summarize all the points, you need to eliminate the software that can’t meet some of the critical “Must have” requirements (the software might have collected a lot of points in less critical areas, but since it doesn’t meet the critical requirement(s), it can’t be considered as a final solution. There is one more remark here – while “0” value obviously means “Requirement not supported”, how about other values? What if the software only offers very basic fulfillment of the requirement (evaluated with the grade “1”)?… For the “Must haves”, we suggest to treat as “fulfilled” only those requirements, that gathered at least 3 evaluation points. If there is a lower grade – we treat it as “A Must have requirement has not been met”. 

Warehouse management system requirements table

Example requirements evaluation 

The requirements evaluation is a bit slick area – if you want to be objective and fully transparent here, you might define additional criteria on when to use 1, 2, … 5 values. One way is to check if the solution offers a particular feature “out of the box”, or if it requires customizations. From our perspective, it doesn’t matter – after a couple of months the final state will be the same no matter if it was customized or a standard solution, so it is better to focus on user experience, efficiency, or other aspects. 


We hope that our article will help you better organize your system requirements and prepare complete Requirements Table. We also know, that this is not an easy task, you need to think about various aspects (from business requirements to technology). It is especially hard when you do that the first time without a good example. But actually, why do that without an example?… 

Below we prepared a generic template that you might consider using when defining requirements for any business systems. We included ~90 requirements divided into the following groups: 

  • GROUP 1: Functional requirements / Business features 
  • GROUP 2: Capabilities – User experience / efficiency 
  • GROUP 3: Capabilities – task management & supervision 
  • GROUP 4: Integration – Business Requirements 
  • GROUP 5: Integration – Technical requirements 
  • GROUP 6: Flexibility / Customization 
  • GROUP 7: Technology / Installations / Security 
  • GROUP 8: System & User Administration 
  • GROUP 9: Commercial terms 
  • GROUP 10: Project plan / methodology 
  • GROUP 11: Vendor evaluation  


This Excel Spreadsheet contains of 82 functional + 84 non-functional requirements directly connected with the warehouse processes in large and medium business. From Inventory Configuration and Basic operations to Commercial terms & Licensing model.