All tips Tip A-1-01: Never start a product development or project without goals. #clean-start Tip A-1-02: Deadlines and budget limits are not goals, but constraints. #constraints Tip A-1-03: You should never have more than a handful of goals for a product. #clean-start Tip A-1-04: Clarify conflicting goals before getting lost in the details of requirements. #goals Tip A-1-05: Visions and business goals need a time horizon. #goals Tip A-1-06: Only in very large projects should you distinguish visions and business goals. #goals #thorough Tip A-1-07: Work with nested goal trees for very large projects. #goals #thorough #large-projects Tip A-1-08: You do not need to put sprint goals in writing. #goals #lean #agile Tip A-1-09: Save the effort of separating visions from goals. #goals #lean Tip A-1-10: Make goals measurable. #acceptance-criteria Tip A-1-11: Save on the PAM formulation of goals. #acceptance-criteria #lean #business-value Tip A-2-01: Conduct a breadth search for stakeholders. #stakeholder Tip A-2-02: Role before person. #stakeholder Tip A-2-03: Iterate: Critically review stakeholder table again and again. #stakeholder Tip A-2-04: Classify your stakeholders by interest and influence. #stakeholder Tip A-3-01: Explicitly define the boundary between your product and its environment! #context #external-interface Tip A-5-01: Use use case models. #use-cases Tip A-5-02: Use activity diagrams to refine epics or use cases. #activity-diagrams Tip A-5-03: Use coarse data models to arrive at a unified domain language. #data-models #lean Tip A-5-04: Use more precise data models. #data-models #thorough Tip A-6-01: Always work with explicit quality requirements. #scenarios Tip A-6-02: Quality requirements are the architecture drivers. #scenarios Tip A-6-03: Use checklists to get ideas for topics for which you should collect explicit quality requirements. #checklist Tip A-6-04: Use Q42's 150+ quality attributes as a starting point to find sample formulations that you can copy or adapt. #checklist #lean #examples Tip A-6-05: Never argue about whether a requirement is a functional requirement or a quality requirement. #requirements-categorization Tip A-6-06: Focus on the 'killer qualities' early in the project. #killer-qualities #lean Tip A-6-07: Take advantage of the property that quality requirements are highly reusable within a domain. #reusability #lean Tip A-7-01: Look for constraints in other projects within your organization. #reusability #lean Tip A-7-02: Never argue about whether a requirement is a quality requirement or a constraint. #categorization Tip A-12-01: Search for risks with different stakeholders #stakeholder Tip A-12-02: Analyze external interfaces for risks #Interfaces Tip A-12-03: Enrich your risk list with probabilites and #risks Tip B-01: Designate a responsible person. #docu-gardener Tip B-02: Document sparingly ('less is of more'). #documentation #lean Tip B-03: Clarify appropriateness and need through early feedback. #documentation #lean Tip B-04: Always explain and communicate top-down, work differently as needed. #top-down Tip B-05: Focus on benefits rather than functionality. #style Tip B-06: Always put usefulness before principles. #style Tip B-07: Separate volatile and permanent documentation. #docu-gardener Tip B-08: Avoid redundancy in your requirements documentation, if possible. #redundancy Tip B-09: Establish a positive attitude towards documentation. #documentation Tip B-10: Document from your readership's point of view. #documentation Tip C-01: Work with any agile method. #Scrum, #Lean, #Kanban, #SAFe, #LeSS Tip C-02: Make req42 a part of your Definition of Done. #DoD Tip C-03: Deliberately decide what to capture in writing and what to communicate orally. #communicating-requirements Tip F-1-01: Where does the 42 in the name come from? #general-question Tip F-1-02: What's the License for req42? #general-question Tip F-1-03: What's the pricing model of req42? #general-question #license #pricing Tip F-1-04: How widely is req42 used? #general-question Tip F-1-08: Can I contribute to req42, make suggestions or report bugs? #general-question Tip F-2-01: Which parts of req42 are 'can', which are 'must'? Should I fill in all parts? #method-question Tip F-2-02: Does req42 prescribe or enforce specific notations? #method-question #notations
Tip A-1-06: Only in very large projects should you distinguish visions and business goals. #goals #thorough
Tip A-3-01: Explicitly define the boundary between your product and its environment! #context #external-interface
Tip A-6-03: Use checklists to get ideas for topics for which you should collect explicit quality requirements. #checklist
Tip A-6-04: Use Q42's 150+ quality attributes as a starting point to find sample formulations that you can copy or adapt. #checklist #lean #examples
Tip A-6-05: Never argue about whether a requirement is a functional requirement or a quality requirement. #requirements-categorization
Tip A-6-07: Take advantage of the property that quality requirements are highly reusable within a domain. #reusability #lean
Tip A-7-02: Never argue about whether a requirement is a quality requirement or a constraint. #categorization
Tip C-03: Deliberately decide what to capture in writing and what to communicate orally. #communicating-requirements
Tip F-2-01: Which parts of req42 are 'can', which are 'must'? Should I fill in all parts? #method-question
