Site Overview 
Focusing on Delivering Stakeholder Value
Blogs
File Galleries
Forums
[ Execution time: 0.46 secs ] [ Memory usage: 15.83MB ] [ 58 database queries used in 0.0 secs ] [ Server load: 1.5 ]
Tracker Item: Glossary Concepts
View Item
| Name | Requirement Concept | ||
| Concept Number | 026 | ||
| Definition |
anything Stakeholders require. |
||
| Examples | |||
| Notes |
To capture the whole concepts of Requirements, I find it necessary to start with this broad definition. It is based on the idea that if a Stakeholder has a Requirement, it is a Requirement, if no Stakeholder has a Requirement, there is no Requirement. The concept is based on someone (a Stakeholder) requiring, it is the requiring that makes it a Requirement, not what they are requiring. Then we can further categorize the Requirement into types, e.g. Function, scalar, solutions, development resources. And levels, Stakeholder, Product, Sub-product. And we can make a separation between a Stakeholder having a Requirement, and we taking that Requirement into our responsibility. Do we need to comply with all expressed requirements?For an expressed Requirement to be a Requirement that our project is interested in fulfilling, I consider:1. Who/what it came from. The people/products with an interest in our project I call Stakeholders. Does the Requirement come from a Stakeholder that we must or want to listen to? 2. Will it be profitable to fulfill the Requirement? Are the Stakeholder requiring the Requirement willing to pay for it? 3. Is it a market we and our company want to be in? Fulfilling a Requirement puts you in the market of people wanting that Requirement. |
||
| Illustration |
|
||
| Related Concepts |
End-State Requirements: Functions, Stakeholder Values, Product Qualities & Development Resources. Means Requirements, or Solution Constraints. |
||
| Synonyms | |||
| Language Name Variants | |||
| Submitted | Kai Thomas Gilb | ||
| Editor | |||
