Identify functional requirements

4 minutes

Requirements are commonly referred to as either functional or non-functional. Functional requirements describe what the solution needs to do or its behaviors, and non-functional requirements commonly describe non-behavior aspects of the solution such as performance requirements. This topic covers considerations for functional requirements.

Each functional requirement should clearly capture the who, what, and why of the requirement. If the requirement is too large, it should be divided into smaller parts.

Example functional requirements

The following scenarios describe simple examples of functional requirements:

As a sales user, I need to be able to close an opportunity as lost and then capture why it was lost so that we can improve our sales tactics in the future.
As a sales manager, I need to be able to approve a discount on a quote so that I can reduce the total price and give a discount to the customer.
As a staff accountant, I want to be prevented from closing a batch that has pending items so that I do not have to reopen it later.

These situations communicate the who, what, and why of a requirement.

The following examples are poorly worded requirements:

Opportunities can be won or lost.
Price should reflect discounts.
From the Batch Item list, selecting the Close Batch button, which is the third button from the left, should close the batch if no items exist that would stop it from happening.

When you are gathering requirements of any variety, it is helpful to map toward process rather than simply listing features and functions. Build a story for a user and describe how they will successfully use the system that you are designing. You can write or draw on a whiteboard, use a tool to diagram a process, or use whatever methods will work for your team at the planning stage that you are in. Your team will dissect the pieces into smaller actionable items later.

Acceptance criteria

It's important to have a clear understanding of how a requirement is considered satisfied. Often, documenting satisfaction will help determine if the requirement is detailed enough and is the right size. This approach is also helpful for testing teams when they're evaluating the implementation of the requirement. Finally, the requirement's satisfaction should be reviewed with the stakeholder to ensure that it is accurate because it can be used to help prevent scope creep. The solution architect needs to look for acceptance criteria that can't possibly be met and then negotiate to reach a compromise that is achievable.

Capture exceptions

Typically, a simple requirement, like closing a transaction, might have a straightforward path and only a few exception paths. Make sure that you look for and identify these exceptions when capturing the successful path. As you move into design, you don't want to design primarily for exceptions. They should be handled as such, but if you do not know that they exist, you will have to rework the design later. Additionally, remember to capture how frequent the exception occurs because some exceptions are best handled by procedure and/or process and not software customization.

Avoid scope creep

Left unchecked, every project would add scope from what was envisioned and budgeted for. The solution architect must be vigilant in looking for requirements that are out of scope from the original assumptions. The project governance process should be used to evaluate how to handle these after they've been identified. Often, those out-of-scope requirements that are accepted for inclusion might result in a change order, depending on the project's contractual structure. Ignoring the fact that the scope is increasing can easily result in project failure.

Exercise: Find the functional requirements

Review Woodgrove Bank's teams and identify likely overlap between the teams in the functionality that they will need to do their work.