软件需求是一个软件项目成功的关键因素，许多软件项目失败都是因为软件需求的“不完整、不准确、不一致”。而软件需求是从业务需求经用户需求最终得到系统需求的，所以业务需求是软件需求的源头，而业务需求又是从客户业务中来的，客户有问题且需要解决的业务才是业务需求。所以准确、完整的根据用户的描述获取用户的业务需求至关重要。从软件开发的角度入手，使用用户故事，从用户角度描述功能，让我们可以从用户角度出发思考问题，避免程序员的自以为是，使得业务需求更加的准确、完整。
用户故事描述了对用户、系统、或软件购买者有价值的功能；包括三个方面的内容：一份书面故事描述（用来做计划和作为提示）；有关故事的对话（用于具体化故事细节）；测试（用于表达和编档故事细节且可用于确定故事何时完成）。而使用用户故事时，多个小故事要胜于一个庞大的故事；故事卡上需要带有适当的注释，来规定对于每个功能的用户期望是什么，对下面的测试有着很大的作用。对于故事驱动的项目需要客户和用户在项目过程中全程参与。
编写用户故事时最好根据用户类别来编写，每个用户故事都由商业语言来编写而不是技术术语；由客户团队（包括确保软件满足用户需求的所有人，可以安排开发人员的工作优先级）而不是开发人员来编写。客户团队与开发人员一起选择迭代长度，在每个迭代结束时，开发人员需要交付完全可用的应用程序子集，客户团队则要确保项目能够达成交付所需产品的目标。
验收测试时即用来验证实现的用户故事是否符合客户团队的期望。测试应该尽早的在迭代中进行编写，方便客户团队与开发人员进行进度的沟通。
编写的故事卡主要起提醒作用，提醒客户团队和开发人员在以后要进行关于需求的对话，并不是需求本身，具体的细节需要客户团队与开发人员讨论。编写的每个故事必须对用户有价值。有区分软件使用者和软件购买者。针对不同的用户故事卡上的需求侧重点也不同。对于编写的故事卡所需的编码量需要能够估计出来，这样对于规划每个迭代阶段进行的内容有很大的帮助。每个故事都可测试的，测试开发人员是否正确的完成了故事。
总起来说，为了更好的进行软件需求可以采用用户故事的方式。一张好的故事卡需要大小适中，由客户团队用商业语言进编写，可以进行测试。写好用户故事，并根据功能的优先级将各个故事安排在相应的迭代阶段，然后进行实现，对于整个软件项目的进行以及完成的软件与用户的需求的一致也具有很大的促进作用。