Process of Requirements Engineering: Step by Step
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 Requirement and Requirement Engineering?
There are two terms here, “Requirement” and “Requirements Engineering”. A requirement is p recisely 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.
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:
- 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
- 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
- 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
- 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.
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.
Some tips for writing requirements:
Below are some tips that can help you improve your writing for requirements.
- Form short and meaningful sentences using active voice.
- Read the requirements from the developer’s and tester’s point of view to understand the precision of the requirements.
- Do not use ‘and/or’ that composes multiple requirements. Try to make single sentences that can be unitarily tested.
- Ensure a similar level of consistency and uniformity in explaining the requirements.
- Avoid repetition as much as possible because it may ease up the reading but increase maintenance.
- Ensure that the requirement is traceable.
Characteristics of a Requirement Document:
- A requirement document effectively describes all the requirements of the system to be designed.
- All requirements described in this document are practical and verifiable.
- Contractors and suppliers sign off the contracts on the basis of this requirement document.
- The requirement document is a detailed description of the notes taken during requirement elicitation.
- Follows the IEEE 830 – SRS standards.
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.
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.
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.
Functional Vs Non-Functional Requirements:
Functional Requirements, as the name suggests, describe the functions of the system to be designed. It is a description of what the system will be and how it will function to satisfy user needs. They provide a clear description of how the system is supposed to respond to a particular command, the features, and what the users expect.
Non-Functional Requirements explain the limitations and constraints of the system to be designed. These requirements do not have any impact on the functionality of the application. Furthermore, there is a common practice of sub-classifying the non-functional requirements into various categories like:
- User Interface
Sub-classifying the non-functional requirements is a good practice. It helps when creating a checklist of the requirements that are to be met in the system to be designed.
Non-functional requirements are as important as functional requirements are. If functional requirements specify what a system should do, non-functional requirements describe how the system will do it. For example, the new application shall provide us with the final list of all connected users. That is a part of functional requirements. If the requirement says that the system would only work on a Windows and a Linux system, that would be a part of non-functional requirements.
The only difference between the two is that the system can not function without satisfying all the functional requirements. On the other hand, the system will give you the desired outcome even when it does not satisfy the non-functional requirements.
Why Choose 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.
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.