Did you know that the most difficult and at the same time
rewarding task for any teacher is to get students engaged?
They circle the students in desire for that keyword, just to
be sure that they understand the matter. Sometimes it looks
like the teacher is haunting, especially when it is followed
by deep silence in the class. Teachers believe that with
inquiring-based learning they are developing thinkers. They
are provoking curiosity in students, “forcing” them to
independently find answers.
(Sometimes, when matter allows teachers use relaxing
sentences like: “There are no wrong answers.” Students very
often feel empowered!)
There are many benefits for this type of learning, especially
from the cognitive side of human development.
In the world of education is plenty of methods, theories, and
approaches, and one that Is more likely that Software
developments teams will understand is the IB system of
education.
The International Baccalaureate IB is a system that has four
programs that develop inquiring, knowledgeable, and caring
young people motivated to succeed.
First of them is the PYP method which stands for base of
educational journey and its pandan in Software Product
Management is its crucial phase: Eliciting requirements.
Term “requirement” and its essentiality in
Software Product Management
One of the most critical aspects of Software Product
Management is a term known as a requirement. Is noticeable the
dictionary contains various definitions of “requirements.” A
Requirement is most easily understood as a specific
description of your client’s needs, which can be used to help
create a real-world product.
The Institute of Electrical and Electronics Engineers (IEEE)
defines a requirement as:
1. A condition or capability needed by a user to solve a
problem or achieve an objective.
2. A condition or capability that must be met or possessed by
a system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
3. A documented representation of a condition or capability
as in (1) or (2). (IEEE, 1990).
Well-defined requirements help your client's needs be
understood and addressed. Detecting potential problems before
they become large and expensive ones is also the profit from a
precise requirement. Overall, its essentiality lies in clarity
and unambiguity like that thin boundary that helps Product to
succeed knowing what to expect out of every next task.
Requirements elicitation has several key benefits and this is
how it looks at the beginning of this phase:
During the elicitation process, a business analyst works
closely with stakeholders and clients to study their needs.
The discussion ends when they find enough information for an
iteration of development or risk mitigation--but not both!
Establishes the precise scope of work and budget.
Clear, prioritized requirements allow for accurate planning
and estimation with a development team that can provide
realistic timelines and budget estimates to the clients.
Avoids confusion during development. A shared
understanding of what should be done, when, and how to finish
a project greatly speeds up communication so that both parties
are productive from the beginning until the end-product has
been achieved.
Add Business value: Developing a product that will
increase the company's business value is important for the
development team members and clients to have an understanding
of what needs to be done. This way they can create solutions
that meet all customer requirements in suitably creative ways.
Reveals hidden and assumed requirements. Stakeholders
always know their market, and business needs the best. That’s
why stakeholders may find some requirements too obvious to
discuss. But developers need to know each aspect of the
solution, and an SPM helps them figure out and specify such
requirements.
Allows for developing only relevant functionality. When
discussing requirements, the PM uses their knowledge of the
development team to improve the initial requirements. They
help clients cast off inefficient features and choose the best
possible technologies.
Thence, the purpose of this text is to facilitate the
Eliciting phase by introducing readers to some well-known
methods in schools, used by plenty of educators. Getting a
proper answer may be hard work, especially if both sides are
aiming for the same goal, but their starting position is
different.
What are Requirement's activities and
what is Eliciting?
Eliciting is the first of Requirement's activities, and the
next four is the following:
2. Expressing requirements
3. Prioritizing requirements
4. Analyzing requirements
5. Managing requirements
It's not strange for eliciting being in the first position
because this activity is a collaborative and investigative
process and occurs when the client and users meet.
Some clients have basic knowledge of what they want and
require when it comes to software. They may not even
understand how programming works, leaving them feeling lost in
the process. It can be difficult for such people because there
isn't always one perfect answer or solution; instead,
different projects will produce varying results depending on
many factors like budget size, time available, etc., which
makes choosing between options harder than ever before.
The software product manager is a key player in the process of
developing and managing products. They work closely with
clients, helping them understand what they "want" from their
systems through clear communication while also finding out how
we can best satisfy those needs using our technical expertise.
Do you see a resemblance between the teacher’s point of view
and the Manager’s position? It is very similar in this
particular phase because they try to derive a certain answer.
(Knowing how to ask is a key for understanding both
perspectives)
Why do requirements need to be elicited? Is that simple like
when we read some literature and imagine a certain character?
Do we all imagine those characters exactly the same? Of
course, we don’t. Colores of their clothes, shoes...the tone
of their voice, their movement. The answer may not always seem
so obvious until we take time to examine each detail needed
for both sides to understand what exactly it means.
That’s how elicitation works during software development
projects; every little piece matters so there should never be
any question left unanswered. Or even unopened.
In-class activities that are equivalent to
Eliciting phase
Being an effective Product Manager, assume that at some point
PM should be acting like a teacher. That is more likely to
happen in the Eliciting phase. It is known that the role of a
teacher is demanding, but also rewarding. Here is the point
where resemblance arises.
What do teachers use for eliciting knowledge and for
substantiating current ones?
A conceptual inquiry approach is a powerful vehicle for
learning that values concepts and promotes meaning. The key to
this type of teaching isn't just understanding what is
studying, but critically engaging with significant ideas in
order to create your own understanding.
When we replace the terms teaching for eliciting requirements,
studying for producing it becomes clearer what is going to
happen. (The key to this type of eliciting requirements isn't
just understanding what you're producing, but critically
engaging with significant ideas in order to create your
understanding.)
We are going to get a significant number of prospects
therefore the client is far more instructed in the future
product and so helps the manager to organize the desired
requirements.
Learners that are undergoing such training by organizing
knowledge around broad topics or subjects – are enabled to see
things differently than before so they can make sense of the
matter. They are guided to see-through lenses of abstractions
provoked by the right questions.
Many in-class activities are similar to Eliciting phase in
Software development like brainstorming, flashcards,
roleplays, and mind maps. Here is one example with the method
Caption It. This is when teachers use pictures in
connection with words.
An appropriate image is chosen, then students have to add:
- one word – a word that will confuse or intrigue
-
a statement – to guide or change the viewers’ perspective
-
ask the learners to add their own caption – then compare and
discuss thinking.
- ask the learners to ask the picture a question.
(Of course, the teacher is driven by subject and PM is
driven with finding the same perspective with the client)
Many more skills are progressing through this type of
education, and their manifestation could be seen in a powerful
Product manager position, such as:
- Thinking skills,
- Communication skills,
- Research skills,
- Self-management skills and
- Social skills.
And again, interweaving between teaching and dealing with
developing Sofware is on the spot.
The rewarding part is the same in the Software developer
industry. It is a lane to client wants and needs. And
resemblance stops here, due to teacher and Manager are diverge
here.
Conclusion
So, the circle is closed, the student becomes a teacher to a
client, the client becomes a student. In order to do the right
job for a future Product, the Manager has to be good at
figuring out what clients “want” and what they “need”. A
“want” is usually a functionality or feature that the client
would like the product to have. That may add value, but is not
necessarily core to the product itself. On the other hand,
“need,” is the core functionality that the product must have
in order to fulfill the product’s purpose. Needs should take
priority in product development. Discovering needs and wants
is the best through engaging in discussion about the product.
Eliciting phase: where the software product manager and the
team can help provide insights on what the client “needs” and
“wants” the product to do, and how these goals can be feasibly
achieved.
Eliciting requirements, or inquiring answers from educational
perspectives, engages in in-depth discussion and collaboration
from the start of product development, so both the client and
the development team work together to build a successful
product.
If you can relate with teachers worldwide, maybe these
insights in different spheres could help in managing Software
products.
Takeaways
-
Teachers believe that with inquiring-based learning they are
developing thinkers. They are provoking curiosity in
students, “forcing” them to independently find answers.
-
A requirement is most easily understood as a specific
description of your client’s needs, which can be used to
help create a real-world product.
- Eliciting is the first of Requirement's activities.
-
A conceptual inquiry approach is a powerful vehicle for
learning that values concepts and promotes meaning. The key
to this type of teaching isn't just understanding what is
studying, but critically engaging with significant ideas in
order to create your own understanding.
-
Many in-class activities are similar to Eliciting phase in
Software development like brainstorming, flashcards,
roleplays, and mind maps.
-
Eliciting requirements, or inquiring answers from
educational perspectives, engages in in-depth discussion and
collaboration from the start of product development, so both
the client and the development team work together to build a
successful product.