Introduction

An initial Request is handled by the systems architect to get a general understanding of the application.

We take a User-focused approach, asking 6 overlapping User-related questions.

The 6 U's - User-focused Request

tip

• Meeting types for Request:
  • Initial: 30-45 minutes informal "heads-up", to get basics. Less invitees.
  • Extended (1-2mo. followup): 60 minute meeting + in-depth + more invitees.
  • Business Functional Document (3-4 mo.): 60 minute review, all involved in it.
• Important: Save the answers and info you get.
  • Save the meeting video/recording if possible.
    • to review if you forget details, share with colleagues and
    • to clear up misunderstandings if changes requested.

Each one of these is handled in more detail later in this Request category.

1. User Story (5 min.)
   • What does the app do?
   • How: Ask for summary, in 2 minutes or less. App must-haves.
   • Why: Highlights main functionality.
   • Insights:
     • Problem, action, solution, benefit? Organized? Clarity?
2. User Roles (5 min.)
   • What User roles are needed?
   • Roles have Responsibilities which have Requirements
   • Roles > Responsibilities > Requirements
   • How: Ask for a list of each user/responsibility. Hard requirements/user
   • Why: Highlights facets of the app needed, IAM users, must-haves per user.
   • Insights:
     • Admin? Multiple apps? Auth, User data requirements. Must-haves. ie. compliance, tax etc.
3. User Qualities (5 min.)
   • What are the user characteristics ie. number, usage patterns, locations, devices, etc.
   • How: Ask for list of demographics, location, devices, other relevant user info.
   • Why: More info on who is using the app, for device and location.
   • Insights:
     • Number of users, availability needed, locations, devices, time-usage patterns
4. User Interface (5 min.)
   • 5 items on the nav bar, home screen, importance of the interface/latency.
   • How: Ask for mockup or design vision.
   • Why: Highlights most important parts of the app.
   • Insights:
     • Qualify the most important frontend/user-facing functions of the app.
     • Helps us understand interface and importance for this app (some internal apps may be lower priority, others very high)
5. User Screens (10-15 min.)
   • Drill down into screens for each main function.
   • How: Ask for list of what main screens there are and what they do.
   • Why: More detail so we can start thinking about data models and APIs.
   • Insights:
     • More details for data modeling and API design/contracts.
     • Helps guage complexity for number/type of features/options available to the user.
6. User Growth (10-15 min.)
   • Projections of near-future user growth
   • How: Ask for some of the daily user requirements and expected growth at 1-2-3-6-9-12 months
   • Why: Right-size our architecture, consider scalability, availability and other factors post-launch.
   • Insights:
     • Start thinking about number, type, complexity, and staffing of resources needed in the next year. At this point only gathering impressions.
     • Look for red flags due lack of planning for projected growth.
     • A system is normally not built for launch day requirements only, but ongoing growth/usage.

Additional thoughts:

• Can you just email out these questions?
  • No, it's recommended to have a live zoom/video, phone or in-person meeting.
  • Most product managers/owners are more receptive to a meeting.
  • An email may be overwhelming, forgotten, ignored, de-prioritized.
  • An email may miss key details that can be asked in the meeting
• This could be shortened to 30 minutes for a brief meeting.
• 45-60 minutes is usually about right to get into enough detail.
• Ask a lot of questions (examples below), as finding issues upfront saves effort and misunderstandings later.
• Get initial impressions
• Look for red flags (below)

Invitees for Extended Systems Design Meeting

• There can be an initial meeting with only one or a few roles mentioned below.
• However, if some can be present it helps to get awareness and "buy-in" earlier in the process.
• Extended (followup) meeting is when more gaps have been filled in a and it's closer to the final Business Functional document.

An extended Functional Document kickoff meeting should include representation for these roles:

Role	Responsibility
Product Owner/Product Manager	Responsible for the overall vision and strategy for the product or feature being discussed.
User Researcher	Researching the needs and behaviors of the users of the product.
UX/UI Designer	Designing the user interface and user experience of the product.
Systems/Solutions Architect	Technical design of the software and system for the product or feature.
Tech Lead	Lead for technical implementation.
Systems/Software Engineers	Technical implementation of the product or feature. May require multiple roles for specialties like Database, DevOps, Network.
Business Analyst	This person is responsible for analyzing the business requirements and goals of the project.
Quality Assurance/Tester	Responsible for testing the product or feature to ensure it meets the requirements and is free of defects.
Project Manager	Responsible for managing the schedule and resources for the project.

❌ Red flags (risks) in "Request" phase meetings.

• These are "red flags", risks, if not considered early in the systems design process.
• Address issues in extended or final business decision meetings.

Potential Problem	Reason
Lack of clear goals/objectives for the project	Success requires clear goals, requirements and success measurements.
Unclear agenda or schedule	There should be a clear agenda and schedule, outlining what will be discussed, who will be responsible for specific tasks and when decisions will be made.
Lack of collaboration and communication	There should be a culture of collaboration and communication. All stakeholders should be encouraged to share their ideas and feedback.
No user research	Research is needed to understand the needs and behaviors of the users of the product.
No end-users involved	The project needs representation of end-users to give feedback and ideas.
No clear product owner	Who is responsible for the overall vision and strategy for the product?
Lack of technical expertise	Developers who will be responsible for building the product, particularly for specialized applications like AI, IoT etc.
No design representation	UX/UI designers responsible for designing the user interface and user experience may add important insights.
Lack of business analysis	The meeting needs representation of the business analysts who are responsible for analyzing the business requirements and goals of the project.
No project management	A project manager who is responsible for managing the schedule and resources for the project can help with planning/scheduling.
No QA/Testing representation	Quality assurance/testers will be needed at an early stage to plan for testing the product or feature to ensure it meets the requirements and is free of defects.
Limited or no discussion of scalability	The meeting should consider how the product will handle increasing numbers of users or data, and have a plan in place for addressing scalability issues.
No plan for maintenance and support	The project needs a plan in place for maintaining and supporting the product after it has been released.
No consideration of accessibility	The project should consider how the product can be made accessible to users with disabilities and adhere to accessibility guidelines.
No discussion of security	The meeting should consider the security risks associated with the product and have a plan in place to mitigate them.