What is requirement engineering?
What does software requirements engineering mean? While it is a crucial phase in software engineering, we often tend to misunderstand it. Software requirements engineering is the first phase before any of the actual designing, coding, testing, or maintenance takes place.
To start with the software design, we create an initial requirement specification document called
What is requirement engineering?
Requirement engineering is the early part of software engineering. In software engineering, we start eliciting the stakeholders' requirements and move on to software design. Then we implement, code, test, integrate, and eventually deploy and maintain. This takes more effort because people usually don't take requirement engineering seriously. Having this document at an early stage saves time and cost, as when it reaches the end and the requirements don't match those of the stakeholders, it becomes challenging to make changes.
Activities
Requirement engineering consists of the following activities:
Feasibility study
A feasibility study is a report made before accepting a project. It consists of an estimate of whether the project can be completed using the current technologies with the given budget. This study leads to a decision to either go with the project or to leave that project.
Requirements analysis
This involves frequent discussions with the stakeholders to see if there are any existing systems through research and observation. Here are some techniques used to capture requirements:
Interviews: These usually take place with the stakeholders and end users. This will help in gathering specifications with the requirements. Most of the time, the client has a vague concept of the requirements, and the best way to do this efficiently is to allow them time to prepare before the interview.
Prototyping: A prototype is a dummy of the final product. This helps in the project's feasibility, scope, and issues.
Focus groups: This group interview usually involves 6 to 10 people. This is a cost-effective research approach for obtaining qualitative feedback regarding the product.
Requirements specification
This is where we write down the information we gathered using the techniques discussed earlier. There are usually two types of requirements mentioned in this document: user and system requirements.
Requirements validation
As the name suggests, this activity is mainly validating the requirements and making sure they're realistic and consistent.
User and system requirements
User requirements: These are requirements written for the customers. These are usually written in plain English without any technical details.
System requirements: These are written for developers and contain functional and non-functional requirements. These are extensive and detailed.
Functional and non-functional requirements
Functional requirements: These describe the functions that the system must perform. They're specified by the user and are necessary to be incorporated into the system. Let's take the example of a learning management system. We have three actors—Admin, teacher, and student. The functional requirements of a student will be the following:
The student should be able to log in.
The student should be able to view previous and current results.
The student should be able to view courses.
The student should be able to register for courses.
The student should be able to view fee information.
Non-functional requirements: These are requirements directly concerned with the functions that the system must perform. These are not mandatory, but they will increase the system's overall efficiency. Here are a few examples of non-functional requirements:
Maintainability
Reliability
Scalability
Conclusion
Requirement engineering is critical to satisfying the clients and ensuring the project is a success. Being aware of the potential issues can save us time and cost and resources. The developers will also have a clear understanding of the requirements, which will help in the overall efficiency of the product.
Free Resources
