Work with requirements for Microsoft Power Platform and Dynamics 365
☰Fullscreen
Table of Content:
- Question 1: What is the primary role of a Solution Architect during requirement capture sessions?
- Question 2: How are non-functional requirements different from functional requirements?
- Question 3: Why are non-functional requirements important?
- Question 4: Give common types of non-functional requirements.
- Question 5: Give an example of a good non-functional requirement.
- Question 6: Give an example of a bad non-functional requirement.
- Question 7: Why should non-functional requirements be measurable?
- Question 8: What kind of external factors can affect non-functional requirements?
- Question 9: Why is early identification of non-functional risks important?
- Question 10: What does feasibility mean for non-functional requirements?
- Question 11: Why is “99.999% availability” often unrealistic?
- Question 12: When should requirements be reviewed and finalized?
- Question 13: Why should requirements be reviewed after workshops?
- Question 14: What key questions should a Solution Architect ask while reviewing requirements?
- Question 15: What should be done if a requirement does not map to business objectives?
- Question 16: Why is stakeholder agreement important before finalizing requirements?
- Question 17: What are non-functional requirements?
- Question 18: What is scope creep and how can it be controlled?
- Question 19: Why should exceptions be captured during requirement gathering?
- Question 20: Why should a Solution Architect remain methodology-agnostic during requirement gathering?
- Question 21: What preparation should a Solution Architect do before leading requirement workshops?
- Question 22: What is the difference between functional and non-functional requirements?
- Question 23: Give an example of a well-written functional requirement.
- Question 24: Why are poorly worded requirements dangerous in a project?
- Question 25: What key elements must every good requirement contain?
- Question 26: What should a Solution Architect do if a requirement is too large?
- Question 27: What is an MVP and why is it important in Dynamics 365 projects?
- Question 28: How should requirements be prioritized?
- Question 29: How does a Solution Architect assess requirement feasibility?
- Question 30: Why is asking “Why?” critical during requirement discussions?
- Question 31: What techniques help extract true requirements from business users?
- Question 32: How should a Solution Architect handle conflicting requirements from different teams?
- Question 33: Why can having senior management in requirement sessions be risky?
- Question 34: What are acceptance criteria and why are they important?
- Question 35: What is the role of a roadmap in requirement finalization?