Requirements Elicitation in Software Engineering

"Understanding and gathering software requirements is a critical step in the software development process. This involves identifying, analyzing, documenting, and validating the needs and constraints of the project stakeholders. Effective requirements elicitation ensures that the final product meets the intended goals and user expectations. Various techniques such as interviews, surveys, workshops, and observations are used to elicit requirements, leading to successful project outcomes."

• Software Engineering
• Requirements Elicitation
• Stakeholders
• Validation
• Techniques

ailani Follow

Uploaded on Mar 26, 2024 | 2 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

Presentation Transcript

1. REQUIREMENTS ELICITATION Requirements Engineering 1

2. AGENDA Expectation gap Feasibility study Requirements elicitation Stakeholders and customers Requirements elicitation techniques 2

3. THE EXPECTATION GAP A RUDE SURPRISE TO EVERYONE Without adequate customer involvement, the inescapable outcome at the end of the project is an expectation gap, a gap between what customers really need and what developers deliver based on what they heard at the beginning of the project Requirements also get out of date because of changes that occur in the business, so ongoing interactions with customers are vital 3

4. FEASIBILITY STUDIES FEASIBILITY STUDIES A feasibility study decides whether the proposed system is worthwhile or not A short focused study that checks: If the system contributes to organizational objectives If the system can be engineered using current technology and within budget If the system can be integrated with other systems that are used 4

5. REQUIREMENTS ELICITATION The heart of requirements development is elicitation Elicitation is the process of identifying the needs and constraints of the various stakeholders for a software system Elicitation includes activities related to collecting, discovering, extracting, and defining requirements. Elicitation is used to discover business, user, functional, and nonfunctional requirements, along with other types of information. Requirements elicitation is perhaps the most challenging, critical, and communication-intensive aspect of software development. To facilitate clear communication, use the vocabulary of the business domain instead of forcing customers to understand technical jargon. 5

6. STAKEHOLDERS & CUSTOMERS A stakeholderis a person, group, or organization that is actively involved in a project, affected positively or negatively by its process or outcome, or can influence its process or outcome. Stakeholders can be internal or external to the project team and to the developing organization Stakeholder analysis is an important part of requirements development A customeris an individual or organization that derives either direct or indirect benefit from a product Be careful, some stakeholders are not customers User requirements should come from people who will actually use the product, either directly or indirectly. These users (often called end users) are a subset of customers. 6

7. STAKEHOLDERS & CUSTOMERS Direct users will operate the product hands-on. e.g. cashier i.e. Operational Stakeholders Indirect users might receive outputs from the system without touching it themselves, such as a warehouse manager who receives an automatic report of daily warehouse activities by email. i.e. Executive Stakeholders Users can describe the tasks they need to perform with the product, the outputs they need, and the quality characteristics they expect the product to exhibit. 7

8. STAKEHOLDERS OF A COMPREHENSIVE ACCOUNTING SYSTEM FOR PUBLIC COMPANY 8

9. STAKEHOLDER EXAMPLES 9

10. REQUIREMENTS ELICITATION TECHNIQUES There are always many types of information to be discovered, and different stakeholders will prefer different approaches Elicitation techniques include both: Facilitated activities, in which you interact with stakeholders to elicit requirements, and Independent activities, in which you work on your own to discover information Facilitated activities primarily focus on discovering business and user requirements. Working directly with users is necessary because user requirements encompass the tasks that users need to accomplish with the system. To elicit business requirements, you will need to work with people such as the project sponsor. Most projects will use a combination of both facilitated and independent elicitation activities. Requirements elicitation techniques examples: interviews, workshops, focus groups, observation, questionnaires, system interface analysis, user interface analysis and document analysis. 10

11. 1- INTERVIEWS Interviews are easier to schedule and lead than large-group activities such as requirements workshops. If you are new to an application domain, interviews with experts can help you get up to speed quickly. This will allow you to prepare draft requirements and models to use in other interviews or in workshops Interviews are appropriate for eliciting business requirements from executives who do not have a lot of time to meet. These are usefultips for conducting elicitation interviews: Establish rapport Stay in scope Prepare questions and straw man models ahead of time Suggest ideas Listen actively 11

12. 2-WORKSHOPS Workshops: a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, and refine models and documents that represent user requirements. Workshops often include several types of stakeholders, from users to developers to testers. Workshops are useful for: Eliciting requirements from multiple stakeholders concurrently. Working in a group is more effective for resolving disagreements than is talking to people individually. Helpful when quick elicitation is needed because of schedule constraints. 12

13. 2-WORKSHOPS Following are a few tips for conducting effective elicitation workshops: Establish and enforce ground rules Fill all of the team roles Plan an agenda Stay in scope Time box discussions Keep the team small but include the right stakeholders Keep everyone engaged Read pages 123-124 13

14. 3-FOCUS GROUPS A focus group is a representative group of users who meet in a facilitated elicitation activity to generate input and ideas on a product s functional and quality requirements. Focus group sessions must be interactive, allowing all users a chance to voice their thoughts. Focus groups are useful for exploring users attitudes, impressions, preferences, and needs. They are particularly valuable if you are developing commercial products and don t have ready access to end users within your company. 14

15. 3-FOCUS GROUPS How you select participants in focus groups? include users who have used previous versions or products similar to the one you re implementing select a pool of users who are of the same type (and hold multiple focus groups for the different user classes) or select a pool representing the full spectrum of user classes so everyone is equally represented Participants in focus groups normally do not have decision- making authority for requirements. Follow tips as ones in workshops. 15

16. Like watching 4-OBSERVATION cake baking Observations can be silent (independent) or interactive (facilitated). Silent observations are appropriate when busy users cannot be interrupted. Interactive observations allow the BA to interrupt the user mid-task and ask a question. This is useful to understand immediately why a user made a choice or to ask him what he was thinking about when he took some action. Document what you observe for further analysis after the session. You might also consider video recording the session, if policies allow, so you can refresh your memory later. 16

17. 5-QUESTIONNAIRES Questionnaires are a way to survey large groups of users to understand their needs. They are inexpensive, making them a logical choice for eliciting information from large user populations, and they can be administered easily across geographical boundaries. Preparing well-written questions is the biggest challenge with questionnaires. The analyzed results of questionnaires can be used as an input to other elicitation techniques. For example, you might use a questionnaire to identify users biggest pain points with an existing system, then use the results to discuss prioritization with decision makers in a workshop. 17

18. QUOTE Nothing Will Work Unless You Do Maya Angelou 18

19. 6-SYSTEM INTERFACE ANALYSIS Interface analysis is an independent elicitation technique that requires examining the systems to which your system connects. System interface analysis reveals functional requirements regarding the exchange of data and services between systems You might also discover existing functionality that you do not need to implement in your system. Example: validation in the shopping cart in e-commerce website. 19

20. 7-USER INTERFACE ANALYSIS User interface (UI) analysis is an independent elicitation technique in which you study existing systems to discover user and functional requirements It s best to interact with the existing systems directly, but if necessary, you can use screen shots. (User manuals) UI analysis can help you : identify a complete list of screens learn about the common steps users take in the system draft use cases to review with users know type of data users need to use/enter 20

21. 8- DOCUMENT ANALYSIS Document analysis requires examining any existing documentation for potential software requirements. Document analysis is a way to get up to speed on an existing system or a new domain. Example of documentations: requirements specifications, business processes user manuals for existing or similar applications lessons- learned collections Documents can describe corporate or industry standards or regulations that must be followed. Document analysis can reveal information people don t tell you, either because they don t think of it or because they aren t aware of it. 21

22. QUOTE Anyone who has never made a mistake has never tried anything new Albert Einstein 22

23. REFERENCES This presentation material has been prepared from the references below: Karl Wiegers and Joy Betty, Software Requirements, 3rd Edition, Microsoft. Chapter 7 23