What, Who and Why- The
requirements (part 1)

What is a Requirement?

Requirements are the specific description of our client’s needs. Their purpose is to determine a product and how the product can meet the assigned purpose.

How will 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 not necessarily core to the product itself are Wants.

From the above, it is clear that the name of the session comes from the clients' needs and wants for the success of his product.

When the time for the client's Needs and Wants meeting to occur (and that can happen consecutively in 2 or 3 weeks) is considered to be the most important meeting when we are talking about requirements. It would be more to come in, but from now one Product manager is testing its approaches, its knowledge and, ability to adapt to a certain perspective.

At this point, the focus is on 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 SPM is familiar with 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.

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 and 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 requirements don’t just sit around waiting to be taken and collected together.

In reality, there's not too much information when planning an effective project kick-off meeting. We, Phoenix Consultancy, single out that requirements need to be elicited through an interactive process between the client and the Product Manager.

We strongly believe that collaboration over-extraction of requirements is crucial. For example, our latest client was adding requirements and that affected developers and the design solution. What he thought he need?

Our client considered that it is very important for his service that the appropriate image is always in front of the eyes of the customer on the App that we are developing.

Our solution: This meant that we had to leave the image visible for as long as possible customer scroll through.

What was the outcome:
On the single page where service is offered the image of the company and information about service was pointed out so that the purchase was more accessible.

At this point (and in any other that requirements need to be documented) the Software Product Manager writes product requirements. This activity may be in various formats like Product Requirement Document or wireframes, but the most suitable for developers are user stories.

At some point, the Software Product Manager will be refining its user stories through a technical review and generating a risk plan based on a discussion with your development team.

Types of Requirements

Everything is in the plural, why requirements wouldn’t be?

Without retention on this section, here is just a glance at the type of Requirements that the Project Manager could meet and it is important for this role so that it can be grouped.

• Business requirements


• Business rules


• User requirements  


• Functional requirements  


• Non-functional requirements  


• External interfaces  


• Physical product settings  


• Development constraints  

Business requirements and business rules can be a major influence on the project, but user requirements, functional requirements, and non-functional requirements are considered the most essential requirements. On the other side external interfaces, physical product settings, and development constraints are requirements that add context for the design and implementation of the product.

What is the goal of the Needs and Wants session?

There are several goals:

• To get a list of things that will be in focus in the coming period (regardless of whether the project is kicking off or ongoing),
• To review the ideas of the client or stakeholder and to determine what is important and what is not (will end-users benefit from it),
• To document it all (Product Requirement Documents, wireframes, user stories, tasks, etc.).  
• To give estimates based on documented items and thus determine the timeline/budget.
  If we have to put in one sentence that would be the answer to the question WHY and to go behind the idea. Closer steps toward this goal are certainly writing the clear and correct requirements. On the material side of a meeting or what we get from this is documentation in the form of PRD, wireframes, use cases, or tasks. It is not sufficient to add that from these documents (one of established),
  QA starts to follow the project.  

But, to ensure the requirements are clear, complete, and consistent they have to be grouped into one document due to better estimation settings based on the documented items.
Another benefit of precise requirement is ensuring everyone involved knows exactly how something needs done making and no one gets lost or left behind along this process journey.

Troubles

Source even from 1976th proof that inadequate, inconsistent, incomplete, or ambiguous requirements had a critical impact on the quality of the resulting software. Newer information says (a tiny detail that was known back then) that late correction of requirements errors was observed to be incredibly expensive.
A very small number of projects from the survey of 8000 companies show success due to completing and clear requirements.

But it is not only the requirement's fault: And why does the project fail?

1. Lack of user involvement
2. Incomplete requirements
3. Unrealistic customer expectations  
4. Changing requirements and specifications  

References: