Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Design requirements are the blueprints used to build an application. This article shares 10 tips for creating requirements that meet the needs of users, managers, and developers alike.

Here’s what you will get from this guide covering 20 popular product prioritization techniques:
* A map, in the form of a Periodic Table to help you make sense of what each technique has to offer;
* An overview of each method, with graphics and links to more in-depth resources;
* 5 commonalities and takeaways from all these methods.

Writing good User Stories is difficult for new teams starting with a new agile project. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a look at the five most common mistakes people make writing User Stories.

Scrum teams need to prepare backlog items for future sprints. This is called backlog refinement. Items for the next one or two sprints need to be "ready." But getting backlog items ready is not a goal in itself. Only just enough is needed to be able to get backlog items to "Done" smoothly during a sprint. A balance must be realized in terms of how much, how far ahead, and how collaboratively backlog refinement is done. You must continually inspect and adapt this balance.

This article describes a Lean and Scalable Requirements Information Model that extends the basic team‐based agile requirements practices to the needs of the largest, lean‐thinking software enterprise. While fully scalable to all levels of the project, program and portfolio levels, the foundation of the model is a quintessentially lean and agile subset in support of the agile project teams that write and test all the code.

So they are basically part-time product owners. The customer cannot afford to hire full-time trained product owners in maintenance projects. In such cases, the product manager or customer is generally the final authority for approval on any functional or nonfunction requirement, as well as having the final word on technical decision making.

Sizing software requirements is an essential best practice in software project management for forecasting the work effort required for software development projects (and other related metrics). Arguably, the currently most accurate software metric for measuring the size of software is the International Function Point Users Group (IFPUG) “function point,” which has the ISO standard ISO/ IEC 20926:2009. Function points basically measure the size of the data flow and storage through the software, which we define in this paper as “functional” requirements. But function points do not measure other software requirements, which also require work effort resources. IFPUG has recently completed a successful beta test of a new method to assess the size of other, “nonfunctional” requirements, which when used in conjunction with function points should further increase the accuracy of software forecasting.

The product backlog might be the more important item for a Scrum team as it represents the business value that the project should deliver to its customers. Putting a priority on the features and user stories is however not always easy for the product owners, especially if they are dealing with multiple stakeholders. In this article, Samantha Laing shares a technique that can help to improve the results of this activity.

While aspect-orientation originally has emerged at the programming level, it now stretches also over other development phases. There are, for example, already several proposals to Aspect-Oriented Modeling (AOM), most of them pursuing distinguished goals, providing different concepts as well as notations, and showing various levels of maturity.