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. The business process catalog is available as a template that you can import into Azure DevOps Services. It helps you define scope, establish ownership of processes, create and track requirements, and manage the project using agile or other methodologies. Additionally, tools that specialize in backlog and roadmap management are available for teams to use. Capture requirements in these tools or in a requirements document, using 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. A sprint or iteration is a defined period during which a project team implements part of a 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 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 a large requirement as an epic, which represents a high-level requirement before a project team breaks it into smaller parts.

Requirements are often considered functional or nonfunctional. Functional requirements describe what the solution needs to do or its behaviors. Nonfunctional requirements commonly describe nonbehavior aspects of the solution, such as performance requirements. To completely describe a new solution, define both functional and nonfunctional 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 come from users of the finalized solution.

You can use nonfunctional 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 nonfunctional requirement.

nonfunctional requirements

Most of your nonfunctional requirements come from IT or corporate compliance staff and not your end users.

nonfunctional requirements must be clear on how to measure and determine success. Often, the requirements don't include clear start and end points in measurements to accurately gauge the success. It's also common to include nonfunctional 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 below one-second performance requirement on mobile devices in the field.

nonfunctional requirements are commonly the solution architect's responsibility to determine how to meet. However, a consultant should be aware of the solution's nonfunctional requirements. In many cases, you might be asked to implement a change that supports the objective of the nonfunctional requirement.

Ensure that your requirements are high quality and accurately reflect the solution you plan to deliver. This assurance can help improve the success of a Dynamics 365 deployment.