Identify functional requirements
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.
Business Growth and Asset Management - Commercial Accounts with less than USD 1 billion in annual transactions. Growth in this sense refers to the loans that are used to reinvest in the corporation. These customers share a group of account managers; they are not assigned to an individual.
Fortune 500 - Each customer in this division is assigned a senior account manager as their primary contact for all banking matters. When a company is managed in this division, they remain here, even if they roll off the Fortune 500.
Group Portfolio Management - This team manages the parent/child accounts under a common umbrella for firms with multiple organizations.
New Business Development - This division is primarily marketing for new business. When an account is qualified and active, it moves on to the appropriate management team.
Public Sector/Government/Higher Education - Woodgrove Bank is a preferred lender to many sovereign governments around the globe and to private universities. This team also tends to the handful of high-volume non-profit organizations that are serviced by the bank.
Consumer Lending - This team is the smallest because Woodgrove focuses on commercial products. However, high-volume consumer lending is available on a case-by-case basis. This team is not advertised to external prospects, but mostly used by the executives of corporate clients.
Relationship Managers - This team consists of members of each of the other teams, which ensures a consistent experience because accounts might move between teams and interact in other ways. This team also establishes best practices for users.