What are the most effective ways to elicit requirements for a high-performance system?

What's the best way to avoid wasting the customer's time and money: two-fold understanding. What do you want? What are my limitations? So often, customers have an idea of what they want, but after TRUE analysis, they need something radically different. In '07, I wrote a payroll program. The contract form picked me because I know Excel and that's what the customer wanted. But, as the system requirements were discussed, they wanted much more. I finished the copy/paste automation for which I'd been hired, and advised them to get a database programmer to finish the job. Excel just didn't have the horses to do everything they wanted.

Eliciting high-performance system requirements involves engaging stakeholders, analyzing the existing system, collaborating with domain experts, benchmarking, using performance modeling, and maintaining feedback loops to ensure robust requirements that align with performance expectations.

Know, understand, and document: 1.) What the “need” is. 2.) What the “why” is. 3.) Answer is the juice worth the squeeze question - complete a business case of the pros, the cons, and the lessons that others have learned or burned trying. 4.) And most importantly - “who” is funding the payroll to get whatever done before you do anything.

Remember that the requirements must fit the future state of the business, which may be different from today's situation. If the future system is to be designed, the business's visions and plans are important to take into account.

One of the techniques we use at GE, is GENBA walk. Basically, witnessing the daily operations of the end user..with them walking us through the AS-IS process while the Business Analysts prepare a VSM ( Value stream mapping for the process). Breaking up the process in steps and identifying waste and downtime in each step is key in identifying and eliciting requirements for an improved or new TO-BE solution. Look for simplification, elimination and automation. And ofcourse prioritising the requirements is a must. Hence we should break up the requirements into MUST-Haves and NICE-to Haves

Any existing documentation in any form that describes the context of the system or project is always helpful to go through before requirements elicitation

Depending on an environment and circumstances BA may choose different elicitation techniques. When new project is about building new product aka greenfield, then you may start with survey techniques (workshops, interview, focus-groups, surveys). If you are working with brownfield you may use document-centric techniques (system archeology, document analysis, interfaces analysis etc.). If stakeholders are struggling with defining clear ideas what should be developed you may suggest creative techniques (brainstorming, 6 thinking hats etc.) If the product has already been developed and you are interested in business processes optimization, you may try observation techniques (shadowing, observation itself, learning etc.)

The choice of the right techniques for eliciting requirements for a high-performance system is a critical decision that impacts the success of the project. It should be made based on a careful assessment of the project's specific context, objectives, and constraints. Selecting the right technique enhances the chances of delivering a high-performance system that meets user expectations and aligns with business goals. Important to keep in mind and check every time a technique is used its accuracy and relevance, level of stakeholder engagement, clarity and understanding for the purpose of its use, efficiency, adaptability, compatibility, compliance, consistency or if it a tailored approach is needed for the requirement elicitation process.

Analysts should make sure that they acquire knowledge about the stakeholder and their role in the system which will help them decide what approach to use for requirements elicitation.

Using KANO-model for prioritization is a great approach. Define for every requirement level of stakeholders satisfaction and developers efforts. You will get 4 categories: - desired & quick to develop - desired & difficult to develop - not that desired but quick to develop - not that desired & difficult to develop (this category can stay at the bottom of the backlog)

It is always best to get the priority and urgency of requirements from the stakeholders themselves and do internal planning for categorizing requirements.

Having a peer review of your requirements before your final stakeholder review has proven most valuable. Having that extra set of eyes helps to catch details that might have been missed.

It's totally make sense to differentiate validation process for single requirements and set of requirements for the whole product. For single requirements it's important to put focus on adequacy, understandability, completeness. Looking at set of product requirements it's important to pay attention on consistency and traceability.

I usually create documents like the BRD and SRS which contain the requirements and their description along with assumptions, scope etc. and then get these reviewed and approved by the client.

When I see or hear the word “performance,” I immediately think Non-functional requirements. I learned this lesson the hard way. I thought I had rock solid requirements and while yes, the solution technically met those requirements, it was slower than molasses (which is NOT OK for a mobile application). To have a performant system, you must elicit the supporting non-functional requirements, which as all seasoned Business Analysts know, is the hardest type to nail down. And those requirements must be measurable.

When gathering requirements for high-performance systems, don't forget to think green! Consider the environmental impact and aim for energy-efficient and sustainable solutions that not only deliver speed but also benefit the planet. 🌱🚀

Building rapport with SMEs is advantageous for Business Analysts as it facilitates better communication, trust, collaboration, and ultimately leads to more accurate and tailored requirements, contributing to the success of the project. A strong relationship often leads to deeper insights into the subject matter. SMEs are more inclined to provide detailed information and share tacit knowledge that might be crucial for requirements. When you build rapport, you gain the trust of SMEs, which enhances your credibility. They are more likely to accept your guidance and trust your analysis. You can build trust through; active listening, asking open-ended questions, respecting their expertise and demonstrating their value.

A crucial element in excelling at requirement gathering is the effective management and engagement of stakeholders. The process begins with identifying all relevant stakeholders for the areas requiring requirements gathering. Subsequently, categorize these stakeholders, assigning specific responsibilities and importance to each one. Distinguish between those you'll depend on for providing detailed information and those responsible for verifying the gathered data. Finally, it is of utmost importance to ensure that the requirements are officially signed off by the appropriate stakeholders to guarantee their validity and alignment with the project's objectives.

There are numerous other considerations to take into account, but the following key aspects should be highlighted: - iteration, - balancing these requirements with other project constraints and user needs, - collecting user feedback, - and fostering communication and collaboration among stakeholders, development teams, and performance experts.

In pursuit of high-performance system requirements, benchmarking serves as an invaluable strategy to gain insights into performance standards and establish achievable objectives. Prototypes and Proof of Concepts (POCs) can further aid in visually comprehending the system's capabilities. In my extensive experience, I have also sought the counsel of experts, fostered iterative feedback, and conducted scenario-based analyses to refine performance specifications. The process of gathering requirements is inherently iterative, necessitating continual communication with stakeholders. Equally critical is the documentation and validation of requirements, ensuring their alignment with the precise performance expectations of the system.

To avoid scope creep, it is best to define the scope in a document in the beginning of the project and get it approved by the client. I faced this situation during a recent project involve a digital supply chain solution which got dragged beyond the budget and timeline due to a non clearly defined scope.