Software Engineering, Lecture notes of Introduction to Software Engineering

Download Software Engineering and more Lecture notes Introduction to Software Engineering in PDF only on Docsity!

REQUIREMENTS ELICITATION

LECTURE NOTE 3

DEPARTMENT OF SOFTWARE & CYBER SECURITY

ALQALAM UNIVERSITY KATSINA

Requirements elicitation is the process of gathering and defining the requirements for a software system. The goal of requirements elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of the user’s needs and requirements. Requirement Elicitation is the process of investigating and learning about a system's requirements from users, clients, and other stakeholders. Requirements elicitation in software engineering is perhaps the most difficult, most error-prone, and most communication-intensive software development. Features of Requirement Elicitation

1. Requirement Elicitation can be successful only through an effective customer- developer partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and is typically performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the organization, including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and well- defined requirements that serve as the basis for the design and development of the software system.
6. Requirements elicitation is difficult because just questioning users and customers about system needs may not collect all relevant requirements, particularly for safety and dependability.

Requirements Elicitation Activities

1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development. **Requirements Elicitation Methods
6. Interviews** The objective of conducting an interview is to understand the customer's expectations of the software. It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. Interviews may be open-ended or structured.
7. In open-ended interviews, there is no pre-set agenda. Context-free questions may be asked to understand the problem. 2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview. 2. Brainstorming Brainstorming is a method used to solve problems and generate innovative ideas through creative thinking. This technique involves bringing together individuals or groups to generate a wide range of solutions or new concepts that can help a brand or project stand out. By encouraging open and unrestricted thinking, brainstorming creates an environment where new and creative ideas can emerge and be explored.

During a brainstorming session , participants are encouraged to think freely and propose any idea that comes to mind, without fear of criticism or judgment. This approach helps in uncovering unique solutions that might not be immediately obvious. Typically, brainstorming is conducted in a team setting to leverage the diverse perspectives and ideas of different participants. However, it can also be effectively done by an individual. Importance of Brainstorming Creates Unique Identity: Brainstorming helps brands develop a distinct identity that sets them apart from competitors, giving them a competitive advantage. Effective Problem-Solving: When a problem is too challenging for an individual, a team can combine their unique perspectives to find the best solution. Encourages Diverse Approaches: The flexibility of brainstorming allows for various approaches and ideas, leading to innovative and unique solutions. Enhances Team Collaboration: Fosters teamwork and collective thinking, improving overall team dynamics and productivity. Promotes Innovation: Encourages out-of-the-box thinking, driving fresh and creative ideas that can propel the brand forward. Improves Decision Making:

potential problems and outcomes, allowing the team to avoid specific obstacles and improve the overall process. c. Rapid Ideation Brainstorming Here, everyone in the team writes down their first thoughts privately. Unlike random brainstorming, where ideas are spoken aloud, this method ensures that each member has the privacy to jot down their thoughts, leading to more unique and creative solutions. This can provide multiple perspectives on the problem. d. SCAMPER Brainstorming SCAMPER stands for Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. This technique involves looking at a problem from various angles to generate a variety of ideas. Each idea is tested and refined through a series of questions, resulting in a well-rounded solution. e. Star-bursting Brainstorming In this technique, team members ask questions instead of presenting ideas. This helps in identifying potential issues and exploring different perspectives. By breaking down the problem into multiple questions, it provides a step-by-step solution and a thorough understanding of the problem.

3. Facilitated Application Specification Technique Its objective is to bridge the expectation gap - the difference between what the developers think they are supposed to build and what customers think they are going to get. A team-oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are: i. Part of the environment that surrounds the system.

ii. Produced by the system. iii. Used by the system. Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, the team is divided into smaller sub-teams to develop mini- specifications and finally, a draft of specifications is written down using all the inputs from the meeting.

4. Quality Function Deployment In this technique customer satisfaction is of prime concern, hence it emphasizes the requirements that are valuable to the customer. 3 types of requirements are identified:  Normal requirements: In this the objective and goals of the proposed software are discussed with the customer. For example - normal requirements for a result management system may be entry of marks, calculation of results, etc.  Expected requirements: These requirements are so obvious that the customer need not explicitly state them. Example - protection from unauthorized access.  Exciting requirements: It includes features that are beyond customer's expectations and prove to be very satisfying when present. For example - when unauthorized access is detected, it should back up and shut down all processes. 5. Use Case Approach Use Case technique combines text and pictures to provide a better understanding of the requirements. The use cases describe the 'what’, of a system and not 'how’. Hence, they only give a functional view of the system. The components of the use case design include three major things - Actor, use cases, and use case diagram.

2. Gather Requirements Once you've identified the stakeholders, the next step is to gather their requirements. This means understanding what they need from the system or product. Requirements can be functional (what the system should do) or non-functional (how it should perform). You can use different methods like interviews, surveys, or group discussions to collect all these needs.
3. Prioritize Requirements Not all requirements are equal in terms of importance. After gathering them, you’ll need to prioritize which ones should be addressed first. This helps ensure that the most important features are built into the system first, especially when resources (like time and budget) are limited. A common approach is to categorize them into things that are "Must-have," "Should-have," "Could-have," and "Won’t-have."
4. Categorize Feasibility After prioritizing, the next step is to assess how realistic each requirement is. You’ll categorize them into three groups:  Achievable : These are requirements that are realistic and can be done within the available resources (time, budget, etc.).  Deferred : These requirements are important but can’t be implemented in this phase. They’ll be put on hold for now with a clear reason why.  Impossible : These requirements can't be done because of technical or other limitations, and they should be removed from the list.