Requirement Engineering Process
It is a four step process, which includes –
2. Requirement Gathering If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
3. Software Requirement Specification (SRS) SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and used by the software development team. SRS should come up with the following features: ●User Requirements are expressed in natural language. ●Technical requirements are expressed in structured language, which is used inside the organization. ●Design description should be written in Pseudo code. ●Format of Forms and GUI screen prints. ●Conditional and mathematical notations for DFDs etc.
4.Software Requirement Validation After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements inaccurately. This results in huge increasein cost if not nipped in the bud.
Requirements can be checked against following conditions - ■If they can be practically implemented. ■If they are valid and as per functionality and domain of software. ■If there are any ambiguities. ■If they are complete. ■If they can be demonstrated.
It is a four step process, which includes –
- Feasibility Study
- Requirement Gathering
- Software Requirement Specification
- Software Requirement Validation
2. Requirement Gathering If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
3. Software Requirement Specification (SRS) SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and used by the software development team. SRS should come up with the following features: ●User Requirements are expressed in natural language. ●Technical requirements are expressed in structured language, which is used inside the organization. ●Design description should be written in Pseudo code. ●Format of Forms and GUI screen prints. ●Conditional and mathematical notations for DFDs etc.
4.Software Requirement Validation After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements inaccurately. This results in huge increasein cost if not nipped in the bud.
Requirements can be checked against following conditions - ■If they can be practically implemented. ■If they are valid and as per functionality and domain of software. ■If there are any ambiguities. ■If they are complete. ■If they can be demonstrated.
