|
Requirement Engineering
part1
In reality, Quality Assurance is activity which is performed throughout the Software Development Life Cycle (SDLC). Although many organizations don’t include Quality Assurance at early stages of SDLC as a result, they have to spend some extra time, cost and resources during Software Testing to ensure the quality of software product.
Many Experts and Analysts consider Requirements engineering as one of the most crucial stages in SDLC as it provides grounds for software development. Rest of all processes of SDLC depends on the results of Requirement Engineering. Without knowing the valid requirements it is impossible to create a valid design for software application and without a valid design an application can’t fulfill all the needs of client. So we can say that Requirements engineering is the initial part of a software development process and all later stages of the development are influenced by the requirements. 1. Requirment Engineeering
Requirement Engineer (RE) is a process, in which stakeholders and their needs are identified. 1.1 Imprtance of REquirement Engineering
1) knowing Stakholders Needs
2) Controlling Cost of software project
3) Saving time
4) Making success and Failure Criteria of software.
2. Requirement Engineering Process
2.1 Requirement Elicitation
Requirements elicitation is the process that identifies the sources of requirements for a new system and after identifying it obtains requirements from those sources. Requirements elicitation is a crucial part of the Requirements Engineering. Requirements elicitation is a very challenging activity that requires focus and skill from the business analyst. For Requirement Elicitation, a business analyst need to have knowledge of Domain, Regulation, Standards and other constrains. If a business analyst doesn’t have prior knowledge then quality of requirement will suffer.
1) Requirement Elicitation vs. Requirement Gathering
Most of the times, terms Requirement gathering and Requirement Elicitation are considered as a same things but Actually Requirement gathering is a limit process in which requirements are obtained by asking User/Customer “What he wants?” but Requirement Elicitation has broader scope as good requirements can’t be gathered by customers. Requirement Elicitation involves many activities to identify all the stack holders, and all the requirement of all the stack holders. Purpose of requirement elicitation is to identify and resolve the conflict in requirements of different stakeholders.
2) Type of Requirement Elicitation
a. Greenfield Engineering
In this type of Requirement Elicitation, a new system is build. No Prior system exists so requirements are extracted from Client and End User. This type of engineering is dependent on User needs.
b. Re-Engineering
In this type of requirement elicitation, an existing system is re-design and re-implemented using a newer technology. This type of engineering is technology oriented.
c. Interface Engineering
In this type of requirement elicitation, system and functionally of system remains same but environment is modified. This type of engineering is dependent on new market needs.
3) Requirement Elicitation Techniques
In requirement Elicitation the following activities are performed:
- Identify actors - Identify scenarios - Identify use cases - Identify relationships among use cases - Refine use cases - Identify nonfunctional requirements - Identify participating objects For performing the above stated activities different Requirement Elicitation Techniques are being used. Some of requirement elicitation techniques are: - Brainstorming: Brainstorming sessions are used to let the stakeholders come up with creative ideas or new approaches to a problem.
- .Workshops: Workshops are facilitated meetings with multiple stakeholders. - Interviewing: Interviews are one-on-one meetings where the business analyst asks questions to get information from the stakeholders about their needs and expectations. - Surveys: Surveys are used to gather information anonymously from the stakeholders. This elicitation technique is good when stakeholders are too many. - .Documentation Review: This is the process of obtaining requirements from written documentation such as manuals. - Prototyping: This is the use of partially finished versions of the software that have been created to help validate requirements. Most of the time a prototype contains no or less functionality. - Focus Groups: Focus Groups are group interviews with potential and/or actual users where the business analyst raises issues and questions to obtain information from the stakeholders. - Observation: Observation is when the business analyst watches the users performing their daily tasks and asks questions about the tasks and work. This technique gives you the advantage of actually seeing what the users do. 2.2 Requirement Analysis and Negotiation
1) Requirement Analysis is a process in which different requirement are analyzed in terms of cost. In this process, dependencies among different requirement are identified. Moreover requirement analysis is an initial step which helps in identifying how the application integrates with the business processes. In requirement analysis scope and limitations of software application are finalized.
2) Requirement Negotiation is a process starts with identification all the stakeholders. Aim of requirement negotiation is to resolve conflicts between different requirements. In this process all requirements are discussed with different stakeholder and acceptance creation for every requirement is set and every requirement is prioritized.
3) Why Requirement Analysis and Negotiation is important:
Requirement Analysis and Negotiation is important for many reasons. Some of the reasons are given below:
- Avoiding (Scope, Cost, Schedule) Creeps: In Software Project Management terms a creep is regarded as an uncontrolled change. This uncontrolled change can have imparts on project scope, project cost and project schedule. As a result, a software project can drift away from target cost, target schedule and target scope. In most of the case, (scope, cost and schedule) creeps occur because of unrealistic requirements. So for avoiding these creeps Requirement Analysis and Negotiations is very important. With the help of proper requirement analysis and negotiation, needs of all stakeholders can be indentified and prioritize at the start of project. - Better Understanding of requirements: Reason behind most software project failures is unrealistic or poor requirements. Unrealistic and poor requirements always lead to a fail software product because every building needs proper bases if bases are weak then quality of building will suffer as well. Similarly for understanding the needs and requirements of all the users, we need to spend time on requirement analysis and negotiation. - Avoiding Conflicts (between stakeholders): It is a common observation that within an organization different stakeholders have different/conflicting requirements. Requirement Analysis and negotiation provides solution to this problem as well. In the process of requirement analysis and negotiation, requirements are prioritize and for conflicting requirement alternative ways are identified. - Understanding Customer Needs: Software is considered as a successful product if it satisfies the needs of customer (end user). Software can only satisfy customer needs when development and design team are aware with actual customer needs. For a healthy design and development process, requirements are negotiated with all the stakeholders. In this way, all the stakeholders get involved in requirement engineering process and it becomes easy to understand the need of all stakeholders. - Avoiding Ambiguous Requirements: When Requirements are gathered from requirement elicitation phase, it is possible that some ambiguous requirements may emerge along real requirements. For avoiding such requirements it is important to analyze every requirement. 4) Difficulties during Requirement Analysis and Negotiation: Many difficulties and problem emerge during the process of requirement analysis and negotiation. Some of the problems are given below:
- Confused Stakeholder: Sometime stakeholders get confused while explaining their requirements. This may lead the requirement engineering team to serious consequences. So Requirement Analysis should discuss the requirement of stakeholders in a very friendly way. So that needs of all stakeholders could be considered during software development. - Difference of Expression: Most of the times, stakeholders are non-technical individuals. So they will express their demands in a plain (real life) language. Requirement Analyst will have to understand that plain language and will have to extract the valid technical requirements. For this purpose requirement analyst should have strong communication skills. - Conflicting Requirements: During the requirement analysis and negotiation, it is possible that different group of people may have different requirements. These requirements can be conflicting as well. In case where conflicting requirement emerge the requirement analyst will have to act smartly and will have to modify the requirement so that it may entertain maximum number of stakeholders. - Organizational and Political Factors: Organizational and Political factors of an organization play an important role in requirements. So a requirement analyst should keep the impact of these factors in mind as well. - Change of Environment: During requirement analysis process, a new requirement may emerge and that new requirement may lead to a change in whole environment. In that case, Requirement Analyst must know how to deal with this situation. |
|
|
来自： hildaway > 《references》
