Anticipating Software Project Requirements – Part I
You can’t always get what you want
(Unless you ask the right questions)
Avoiding unforeseen showstoppers and “gotchas” in software development projects can be as simple as knowing what to ask your customer upfront. Identifying and addressing these “but what about. . .?” or “and then what. . .?” questions at the outset of the requirement gathering process is essential to safeguarding everyone’s time and money..
Helping a customer think about and answer deeper-dive, project-critical questions they haven’t yet considered will keep your project moving ahead smoothly with fewer speed bumps, delays, and roadblocks. Here are some overall guidelines for getting the most from your customers when gathering project requirements:
- Prepare high level questions ahead of time: To make the most of your time with your customer, prepare a basic list of questions ahead of time. Using the How/Where/When/Who/What/Why framework, you can gather a great deal of core project information before you turn the conversation over to the client to give you their take on the project, or you can use them to guide the conversation with a customer who may wander off-topic. Some examples might include:
- How Will this feature be used? OR will we measure success?
- Where In the workflow does this process begin? OR Would a user access the feature/tool/solution?
- When Does this feature/tool/solution need to be available? OR do you need our final plan in place?
- Who Is the audience for this solution? OR is the Subject Matter Expert (SME) we will be working with?
- What Needs to happen before we begin the project? OR are the metrics that need to be tracked?
- Why Have we chosen this methodology; are there other ways to accomplish this? OR does the user care about this?
- Cover all of the basics: Make sure you cover all the core questions before you dive deeper, as they may drive new questions:
- What’s the “big-picture” vision for your project? Have the customer outline their goals and objectives at a high level.
- Who will directly benefit from this solution? Find out if the solution is targeted at in-house staff, customers, sales, partners, third-party vendors—or any combination of these.
- Who are the stakeholders and decision makers for this project? Understand who will be contributing to the process, who will be participating in reviews, and who makes the final call on questions or concerns.
- What infrastructure, products, and services will be associated with or affected by this solution? Learn how the solution will be used to develop or support these deliverables and determine what kind of infrastructure changes will be required to enable legacy systems to work with the new solution.
- What kind of development schedule are you anticipating? Go over milestones and any incremental implementations you should be aware of to keep things realistic and avoid scope and schedule creep.
- Will we need to bring partners, collaborators, or SMEs into the project? Know upfront whether third-party resources will be involved or required—and what they must bring to the table.
- Will any specialized systems or tools be needed? Outline any software, hardware, or other infrastructure that will be required, and get clear on who is expected to source or supply them.
- What are the known risks associated with this project? Understand the risks associated with this project, and the expectations for managing and mitigating them.
- Are there legislative requirements or compliance mandates that this solution must satisfy? Be aware of compliance issues before the Discovery phase begins. You need to plan for, address, and avoid requirements that will become deal-breakers.
- Start high-level and drill down: Use client requests as a jumping-off point for conversations that will unearth important details about project requirements:
The high-level situation: Now let’s get specific A client requested a button that will stop a specific process at any stage of the workflow being built. • What are reasons the process would need to be stopped?
• If the process is stopped, should there be a text field to allow a user to document the specific reason why the process was stopped?
• Does “stop” mean “stop permanently,” or is it more of a “pause” function?
• Should there be a way to resume the process in the workflow after it’s been stopped or paused?
• Do we need to log and report on this activity?Even with a straightforward request like an account login page (username/password), there could be a number of scenarios that affect features and functionality. • Will users need to create an account before logging in?
• Is two-step authentication a requirement?
• Do we need to provide a way for users to reset a forgotten password?
• Should we include support for one-time “guest accounts” for users who don’t have/want an account?Requirements related to monthly subscription services go beyond just automated billing. The lifecycle and journey of a subscription customer will be affected by a number of factors, including: • Will customers be given the option to temporarily pause a subscription?
• Should customers be able to adjust their billing and shipping dates?
• How should refunds be handled?
• What notification functionality will be required for declined or expired credit cards?
• What kind of reporting will you need to support for subscriptions?
• Do your subscription services need to integrate with your accounting system?
• What happens when a credit card charge fails?
Do we want subscription terms longer than a month? - How will you measure the success of this project? In addition to understanding upfront goals, having a concrete idea of the specific metrics the project will be measured against can help you better plan and course correct as needed.
Continue to the second part of this blog. Click here
