Lead requirement capture sessions
The solution architect commonly leads the requirements capture sessions. The goal of these sessions is to develop the high-level needs into implementable requirements. If the same solution architect was involved during the presales phase, they might already understand the customer needs and success factors. Otherwise, the solution architect should ensure that they are well-informed prior to the first session. This information should be used to drive the discussion with the attendees.
As you gain more experience driving these meetings, you will adopt a preferred methodology. Be prepared to fluctuate with the needs of any particular project or customer. Arrive to these sessions with a plan, templates, and desired results; however, avoid being so rigid that it stifles conversation, creativity, and solutions.
What a requirement looks like
The specific way that a project documents a requirement can be specific to a chosen methodology. However, in all cases, requirements should capture who, what, and why. These parameters can be captured in user stories, or they can be line item requirements, but they should be testable and accountable. A good requirement keeps the following factors in mind:
Who needs the requirement
What the customer needs
Why the customer does what they do
Larger requirements or stories need to be broken down into manageable parts. Different methodologies use different terms for these parts, for example, agile approaches typically call them epics. Regardless of the name, the solution architect needs to be vigilant to ensure that this process happens.
Prioritization
Every project has a limited amount of time and resources that can be applied to implement requirements. The solution architect, along with the project team and often the customer, needs to prioritize the requirement list/backlog.
Because business application projects lend themselves well to incremental deployments, teams often first prioritize a minimum viable product (MVP). An MVP identifies the requirements that need to be completed to initially go live. Then, the remaining items fall to future iterations or sprints.
The solution architect should use the identified key business objectives to evaluate the requirements. Priority should be given to requirements that help meet the objectives. This approach can also help identify a disconnect with the key objectives if you identify a requirement that is clearly important but doesn't help achieve the key objectives.
Feasibility
The solution architect should evaluate requirements to ensure that they are feasible. Look for requirements that, while appealing, aren't achievable for a number of reasons, such as those that require:
Data that you don't have.
Updates of other systems that aren't possible in the time frame.
A good question that the solution architect can ask themselves: "Is there anything that would prevent these requirements from getting done?"
Manage attendees
Expectations should be set ahead of the sessions to ensure that the right people attend. You want to make sure that you have experienced people who understand the target areas. Having multiple, smaller and shorter sessions can be more targeted and productive. Inviting different people to handle different parts of a process is valuable because it helps you get a full picture of how that part of the process works. Often, this approach will save you from having to follow up to fill in the missing pieces of how something works.
Inviting management to attend can be helpful because you often receive more decisive information. However, keep in mind that a senior manager's presence can have an effect on their staff's willingness to participate. In many cases, their staff will be quieter and will defer to the manager for answers to avoid misspeaking. If you find that scenario happening in a negative way, you might have to address it either by following up separately or by asking the manager not to attend all the sessions.
Prework before sessions
Prior to the session, the solution architect should try to get as much information as possible on the current solution and its processes. This information can be studied ahead of time to help formulate questions that can be used to keep the discussion moving. Preparation can also help those in attendance gather documents and examples that they can bring to the sessions.
Also, remember to gather what the presales team collected. Avoid making customers start over and repeat the same information that was already discussed. Determine whether any demo recordings were made to help you become more well-informed.
Drive toward requirement clarity
Often, the initial requirement statement by a business user won't be the
real requirement. It will take investigative work by the solution
architect to guide the user or communication with others to get to the
real requirement. The solution architect must learn how to ask
"Why?" without upsetting the user or making it appear as if
the user is inept at doing their job. The real reason for the questions
is for understanding the core problem so that the best solution can be designed.
Having common questions ready can help you extract information:
Can you go through a day in the life of that process?
Who else is involved in this process?
Where does that information come from?
Can you help me understand why that process is needed?
If you start with open-ended questions to get to the real requirements and needs, you can work toward a yes or no question to confirm your understanding. The following example is a simple exchange between a solution architect (SA) and business users:
User: We need a printed report of all expired transactions in the last 30 days.
SA: Who uses the report?
User: It's used by the managers.
SA: Manager, how do you use the report? Does it have to be a report, or is the real ask simply to see the expired transactions for the last month?
Manager: We only look at the report once a month, so that would be fine.
SA: What do you look for when you review the data?
Manager: We look for any transaction that was over 50,000 dollars, and then we do a deeper review on those.
SA: So, would it be helpful if the system only presented expired transactions over 50,000 dollars for review?
Manager: Yes, that would be great.
Revised Requirement: Managers need to review expired transactions over 50,000 dollars monthly.
If the solution architect hadn't inquired enough, the team would have created a paper report. Always ask "Why?" and get to a point where you feel that you truly understand the need.
Resolve conflicting requirements
Frequently, different business users will create requirements that are conflicting. It's essential that the customer has someone who is decisive. The solution architect can help guide the parties toward a conclusion by offering ideas and compromises; however, they shouldn't get involved in corporate politics.
Stand up for your perspective
A solution architect needs to be good at respectfully pushing back on requirements. Part of this responsibility is being able to clearly communicate the solution vision that you came up with and helping the customer see how this vision helps achieve their goals. New solution architects often get into trouble at this stage by coming across as condescending. Make sure that when leading the customer toward your vision that you avoid being dismissive of their ideas.
Exercise: Plan your requirements capture sessions
Review Woodgrove Bank's teams. Determine which of these teams you would group together for requirements gathering. Decide which teams you would not group together for requirements gathering. Explain why you would make these decisions.