Wiegers, Chapter 7: Requirements Elicitation
A better question is
"What do you need to do?"
When working on a replacement project ask...
"What three things annoy you the most about the existing system?"
Elicitation is
A collaborative and analytical process that includes activities to collect, discover, extract, and define requirements.
The output of requirements development is
A common understanding of the needs held by the diverse project stakeholders
Anything that doesn't fit into our categories might be
A project requirement (need to train users) A project constraint (cost, schedule restriction) An assumption or a dependency Additional info Extraneous information without value
Solution idea
A specific way to interact with the system to perform some action
Requirements workshop is
A structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach closure on deliverables that represent user requirements
UI analysis is
An independent elicitation technique in which you study existing systems to discover user and functional requirements
Business Requirements
Anything that describes the financial, marketplace, or other business benefit that either customers or the development organization wish to gain from the product is a BReq
Take good notes
Assign sb to be the scribe, responsible for taking accurate notes. Session notes should contain an attendee list, invitees who did not attend, decisions made, actions to be taken and who is responsible for each, outstanding issues, and the high points of key discussions
Cautions about elicitation
Balance stakeholder representation Define scope appropriately Avoid the requirements-versus-design argument Research within reason
Categories of customer input
Business Requirements (BReq) User Requirements (UR) Business Rules (BRl) Functional Requirements (FR) Quality Attributes (QA) External Interface Requirements (EIR) Constraints (C) Data Requirements (DR) Solution Ideas (Sol.Id.) Data Definition (DD)
Following up after elicitation
Consolidate input from multiple sources. Review and update notes soon after the session is complete, while the content is still fresh in your mind.
Prepare for elicitation (activities)
Decide on elicitation scope and agenda Prepare resources Prepare questions and straw man models
Plan session scope and agenda
Decide on the scope of the elicitation session, taking into account how much time is available.
Elicitation strategy and planned techniques
Decide which techniques to use with different stakeholder groups
To find missing requirements:
Decompose high-level requirements into enough detail Ensure that all user classes have provided input Trace SR, UR, event-response lists, and BRls to their FRs to make sure that all necessary functionality is derived Check boundary values for missing requirements Represent requirements information in more than one way Create a checklist of common functional areas to consider for your projects Create a data model
Expected products of elicitation efforts
Define the outcomes of elicitation activities
External Interface Requirements
Describe the connections between your system and the rest of the universe.
Tips for performing elicitation activities
Educate stakeholders Take good notes Exploit the physical space
Workshops are used to
Elicit requirements from multiple stakeholders concurrently
Interviews are also appropriate for
Eliciting business requirements from executives who don't have a lot of time to meet
Tips for conducting workshops
Establish and enforce ground rules Fill all of the team roles Plan an agenda Stay in scope Use flipcharts to capture items for later consideration Timebox discussions Keep the team small but include the right stakeholders Keep everyone engaged
Useful tips for conducting interviews
Establish rapport Stay in scope Prepare questions and straw man models ahead of time Suggest ideas Listen actively
Document analysis
Examining any existing documentation for potential software requirements
Functional Requirements
FR describe the observable behaviors the systems will exhibit under certain conditions and the actions the system will let users take
Data requirements
Format, data type, allowed values, or default value for a data element
User Requirements
General statements of user goals or business tasks that users need to perform (use cases, scenarios, user stories)
Prepare questions
Go into every facilitated elicitation session with a set of prepared questions
Schedule and resource estimates
Identify both customer and development participants for the various elicitation activities, along with estimates of the effort and calendar time required
Elicitation risks
Identify factors that could impede your ability to complete the elicitation activities as intended, estimate the severity of each risk, and decide how you can mitigate or control it
Documents and systems needed for independent elicitation
Identify the materials needed to ensure that you have docs when you need them
Learn about the stakeholders
Identify the relevant stakeholders for the session, learn about their cultural and regional preferences for meetings.
Focus group
Is a representative group of users who convene in a facilitated elicitation activity to generate input and ideas on a product's functional and quality requirements
Follow up after elicitation (activities)
Organize and share notes Document open issues
Perform elicitation (activities)
Perform elicitation session
Tips for preparing for elicitation
Plan session scope and agenda Prepare resources Learn about the stakeholders Prepare questions
Tips for writing questionnaires
Provide answer option that cover the full set of possible responses Make answer choices both mutually exclusive and exhaustive Don't phrase a question in a way that implies a "correct" answer If you use scales, use them consistently throughout the questionnaire Use closed questions with two or more specific choices if you want to use the questionnaire results for statistical analysis Consider consulting with an expert in questionnaire design to ensure that you ask the right questions of the right people Always test a questionnaire before distributing it Don't ask too many questions or people won't respond
Constraints
Restrict the options available to the developer.
Prepare resources
Schedule the physical resources needed, such as rooms, projectors, teleconference numbers, and videoconferencing equipment; and participants being sensitive to time zone differences.
Comparative reviews point out
Shortcomings in other products that you could address to gain a competitive advantage
Quality Attributes
Statements that describe how well the system does something are QA. (fast, user-friendly, reliable, secure)
Educate stakeholders
Teach your SHs about your elicitation approach and why you chose it, explain techniques you'll be using and how they can help provide better requirements
Facilitation is
The art of leading people through processes toward agreed-upon objectives in a manner that encourages participation, ownership, and productivity from all involved
An elicitation plan includes
The techniques you'll use, when you plan to use them, and for what purpose
Exploit the physical space
Use something to draw diagrams or create lists
Business Ruless
When a customer says that only certain users perform an activity under specific conditions, he might be presenting a BR
Questionnaires are
an inexpensive way to survey large groups of users to understand their needs
Hold additional discussions to resolve...
any inconsistencies and to fill in any blanks.
Implied requirements
are necessary because of another requirement but aren't explicitly stated
Assumed requirements
are those that people expect without having explicitly expressed them
Interface analysis
entails examining the systems to which your systems connect, reveals functional requirements regarding the exchange of data and services between systems
Plan the elicitation objectives...
for the entire project and the objective for each planned elicitation activity
For observations in agile,
have the user demonstrate only the specific tasks related to the forthcoming iteration
For observations, select
important or high-risk tasks and multiple user classes
If you are new to an application domain,
interviews with experts can help you get up to speed quickly
Imagine yourself learning the user's job,
or actually do the job under the user's direction
The most useful documentation includes
requirements specifications, business processes, lessons-learned collections, and user manuals for existing or similar applications
Soon after each activity,
share the consolidated notes with the participants and ask them to review them to ensure that they accurately represent the session
Probe around...
the exceptions. What could prevent the user from successfully completing a task? How should the system respond to various error conditions?
Document...
the source of each requirement so that you can obtain further clarification if needed and trace development activities back to specific customer origins
Goal of elicitation is
to accumulate a shared understanding of requirements that is good enough to let construction of the next release or increment proceed at an acceptable level of risk
Phrase questions...
to avoid leading customers down an unintended path or a specific answer
Elicitation is used
to discover business, user, functional, and nonfunctional requiremtns, along with other types of information.
To facilitate clear communication,
use the vocabulary of the business domain instead of forcing customers to understand technical jargon
Observing users helps to
validate information collected from other sources, identify new topics for interviews, see problems with the current system
