Many years ago, at an interview, I was asked to design an Internalization (i18n) system, also called Localization (l10n), and Globalization (g11n).
After hearing this question, I was so excited and relieved — I was working at a company that already had this exact system in place. Right after the interviewer finished his spiel, I immediately picked up the marker and started to draw everything I knew about the system.
Many years later, after interviewing hundreds of candidates, I know the exact reason why I did not pass that i18n interview: I did not ask any question.
A system design question is designed to be vague. It is to test whether the candidate makes assumptions easily and whether they can communicate.
After interviewing hundreds of candidates, I found, surprisingly, many of them, like me many years ago, did not ask any questions.
Ask the ones that would yield the information that you need to build the system, for example, services, clients, data storage, etc.
In the real world, not every requirement is treated equally. Each one has a priority. The ones that could yield the most value to the customers would be built first. Knowing the priorities and turning a project into milestones is another important skill of an engineer. So you could also ask:
NFRs are often thought of as the “itys”, because the areas it covers can often end with “ity”:
Don’t always just take orders. In real life, when the requirements are presented to you, they may not be realistic or doable. An engineer should not feel they are always there for taking orders. They should feel empowered to ask questions and check the assumptions of the product manager. Good questions also lead to good discussions.
Be aware of the scope changes and recollect the requirements. During a design interview, a problem space may be changed a few times.
For example, you are first asked to build an English-only i18n system. You’ve designed a solution. Then you are asked to build a multi-language18n system. Many interviewers immediately jumped to update their architecture diagrams but did not realize the additional language support could have other implications for requirements, for example, “do you need to serve users from different countries?”
The design interview is not to test what you’ve already known, but how you solve a problem and how you communicate. So before diving to solve any system design question, remember to ask questions, most important, good questions.
If you enjoy reading stories like these and want to support me as a writer, consider signing up to become a Medium member. With $5 a month, you will get unlimited access to stories on Medium. If you sign up using my link below, I’ll earn a small commission.
Creator. Founder of Roxy (acq. by $TWTR, ‘19). I write about startups, entrepreneurship, investing, software, hardware and manufacturing.
Business Analyst Interview Questions and Answers – [Requirement Gathering]
What is a Requirements Questionnaire?
A requirements questionnaire is a list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective). Essentially each high-level requirement from your scope document should have a list of questions to further refine your understanding.
Investing time in a requirements questionnaire will help ensure you not merely gather up requirements, but also that you discover undreamed of requirements.
And while it might seem like this would take a lot of time, the reality is that a well-thought-out questionnaire helps you run a more effective stakeholder meeting. One of our course participants reported eliminating several follow-up meetings by using our requirements questionnaire checklists and active listening techniques.
(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack. You can also download a sample checklist absolutely free of charge.)
What Requirements Questions Should I Ask?
When creating a requirements questionnaire, I work through each feature one at a time. I write down what I know about that feature (or what I assume to be true about that feature). Then I go about drafting questions. Most of the time, the questions evolve naturally as I think through the implications of a feature. But sometimes I need to spur my thinking a bit. Just like a good story, requirements will answer all the important questions. Think about the how, where, when, who, what, and why.
Here’s some generic questions you can use to spur your thinking.
Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project.
(You’ll notice that we don’t typically ask a why question by using the word “why”. Among other reasons that’s because we don’t want to sound like a 2-year-0ld and annoying our stakeholders, even as we apply the 5 Whys Technique.)
So the answer to the question “How do you gather requirements” is not about asking questions and then writing down the answers.
It’s about listening, eliciting, researching, collecting information, and analyzing it. It’s about validating whether this analysis makes sense, and then formulating what is required to achieve the desired state.
“I will start by asking who my main stakeholders are. I will then interview them, and ask what are their requirements.”
If you can speak to this point, emphasize the role of analysis versus gathering information, and give examples of some business analysis techniques that you would use, this will show your interviewer that you understand the meaning of analysis.
What you need to realize is that the information from the stakeholders you’ve interviewed, and their opinion on what is happening and why may not be the full picture.
Yes! I have used the ranking technique in which i have given the ranks to the requirement items based on multiple discussions and prioritize requirements accordingly.
According to me the most effective requirement gathering technique is Workshop. But before that we require to complete the document analysis and everything which we require. After that we require to arrange the Workshop technique where we can gather highly important requirements from variety of stakeholders. Here you will get the clear requirements from set of stakeholders. You can gather most effective requirements in short span of time.
The requirement is nothing but the need or usable representation of need. The need is nothing but the what exactly software needs to run and which functionalities the software requires to complete the business need.
It represents how to achieve the business requirements and technical team involvement is must for gathering functional requirements.
Question 10 : What are different requirement prioritization techniques which you have used ? Give us example.
FAQ
What are the five stages of requirement gathering?
- How will you use this feature?
- Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps?
- How might we meet this business need?
- How might we think about this feature a bit differently?
- How will we know this is complete?
What to include in requirements gathering?
- Step 1: Understand Pain Behind The Requirement. …
- Step 2: Eliminate Language Ambiguity. …
- Step 3: Identify Corner Cases. …
- Step 4: Write User Stories. …
- Step 5: Create a Definition Of “Done”
