What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.
Monthly Archives: October 2006
Posted in Business Process Modeling, Product Management, Requirements, Requirements gathering
Tagged business requirements, Business Rules, eliciting requirements, gathering business requirements, gathering business rules, gathering requirements, managing data, Requirements, requirements elicitation, Requirements gathering, rules, rules and requirements
4 Comments
How Many People for Requirements Elicitation?
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F10%2F17%2Fhow-many-people%2F”, “style”: “big”, “title”: “How Many People for Requirements Elicitation?” }); How many people should be involved in requirements elicitation? A question from one of our readers via email. Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a [...]
Nice To Have
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F10%2F16%2Fnice-to-have%2F”, “style”: “big”, “title”: “Nice To Have ” }); Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements – things that solve problems and achieve value in a significant way. Needs and Wants Our customers [...]
Posted in Communication, Design, Prioritization, Product Management, ROI, Requirements, Software development, Usability, Writing
Tagged documentation, documenting upgrades, goal-driven documentation, managing data, passion threshold, prioritizing upgrades, software documentation, software upgrade, suck threshold, upgrade prioritization, upgrade priority, upgrades, user centric documentation
Leave a comment
Posted in Communication, Design, Interaction design, Requirements Models, UX, Use Cases, Writing
Tagged doc, documentation, help file design, Interaction design, interaction design and documentation, managing data, software doc, software documentation, structured requirements, structured requirements and documentation, use case analysis, Use Cases, use cases, writing doc, writing documentation
3 Comments
Goal-Driven Documentation
Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.
Posted in Product Management, Software development, Writing
Tagged competent users, goal-driven doc, goal-driven documentation, managing data, raising the suck threshold, software doc, software documentation, suck threshold, writing doc, writing software doc, writing software documentation
3 Comments
Latest Articles
Comments on all Articles
