The Microsoft Dynamics 365 learning paths are a great resource for expanding product knowledge and enhancing skills. While following the learning path for the solution architect Exam MB-700, I appreciated its emphasis on Who, What, and Why in requirements gathering:

Who, What, & Why

An easy trap during requirements gathering is to jump straight from a need to its system solution. Focusing on Who, What, and Why helps capture the complete functional requirement so that the solution will also be complete. This type of requirement gathering can be written in a formula: As a [fill-in-the-blank], I need to [fill-in-the-blank], so that [fill-in-the-blank].

Some examples of this functional requirement formula from the learning path:

Non-Functional Requirements

Who, What, and Why frame the functional requirements, non-functional requirements should also be considered. Non-functional requirements are elements outside of the direct need that will influence the performance or acceptability of the solution. Some types of non-functional requirement considerations are Availability, Compliance, Data retention/residency, Privacy, Security.

Some examples of non-functional requirements from the learning path:

An Application?

I like this framing of Who, What, and Why in a functional requirement, along with its non-functional elements. Again, capturing complete requirements is an important first step to building complete solutions. Thinking about this made me wonder – can I build an application to help gather requirements in this format?

Stay tuned for Part 2!