Having handled dozens of requirements engineering projects throughout my career, I've developed a unique approach that differs from conventional methods. I'd like to share these insights and compare them with traditional approaches.
IT Is Not Just About Technology
One of the greatest lessons from my 30 years in this field is this: IT systems cannot succeed on IT knowledge alone.
Every industry operates under its own unique conditions, and IT solutions are akin to tailoring a suit for each business. However, not every situation requires a tailored suit. Many IT vendors, driven by profit motives, often sell complex "business suits" to clients who might just need casual wear.
Consider this real-world example: An IT vendor once recommended a meal ticket vending machine for an izakaya (Japanese pub). This completely misses the nature of izakaya dining, where customers typically place multiple additional orders throughout their stay. A tablet ordering system would have been more appropriate. This mismatch occurred because the vendor prioritized making a quick sale over thoroughly understanding the client's business operations - a common pitfall in IT implementation projects. This case clearly shows how understanding business operations is crucial for proper system selection.
This principle has guided me to prioritize practical, business-aligned solutions over purely technical implementations. It's a philosophy that underscores my consulting and systems design work.
A Practical Approach to Requirements Gathering
My requirements gathering process begins with stakeholder interviews. Through careful organization of client needs and objective evaluation, unnecessary requirements are filtered out. Additionally, I incorporate potentially necessary requirements while comprehensively examining everything from development to operational methods, creating proposal-level documentation.
Figure 1: Iterative Requirements Gathering Process
This flowchart illustrates our systematic approach to requirements gathering, emphasizing continuous evaluation and refinement.
This process actively utilizes methods such as SWOT analysis. Sometimes, the analysis concludes that an IT system isn't necessary at all. In such cases, I might suggest operational improvements instead, incorporating a consulting perspective.
Real-world Digital Transformation Decisions: A Case Study
Let's examine a hypothetical example: A small retail shop with an elderly owner and predominantly senior customers, processing about 20 transactions daily with an average purchase value of $15. While digital transformation might seem appealing, a deeper analysis is necessary.
Through stakeholder interviews and operational analysis, the conclusion was that introducing a cashless payment system would not provide significant productivity gains. Instead, we recommended minor adjustments to cash handling processes. This highlights an essential truth: sometimes, not implementing IT solutions is the best decision.
A Practical Approach to Requirements Specification
In requirements specification, I conduct additional interviews as needed. Similar to requirements gathering, this involves organizing and evaluating requirements, but with emphasis on setting appropriate performance targets based on business scale and operational metrics (target revenue, access numbers, etc.). Operational costs are prioritized, with detailed examination of system configuration and operational methods.
For documentation, I primarily use tools like PlantUML and Mermaid. These tools enable efficient, text-based diagram creation, making them ideal for agile workflows and integration with version control systems like Git. Additionally, they align seamlessly with Markdown and AI-driven documentation processes.
Commonly used diagrams include:
- Use Case Diagrams: For visualizing user interactions.
- Sequence Diagrams: For understanding processes.
- Component Diagrams: For system architecture visualization.
Industry Parallels and Future Outlook
The system development industry shares similarities with real estate, particularly regarding monetary incentives and sales approaches. This understanding has led me to focus on budget-conscious and scale-appropriate requirements engineering.
In recent years, I've incorporated AI into my workflow, treating it as another perspective rather than an absolute authority. In my consulting and system development practice, I effectively use AI to analyze various data sources including interview transcripts, company information, and existing system documentation to refine requirements. This comprehensive analysis helps identify patterns, potential gaps, and opportunities that might be missed in traditional requirements gathering. However, ultimate decisions still require human judgment and deep understanding of the business context.
While currently operating independently, I share these experiences through blogs to benefit younger engineers, emphasizing that requirements engineering demands understanding business fundamentals beyond technical aspects.
Conclusion
Finding the optimal IT solution requires more than technical expertise - it demands the integration of business owner insights and operational staff perspectives. The key is not to implement the most advanced technology, but to find the most appropriate solution for each specific context.
I encourage readers to apply this comprehensive approach in their own projects. Remember: Sometimes the best technical solution might be no technical solution at all. What matters most is understanding the real needs of your business and its stakeholders.
This mindset, combined with modern tools like AI and systematic requirements engineering processes, can help ensure that your IT implementations truly serve their intended purpose and deliver lasting value.
Top comments (0)