What are the types of Requirements?

There are broadly two types of requirements: System Requirements – System requirements can be called the expanded version of the user requirements. System requirements act as the commencement point for any new system design. These requirements are a detailed description of the user requirements the system must satisfy. User Requirements – User requirement is a combination of functional and non-functional requirements. These user requirements must be designed in such a way that they are easily understandable by users who do not have any sort of technical knowledge. Hence, they must be written in natural language using simple tables, forms, and diagrams. Also, make sure the document does not have details on system design, software, or formal notations.

The Most Complete Guide to Requirements Management and Traceability

Requirements Engineering

In order to produce a quality product, it is important to have accurate requirements from the customer. This begins with the requirements engineering process, which can be divided into five steps: gathering requirements, documenting requirements, analyzing and verifying requirements, managing changes to requirements, and closing the requirement phase. In this blog post, we will discuss each of these steps in detail and show how they help to produce a high-quality product.

What are Requirements and Requirements Engineering?

There are two terms here, “Requirement” and “Requirements Engineering”. A requirement is precisely defined as a condition or a capability that a user needs to solve a problem or achieve a goal. In other words, requirements are conditions or capabilities that must be met or possessed by a system in order to satisfy a contract, standards, specifications, and other formal documentation.

Requirements Engineering is defined as the process of defining, documenting, and maintaining the requirements. The discipline includes all the techniques, methods, and procedures related to the definition and management of users’ needs related to the system being studied.

All-in-all, Requirements Engineering is a set of activities that are concerned with identifying and communicating the purpose of a system or software and the context in which it will be used.

Therefore, Requirements Engineering acts as a bridge between the real-world needs of the users, customers, and other constituencies that are affected by software or system and the capabilities and opportunities afforded by the software-intensive technologies.

What are the principles of Requirements Engineering?

The two basic principles of Requirements Engineering are the problem and solution of the requirement engineering.

It is useful to separate the problem and the solution when gathering the requirements.
This separation can never be achieved fully in practical life.

Requirement engineering is about building the right system. Basically, it is about building a system that fits the user’s problems. This is a problem-oriented part. It is basically about designing, verifying, implementing, and maintaining the system that is created to ensure that it fits the user’s problems. This is the solution-oriented part.

Requirements Engineering Process

There are a few activities that we face when working with the requirements. In the Requirements Engineering cycle, there are five main activities, namely,

Requirements Elicitation – this is the process of reviewing, documenting, and understanding the stakeholders and user needs and constraints for the season. Users need domain information, existing system information, regulations, standards, etc. Based on this information, we elicitate the requirements. After this, we move to requirements analysis and negotiation.
Requirements Analysis and Negotiation – analysis is the process of refining the user needs and constraints on the basis of gathered and elicitated information. Then, we move to the documentation activity.
Requirements Documentation/Specification – after getting the requirement specifications, we move to the documentation part. We document the user needs and constraints clearly and precisely.
Requirements Validation – finally, in the validation activity, we insert that the season requirements are complete, concise, and clear.
Requirements Management – Requirements management is a way of collecting, analyzing, refining, and prioritizing all the products or requirements, in the development phase.

When we finalize these five activities, we repeat them time and again until we get a set of agreed requirement documents that are formal specifications.

Requirements Elicitation

As we discussed before, requirements elicitation is the process of reviewing, documenting, and understanding the user needs and constraints for the season. Users need domain information, existing system information, regulations, standards, etc. Based on this information, we elicitate the requirements. We use the word ‘Elicitation’ instead of ‘Gathering’ because gathering interprets as just picking up the requirements and putting them into a document. On the other hand, elicitation is a more complex process. You don’t get the requirements as easily as you get while gathering. It requires extra effort.

During elicitation, you ask the user or customer:

What are their objectives for the system/product?
What is to be accomplished?
How do the seasonal needs fit into the needs of the business?
How is the seasonal product/system to be used on a regular basis?

It sounds simple, but it is quite not!

According to Ian Sommerville and Pete Sawyer, Requirements Elicitation is the process of discovering the requirements for a system by communicating with the customers, system users, and others who have a stake in the system development. Since ‘gathering’ or ‘capturing’ doesn’t sound very accurate, we use the word ‘elicitation’.

“ I know that you believe that you understood what you think I said, but I am not sure you realize that what you heard is not what I meant ” — Robert McCloskey, State Department Spokesman.

What he meant by his quote is sometimes people misunderstand what other people say to them. Sometimes what they say is not what they have in mind. Eventually, this whole miscommunication led to the misdoing of requirement gathering.

What are the Steps during Elicitation?

STEP – 1

Source of Requirements:

There are various sources from which we can gather our requirements. Some of them include:

Stakeholders
Existing systems
Existing documents
Competitors and other similar systems
Interfaces with the systems
Laws and standards
Company policies

STEP – 2

Set the Project Scope:

The following steps can be followed in order to set up the scope of the project:

Find out why the project is initiated
Property defines the key objectives to be achieved through the project
Draw out a statement of work for the project that will help you appropriately breakdown the work among the team members
List up the items to be delivered at the end of the project
Select the key milestones to be achieved
Identify the major constraints and limitations the team can possibly face during the development of the project
Create a list of items that are excluded from the list of scope items
Get the stakeholders to sign the scope document as it provides a confirmation that they are informed about the project and its contents.

STEP – 3

Elicitation Tasks:

Planning elicitation:

Why should this particular requirement be implemented and the benefits it will provide? – Objectives of the project
Who will be responsible for creating it? – Professionals for elicitation efforts
When will be the best time to implement it? – Schedule an estimate sources
How will it be implemented? – Strategies and Procedures
And the risks

During elicitation:

Confirm the viability of the project. Find out if the project is really worth it or not
Understand the problems and issues from a stakeholder’s perspective
Extract the essence of the requirements stated by the stakeholders
Find out better ways to do the work for the users
Innovation is the key to victory

Following elicitation:

Analyze the results in order to properly understand the gathered information
Negotiate a coherent set of requirements acceptable to the stakeholders. Establish the priorities as well
Record the results in the specifications of the requirements

Elicitation is an incremental process. You must repeat this step as much as required.

Now, select an appropriate set of techniques for each source of requirements. Determine this technique based on the source, the system to be developed, and so on. Remember that not all techniques can be used in every situation.

STEP – 4

Documentation of the Requirements –

The last step in the elicitation process is to finalize all the requirements in the form of a document. This document mainly contains the notes and user requirements. And these requirements are going to be incomplete, inconsistent, and unorganized. But this is just the starting point. The document can be edited every now and then, and things can be added or altered.

Requirements Analysis and Negotiation

Requirement analysis is typically a procedure of analyzing, validating, and aligning the requirements documented during the phase of Requirement Elicitation. In other words, requirement analysis is a process of studying and understanding the requirements stated by the stakeholders. Requirement analysis requires frequent communication with the stakeholders and end-users in order to define the expectations, solve the conflicts, and finally, document the key requirements. The solutions may involve issues like:

Different kinds of set-up for the workflow in the company
Setting up a new system that is to be used from now onwards, etc.

One thing to be kept in mind is that Requirement Elicitation and Requirement Analysis work together. They two feed each other. When we start gathering the requirements, we elicitate them and analyze them at the same time as well.

Objectives of Requirement Analysis

The first and foremost objective of requirement analysis is to understand the requirements and needs of the users
When we use different sources to gather the requirements, there may be some conflicts between them. Requirement Analysis is about finding those conflicts among the requirements stated by the users and resolving them.
Negotiate the requirements with the users and stakeholders. There is no way our system can meet all the requirements in the exact way they are explained by the stakeholders and users.
We will have to negotiate and prioritize the requirements. Some requirements may not be big for us but they can be pretty important for the end-users. To understand them, we have to analyze and prioritize the requirements of the stakeholders.
We must elaborate on the requirements stated by the users and system. This helps while documenting the requirements in the requirement specifications. Also, this helps the developers develop, design, and test better as they understand the requirements in an elaborated and better way.
We must classify the requirements into various different categories and sub-categories and further allocate those requirements to different sub-systems.
We must also evaluate the requirements for the quality that is desired by the organization.
Lastly, we must ensure not to miss anything important.

Requirements Documentation/Specification

Requirement specification, also known as documentation, is a process of jotting down all the system and user requirements in the form of a document. These requirements must be clear, complete, comprehensive, and consistent.

During the capturing activity, we gather all the requirements from various sources. During the analysis and negotiation activities, we analyze and understand those requirements. Now, we must prepare a formal document explaining those requirements. That is what the requirement specification is. To be precise, it is the process of documenting all the user and system needs and constraints in a clear and accurate manner.

Method For Documenting Requirements

EARS would be an effective methodology here. It stands for Easy Approach to Requirements Syntax. In this method, we write clear, concise, and understandable language. This improves the whole requirements engineering workflow and simplifies the work by making things pretty easy to understand.

To achieve this, here are some principles that must be kept in mind while writing the requirements. They involve:

Each requirement must be in the form of a complete sentence. No bullet, acronyms, abbreviations, or buzzwords should be used. Try to make short, direct, and complete sentences.

Make sure that each requirement has a proper subject, predicate, and verb. The subject would be the user type or the system that we are talking about. The predicate would be the conditions or actions or desired results we expect. We must use words like ‘shall’, ‘will’, and ‘must’ to express some kind of necessity, and words like ‘may’ to express optionality in the requirement.

Each requirement must efficiently explain the end result we desire from the system.

Also, the requirement must describe the quality we expect from the system. It helps when we measure the end result and see if the requirement is properly implemented or not.

Requirements Validation

Validation is a process used for checking if the system is up to the mark or not. Validation answers the question, “Are we building the right system?” It is about testing and validating the system and seeing if the system we built is right or not and if it meets the customer’s expectations or not. Various methods that are used to validate the system include black-box testing, white-box testing, integration testing, and unit testing. Validation always comes after verification.

Verification is a process used for checking if the system achieves its expected goals or not without any bugs or issues. Verification answers the question, “Are we building the product right?” It is about testing and verifying if the system meets its requirements without any problems. Various methods that are used to verify the system include reviews, walkthroughs, inspections, and desk checkings. Verification is a manual process done before validation.

Validation Techniques

There are various techniques that can be used to validate the requirements. They include:

Checks – While checking the requirements, we proofread the requirements documents to ensure that no elicitation notes are missed out. During these checks, we also check the traceability level between all the requirements. For this, the creation of a traceability matrix is required. This matrix ensures that all the requirements are being considered seriously and everything that is specified is justified. We also check the format of requirements during these checks. We see if the requirements are clear and well-written or not.
Prototyping – This is a way of building a model or simulation of the system that is to be built by the developers. This is a very popular technique for requirements validation among stakeholders and users as it helps them to easily identify the problems. We can just reach out to the users and stakeholders and get their feedback.
Test Design – During test designing, we follow a small procedure where we first finalize the testing team, then build a few testing scenarios. Functional tests can be derived from the requirements specification itself where each requirement has an associated test. On the contrary, the non-functional requirements are hard to test as each test has to be traced back to its requirement. The aim of this is to figure out the errors in the specification or the details that are missed out.
Requirements Review – During requirement review, a group of knowledgeable people analyze the requirements in a structured and detailed manner and identify the potential problems. After that, they gather up to discuss the issues and figure out a way to address the issues. A checklist is prepared consisting of various standards and the reviewers check the boxes to provide a formal review. After that, a final approval sign-off is done.

Requirements Management

According to Ian Sommerville, “Requirements management is the process of managing changing requirements during the requirements engineering process and system development.”

The major purpose of requirement management is to ensure clear, concise, and error-free requirements to the engineering team so that they can make sure to detect errors in the system and potentially reduce the project cost as well as risk.

Principal concerns of Requirements Management

There are some concerns about requirements management. They include:

Managing the changes in the agreed requirements
Managing the relationship between all the requirements
Managing the dependencies between the requirements documents that are produced during the system engineering process.

Types of Requirements

There are broadly two types of requirements:

System Requirements – System requirements can be called the expanded version of the user requirements. System requirements act as the commencement point for any new system design. These requirements are a detailed description of the user requirements the system must satisfy.
User Requirements – User requirement is a combination of functional and non-functional requirements. These user requirements must be designed in such a way that they are easily understandable by users who do not have any sort of technical knowledge. Hence, they must be written in natural language using simple tables, forms, and diagrams. Also, make sure the document does not have details on system design, software, or formal notations.

Visure Requirements ALM Platform

Visure Requirements ALM Platform is one of the most trusted modern ALM platforms that specialize in requirements management for organizations of all sizes across the globe.

It’s a must-have tool for teams building complex products, systems, and software, which require end-to-end traceability from conception to testing and deployment, all the way to source code, along with standard certification compliance.

Visure Requirements is a proven flexible and complete Requirements Engineering tool, capable of streamlining the software requirements process as part of the hardware and mechanical definition process. Visure Requirements aid effective project collaboration and increase software quality through Requirements capture, analysis, specification, validation and verification, management, and reuse.

Visure Solutions can help overcome the challenges of product and embedded development,

Improve the quality of definition as an essential first step in boosting software quality
Regain control of development and regulatory processes
Standardize and enforce the requirements definition across the organization
Support effective reuse of requirements across project teams and product lines and variants
Formalize a common requirements specification structure, and handle changes throughout the lifecycle
Achieve full traceability through all elements, from requirements to testing to execution
Track all aspects of development with ease, from risk calculation graphics to orphan requirements reports
Avoid pitfalls and mitigate risk at all levels, from writing better requirements and prioritizing needs to changing impact analysis capabilities.

Benefits of using Visure Requirements for product and embedded development

Certification support for industry standards, such as DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA and GAMP5
One complete platform for all requirement-related activities
Process enforcement through a flexible solution that supports different process models including Automotive SPICE, CMMI, V-model, Agile, and ad hoc
Improved team communication and collaboration through role-based capabilities
Support for better quality products, and reduced software defects.

Companies who actively use Visure, claim a clear impact with on-time project deliveries, project compliance, and a decrease in development costs and cycle times.

Conclusion

Requirements engineering is a critical process for ensuring that the products and systems we build are what our customers need. The five-step process outlined in this article can help you get your project off to a good start by getting feedback from stakeholders early and often and using that feedback to generate clear and concise requirements. If you’re looking for a tool to help you manage your requirements engineering process, Visure Requirements ALM Platform can help. Request your free 30-day trial today to see how our platform can make your next project a success.

Don’t forget to share this post!