The complexity of requirements

The complexity of requirements

In the following text you will find out:

  • What is a requirement??
  • Needs and Wants meeting
  • Requirement Activities?
  • What does our Software Product Manager say

?

It can be tricky finding the perfect words at an important moment, but that task is even harder during Needs and Wants meetings with clients.?

Every syllable matter; those phrases define exactly what is needed for success!?

This is a frequent situation at the Needs and Wants meeting, and those critical words are the requirements. ?

What is a requirement??

The requirement is a top term in the Software development industry. ?

It could easily be at the top of the Software development Glossary and might be right under the Software Development Lifecycle the term and definition.?

Requirements are the specific description of our client’s needs. We reach them at one specific meeting. The Software Product manager is responsible for eliciting them. ?

The requirements’ purpose is to determine a product and how that product can meet the assigned purpose.?

How will the Software Product manager know are those needs “the thing”??

If they are the core functionality of a product that the product must have to fulfill a product purpose, they certainly are the Must and they are Needs.?

Functionality that the client would like to have which may add some value, but is not necessarily core to the product itself are Wants.?

?Needs and Wants Meeting?

From the above, it is clear the session's name comes from the client's needs and wants for the success of his product. For this reason, the mandatory roles at the meeting are the client, stakeholder, and product manager. ?

The time for Needs and Wants meeting can happen consecutively in 2 or 3 weeks. It is considered the most important meeting when we are talking about requirements. It would be more to come in, but from this meeting, the Product manager is testing his approaches, knowledge, and ability to adapt to a certain perspective.?

At this point, the focus is on the requirements for the software product that the Product Manager will be taking care of. This will be accomplished through meetings with our client and an expert advisor to learn about their vision for the software they wish to produce and then discuss it further with your development team. ?

Not only that those meetings are there for learning and exploring, but these meetings are set times when clients will very often change requirements, re-prioritize them, and add new ones.?

As the Software Product Manager is familiar with the material and necessary information about the product, with client and expert advisors he is moving forward effectively, and he is provided with more context.?

To Phoenix Consultancy the goal is always highlighted, and it is to build the right product for our client.?

Requirement Activities?

The phases that requirements are going through are:?

  1. Eliciting requirements?
  2. Expressing requirements?
  3. Prioritizing requirements ?
  4. Analyzing requirements ?
  5. Managing requirements ?

All those activities are transitioning from:?

  • investigative process, ?
  • over framing,?
  • prioritizing them, ?
  • through analyzing and ?
  • finally organizing them.?

As it is seen there is no term like Gathering as is heard a lot. The most basic argument against requirements gathering is that they don’t just sit around waiting to be taken and collected.?

Here is one example of requirements without reflection if that really needs your product.?

Gathering:?

The client: “I want a Promo code.”?

Product Manager: "Promo codes? Okay, I will?add that in my notebook"?

On the other side, the relaxed product manager will first have the Why on their mind and then ask a question:?

Eliciting:?

The client: “I want a Promo code.”?

Product Manager: “Would you like to?randomly generate a?promo code, or would you?like to make your own?promo codes?"?

Do you see the difference? The question, not the instant confirmation is crucial for a deeper understanding on both sides.?

The reason we write about it is that we take requirements seriously. And because we enjoy those meetings where versatility is mandatory. The Product Manager must understand everything that is articulated and induce everything that isn’t.?

What does our Software Product Manager say??

  • Frequent interaction ?
  • Transparency?
  • A bit of clairvoyance??
  • Ask Why?
  • Ask Who will use?

And that is how to get one solid requirement!?

BUT!?

The complexity of requirements has just begun. And what do we have to know more about requirements??

  • Do they control our scope??
  • Do they affect our design??
  • Who knows all that? ?
  • How can you know all that? ?

This is not the end of the puzzle. There are several types of requirements, and requirements can change! ?

No alt text provided for this image

要查看或添加评论,请登录

Phoenix Consultancy的更多文章

社区洞察

其他会员也浏览了