8 Requirements Elicitation Tips You Should Know
/Early defect fixes are typically two orders of magnitude cheaper than late defect fixes, with early requirements and design defects typically leaving more serious operational consequences - US Department of Defence.
The science and art of requirements elicitation is central to building systems that are acceptable to users but the skills required to do it effectively cannot be learnt in one day. Business analysts often have to deal with the volatile nature of requirements, scope creep and the difficulties inherent in ensuring that stakeholder groups have a common understanding of requirements. Requirements elicitation at its core, is difficult to accomplish.
Academic literature is rife with reasons why elicitation is difficult to do effectively (See Why are Software Projects so Difficult?). The quote from Fred Brooks (See No Silver Bullet: Essence and Accidents of Software Engineering, 1987) concisely describes the requirements dilemma:
The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function to perform for the client is the iterative extraction and refinement of product requirements.
This post is a compilation of 8 tips you can apply to improve the outcome of your requirements elicitation effort.
1. Link Requirements To Business Objectives
In eliciting requirements, always keep your eyes on business objectives – never forget the problem you are trying to solve and whom you are solving it for.
Start by defining high-level business requirements which describe the overall goals and needs of the organization, before moving on to stakeholder requirements and solution requirements, which may be functional or non-functional. This will ensure that low-level requirements and eventually product features, are always associated with specific business objectives and that the business can track ensuing benefits.
2. Consider Data Requirements
In addition to the requirements discussed above, data, along with other transition requirements, should be discussed during elicitation sessions.
Ask stakeholders questions that will clarify entities, relationships and their attributes. Let's say discussions with stakeholders reveal entities such as order, customer, product and category. Dig further by asking questions like:
How many categories can a product have?
How many products can be linked to one order?
Such questions create a deep understanding of the domain and form the basis of data analysis and modelling.
3. Keep Things In Scope
Discussions with stakeholders should be centred on only those issues that fall within the scope of business objectives; requirements should not address too little or too much.
In keeping to scope, keep business objectives in mind and separate key issues from noise. Stakeholders will often propose requirements that promote their own activities or perspectives, which may be out of scope.
Design issues for instance, are considered out of scope and should not be addressed during elicitation sessions since they detract from the core objective, which is to identify what the real business needs are. Design emphasizes what developers need to build applications and may not reflect users' real needs.
4. Do Not Ignore Politics
Politics is everywhere – prepare for it, understand it and deal with it. Requirements are products of contributions from different individuals with varying needs, interests and goals. Politics can lead to the interests of certain stakeholders being placed above others, with the likely consequence of delivering a solution that does not reflect a balanced view of users' requirements.
Ignoring turf wars without managing them can be detrimental to the success of your project.
5. Manage Stakeholders
Start by identifying all relevant stakeholders, making sure that each party is adequately represented. Document the requests of each stakeholder category and ensure that you understand their underlying feelings about the project - this will help you develop a strategy for managing them.
Considering only one stakeholder group implies that the requirements you elicit will be biased towards the views, preconceptions and interests of only that stakeholder group. One key responsibility of analysts is facilitating understanding between and within groups by ensuring that all views are considered in fairness.
6. Let The Stakeholder Be The Expert
Have the humility to listen to stakeholders and learn from them. The source of the requirements is usually the expert so take the time to listen, learn and understand stakeholders' requirements.
7. Allow Sufficient Time For Requirements Elicitation
In our fast-paced and dynamic world, most projects are under extreme time-pressure to deliver business value. Granting a 2-week window to elicit requirements for a project expected to last for more than 6 months is a potential recipe for disaster.
Elicitation should not be approached as an activity to be concluded or limited to one phase of the project but should instead, be re-visited even after modelling and design have begun. This is because the art of eliciting requirements, which involves interaction with stakeholders and the environment, is not a passive act. Requirements elicitation continually alters reality and reveals information that needs to be analyzed.
8. Plan For Requirements Volatility
Requirements by their nature, are extremely volatile. They evolve over time, meaning that what stakeholders wanted yesterday will not necessarily be what they want tomorrow. New knowledge unfolds everyday as the project progresses. Organizational structures, policies and processes also change with time, all of which influence existing requirements.
Agile methodologies are designed to anticipate and embrace change. Planning for and managing change proactively will ensure that the negative effects of changing requirements are curbed.
Don't forget to leave a comment below.
Reference
Issues in Requirements Elicitation
ABOUT THE AUTHOR
This post was contributed by Melisa Marzett, specialized in business writing. Melisa has written a lot of articles which can be viewed here. Connect with her on Google+.
