Challenge your inner teacher while you elicit requirements for future Software Products (The requirements, part 2)

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.  

A venn diagram of product manager responsibilities and the overlap of UX, technology, and business (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.

A venn diagram of product manager responsibilities and the overlap of UX, technology, and business (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.
A venn diagram of product manager responsibilities and the overlap of UX, technology, and business (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.