Techniques
Project teams can use different techniques to capture and manage requirements. Microsoft Azure DevOps work items and GitHub issues are commonly used to facilitate the collaboration on the requirements by the project team. Additionally, tools are available that specialize in backlog and roadmap management that teams can use. Requirements will be captured in these tools, or a requirements document, in a narrative or user story format.
User stories focus on who the user is, what they want, and why they want the system to do something.
For example, "As a sales user, I want to be able to send a discount to my customer using email."
Requirements are often categorized into a backlog while they wait to be prioritized into an active project sprint/iteration to be implemented. Consider the backlog as a list of ideas that are waiting to be implemented. Think of a sprint or iteration as a defined period of time or work that has been grouped together for the project team to implement into the solution.
While planning for a sprint or iteration, you might be asked to help prioritize and estimate the amount of work for a work item/issue in the backlog. Different teams use different approaches to estimating the level of effort. Some use hours, while others use a reference such as t-shirt size. Essentially, to estimate an item, you might categorize it as small, medium, or large. Then, teams will use the size to help group items for implementation in a sprint or iteration.
Requirements should be feasible to implement and not too large to complete in a single sprint or iteration. You can divide large requirements into smaller requirements that could be easier to accomplish. Some methodologies refer to the large requirement as an epic, which is the high-level requirement before it's broken into smaller parts.
Requirements are often considered functional or non-functional. Functional requirements describe what the solution needs to do or its behaviors. Non-functional requirements commonly describe non-behavior aspects of the solution, such as performance requirements. To completely describe what's expected of a new solution, you should have functional and non-functional requirements.
Functional requirements
Functional requirements should focus on the who, what, and why of the requirement. For example, "As a customer service rep, I need to be able to look up similar customer problems that were resolved to find a solution to the current customer problem" describes a Microsoft Dynamics 365 Customer Service functional requirement.
Most of your functional requirements will come from users of the finalized solution.
You can use non-functional requirements to capture topics that users generally care about but are important to the success of the solution. These types of requirements commonly cover topics such as the performance of the solution, capacity, privacy, security, and compliance.
For example, "The system must handle 2500 concurrent customer inbound problem reports during outages" describes a Dynamics 365 Customer Service non-functional requirement.
Non-functional requirements
Most of your non-functional requirements will come from IT or corporate compliance staff and not your end users.
Non-functional requirements must be clear on how to measure and determine success. Often, the requirements won't include clear start and end points in measurements to accurately gauge the success. It's also common to include non-functional requirements beyond your control, and it's important to identify these requirements and mitigate risk with the customer. An example of this scenario might be a sub-one-second performance requirement on mobile devices in the field.
Non-functional requirements are commonly the solution architect's responsibility to determine how to meet. However, a consultant should be aware of the solution's non-functional requirements. In many cases, you might be asked to implement a change that supports the objective of the non-functional requirement.
Taking the time to ensure that your requirements are high quality and represent what you've agreed to deliver is important. In many cases, this assurance can make a difference in how successful the Dynamics 365 deployment is after you've implemented the requirements.