requirements elicitation: understanding user needs 4
TRANSCRIPT
Requirements Elicitation: Understanding User Needs
4
1.Analyzing the problem1.Analyzing the problem
3.Managing the system
3.Managing the system
2.Understanding user needs
2.Understanding user needs
4.Defining the System
Defining.4the System
6.Building the right system
6.Building the right system
5.Refining the system definition
5.Refining the system definition
Business ModelingBusiness Modeling
System Engineering of
soft. Intensiv sys
System Engineering of
soft. Intensiv sys
Five steps in problem statment
Five steps in problem statment
1.Gaine Agreement
on the Problem
Definition
1.Gaine Agreement
on the Problem
Definition
5.Identifiy the constraints to be Imposed on solution
Identifiy the.5 constraints to be Imposedon solution
4.Define the solution System
boundary
4.Define the solution System
boundary
3.Identify the
Stakeholders and the
users
3.Identify the
Stakeholders and the
users
2.Understand the Root
CausesProblem Behind
Problem
2.Understand the Root
CausesProblem Behind
Problem
Effective Requirements Management
Effective RequirementsManagement
Until Now
Requirements Engineering
Team Skill 1 - Analyzing the problem.
Team Skill 2 - Understanding user needs.
Team Skill 3 - Defining the system.
Team Skill 4 - Managing scope.
Team Skill 5 - Refining the system definition.
Team Skill 6 - Building the right system.
2. UNDERSTANDING USER NEEDS
What is Requirements Elicitation?
Understanding the requirements for the system.
Understanding the product or system features which are high level expressions of desired system behavior.
Requirements Elicitation
“The process of identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints of these communities.”
“…requirements elicitation involves social, communicative issues as well as technical issues.”
“…research efforts should be directed towards methods…providing more support to the elicitation of requirements.”
Elicitation process
Identify relevant sources of requirements Ask appropriate questions to gain an
understanding of the needs Analyze the gathered information, looking for
implications, inconsistencies, or unresolved issues
Synthesize appropriate statements of the requirements
Confirm your understanding of the requirements with the users
Loop back if conflicts occur
Actors in requirements elicitation
Software requirements engineer & his staff Designers of the target system Potential users of the target system Application domain experts The users’ managers
No ONE person knows everything about what a software system should do
We have to find the right persons, then meet with them effectively by asking the right questions and use various techniques to gather as much information as early as possible
Outcomes of good elicitation
Helps the users in the separation of what they want and what they need
Enables all actors to share the same vision of the problem and the solutions that are feasible
Enables trust between software developers and customers
Minimizes the interactions between developers and customers
Outcomes poor elicitation
The developers might solve the wrong problem
Customers might be dissatisfied Developers are enforcing their on view on the system Customers are not participating enough
Chaotic development process Additional meetings are required with the customers Developers make wrong decisions Change in requirements can have unexpected wide-range
impacts
Loss of reputation, credibility and morale for the developers
Loss of money, time and confidence for the customers
Difficulties of elicitation
Requirements elicitation is a complex and imprecise process that varies greatly for different projects
Many technical problems are related to this process: Scope problems Problems related to the nature of computer science Problems related to the process itself
Many problems pertaining to human nature are related to this process: Articulation problems Communication barriers Knowledge and cognitive limitations Human behavior issues
Scope problems
The boundaries of the system are ill-defined
The context of the system is ill-defined Hardware and software constraints System’s role in a larger system Maturity of the system’s domain Attributes of the actors: management style,
hierarchy, domain experience, computer experience, etc.
Unnecessary or restrictive design information is given
The nature of computer science
Problems are becoming increasingly complex
Processes are evolving
Software and hardware technologies are changing rapidly
Problems with the process itself
Requirements change over time
There are many sources of requirements
The nature of the system imposes constraints on the elicitation process
The cross-referencing and heterogeneity of information gathered complexifies its management
Articulation problems
Users are aware of their needs but unable to express them Users are not aware of possible solutions available to them Users may be aware of some needs but afraid to articulate it Actors have different meanings for common terms Users are not aware of the consequences of their needs No actor has the complete picture of the system Developers might not be really listening to the user’s needs Developers fail to understand, appreciate or relate to users Developers overrule or dominate users
Communication barriers
Actors have different vocabularies
Users often have very grounded concerns
All media of communication have their problems
Actors have incompatible styles of interaction
Actors have different personalities
Knowledge and cognitive limitations
Developer must have adequate domain knowledge
Actors have selective memories
Actors use intuitive statistics to express ideas
Actors have difficulties with scale and complexity
Actors have preconceived ideas to the solution
Actors focus on some narrow aspects of the problem
Actors are not willing to undertake extensive exploration
Human behavior issues
There are ambiguities in the roles that each actor has to play in the elicitation process
Users fear that the introduction of the system will necessitate changes in their behavior
Users fear the system will make them lose their jobs
Barriers to elicitation
The “Yes, But” Syndrome Two reactions when the users see the system
implementation for the first time: “Yes, this is so cool.” “Yes, but what about this...?”....
It is human nature and is an integral and important part of application development
To address this problem, apply techniques that can get the “buts” out early
The later problems are found, the more costly they are to fix
Barriers to elicitation
The “Undiscovered Ruins” Syndrome
Searching for requirements is like searching for “Undiscovered ruins”; the more you find, the more you know remain.
“Now that I see it, I have another requirement to add”. It is impossible to know when requirements are complete The validation phase will assess the completeness To address this problem
Identify all of the stakeholders Use the techniques we will discuss later
Barriers to elicitation
The “User and the Developer” Syndrome There is a communication gap between the user and
the developer They don’t use the same language They don’t have the same background knowledge They don’t have the same motivations and objectives The gap has to be minimized
Most developers are not trained in elicitation techniques
To address this problem Learn to communicate effectively
The “User and the Developer” Syndrome
Problem Solution
Users do not know what they want, or they know what they want but cannot articulate it.
Recognize and appreciate the user as domain expert; try alternative communication and elicitation techniques.
Users think they know what they want until developers give them what they said they wanted.
Provide alternative elicitation techniques earlier: storyboarding, role playing, throwaway proto-types, and so on.
Analysts think they understand user problems better than users do.
Put the analyst in the user's place. Try role playing for an hour or a day.
Everybody believes everybody else is politically motivated.
Yes, its part of human nature, so let's
get on with the program.
Global problems
13% Lack of user input
12% Incomplete requirements and specifications
Lack of understanding and communication (25%)
Stakeholders never take the initiative of communicating their needs
Initiative has to come from the developers
Developers are responsible for choosing the techniques for requirements elicitation
Understanding user needs
“Problem analysis” describes the process of analyzing the problem to be solved
This process is based on input data gathered from the stakeholders
How do we gather this data?
Requirement elicitation techniques
To address the three problems, we will discuss the following techniques: Interviewing and questionnaires – (talking
about) Requirements Workshops + Brainstorming –
(discussing about) Storyboarding – (presenting about) Applying Use Cases - ( visualizing it) Role Playing – (experiencing it) Prototyping – (realizing it)
How do we choose the right technique for elicitation?
Ch 8: The features of a Product or System Stakeholder needs
A stakeholder need is: a reflection of the business, personal, or operational problem. must be addressed in order to justify consideration, purchase,
or use of a new system. Most needs are very abstract and require analysis:
“I need easier ways to understand the status of my inventory” “I’d like to see a big increase in the productivity of sales order
entry” “The weapon system must score a hit in 95% of missile firing” “The vehicle must be able to slow down as quickly as possible”
Others are very specific: “The ATM machine must provide features such as withdraw,
deposit, and transfer money” We have to understand the true stakeholders needs
System features
The features of a product or system are high-level expressions of desired system behavior
These features are often not well defined and may even be in conflict
Features are a convenient way to describe functionality without getting down in detail
The features are easily expressed in natural language and consist of a short phrase
Features and needs are sometimes hard to categorize
Needs vs. features
If needs are not met, project is a failure
Features should satisfy needs Stakeholders will express
either needs or features Needs generate features Needs and features will be
analyzed to form software requirements
Requirements can be modeled into software specifications
Each level is adding details and coming closer to implementation considerations
Needs
Features
Software requirements
Software specifications
Managing complexity
Complexity of system analysis comes mainly from the amount of data acquired during elicitation Introduce abstraction levels to reduce the local
complexity Any system can be defined in a list of 25-99 features The small amount of information provides a
comprehensive and complete basis for product definition communication with the stakeholders scope management project management
Managing complexity
Features can be described and categorized using attributes
They are used to provide additional information about the features
They help us to manage the complexity of the information
Helps in project scoping and planning
Table 8-2, p92
Attributes of the featuresAttribute Description
Status Tracks progress during definition of the project baseline and subsequent development. Example: Proposed, Approved, Incorporated status states.
Priority/Benefit
All features are not created equal. Ranking by relative priority or benefit to the end user opens a dialogue between stakeholders and members of the development team. Used in managing scope and determining priority. Example: Critical, Important, Useful rankings
Effort Estimating the number of team- or person-weeks, lines of code or function points, or just general level of effort helps set expectations of what can and cannot be accomplished in a given time frame. Example: Low, Medium, High levels of effort.
Risk A measure of the probability that the feature will cause undesirable events, such as cost over-runs, schedule delays, or even cancellation. Example: High, Medium, Low risk level.
Attributes of the features
Attribute Description
Stability A measure of the probability that the feature will change or that the team's understanding of the feature will change. Used to help establish development priorities and to determine those items for which additional elicitation is the appropriate next action.
Target release
Records the intended product version in which the feature will first appear. When combined with the Status field, your team can propose, record, and discuss various features without committing them to development.
Assigned to
In many projects, features will be assigned to "feature teams" responsible for further elicitation, writing the software requirements, and perhaps even implementation.
Reason Used to track the source of the requested feature. For example, the reference might be to a page and line number of a product specification or to a minute marker on a video of an important customer interview.
Requirements Elicitation Techniques
Interviewing
Interviewing
Interviewing is a simple and direct technique that can be used in every situation
Make sure that any preconceived ideas do not interfere Normalize first impression effects by making the
context clear Be open to all input and expect conflicts of all sorts Do not impose your views
Nothing substitutes for an interview Good technique in early stages Can be structured or unstructured
Interviewing
Context-free questions Question about the nature of the user’s problem
without any context for a potential solution Aims at coming to an understanding of the problem Force you to listen before attempting to invent or to
describe a potential solution Listening gives us a better understanding of the
user’s problem and any problems behind the problem
Context, such as solution hints, will later give more information to stimulate the user’s imagination
Interviewing
Prepare an appropriate context-free interview, and jot it down in a notebook for reference during the interview. Review the questions just prior to the interview.
Before the interview, research the background of the stakeholder and the company to be interviewed. Don't bore the person being interviewed with questions you could have answered in advance. On the other hand, it wouldn't hurt to briefly verify the answers with the interviewee.
Jot down answers in your notebook during the interview. (Don't attempt to capture the data electronically at this time!)
Refer to the template during the interview to make certain that the right questions are being asked.
Interviews - Recap
Most commonly used technique
Basic steps: Selecting Interviewees Designing Interview Questions Preparing for the Interview Conducting the Interview Post-Interview Follow-up
Types of Questions
Types of Questions Examples
Closed-Ended Questions * How many telephone orders are received per day?
* How do customers place orders?* What additional information would you like the new system to provide?
Open-Ended Questions * What do you think about the current system?* What are some of the problems you face on a daily basis?* How do you decide what types of marketing campaign to run?
Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit more detail?
Organizing Interview Questions
Unstructured interview useful early in information gathering Goal is broad, roughly defined information
Structured interview useful later in process Goal is very specific information
Interviewing
Questionnaires The questionnaire is not a substitute for an interview Can be applied with good effect as a corroborating
technique after the initial interviewing and analysis activity
Be careful when designing questions Answers are often unclear
Requirements workshop
Requirements workshop
It gathers all key stakeholders together for a short but intensely focused period (1-2 days)
One of the most powerful technique for eliciting requirements
The use of an outside facilitator in requirements management can help ensure the success of the workshop.
Brainstorming is the most important part of the workshop
Requirements workshop
Preparing for the workshop Proper preparation for the workshop is critical to
success. The steps of preparing
Selling the concept Identifying stakeholders Logistics Sending materials out in advance
Ask a facilitator to run the workshop
Requirements workshop
Running the workshop Facilitator:
Outsider, if possible Trained and/or experienced in workshops Great team worker and mediator Respected person
Brainstorming and idea reduction Workshop tickets (figure 10-2, p110) Output of the workshop
Requirements workshop
A properly run requirements workshop has many benefits. It assists in building an effective team. All stakeholders get their say. It forges an agreement between the stakeholders
and the development team. It can expose and resolve political issues. The output, a preliminary system definition at the
features level, is available immediately.
RW Meeting Room
JPEG Figure 5-5 Goes Here
Managing Problems in RW Sessions
Reducing domination
Encouraging non-contributors
Side discussions
Agenda merry-go-round
Violent agreement
Unresolved conflict
True conflict
Use humor
Brainstorming and idea reduction
Brainstorming - Idea generation
What is idea generation?
The first half of Brainstorming session is idea generation:
Let every stakeholder speak. It may be out-of-box thinking and seemingly unrelated ideas.
Generate as many ideas as possible.
The primary goal during idea generation is to delineate as many ideas as possible; the goal is breadth of ideas, not necessarily depth.
Rules of Brainstorming
Do not allow criticism or debate
Let your imagination soar
Generate as many ideas as possible
Mutate and merge ideas
Set up a goal (e.g. What features are needed?)
Facilitator writes down ideas clearly, keeps the participants on focus, and decides when to end the meeting
Brainstorming - Idea reduction
What is idea reduction?
The second half of Brainstorming session is idea reduction:
The goal here is depth of ideas, not necessarily breadth. Pruning:Pruning:
remove those ideas that are not worth of further investment by the group.
Grouping ideasGrouping ideas:
classify the ideas, group similar ideas and name the group.
(How to classify the ideas – next page) Feature definition:Feature definition:
write a short description of what the idea meant to the person who proposed it. This way everyone understands what was meant by the idea.
Prioritization:Prioritization:
once the ideas are collected and listed, it may ordered in 3 levels: critical, important and useful.
Idea classification
How do you classify the ideas?
The ideas may be classified as follows:
1. Business requirements
2. Use cases or scenarios
3. Business rules
4. Functional requirements
5. Quality attributes and non-functional requirements.
6. External interface requirements
7. Constraints
8. Data definitions
9. Solution ideas
Brainstorming and Idea Reduction
The benefits of this elicitation technique: It encourages participation by all parties present. It allows participants to “piggyback” on one another’s
ideas. The facilitator maintains a written trail of everything
discussed. Large scope is discussed. Typically, it results in a broad set of possible
solutions. It encourages free thinking without being limited by
normal constraints.
Storyboarding
Storyboarding
Put the stakeholders in a situation and ask them to comment
Goal : elicit early “yes, but” reactions
3. Storyboarding
How do you classify Storyboarding?
Storyboarding can be classified into 3 types:
Passive Storyboarding:Passive Storyboarding:It may consist of sketches, pictures, screen shots, Power Point slides or sample outputs. It explains “when you do this, this happens”.
Active Storyboarding:Active Storyboarding:It may be simulations, animation or automated sequencing slide presentation or movie. It explains the way the system behaves in a typical usage or operational scenario.
Interactive Storyboarding:Interactive Storyboarding:It may be a live demo, interactive presentation (may be throw away prototypes). It lets the user experience the system in as realistic a manner as practical.
Storyboarding - classification
Passive
Simulation
Business rules
Output reports
Active Interactive
Slide Show
Animation
Screen shots
Live demo
Interactive presentation
Prototyping
Storyboarding
Tips Don’t invest too much Make the story board easy to change Don’t make the storyboard too good The more interaction, the better
When? Early Often On any project with innovative content
Use cases
Use cases
As in the use case driven approach
Defines the who, what and how of the system
Defines only the functional behavior Input only from users Does not address non-functional issues
Meshes perfectly with OO design
Very powerful to elicitate GUI-intensive applications
Define Use Cases
Use case: A coherent unit of externally visible functionality provided by a system unit.
Used to define a behavior without revealing the internal details.
A use case describes what the system does, not how it does it.
Scenario: flow of events describing how a use case is realized.
Each use case has a primary scenario. Eventually also has a set of alternate scenarios. Pre-conditions and post-conditions are stated.
Define Use Cases
Place OrderPre-conditions: A valid user has logged into the systemPrimary Flow of Events: 1. (start) The customer selects Place Order 2. The customer enters its address 3. The customer enters the product codes it wants to order 4. The system provides the items description and prices, and a running total 5. The customer enters its credit card number 6. The customer clicks on submit 7. The system validates the information, saves the order and forwards the transaction request to the accounting system 8. (end) When the payment is confirmed, the order is marked as paidAlternate Flow of Events 1: In step 7, the system prompts the user to correct any incorrect informationAlternate Flow of Events 2: In step 8, if the transaction is refused by the bank, the order is marked as pendingPost-conditions: The order has been saved in the database
Scenarios: Diagrams
Complex scenarios are better expressed using diagrams.
The UML provides two kinds of diagrams: Activity diagrams for a high-level description. Sequence diagrams for more in-depth analysis.
Use Case Diagrams
Roles Model the context of the system. Define what are the
actors that are external to the system Model the requirements of the system. Define what
the system should do from an external point of view
Order-Processing Use Case Diagram
Customer
ShippingClerk
Supplier
Shipping Company
CustomerRepresentative
PlaceOrder
Cancel Order
SendCatalog
CalculatePostage
Get orderstatus
Return Product
DeliverProduct
Send UsProduct
Role playing
Role playing
The problem: We have talked about it (interview) We have discussed it (workshops) We have presented our view of it (storyboarding) We haven’t experienced it
Sometimes, experience is needed: Some situations are hard to articulate (e.g. tie your
shoes) Some situations are hard to admit (e.g.
workarounds) The context is sometimes important (e.g. working
environment)
5. Role Playing
What is Role Playing? What is the outcome of Role Playing?
Role playing allows the development team to experience the user’s world from the user’s experience. In the simplest form of role playing, the developer,the analyst, and, potentially, every member of the development team simply take the place of the user and execute the customer’s work activity.
Class – Responsibility – Collaboration (CRC) cards, often in OO analysis, are outcomes of role playing.
A Design Process
The design process follows from the Requirements Phase. There are several theories and methods of design process. Here we discuss a simple design process.
1. Identify the classes and objects.
2. Describe the object collaborations and the classes.
3. Design the class diagram.
4. Sketch the user interface.
1. Identifying classes and objects
An effective way to identify classes is by preparing what are known as Class-Responsibility-Collaboration (CRC) cards.
Responsibilities: Collaborations:
Class:
Preparing CRC cards from a Problem Summary Statement
1. Classes – Read through the problem summary statement and identify nouns and noun phrases, placing them on a list. When the list is complete, review it for possible classes, which may be physical objects, concepts, categories of objects, or attributes of other objects.
2. Responsibilities – Responsibilities relate to actions. A good starting place for finding responsibilities is in the verbs of the problem summery statement. List the verbs, decide which of them represent responsibilities that must be discharged by some class, and allocate each such responsibility to a class.
3. Collaborations – Simply scan the list of responsibilities of each class and identify any other class it needs in order to fulfill its responsibilities. List these as its collaborations.
How do we find classes?
One approach for identifying classes is to use the noun phrases of the itemized requirements which is normally in simple English. Normally the nouns are used to extract the classes and the verbs are used to identify the methods of the classes.
Here we rewrite the requirements (Problem Summary Statement) and mark the nouns in red color and verbs in pink color.
Listing nouns and verbs
Nouns Verbs
customer
balance
account
money
message
tracks
withdraw
decreases his balance
deposit
increases his balance
displays
Initially a customer opens an account with 500 riyals. The customer tracks the balance in his account through the ATM. There are two buttons on the screen of ATM: Withdraw and Deposit. The customer can withdraw money from his account, which decreases his balance. The customer can deposit money in his account, which increases his balance. Whenever money is withdrawn or deposited, a message is displayed confirming the action. If the customer tries to withdraw money, which is more than the balance, an error message is displayed. Here is a restriction on the ATM transaction of a customer. A customer can withdraw or deposit exactly 50 riyals at a time.
Finding classes – CRC cards
The possible classes may be customer and account. The balance may be an attribute in the class account. The money and message may be passing parameters of methods.
Responsibilities: Collaborations:
Withdraw money Account
Deposit money Account
Display message N/A
Class: customer
Finding classes – CRC cards
Responsibilities: Collaborations:
Withdraw money customer
Deposit money customer
Return balance customer
Class: account
2. Describing the object collaborations and the classes
withdraw money
customer
deposit money
account
2.1. Recall the use case diagram:
:Customer
:Account
tellResult()
3:
withdraw()
1:
getBalance( )
2:
2.2. Preparing collaboration diagram:
2.2.1. A collaboration diagram for the withdraw use-case
:Customer
:Account
tellResult()
3:
deposit()
1:
getBalance( )
2:
2.2.2. A collaboration diagram for the deposit use-case
CustomerINITIAL_BAL : IntegertheAccount : Account
tel lResult()
Accountbalance : Integer
withdraw()deposit()getBalance()
3.1. Preparing class diagram:
3. Designing the Class Diagram
Prototyping
Prototyping
Goal : validate our understanding of the problem by implementing a partial solution that the user can use
Addresses two syndromes: Yes but : “That is not exactly what I meant” Undiscovered ruins : “Now that I see it, I have
another requirement to add”
Two types of prototypes: Throwaway: tool for requirements validation Evolutionary: Early version of the system to be
delivered
Prototyping
Emphasis on the interface, not on internal mechanics of the system
Cannot validate non-functional requirements effectively
Must be cost-effective
Must be exercised in the deployment environment
Prototyping
What to prototype? Well-understood requirements are not needed,
unless they are necessary for the prototype to function
Unknown or undefined needs cannot be prototyped Only the “fuzzy” part in between is prototyped
Result Validation of understanding of the problem Refinement of understanding Reduces risks in the project
Must look as closely as possible as the final product
The advantages of Prototyping
What are the advantages of prototyping?A software prototype supports two requirements
engineering process activities:1. Requirements elicitation: Software prototypes allow
users to experiment to see how the system supports their work. They get new ideas for requirements and can find areas of strength and weakness in the software. They may then propose new system requirements. Misunderstandings between software developers and users may be identified as the software prototype is demonstrated.
Software development staff may find incomplete and/or inconsistent requirements as the prototype is developed.
2. Requirements validation: The prototype may reveal errors and omissions in the requirements which has been proposed. It helps to go back to amend changes in the requirements specification.
Prototyping - advantages
3. User Training: A software prototype can be used for training users before the final system has been delivered.
4. System testing: A software prototype can run “back-to-back” tests. Using this prototype, test plan, test cases and test data can be generated. It is very useful to prepare for User Acceptance Plan.
5. Planning and scheduling: It is helps the Project Manager to estimate the size of the project accurately. That helps the PM to plan and schedule the project.
6. Risk analysis: Prototyping can be used as a risk analysis.
Prototyping - advantages
7. Accelerated delivery of the product: The customer is not going to wait until the end of the project to see the functionalities of the product. The prototype is giving a comfortable feeling of the product which he is going to get at the end of the project.
8. User engagement with the system: The incremental prototype model brings the involvement of users with the development process. It engages the user one-to-one in the project right from the requirement phase itself.
Throw-away vs. Evolutionary
Throw-away prototypes Evolutionary prototypes
Throw-away prototypes have, by definition, a very short time. Once SRS is written, it is thrown away.
Evolutionary prototypes on the other hand is incremental and become a part of the product. Its life is long.
This is not used for testing and training.
This is used for testing and training.
This may not include the features of non-functional requirements such as performance, security, scalability etc.
The standards of the features of non-functional requirements may be reduced but the features are there in the evolutionary prototypes.
The development of Throw-away prototypes is not necessary to meet the organizational quality standards.
It should meet the organizational standards.
To make Prototyping effective
What are the guidelines to make prototyping effective?
These are the guidelines:
1. Include prototyping tasks in your project plan. Schedule time to develop, evaluate, and possibly modify the prototypes.
2. Plan to develop multiple prototypes, because you will rarely get them right on the first try.
3. Create throw-away prototypes as quickly and cheaply as possible. Invest the minimum amount of work in developing prototypes that will answer questions or resolve uncertainties about the requirements. Don’t try to perfect a throwaway prototype’s user interface.
4. Don’t include code comments, input data validations, defensive coding techniques, error-handling code in a throwaway prototype
5. Don’t prototype requirements you already understand.
6. Resist the temptation – or the pressure from users – to keep adding more functionality. Don’t allow a simple throwaway prototype to become more elaborate than is necessary to meet the prototyping objectives.
Summary
Elicitation is the input to all system development
Elicitation technique varies greatly across projects
No one technique is universal
Missing requirements is extremely costly to fix
Completeness can never be assured
Lots of human nature and communication problems
Elicitation skills, techniques and processes are minimal in too many SE companies