This document discusses requirements elicitation and analysis. It describes the components and stages of elicitation including understanding the problem domain, stakeholders' needs, and collecting requirements. Analysis techniques are discussed like necessity, consistency, and feasibility checking. Requirements elicitation involves iterative negotiation when conflicts arise. Various techniques are presented like interviews, scenarios, prototyping and observation to understand requirements.
You may probably recognize the situation when a requirements professional is assigned to a new, challenging, agile project.
As Scrum does not know the role of a Requirements Engineer (RE) or Business Analyst (BA), the requirements professional will either become the Product Owner or be part of the Scrum Team (which consists of members with cross-functional know-how). Either way, the activities of requirements engineering will be executed in some way in an agile environment: that is handling requirements, often associated with user stories, eliciting needs from various stakeholders, documenting them accordingly, negotiating them and achieving acceptance and finally dealing with changes.
There is definitely a lot that goes on with requirements in Agile projects. Sometimes, you may not recognize that a practice used is nothing other than the basic method such as prioritisation; it becomes even more important and may be performed in a very similar way to traditional approaches (e.g. single-criterion classification or the Kano model), even if the result is represented as a sorted Product Backlog.
In this slideshare, the presenter will make some propositions about practices of the four major activities of requirements engineering (elicitation, documentation, validation, management) that may be implemented in a Scrum environment. This will be done by virtue of eliciting differences between the classic way of requirements engineering versus requirements engineering done in the Agile way published in the presenter's article at:
https://www.scrumalliance.org/community/articles/2017/august/requirements-engineering.aspx
This slideshow walks through common and popular Architectural design patterns such as Data-Driven Architecture, Micro-Services, Layered Architecture, and Micro-Kernel Architecture. I also go over the pros and cons and in which scenario each architecture is preferable
Agile requirement gathering and elicitation techniques will be explained on this presentation. It is useful for Business Analysts and Agile practioners.
You may probably recognize the situation when a requirements professional is assigned to a new, challenging, agile project.
As Scrum does not know the role of a Requirements Engineer (RE) or Business Analyst (BA), the requirements professional will either become the Product Owner or be part of the Scrum Team (which consists of members with cross-functional know-how). Either way, the activities of requirements engineering will be executed in some way in an agile environment: that is handling requirements, often associated with user stories, eliciting needs from various stakeholders, documenting them accordingly, negotiating them and achieving acceptance and finally dealing with changes.
There is definitely a lot that goes on with requirements in Agile projects. Sometimes, you may not recognize that a practice used is nothing other than the basic method such as prioritisation; it becomes even more important and may be performed in a very similar way to traditional approaches (e.g. single-criterion classification or the Kano model), even if the result is represented as a sorted Product Backlog.
In this slideshare, the presenter will make some propositions about practices of the four major activities of requirements engineering (elicitation, documentation, validation, management) that may be implemented in a Scrum environment. This will be done by virtue of eliciting differences between the classic way of requirements engineering versus requirements engineering done in the Agile way published in the presenter's article at:
https://www.scrumalliance.org/community/articles/2017/august/requirements-engineering.aspx
This slideshow walks through common and popular Architectural design patterns such as Data-Driven Architecture, Micro-Services, Layered Architecture, and Micro-Kernel Architecture. I also go over the pros and cons and in which scenario each architecture is preferable
Agile requirement gathering and elicitation techniques will be explained on this presentation. It is useful for Business Analysts and Agile practioners.
The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model.
In this Business Analysis training session, you will learn about Requirement Elicitation Techniques. Topics covered in this session are:
• Requirements Engineering
• Project Scope
• Landscape of Requirements
• Properties of Requirements
• Types of Requirements
• Stakeholder
• Requirements Elicitation
• Techniques
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
In this advanced business analysis training session, you will learn Requirement Elicitation. Topics covered in this session are:
• What is Elicitation?
• The elicitation methodology
• The stakeholder connection
• Stakeholder Analysis
• Brainstorming
• One-to-One Interview
• Group Interview
• Document Analysis
• Focus Group
• Interface Analysis
• Observation/Social Analysis
• Prototyping
• Use case and scenarios
• Requirements reuse
• Pre-Project Activity
• Request for Proposal
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model.
In this Business Analysis training session, you will learn about Requirement Elicitation Techniques. Topics covered in this session are:
• Requirements Engineering
• Project Scope
• Landscape of Requirements
• Properties of Requirements
• Types of Requirements
• Stakeholder
• Requirements Elicitation
• Techniques
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
In this advanced business analysis training session, you will learn Requirement Elicitation. Topics covered in this session are:
• What is Elicitation?
• The elicitation methodology
• The stakeholder connection
• Stakeholder Analysis
• Brainstorming
• One-to-One Interview
• Group Interview
• Document Analysis
• Focus Group
• Interface Analysis
• Observation/Social Analysis
• Prototyping
• Use case and scenarios
• Requirements reuse
• Pre-Project Activity
• Request for Proposal
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
This lecture provide a review of requirement engineering process. The slides have been prepared after reading Ian Summerville and Roger Pressman work. This lecture is helpful to understand user, and user requirements.
This lecture include detail about engineering especially software engineering profession. include common and mostly used schema to develop organisational structure.
Fact Finding Techniques:
Introduction to Fact finding techniques,
Decision Tables and trees,
Normalization and its types-
(1st, 2nd, 3rd, 4th, 5th, and Boyce code normal forms),
Introduction to Object oriented programming concepts.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
2. Objectives To describe the processes of requirements elicitation and analysis. To introduce a number of requirements elicitation and requirements analysis techniques. To discuss how prototypes may be used in the RE process.
4. Elicitation activities Application domain understanding Application domain knowledge is knowledge of the general area where the system is applied. Problem understanding The details of the specific customer problem where the system will be applied must be understood. Business understanding You must understand how systems interact and contribute to overall business goals. Understanding the needs and constraints of system stakeholders You must understand, in detail, the specific needs of people who require system support in their work.
7. Elicitation stages Objective setting The organisational objectives should be established including general goals of the business, an outline description of the problem to be solved, why the system is necessary and the constraints on the system. Background knowledge acquisition Background information about the system includes information about the organisation where the system is to be installed, the application domain of the system and information about existing systems Knowledge organisation The large amount of knowledge which has been collected in the previous stage must be organised and collated. Stakeholder requirements collection System stakeholders are consulted to discover their requirements.
9. Analysis checks Necessity checking The need for the requirement is analysed. In some cases, requirements may be proposed which don’t contribute to the business goals of the organisation or to the specific problem to be addressed by the system. Consistency and completeness checking The requirements are cross-checked for consistency and completeness. Consistency means that no requirements should be contradictory; completeness means that no services or constraints which are needed have been missed out. Feasibility checking The requirements are checked to ensure that they are feasible in the context of the budget and schedule available for the system development.
10. Requirements negotiation Requirements discussion Requirements which have been highlighted as problematical are discussed and the stakeholders involved present their views about the requirements. Requirements prioritisation Disputed requirements are prioritised to identify critical requirements and to help the decision making process. Requirements agreement Solutions to the requirements problems are identified and a compromise set of requirements are agreed. Generally, this will involve making changes to some of the requirements.
11. Elicitation techniques Specific techniques which may be used to collect knowledge about system requirements This knowledge must be structured Partitioning - aggregating related knowledge Abstraction - recognising generalities Projection - organising according to perspective Elicitation problems Not enough time for elicitation Inadequate preparation by engineers Stakeholders are unconvinced of the need for a new system
12. Specific elicitation techniques Interviews Scenarios Soft systems methods Observations and social analysis Requirements reuse
13. Interviews The requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements. Types of interview Closed interviews. The requirements engineer looks for answers to a pre-defined set of questions Open interviews There is no predefined agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system.
14. Interviewing essentials Interviewers must be open-minded and should not approach the interview with pre-conceived notions about what is required Stakeholders must be given a starting point for discussion. This can be a question, a requirements proposal or an existing system Interviewers must be aware of organisational politics - many real requirements may not be discussed because of their political implications
15. Scenarios Scenarios are stories which explain how a system might be used. They should include a description of the system state before entering the scenario the normal flow of events in the scenario exceptions to the normal flow of events information about concurrent activities a description of the system state at the end of the scenario Scenarios are examples of interaction sessions which describe how a user interacts with a system Discovering scenarios exposes possible system interactions and reveals system facilities which may be required
16. Library scenario - document ordering Log on to EDDIS system Issue order document command Enter reference number of the required document Select a delivery option Log out from EDDIS This sequence of events can be illustrated in a diagram
18. Scenarios and OOD Scenarios are an inherent part of some object-oriented development methods The term use-case (i.e. a specific case of system usage) is sometimes used to refer to a scenario There are different views on the relationship between use-cases and scenarios: A use-case is a scenario A scenario is a collection of use-cases. Therefore, each exceptional interaction is represented as a separate use-case
19. Soft Systems methods These produce informal models of a socio-technical system. They consider the system, the people and the organisation Not techniques for detailed requirements elicitation. Rather, they are ways of understanding a problem and its organisational context Software Systems Methodology (SSM) is probably the best known of these methods The essence of SSM is its recognition that systems are embedded in a wider human and organisational context
20. Stages of SSM Problem situation assessment Problem situation description Abstract system definition from selected viewpoints Conceptual system modelling Model/real-world comparison Change identification Recommendations for action
21. Observation and social analysis People often find it hard to describe what they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at work Ethnography is a technique from the social sciences which has proved to be valuable in understanding actual work processes Actual work processes often differ from formal, prescribed processes An ethnographer spends some time observing people at work and building up a picture of how work is done
22. Ethnography guidelines Assume that people are good at doing their job and look for non-standard ways of working Spend time getting to know the people and establish a trust relationship Keep detailed notes of all work practices. Analyse them and draw conclusions from them Combine observation with open-ended interviewing Organise regular de-briefing session where the ethnographer talks with people outside the process Combine ethnography with other elicitation techniques
24. Ethnographic perspectives The work setting viewpoint This describes the context and the physical location of the work and how people use objects to carry out tasks. Therefore, in a study of a help desk (say), this would describe the objects which the helper had to hand and how these were organised. Social and organisational perspectives This tries to bring out the day-to-day experience of work as seen by different people who are involved. Each individual typically sees the work in a different ways and this viewpoint tries to organise and integrate all of these perceptions. The workflow viewpoint This viewpoint presents the work from a series of work activities with information flowing from one activity to another.
25. Requirements reuse Reuse involves taking the requirements which have been developed for one system and using them in a different system Requirements reuse saves time and effort as reused requirements have already been analysed and validated in other systems Currently, requirements reuse is an informal process but more systematic reuse could lead to larger cost savings
26. Reuse possibilities Where the requirement is concerned with providing application domain information. Where the requirement is concerned with the style of information presentation. Reuse leads to a consistency of style across applications. Where the requirement reflects company policies such as security policies.
27. Prototyping A prototype is an initial version of a system which may be used for experimentation Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses. They have something concrete to criticise Rapid development of prototypes is essential so that they are available early in the elicitation process
28. Prototyping benefits The prototype allows users to experiment and discover what they really need to support their work Establishes feasibility and usefulness before high development costs are incurred Essential for developing the ‘look and feel’ of a user interface Can be used for system testing and the development of documentation Forces a detailed study of the requirements which reveals inconsistencies and omissions
29. Types of prototyping Throw-away prototyping intended to help elicit and develop the system requirements. The requirements which should be prototyped are those which cause most difficulties to customers and which are the hardest to understand. Requirements which are well-understood need not be implemented by the prototype. Evolutionary prototyping intended to deliver a workable system quickly to the customer. Therefore, the requirements which should be supported by the initial versions of this prototype are those which are well-understood and which can deliver useful end-user functionality. It is only after extensive use that poorly understood requirements should be implemented.
30. Prototyping costs and problems Training costs - prototype development may require the use of special purpose tools Development costs - depend on the type of prototype being developed Extended development schedules - developing a prototype may extend the schedule although the prototyping time may be recovered because rework is avoided Incompleteness - it may not be possible to prototype critical system requirements
31. Approaches to prototyping Paper prototyping a paper mock-up of the system is developed and used for system experiments ‘Wizard of Oz’ prototyping a person simulates the responses of the system in response to some user inputs Executable prototyping a fourth generation language or other rapid development environment is used to develop an executable prototype
32. Executable prototype development Fourth generation languages based around database systems Visual programming languages such as Visual Basic or ObjectWorks Internet-based prototyping solutions based on World Wide Web browsers and languages such as Java
33. Requirements analysis The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirements. These are then fed back to the stakeholders to resolve them through the negotiation process Analysis is interleaved with elicitation as problems are discovered when the requirements are elicited A problem checklist may be used to support analysis. Each requirement may be assessed against the checklist
34. Analysis checklists Premature design Does the requirement include premature design or implementation information? Combined requirements Does the description of a requirement describe a single requirement or could it be broken down into several different requirements? Unnecessary requirements Is the requirement ‘gold plating’? That is, is the requirement a cosmetic addition to the system which is not really necessary. Use of non-standard hardware Does the requirement mean that non-standard hardware or software must be used? To make this decision, you need to know the computer platform requirements.
35. Analysis checklists Conformance with business goals Is the requirement consistent with the business goals defined in the introduction to the requirements document? Requirements ambiguity Requirements ambiguity Is the requirement ambiguous i.e. could it be read in different ways by different people? What are the possible interpretations of the requirement? Requirements realism Is the requirement realistic given the technology which will be used to implement the system? Requirements testability Is the requirement testable, that is, is it stated in such a way that test engineers can derive a test which can show if the system meets that requirement?
36. Requirements interactions A very important objective of requirements analysis is to discover the interactions between requirements and to highlight requirements conflicts and overlaps A requirements interaction matrix shows how requirements interact with each other. Requirements are listed along the rows and columns of the matrix For requirements which conflict, fill in a 1 For requirements which overlap, fill in a 1000 For requirements which are independent, fill in a 0
38. Requirements negotiation Disagreements about requirements are inevitable when a system has many stakeholders. Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities Requirements negotiation is the process of discussing requirements conflicts and reaching a compromise that all stakeholders can agree to In planning a requirements engineering process, it is important to leave enough time for negotiation. Finding an acceptable compromise can be time-consuming
39. Negotiation meetings An information stage where the nature of the problems associated with a requirement is explained. A discussion stage where the stakeholders involved discuss how these problems might be resolved. All stakeholders with an interest in the requirement should be given the opportunity to comment. Priorities may be assigned to requirements at this stage. A resolution stage where actions concerning the requirement are agreed. These actions might be to delete the requirement, to suggest specific modifications to the requirement or to elicit further information about the requirement.
40. Key points Requirements elicitation involves understanding the application domain, the specific problem to be solved, the organisational needs and constraints and the specific facilities needed by system stakeholders. The processes of requirements elicitation, analysis and negotiation are iterative, interleaved processes which must usually be repeated several times. There are various techniques of requirements elicitation which may be used including interviewing, scenarios, soft systems methods, prototyping and participant observation.
41. Key points Prototypes are effective for requirements elicitation because stakeholders have something which they can experiment with to find their real requirements. Checklists are particularly useful as a way of organising the requirements validation process. They remind analysts what to look for when reading through the proposed requirements. Requirements negotiation is always necessary to resolve requirements conflicts and remove requirements overlaps. Negotiation involves information interchange, discussion and resolution of disagreements.