User requirements, functional requirements, nonfunctional requirements, and business rules of the product should be defined consistently with business requirements to keep the project on track and ensure the strategic, user, and technical fitness of the product.
-User requirements: what customer needs/goals the product should meet
-Functional requirements: what functionality the product should have in order to meet user requirements
-Nonfunctional requirements: how the product should work in terms of quality attributes, such as usability, performance, privacy, and security
-Business rules: mainly the conditions, constraints, and formulas that determine how requirements will be handled by the user and the product
If these user, functional and nonfunctional requirements, and business rules are not consistent with business requirements, then project outcomes will not deliver the desired value and fulfill customer needs. To mitigate this risk, business analysts should give highest priority to translating business needs into correct user requirements during requirements-gathering meetings. They should focus on resolving conflicts about these requirements before discussing the technical aspects of the product. They should always keep in mind that “doing the right thing is always more important than doing it right.”
Business analysts should consider conflicts among project stakeholders positively during the requirements-gathering stage. If these conflicts are not discussed and resolved at this early stage of the project, they will later appear as high-cost CRs (change requests) at the development and testing phases. CRs are the main source of waste at PDLC because they
-can’t be planned,
-result in scope creep,
-cause analysis paralysis,
-generate hidden costs,
-are mostly urgent,
-have both direct and indirect impacts on various parts of the product, and
-may bring a regression-testing burden.
In the lean approach, business analysts should be aware of factors that result in CRs and try to prevent them. The main reason for CRs is the “problems and deficiencies in requirements-gathering, documentation, and management process.”
These kinds of CRs should be prevented in a proactive way by applying the following best practices throughout the requirements-gathering phase of a product development project:
-Realize that innovation cannot be achieved at the technical level. Innovation is a matter of formulating solutions that best meet user needs.
-During requirements-gathering meetings, be customer centric and ask, “What are customers’ needs and how will the new product meet them?” instead of asking, “What should be the technical features of the new product?”
-Be open-minded, find alternative solution options, and prevent shallow “either/or” discussions about product features.
-Balance the level of creative vs. critical thinking at requirement-gathering meetings. At the beginning of the project, be as creative as possible. But when you start detailed requirement analysis, employ critical thinking. Critical thinking means asking the right, to-the-point questions and verifying them before assuming that they are correct.
-At the meetings, get ready to say no to even good ideas from the business units if these ideas are not in alignment with business and user requirements of the product.
-Although business analysts and project managers may have enough level of business and technical knowledge, technical teams should still be invited to requirements-gathering meetings to better evaluate the technical feasibility of requirements.
-Don’t try to find the answers to why (we need the product), what (the product does), how (the product does), and technically how (the product works) questions during one single meeting. For large-scale projects, conduct separate sessions for interviews, focus groups, and workshops if your project is not a time-sensitive, fast-track one.
Go to the Gemba
-Don’t listen to the voice of the customers only from product owners and business unit representatives. Elicitation techniques, such as shadowing, should be used to observe customers while using the products or their prototypes. In the lean approach, this is described as “go to the gemba.”
Yes-Men vs. No-Men
-At requirements-gathering meetings, get ready to deal both with yes-men and no-men from business units. Yes-men are more dangerous than no-men. They are silent and friendly during requirements-gathering meetings but become aggressive and extremely demanding later at user acceptance tests. Although no- men are usually regarded as troublemakers, they are more helpful in identifying and resolving conflicts at the early stages of the project. Resolution of these early conflicts prevents waste due to costly change requests at later stages of the product development project.
Perfectionists vs. Overlookers
-In the lean approach, requirements gathered from both perfectionist and overlooking people should be analyzed carefully. Perfectionists usually focus on details of low-priority product features. On the other side, overlookers may mislead the project team by even undermining high-priority product features.
A Picture Is Worth a Thousand Words
-Benefit from prototyping during requirements-gathering meetings to help participants visualize the requirements in their minds.
Quantum Observer Effect
-The way of asking questions in requirements-gathering meetings is also important. The observer effect in quantum mechanics states that “by the act of watching, the observer affects the observed reality.” Similarly, during requirements-gathering meetings, asking questions in a biased way impacts the objectivity of answers from participants.
-At requirements-gathering meetings, giving the right answers to wrong questions is more dangerous than giving wrong answers to the right questions. Wrong questions mislead the team, generate conflicts, waste project time, and result in failure. Business analysts should prepare simple, objective, and to-the- point questions for these meetings.
Conflict Is a Norm but Not an Exception
–At requirements-gathering meetings, don’t be afraid of conflicts and negotiations among participants. The more conflicts resolved at this early stage means fewer CRs during the project.
-Try to clarify all of the issues during requirements-gathering meetings. Don’t postpone them by entering into an issue database. Issue management means postponing problems.
-Don’t feel desperate during requirements-gathering meetings when the number of conflicts increases and the problems get complicated. At those times, think that the project is not rocket science like at NASA or CERN, and do not exaggerate these situations. Instead of giving up early, remember the advice of Henry Ford: “There are no big problems; there are just a lot of little problems.”
-Apply the “functional decomposition” technique to divide problems into smaller parts and resolve them one by one. When needed, benefit from the “five whys” technique, which is iteratively asking questions as a basis of the next question until finding the root cause of a particular problem.
Butterfly Effect in Chaos Theory
–When a change request is received, analyze its forward and backward impact on all levels of requirements. According to the Butterfly Effect in Chaos Theory, a small change at one place in a complex system can result in large effects elsewhere. The formation details of a hurricane can be influenced even by the flapping of a butterfly’s wings at a distinct location several weeks earlier. This is also valid for CRs. A CR that is considered to be minor may result in a butterfly effect on lots of other product components and require a big effort.
