What is...

Aside from the customer needs - the product’s requirements include all functions, features and behaviors that the product must possess, so that it will be efficient, ease to use, safe, low cost, etc. In other words - any function, constraint or other property that is required in order to satisfy user’s needs. User requirements are gathered from users and described from the analyst with a customer point of view.  

A user is defined as: “One who consumes or employs a good or service to obtain a benefit or to solve a problem, and who may or may not be the purchaser of the item”. A customer is defined as: “A party that receives or consumes products and has the ability to choose between different products and suppliers” (Business Dictionary, 2017).  

Thus, product requirements must be taken very seriously. Requirements management usually requires that a lot of resources early in the product development phase, but on the other hand - the workload decreases in the later stages.

Requirements Attributes (features)

To be considered as good - each product requirement must possess certain attributes. For example, in the software engineering there is the INVEST principle, so the requirements should be: Independent, Negotiable, Valuable, Estimable, Small, Testable. 

For the general product requirements - the desired attributes include the following:

• Clear - the requirement is unambiguously defined.
• Complete - all that is needed - is consisted in the requirement.
• Credible - the requirement must be technically possible to be achieved.
• Consistent - the requirement is not in collision with other requirements.
• Verifiable - the requirement must be verified and validated (so it should be expressed in physical terms and measurable attributes).
• Necessary - if some requirement brings clear business value - it can be treated as more necessary than other requirements that are “nice to have” (e.g. product color).

Product Requirements Lifecycle

The product requirements lifecycle includes the following phases:

• Requirements gathering,
• Requirements analysis,
• Requirements verification / validation,
• Requirements management and tracking,
• Requirements specification (documentation).

We will now briefly describe each of these phases.

Gathering of Product Requirements

In this phase - we have to determine the sources of the product requirements and the approach for their handling and management. It is important to identify all of the sources:

• Objectives - also known as ‘Business concerns’ or ‘Critical Success Factors’, represent the comprehensive goal of the product. Special attention should be paid to the cost of reaching the target (through a feasibility study).
• Domain knowledge - a production engineer needs to have knowledge of the product’s application domain and to be ahead of others; to resolve conflicts in the requirements and to be a mediator between all participants.
• Stakeholders - some products might prove to be unsatisfactory, because of the different perspectives of the stakeholders. The product engineer needs to identify a correct representation and to manage these situations (different culture and politics).
• Operating environment - product requirements come from the environment in which the product is used on daily basis.
• The organizational environment - the product will have to support the business environment and the processes (conditions) that it will be used it. New product should not bring unplanned changes, so it requires careful analysis by the product creators, before making a final decision.

When all sources are identified - the product engineer can start the requirements elicitation (gathering). This area deals with the techniques for selection and extraction, which can be particularly sensitive. For example, users may have difficulty in defining actions and sometimes they omit important information. These techniques are not passive and require hard work for the articulation of all requirements. The interview represents a traditional way of collecting client’s requests. This technique has certain advantages and limitations.

It is necessary to prepare scenarios for the requirements elicitation:

• Providing a framework for defining the questions: What if...? How is this done..? etc.
• Using a technique known as Conceptual modeling - i.e. Case Modeling and Diagrams.

Also, holding meetings (brainstorming) and group work can be more efficient than individual techniques of observation (observing how users will use the product and interact with it).

Requirements Analysis

After the process of requirements gathering - a process for their analysis is necessary. Requirements analysis refers to the processes required in order to:

• Identify and resolve the conflicts between the product requirements;
• Detection of product features, and how the product will behave in real environments;
• Elaboration of product requirements in the process of product development.

The traditional view of the analysis requires the use of conceptual modeling and other methods for analysis, such as the Structured Analysis and Design Technique (SADT).

The most important thing is to accurately describe the clients’ requirements, in order to facilitate their validation, verification of their implementation, and the cost estimates.

Requirements analysis includes:

1. Requirements Classification;

2. Conceptual Modeling;

3. Architectural Design and Requirements Allocation.

4. Conflict resolution (Requirements Negotiation).

Requirement Verification and Validation

Requirement validation checks the specification to ensure that all product requirements are unambiguously defined; that all inconsistencies and errors are discovered and corrected; and that the product will meet all standards defined for the: usability, safety, quality etc.

The primary mechanism for requirement validation is a formal technical review. The review team includes engineers, customers, and other stakeholders who are checking product specification for content errors, areas that need clarification, insufficient information, inconsistencies (a major problem when making large products or systems), conflicting demands, or unrealistic requirements (which cannot be achieved).

Although requirement validation can be done in order to uncover potential errors, it is useful to check each requirement according to a predefined list of questions. The following questions are only a small part of what can be asked:

• Are the requirements clearly stated? Can they be misinterpreted?

• Are all the aspects of the product operation (functioning) covered?

• Is the source of the request identified (e.g. person, regulation, document)? Has the final form of the requirement been verified from the original source?

• Is the requirement quantified?

• What other requirements are associated with this requirement? Are they clearly stated using a reference matrix or other mechanism?

• Does the requirement affect domain restrictions?

• Can the requirement be tested? If it can, can we determine tests (so-called validation criteria) for checking the requirement?

• Can the requirement be tracked in any product that will be created?

Product Requirements Management and Tracking

It was stated above that the product requirements are changing and that there might be a need to change requirements throughout the product lifecycle. Requirement management is a set of activities that helps the project team identify, control, and track requirements and their changes at any point in the product's life. Also in this step - requirements prioritization and re-ordering can be done.

The requirements management begins with identification. Each requirement is assigned a unique identifier of the following form:

<type requirement> <requirement Id>

where < type requirement> can receive these possible values: F = functional requirement, B = behavioral requirement, I = input requirement, O = output requirement etc. Thus, the requirement identified by F09 denotes a function requirement number 9.

Once the requirements have been identified, monitoring (tracking) tables are developed. Each tracking table links specific requirements to one or more aspects of the product or the environment. Some of the many tracking charts are the following:

• Properties Tracking Table - displays how the requirements relate to the visible features of the product.
• Source (reason) tracking table - identifies the source of each requirement.
• Dependency Tracking Table - indicates how the requirements are related to each other.
• Subsystem Tracking Table - categorizes requirements according to the subsystems they belong to.

Product Requirements Documentation

After the gathering and the analysis of the product requirements - the product analyst and the project team should specify all product requirements. Under the requirements specification - there should be a composition (drafting) of a Product Requirements Document (PRD).

The product requirements document is comprised of: full product’s overview, the product features, working environment etc. It is not solely dedicated to the product’s functions and features, but it should list all functional and non-functional requirements (such as usability, safety, reliability, etc.). While writing this document - we must consider the following aspects of the product:

• Define the main product principles (e.g. it should be reliable and ease of use).
• Define the product’s purposes, i.e. the business values that it will bring for your customers (ease of use, cheap price, new features).
• Define your clients / customers, your competition, and your product development team.
• Define the goals of the product, and tasks that can be fulfilled by using the product.
• Define the different user profiles, e.g. young adults, elderly people, wide audience etc.

The PRD document should be written in clear and concise style, so the product developer will have a clear understanding about the function of the device, and can jump straight into the design.

Product Requirement Types

There are particular types of requirements that each product should fulfill and here we list the most relevant ones.

Functionality

            Each product is developed with its main purposes (goals). For example - the cars are designed to take us to the destination by driving, with certain technical characteristics, exterior and interior features etc. The product’s functional requirements should include all technical details in order to provide its uninterrupted functionality.

Quality

Quality is any element (feature), measureable or not, that gives things values beyond their functionality and features. Typical quality requirements include: reliability of the product, consistency, durability, availability, customer experience, look and feel, performance, maintainability, materials / ingredients etc.

Usability

            Usability requirements are created to ensure that the product will be easy to use. Usability is a broad concept, but it can be split into more elementary ones - like intuitive and easy to learn, so the users are able to flow through the tasks without being interrupted. Also - they should increase the productivity and performance of the user while using the product.

Reliability

            Reliability is one of the most important non-functional (quality) requirements. Reliability is measured as time to failure, probability of failure and failure-free operation. It also defines the mean time to repair and between repairs, coefficient of availability and unavailability, failure rate etc.

Safety

            Safety is often introduced as requirement in order to avoid, or reduce potential risks. In physical products (items) - safety relates to well-being, health and life protection of the users, while in the IT systems - it refers to protection of user’s personal data (e.g. credit card number etc.).

Packaging

            Packaging requirement refers to the product packaging and its purpose is to protect the product for transport damages, and also for marketing (design) purposes. Packaging requirements are subject to regulations in all countries worldwide. For example, European Union has introduced Packaging Regulations Directive in 1998, and it must be obeyed in all EU countries. It starts with massive containers, dangerous materials, chemicals and also includes food products and small bags.

References

1. S. Robertson and J. Robertson, Mastering the Requirements Process, Addison-Wesley, 2012.
2. Ian F. Alexander, L. Beus-Djukic, Discovering Requirements: How to specify Products and Services, Wiley, 2009.
3. I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley & Sons, 1997.
4. R.H. Thayer and M. Dorfman, eds., Product requirements Engineering, IEEE Computer Society Press, 1997, pp. 176-205, 389-404.
5. R.R. Young, Effective Requirements Practices, Addison-Wesley, 2001.

2019-11-11 Requirements.com All about Requirements 2020-09-20 Morgan Masters What are Product Requirements?