Requirement Engineering Concepts
Requirement Engineering
Software Engineering | Requirements Engineering Process
Software Engineering | Classification of Software Requirements
How to write a good SRS for your Project
Software Engineering | Quality Characteristics of a good SRS
Software Engineering | Requirements Elicitation
Software Engineering | Challenges in eliciting requirements
Functional vs Non Functional Requirements
Q1. What is requirement engineering ?
Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system.
Q2. What are different activities under requirement engineering?
- Requirements elicitation
- Requirements specification
- Requirements verification and validation
- Requirements management
What is Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and requirements. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.
What are different techniques for requirement elicitation ?
The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.
What is Requirements specification ?
This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
Explain requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
What is the main steps for verification and validation ?
The main steps for this process include:
The requirements should be consistent with all the other requirements i.e no two requirements should conflict with each other.
The requirements should be complete in every sense.
The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
What is Requirements management ?
Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process.
Risk Factors while requirement analysis–
1. Incomplete requirements
2. Inaccurate requirements
3. Unclear requirements
4. Ignoring non functional requirements
5. Conflicting user requirements
6. Gold plating
7. Unclear description of real operating environment
Incomplete requirements:
In 60% of the cases users are unable to state all requirements in the beginning. Therefore requirements have the most dynamic nature in the complete SDLC Process.
If any of the user needs, constraints or other functional/non functional requirements are not covered then the requirement set is said to be incomplete.
Inaccurate requirements: If the requirement set do not reflect real user needs then in that case requirements are said to be inaccurate.
Unclear requirements: Often in the process of SDLC there exists a communication gap between users and developers. This ultimately affects the requirement set. If the requirements stated by users are not understandable by analyst and developers then these requirements are said to be unclear.
Ignoring non functional requirements: Sometimes developers and analyst ignore the fact that non functional requirements hold equal importance as functional requirements. In this confusion they focus on delivering what system should do rather than how system should be like scalability, maintainability, testability etc.
-> Scalability
-> Maintainability
-> Testability
Conflicting user requirements: Multiple users in a system may have different requirements. If not listed and analysed carefully, this may lead to inconsistency in the requirements.
Gold plating: It is very important to list out all requirements in the beginning. Adding requirements later during the development may lead to threats in the system. Gold plating is nothing but adding extra functionality to the system that were not considered earlier. Thus inviting threats and making the system vulnerable.
Unclear description of real operating environment: Insufficient knowledge of real operating environment leads to certain missed vulnerabilities thus threats remain undetected until later stage of software development life cycle.
Risk Factors during Design Phase–
Risk Factors –
1. Complex system
2. Complicated design
3. Large size components
4. Unavailability of expertise for reusability
5. Less reusable components
Complex system: If the system to be developed is very large and complex then it will create problems for developers. as developers will get confused and will not be able to make out from where to start and how to decompose such large and complex system into components.
Complicated design: For a large complex system it may be possible due to confusion and lack of enough skills, developers may create a complicated design, which will be difficult to implement.
Large size components: In case of large size components that are further decomposable into sub components, may suffer difficulty in implementation and also poses difficulty for assigning functions to these components.
Unavailability of expertise for reusability: Lack of proper expertise to determine the components that can be reused pose a serious risk to project. As developing components from scratch takes lot of time in comparison to reusing the components. Thus delaying the projection completion.
Less reusable components: Incorrect estimation of reusable components during analysis phase leads to two serious risk to the project- first delay in project completion and second is budget over run. Developers will be surprised to see that the percentage of the code that was considered ready, needs to be rewritten from scratch and it will eventually make project budget over run.
Software Design
https://www.geeksforgeeks.org/basic-principles-of-good-software-engineering-approach/?ref=rp
ReplyDeletehttps://www.geeksforgeeks.org/principles-of-software-design/
ReplyDeletehttps://adevait.com/software/solid-design-principles-the-guide-to-becoming-better-developers
ReplyDelete