Have you received customer requirements but feel unsure where or how to start analyzing them? In real-world IT infrastructure design projects, customer requirements are rarely clearly defined from the outset. “The system must never go down.” “I want to see production status in real time.” “Please ensure smooth integration with our existing systems.” Statements like these alone aren’t enough to design infrastructure such as servers, networks, and storage. You first need to clarify what they mean, whose requirements they are, and under what conditions they need to be met. Over approximately 20 years working as a systems engineer and technical architect (TA) for organizations in finance, defense, manufacturing, broadcasting, and government, I’ve learned that just as important as the technical design is **the process of accurately eliciting and organizing the requirements needed for that design**. This course uses a hypothetical project to build a new MES for a manufacturing company to show how to turn unclear customer requests into documents that can be used in actual infrastructure design. Across 14 lessons, you’ll learn each step, from identifying stakeholders and conducting interviews and observations to classifying and analyzing requirements, determining priorities and scope, reconfirming requirements with the customer, creating a design input definition document, managing traceability, and handing over the baseline. This is not a course in simply memorizing concepts. Through hands-on exercises and completed examples, you’ll practice evaluating and documenting requirements, and learn how to create documents that can be used in real-world projects. **The goal of this course is not to make you someone who collects as many requirements as possible, but a practitioner who can organize what customers say into design inputs that downstream designers can understand and use right away.** ※ This course focuses on eliciting and analyzing requirements and documenting design inputs. It does not cover selecting server or network products, creating system architecture diagrams, or detailed infrastructure design.
1 learners are taking this course
Level Intermediate
Course period Unlimited
① Ability to analyze ambiguous customer requirements and formulate clarifying questions — able to break down expressions such as “real-time,” “zero downtime,” and “stable integration” into business impact, measurement targets, and verification criteria, then draft the questions needed for the customer.
② Ability to write practical requirements documents—learn how to prepare a stakeholder list, elicitation plan and questionnaire, raw requirements list, and requirements list, and how to track the sources and verification status of requirements.
③ Ability to assess requirement priorities and design scope — Can classify requirements as functional, non-functional, operational, or responsibility-related, and distinguish constraints, assumptions, dependencies, and candidate solutions to clarify what falls within and outside the design scope.
④ Ability to create a design input definition document — Translate the customer’s business language into statements that downstream infrastructure designers can understand, and document measurement and verification criteria, unresolved items, and related downstream design areas.
⑤ Requirements Traceability and Baseline Management - Able to trace the links from the customer’s raw requirements through to requirements and design inputs, distinguish between decisions made and items still pending, and communicate them to the downstream design team.
Final Training Deliverable - Based on a manufacturing MES implementation case, you will gain experience creating a requirements list, design input definition document, requirements traceability matrix, baseline and open issues list, and handoff memo for the downstream design team.
You’ve received the client’s requirements. What should you do first?
Should we select the servers? Draw a network diagram? Or first understand the existing system configuration?
In real IT infrastructure projects, countless questions arise before technical design even begins.
“The system must never go down.”
“I want to check production status in real time.”
“Please integrate seamlessly with the existing ERP.”
“Data must not be lost, even if a failure occurs.”
They may seem like clear requirements to the customer, but there is still a lot for the designer to clarify.
Because it has not been defined what must not stop, how many seconds or minutes “real time” means, or what data needs to be retained and for how long.
If you start designing in this state, requirements may change as the design progresses, forcing you to revisit decisions you have already made about the architecture or design direction.
This course starts with exactly that problem.
Being able to install and operate servers is a different skill from being able to analyze customer requirements and begin designing infrastructure.
In an actual design project, you need to make judgments such as the following.
Is what the customer said an actual requirement or merely a wish?
Which stakeholders should we meet with, and what should we ask them?
How should requirements be distinguished from technical solutions?
How should information that has not yet been confirmed be documented?
Who should decide when requirements conflict?
What documents should be handed over to the downstream design team?
In this lecture, you’ll learn how to answer these questions by following the flow of a single project.
Rather than simply explaining the concept of requirements analysis, this course covers the evidence real-world designers use to make decisions and how they document those decisions.
I worked as a systems engineer (SE) for about 15 years, then spent about 5 years as a technical architect (TA) in the financial sector.
Through my experience in system implementation and operations, I learned that accurately understanding and aligning on requirements between customers and designers is just as important as solving technical problems.
In practice, customer requests are not always delivered in perfectly prepared documents.
Requirements may be vague, different stakeholders may provide conflicting explanations, or undecided matters may be presented as if they were already settled.
At this point, the designer’s job is not to decide the answer based solely on their own experience.
Verify what you don’t know, document the basis for your judgments, and clearly distinguish what has not yet been decided.
This course incorporates this practical perspective.
The course uses a fictional project to build a new MES (Manufacturing Execution System) for the manufacturing industry.
Starting with the customer’s initial request, we work step by step through identifying stakeholders, gathering and analyzing requirements, and ultimately delivering the necessary documents to the infrastructure design team responsible for the next phase.
As the course progresses, customer statements, interview results, observation notes, documents, follow-up questions, and responses accumulate.
Based on this material, we assess the requirements and complete the necessary deliverables.
Who should you ask, and what should you ask them?
Understand the project’s purpose and scope, and identify the stakeholders.
Develop a requirements elicitation plan and prepare appropriate elicitation methods and questions for the situation, such as interviews, group discussions, observation, document analysis, and surveys.
How do you record what customers say and the situation on site?
Gather information from the perspectives of executives, plant managers, production management, quality, equipment, IT, ERP personnel, security personnel, and partner companies.
Distinguish and record what the customer said directly, what was relayed by others, the designer’s inferences, and facts observed on site.
What is a requirement, and what is a solution?
Classify the collected information into requirements, constraints, assumptions, dependencies, and potential solutions.
Analyze functional, non-functional, operational, and responsibility requirements, and review their priorities in light of business impact, dependencies, and other factors.
Also define what is inside and outside the scope of the design, and clarify responsibility boundaries with other systems and organizations.
Is this requirement suitable for use in the design?
Review the requirements for ambiguity, omissions, conflicts, feasibility, and verifiability.
Do not make assumptions about anything that has not been confirmed; ask the customer again.
Distinguish the customer’s response from the decision-maker’s decision, and document the rationale whenever you change the status.
Turn the customer's words into statements a designer can use.
Analyze expressions such as “I want to see it right away” and “It must never stop” in terms of operational criteria, what to measure, data freshness, normal and peak conditions, and verification methods.
Based on this, prepare a design input definition document recording the designer’s interpretation, measurement and verification criteria, unresolved items, and related downstream design areas.
Where did each requirement come from, and which design does it lead to?
Trace the connections from customers’ raw requirements to requirements and design inputs.
Distinguish what has been decided from what remains undecided, document the baseline and open items, and prepare materials to hand over to the design team.
You can identify the stakeholders needed for a project and choose appropriate elicitation techniques and questions.
You can distinguish customer requests as requirements, constraints, assumptions, dependencies, and potential solutions, and explain the reasoning behind your judgments.
Learn how to identify ambiguous or missing information and obtain what you need by asking clarifying questions.
You can document what needs to be covered in this design and where it connects with other organizations or systems.
Learn how to translate customers’ business language into design inputs that infrastructure designers can understand.
You can track the source and decision status of requirements, clarify open items and follow-up actions, and communicate them to the design team.
This course consists of a total of 14 lessons, and you will learn using practice templates and completed examples for each lesson.
The main learning deliverables are as follows.
| Category | Key Deliverables | |---|---| | Requirements Elicitation Preparation | Stakeholder list, elicitation plan, questions | | Requirements Gathering | Interview, observation, and document analysis records; raw requirements list | | Requirements Analysis | Requirements list; constraints, assumptions, and dependencies list | | Priorities and Scope | Priority decision records; scope and boundary definition | | Quality Validation | Quality review records; customer confirmation questionnaire | | Design Inputs | Design input draft; design input definition | | Design Handoff | Requirements traceability matrix, baseline, list of open items, handoff memo for the downstream design team |
The goal is not simply to fill in a blank document.
It is important to understand why this requirement was classified this way, why this value should remain undecided, and why the designer must not arbitrarily choose a solution.
You can learn both the decision-making process and how to write documentation by comparing the practice templates with completed examples.
SEs looking to expand their role from IT infrastructure operations to design
Those with experience in server, network, and system operations but limited experience analyzing customer requirements and writing design documents.
Engineers taking on technical architect (TA) responsibilities for the first time
Those who want to systematically learn what to clarify in customer meetings, what decisions to make, and what deliverables to prepare.
Participants in new system development and enhancement projects
Those who find it difficult to clarify additional items for confirmation, the scope of the design, and boundaries of responsibility because the RFP or initial requirements are unclear.
Practitioners looking to strengthen their design documentation skills
Those who want to learn how to create documents used in actual projects, such as requirements specifications, design input specifications, and traceability matrices.
PMs and PLs who review technical requirements
Those who want to learn how to manage requirement verification status, dependencies, and unresolved issues between the design team and the customer.
It helps if you’re familiar with the basics of IT infrastructure, including servers, networks, storage, databases, and virtualization.
Hands-on implementation or operations experience will help you understand the course material.
Experience as a technical architect or on manufacturing MES projects is not required.
A standard PC and a document or spreadsheet editing environment are all you need.
Separate practice servers, network equipment, and programming environments are not required.
This course is an independent module focused on eliciting and analyzing requirements and documenting design inputs, rather than covering the entire infrastructure design process.
It does not cover selecting server or network products, creating physical or logical architecture diagrams, deciding on detailed redundancy methods, or capacity planning.
Subsequent design stages will be covered in separate follow-up modules.
Rebalance's intermediate course is designed as a modular curriculum that lets you choose and study the practical design topics you need.
In Module 01, you’ll learn how to organize requirements as design inputs. Subsequent modules will cover other infrastructure design topics, such as architecture diagrams and flowcharts.
You don't have to take every module.
The goal is to let you skip what you already know and focus on learning the design skills you need for your work.
Good infrastructure design begins not when you select equipment, but when you clearly understand what needs to be designed.
The ability to go beyond simply writing down a customer’s ambiguous requirements as stated, verify the supporting rationale, document decisions, and clearly organize the inputs needed for subsequent design.
We hope you’ll experience the entire process from start to finish through this course.
Rebalance
IT infrastructure training that starts with real-world practice and leads to design
Who is this course right for?
① System engineers (SEs) looking to transition from IT infrastructure operations to design work — those with experience operating servers and networks but who are unsure how to gather customer requirements and turn them into design documents for new-build projects.
② Engineers taking on technical architect (TA) responsibilities for the first time—those who have started design work but want to systematically learn how to conduct stakeholder interviews, analyze requirements, define the scope of a design, obtain customer sign-off, and prepare documentation.
③ Practitioners involved in new IT infrastructure build-outs or modernization projects who find it difficult to determine what additional information to confirm or which requirements to incorporate into the design because the customer’s RFP or requirements document is unclear.
④ Practicing engineers seeking to strengthen their infrastructure design documentation skills—those with technical knowledge but limited experience preparing project deliverables such as requirements specifications, design input definition documents, and traceability matrices themselves.
⑤ PMs, PLs, and technical staff who need to review technical requirements for IT projects—those who want to distinguish customer requirements from technical solutions and clearly manage unresolved issues and boundaries of responsibility.
Need to know before starting?
You can follow the course smoothly if you understand the basic concepts of IT infrastructure. It is suitable for those familiar with fundamental terms such as servers, networks, storage, databases, virtualization, and high availability (HA). Experience participating in real-world IT system operations or implementation projects can help you understand the examples in the course, but prior experience performing design work as a technical architect (TA) is not required. No programming skills or specialized knowledge of any particular cloud product are required. If you lack a solid foundation in IT infrastructure, we recommend taking Rebalance’s introductory infrastructure design course first. However, taking the introductory course is not mandatory.
All
14 lectures ∙ (6hr 16min)
Course Materials:
Check out other courses by the instructor!
Explore other courses in the same field!
Limited time deal
$79,200.00
20%
$77.00
