MoSCoW Method

When managing a project, it is important to develop a clear understanding of the customers‘ requirements and their priority. Many projects start with the barest headline list of requirements, only to find later the customers‘ needs have not been fully understood.

Once there is a clear set of requirements, it is important to ensure they are ranked. This helps everyone (customer, project manager, designer, developers) understand the most important requirements, in what order to develop them, and those that won‘t be delivered if there is pressure on resources.

So what is the best method for creating a prioritised list of requirements?

The MoSCoW method can help. MoSCoW stands for must, should, could and would:

  • M - Must have this requirement to meet the business needs.
  • S - Should have this requirement if possible, but project success does not rely on it.
  • C - Could have this requirement if it does not affect anything else in the project.
  • W - Would like to have this requirement later, but it won‘t be delivered this time.

The O‘s in MoSCoW are added to make the acronym pronounceable, and are often left in lowercase to show they don‘t stand for anything.

MoSCoW as a prioritisation method is used to decide which requirements must be completed first and which must come later or will not be completed at all.

Unlike a numbering system for setting priorities, the words mean something and make it easier to discuss what‘s important. The must requirements need to provide a coherent solution, and alone lead to project success.

The must requirements are non-negotiable and have to be delivered. Failure to deliver even one of the must requirements will likely mean the project has failed.

The project team should aim to deliver as many of the should requirements as possible. Could and would requirements are ‘nice to have‘ and do not affect the overall success of the project. Could requirements are the first to go if the project timeline or budget comes under pressure.

To deliver a successful project, it is essential that a clear set of prioritised requirements are agreed with the customer, alongside the overall objective, quality, timescale and budget. The recommended method for setting priorities is MoSCoW.

时间: 2024-10-28 22:13:52

MoSCoW Method的相关文章

different between method and function

p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Arial; color: #242729 } p.p2 { margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Arial; color: #242729; background-color: #ffffff } span.s1 { background-color: #ffffff } span.s2 { } A method is on an o

关于form表单中method里get和post的区别

在html里form可谓不得不用的一条代码,而form里的method选项里只有get和post两种. 因为我们大多数情况下只有post,所以get和post的区别很容易被遗忘. 简单区别来讲: get提交:提交的数据会在ul上进行提交,明文不加密,不安全,提交的数据有限. Post提交:以form表单封装的方式提交,适合提交大量的数据,相对安全. 虽然我们很少用get,但是我们一定常见到这种方式,只是我们很少注意到罢了. 比如,百度的搜索内容就是用的get方式,我们可以在url上看到我们都提交

fetch 报错 Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body.

TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body. 在"窗口"上执行"取"失败:GET / get方法的请求不能有正文. GET requests can't have a request body, you can't make them have one. GET requests only retrieve data,

【反射】Class Field Method Constructor

Class public final class java.lang.Class<T> extends Object implements Serializable, GenericDeclaration, Type, AnnotatedElement 类型参数 T:由此 Class 对象建模的类的类型.例如, String.class 的类型是 Class<String>.如果将被建模的类未知,则使用 Class<?>. Instances of the class

设计模式的征途—17.模板方法(Template Method)模式

在现实生活中,很多事情都需要经过几个步骤才能完成,例如请客吃饭,无论吃什么,一般都包含:点单.吃东西.买单等几个步骤,通常情况下这几个步骤的次序是:点单=>吃东西=>买单.在这3个步骤中,点单和买单大同小异,最大的区别在于第2步-吃什么?吃面条和吃满汉全席可大不相同. 在软件开发中,有时候也会遇到类似的情况,某个方法的实现需要多个步骤(类似于“请客”),其中有些步骤是固定的,而有些步骤则存在可变性.为了提高代码复用性和系统灵活性,可以使用一种称之为模板方法模式的设计模式来对这类情况进行设计.

[Angular] HostListener Method Arguments - Blocking Default Keyboard Behavior

We are going to see how to using method arguments for @HostListener. First, we can use HostListener without method arguments: @HostListener('dblclick') toggle(){ this.collapsed = !this.collapsed; } It works fine. But if we need to get the $event obje

Method Tracking

一.能做什么? 直观的看到某个时间段内哪个方法花了多少时间. 二.工作台介绍 非独占时间: 某函数占用的CPU时间,包含内部调用其它函数的CPU时间. 独占时间: 某函数占用CPU时间,但不含内部调用其它函数所占用的CPU时间. 三.如何操作 点击Start Method Tracking, 一段时间后再点击一次, trace文件被自动打开, 我们如何判断可能有问题的方法? 通过方法的调用次数和独占时间来查看,通常判断方法是: 如果方法调用次数不多,但每次调用却需要花费很长的时间的函数,可能会有

MyBatis3.4.0以上的分页插件错误:Could not find method on interface org.apache.ibatis.executor.statement.StatementHandler named prepare. Cause: java.lang.NoSuchMethodException: org.apache.ibatis.executor.stateme

错误: Could not find method on interface org.apache.ibatis.executor.statement.StatementHandler named prepare. Cause: java.lang.NoSuchMethodException: org.apache.ibatis.executor.statement.StatementHandler.prepare(java.sql.Connection)] with root cause 问题

c++ 设计模式8 (Factory Method 工厂方法)

5. "对象创建"类模式 通过"对象创建"类模式绕开new,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定.它是接口抽象之后的第一步工作. 5.1 工厂方法 动机: 在软件系统中,经常面临着创建对象的工作:由于需求的变化,需要创建的对象的具体类型经常变化. 如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种"封装机制"来避免客户程序和这种"具体对象创建工作"的紧耦合? 代码示例