Cách viết yêu cầu IT hiệu quả theo 4 quy tắc đơn giản của Thomas & Angela Hathaway

• Tác giả: Thomas Hathaway
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Cách viết yêu cầu hiệu quả cho Công nghệ Thông tin - Đơn giản thôi!
• Loại tài liệu: Sách
• Năm xuất bản: 2016

Tóm tắt

I. Tổng quan về cách viết yêu cầu IT hiệu quả

Viết yêu cầu hiệu quả cho IT là kỹ năng cốt lõi của mọi chuyên gia phân tích nghiệp vụ. Tài liệu yêu cầu chất lượng giúp dự án IT triển khai đúng hướng, giảm thiểu rủi ro và tiết kiệm chi phí. Theo Thomas và Angela Hathaway, nguyên nhân gốc rễ của hầu hết thất bại dự án nằm ở yêu cầu kém chất lượng. Khi yêu cầu không rõ ràng, nhóm phát triển hiểu sai ý nghĩa. Kết quả là sản phẩm không đáp ứng mong đợi của người dùng. Bốn quy tắc đơn giản có thể cải thiện đáng kể chất lượng yêu cầu IT. Quy tắc đầu tiên yêu cầu sử dụng câu hoàn chỉnh, đơn giản và có cấu trúc rõ ràng. Quy tắc thứ hai tập trung vào xác định nhu cầu nghiệp vụ thực sự. Quy tắc thứ ba giữ yêu cầu nằm trong phạm vi dự án. Quy tắc cuối cùng tìm và sửa các yêu cầu mơ hồ. Mỗi quy tắc đều có bài tập thực hành đi kèm để củng cố kiến thức.

1.1. Tại sao yêu cầu IT chất lượng thấp là vấn đề lớn

Hầu hết các dự án IT thất bại đều có điểm chung: yêu cầu không rõ ràng. Khi yêu cầu mơ hồ, nhà phát triển phải đoán ý nghĩa. Điều này dẫn đến sản phẩm không đúng mong đợi. Thiệt hại bao gồm thời gian, tiền bạc và niềm tin của khách hàng. Quản lý sự không chắc chắn là yếu tố then chốt. Mọi người trong dự án đều phải hiểu yêu cầu theo cùng một cách. Nếu không, dự án sẽ đi chệch hướng ngay từ đầu. Giải pháp nằm ở quy trình viết yêu cầu chuẩn hóa và có hệ thống.

1.2. Vai trò của tài liệu Question File trong dự án

Question File là một trong những tài liệu đơn giản nhưng quan trọng nhất của dự án. Tài liệu này ghi lại danh sách những gì chưa biết. Mỗi câu hỏi cần được ghi ngày để theo dõi tiến trình. Cột "Ai" xác định người có kiến thức và thẩm quyền trả lời. Cột "Trả lời" ghi lại câu trả lời hoặc giả định. Khi không có câu trả lời kịp thời, nhóm làm việc dựa trên giả định đã ghi nhận. Phương pháp này giúp giảm thiểu rủi ro và giữ dự án đi đúng hướng. Mọi giả định cần được thông báo cho các bên liên quan.

II. Các vấn đề phổ biến khi viết yêu cầu IT

Nhiều chuyên gia phân tích gặp khó khăn khi viết yêu cầu IT. Nguyên nhân chính là sự mơ hồ trong ngôn ngữ tự nhiên. Cùng một câu có thể được hiểu theo nhiều cách khác nhau. Người viết nghĩ rằng đã rõ ràng nhưng người đọc lại hiểu khác. Đây là vấn đề chủ quan của ngôn ngữ. Thêm vào đó, nhiều người viết yêu cầu nhầm lẫn giữa "cái gì" và "như thế nào". Họ mô tả giải pháp công nghệ thay vì nhu cầu nghiệp vụ. Điều này giới hạn lựa chọn và có thể bỏ qua giải pháp tốt hơn. Phạm vi dự án cũng thường bị mở rộng không kiểm soát. Yêu cầu nằm ngoài phạm vi tạo ra hiện tượng "scope creep". Dự án bị kéo dài, vượt ngân sách và không đạt mục tiêu ban đầu. Nhận diện sớm các vấn đề này là bước đầu tiên để cải thiện chất lượng yêu cầu.

2.1. Tính chủ quan của ngôn ngữ tự nhiên

Ngôn ngữ tự nhiên luôn mang tính chủ quan. Mỗi người đọc hiểu một câu theo cách riêng dựa trên kinh nghiệm và kiến thức. Ví dụ, câu "hệ thống phải nhanh" có thể hiểu là 1 giây hoặc 1 phút. Sự mơ hồ này là nguyên nhân gốc rễ của nhiều vấn đề yêu cầu. Để khắc phục, cần sử dụng tiêu chí đo lường cụ thể. Thay vì viết "nhanh", nên viết "phản hồi trong vòng 2 giây". Việc kiểm tra chéo với chuyên gia lĩnh vực giúp phát hiện điểm mơ hồ. Sử dụng công cụ đánh giá readability cũng hỗ trợ kiểm tra mức độ dễ hiểu.

2.2. Nhầm lẫn giữa nhu cầu nghiệp vụ và giải pháp công nghệ

Nhiều người viết yêu cầu bị hấp dẫn bởi công nghệ mới. Họ mô tả giải pháp trước khi hiểu rõ vấn đề nghiệp vụ. Điều này vi phạm nguyên tắc "What-not-how". Khi yêu cầu gắn liền với công nghệ cụ thể, nó trở nên lỗi thời nhanh chóng. Giải pháp tốt nhất là tách biệt nhu cầu khỏi cách triển khai. Đầu tiên, xác định rõ nghiệp vụ cần gì. Sau đó mới xem xét công nghệ nào phù hợp nhất. Cách tiếp cận này mở ra nhiều lựa chọn giải pháp hơn. Nó cũng giúp dự án linh hoạt khi công nghệ thay đổi.

III. Bốn quy tắc vàng để viết yêu cầu IT hiệu quả

Bốn quy tắc đơn giản giúp cải thiện chất lượng yêu cầu IT đáng kể. Quy tắc một: sử dụng câu hoàn chỉnh theo nguyên tắc KISS. Câu hoàn chỉnh buộc người viết suy nghĩ trọn vẹn về ý tưởng. Chủ ngữ, vị ngữ và tân ngữ rõ ràng giúp loại bỏ sự mơ hồ. Quy tắc hai: xác định nhu cầu nghiệp vụ trước khi nghĩ đến giải pháp công nghệ. Điều này đảm bảo yêu cầu tập trung vào "cái gì" thay vì "như thế nào". Quy tắc ba: giữ yêu cầu nằm trong phạm vi dự án. Mỗi yêu cầu phải liên quan trực tiếp đến mục tiêu dự án. Loại bỏ những yêu cầu vượt phạm vi ngay từ đầu. Quy tắc bốn: tìm và sửa các yêu cầu mơ hồ. Sử dụng kiểm tra bàn, đánh giá ngang hàng và đọc lại nhiều lần. Áp dụng đầy đủ bốn quy tắc này giúp tài liệu yêu cầu dễ hiểu hơn cho mọi bên liên quan.

3.1. Nguyên tắc KISS và câu hoàn chỉnh

KISS là viết tắt của "Keep It Simple, Stupid". Nguyên tắc này yêu cầu viết câu đơn giản, dễ hiểu. Một câu hoàn chỉnh bắt buộc người viết suy nghĩ đầy đủ. Nó phải có chủ ngữ, vị ngữ và ý nghĩa trọn vẹn. Câu ngắn giúp người đọc nắm bắt nhanh chóng. Tránh sử dụng câu phức tạp với nhiều mệnh đề. Mỗi câu nên truyền đạt một ý tưởng duy nhất. Cách tiếp cận này loại bỏ sự nhầm lẫn ngay từ khâu viết. Nó cũng giúp kiểm tra chất lượng yêu cầu dễ dàng hơn. Bài tập thực hành cho thấy câu hoàn chỉnh giảm đáng kể hiểu sai.

3.2. Kỹ thuật kiểm tra và đánh giá yêu cầu

Kiểm tra bàn là kỹ thuật đọc lại yêu cầu một cách cẩn thận. Người đọc đặt mình vào vị trí người dùng để phát hiện điểm mơ hồ. Đánh giá ngang hàng sử dụng nhiều cặp mắt kiểm tra cùng lúc. Mỗi người đọc yêu cầu và giải thích theo cách hiểu của họ. Sự khác biệt trong cách hiểu chỉ ra điểm cần sửa. Công cụ readability index giúp đánh giá mức độ dễ đọc của văn bản. Viết đúng cấp độ đọc hiểu của đối tượng mục tiêu rất quan trọng. Ngữ cảnh đầy đủ giúp loại bỏ sự mơ hồ hiệu quả. Sử dụng từ viết tắt và tiêu chuẩn công ty cũng cải thiện tính nhất quán.

IV. Ứng dụng thực tế và kết luận về yêu cầu IT

Việc áp dụng bốn quy tắc viết yêu cầu IT cần có thời gian và thực hành. Kết quả mang lại rất xứng đáng với nỗ lực bỏ ra. Dự án có yêu cầu chất lượng sẽ triển khai suôn sẻ hơn. Nhóm phát triển hiểu đúng mong muốn, giảm thiểu sửa đổi. Khách hàng nhận được sản phẩm đúng kỳ vọng. Chi phí dự án được kiểm soát hiệu quả. Bắt đầu bằng việc tạo thói quen viết câu hoàn chỉnh. Tiếp theo, luôn đặt nhu cầu nghiệp vụ lên trước giải pháp công nghệ. Duy trì phạm vi dự án rõ ràng và kiểm tra yêu cầu thường xuyên. Sử dụng Question File để ghi lại những gì chưa biết. Áng chừng câu trả lời khi cần và thông báo cho bên liên quan. Cuối cùng, đầu tư vào đánh giá ngang hàng và kiểm tra bàn. Những bước đơn giản này tạo ra sự khác biệt lớn trong chất lượng dự án IT.

4.1. Xây dựng thói quen viết yêu cầu tốt

Thói quen tốt cần thời gian để hình thành. Bắt đầu với mỗi yêu cầu viết một câu hoàn chỉnh đơn giản. Đọc lại câu hỏi: có ai hiểu khác không? Nếu có, viết lại cho rõ ràng hơn. Sử dụng checklist bốn quy tắc trước khi hoàn thiện tài liệu. Dành thời gian kiểm tra với đồng nghiệp. Nhận phản hồi và cải thiện liên tục. Theo thời gian, kỹ năng viết yêu cầu sẽ tiến bộ rõ rệt. Mỗi dự án là cơ hội rèn luyện thêm. Đầu tư vào kỹ năng này mang lại lợi ích lâu dài cho sự nghiệp.

4.2. Tác động đến thành công dự án IT

Yêu cầu chất lượng cao là nền tảng cho dự án IT thành công. Khi mọi người hiểu yêu cầu giống nhau, công việc diễn ra trơn tru. Số lần sửa đổi giảm đáng kể. Thời gian phát triển được rút ngắn. Ngân sách được kiểm soát tốt hơn. Khách hàng hài lòng với kết quả cuối cùng. Đội ngũ phát triển làm việc hiệu quả hơn vì không phải đoán ý nghĩa. Rủi ro dự án giảm ở mọi giai đoạn. Đầu tư thời gian vào viết yêu cầu tốt tiết kiệm gấp nhiều lần về sau. Đây là khoản đầu tư sinh lời cao nhất trong quản lý dự án IT.

Trích đoạn nội dung tài liệu

How to Write Effective Requirements for IT - Simply Put! Use Four Simple Rules to Improve the Quality of Your IT Requirements Thomas and Angela Hathaway © 2016 by BA-Experts. All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. The contents of this publication are provided in good faith and neither The Authors nor The Publisher can be held responsible for any errors or omissions contained herein. Any person relying upon the information must independently satisfy himself or herself as to the safety or any other implications of acting upon such information and no liability shall be accepted either by The Authors or The Publisher in the event of reliance upon such information nor for any damage or injury arising from any interpretation of its contents. This publication may not be used in any process of risk assessment. Ordering Information: Quantity sales. Special discounts are available on quantity purchases by corporations, associations, and others. For details, contact the publisher at ebooks@BusinessAnalysisExperts. The content of this book is also available as a video course. Table of Contents Preface About the Authors Setting the Stage for Writing Effective Requirements Why Do You Need Better Requirements? Managing Uncertainty THE Question File Exercise: The Subjectivity of Language The “Real” Problem with Requirements Requirements and Project Scope Follow the KISS Concept A Complete Sentence Forces a Complete Thought Exercise: Simple, Complete, and Well-Structured Define the Business Need Exercise: Avoiding the Elusive “How” Requirements and Project Scope Keep Your Requirements in Scope Exercise: Relevant Requirement Components Combat Scope Creep from the Start Exercise: Testing the Scope Boundaries Recap of Rules One through Three Exercise: Applying the First Three Rules Finding and Fixing Ambiguous Requirements Who Needs to Understand Your Requirements? Roadblocks to Effective Requirements Desk-Checking Uncovers Ambiguity Exercise: Finding Ambiguity with the SME Use Peer Reviews to Increase Understandability Exercise: Requirement Interpretations Combating the Major Cause of Project Failure Exercise: Revising Requirements to Reduce Ambiguity Best Practices for Improving Understandability Use Acronyms and Corporate Standards Exercise: Using Revisions to Reduce Ambiguity Add Context to Eliminate Ambiguity Exercise: Appropriate Context Reduces Ambiguity Write to the Readability Level of Your Audience Exercise: Using Readability Indices Recap Rule Four Exercise: Rule Four Applied Where Does Your Path Go from Here? Preface Writing requirements is one of the core competencies for anyone in an organization responsible for defining future Information Technology (IT) applications. However, nearly every independently executed, root-cause analysis of IT project problems and failures in the past half-century have identified “misunderstood or incomplete requirements” as the primary cause. This has made writing requirements the bane of many projects. The real problem is the subtle differences between “understanding” another person’s requirement and “sharing a common understanding” with the author. “How to Write Effective Requirements for IT – Simply Put!” gives you a set of 4 simple rules that will make your requirement statements more easily understood by all target audiences. The focus is to increase the “common understanding” between the author of a requirement and the solution providers (e., in-house or outsourced IT designers, developers, analysts, and vendors). The rules we present in this book will reduce the failure rate of projects suffering from poor requirements. Regardless of your job title or role, if you are tasked with communicating your future needs to others, this book will help. It includes optional exercises with instant feedback to increase retention. Who should read this book? Anyone involved in capturing, writing, analyzing, or understanding requirements for Information Technology solutions, including (but not limited to): Subject Matter Experts (SME) Agile Product Owners Business Process Managers Business Process Users Business Analysts and anyone wearing the BA hat Regardless of your title or role, if you are involved in defining requirements, this book is for you. Specifically, this book will give you techniques to: Express business and stakeholder requirements in simple, complete sentences Write requirements that focus on the business need Test the relevance of each requirement to ensure that it is in scope for your project Translate business needs and wants into requirements as the primary tool for defining a future solution and setting the stage for testing Create and maintain a question file to reduce the impact of incorrect assumptions Minimize the risk of scope creep caused by missed requirements Ensure that your requirements can be easily understood by all target audiences Confirm that each audience shares a common understanding of the requirements Isolate and address ambiguous words and phrases in requirements. Use our Peer Perception technique to find words and phrases that can lead to misunderstandings. Reduce the ambiguity of a statement by adding context and using standard terms and phrases How to get the most out of this book? To maximize the learning effect, you will have optional, online exercises to assess your understanding of each presented technique. Chapter titles prefaced with the phrase “Exercise” contain a link to a web-based exercise that we have prepared to give you an opportunity to try the presented technique yourself. These exercises are optional and they do not “test” your knowledge in the conventional sense. Their purpose is to demonstrate the use of the technique more real-life than our explanations can supply. You need Internet access to perform the exercises. We hope you enjoy them and that they make it easier for you to apply the techniques in real life. You can learn more business analysis techniques by visiting the Business Analysis Learning Store to see a wide selection of business analysis books, eCourses, virtual and face-to-face instructor-led training, as well as a selection of FREE Business Analysis training. Meanwhile, please enjoy this book. We appreciate any comments, suggestions, recommended improvements, or complaints that you care to share with us. You can reach us via email at eBooks@businessanalysisexperts. About the Authors Angela and Tom Hathaway have authored and delivered hundreds of training courses and publications for business analysts around the world. They have facilitated hundreds of requirements discovery sessions for information technology projects under a variety of acronyms (JAD, ASAP, JADr, JRP, etc. Based on their personal journey and experiences reported by their students, they recognized how much anyone can benefit from improving their requirements elicitation skills. Angela’s and Tom’s mission is to allow anyone, anywhere access to simple, easy-to-learn business analysis techniques by sharing their experience and expertise in their business analysis training seminars, blogs, books, and public presentations. At BA-EXPERTS we focus exclusively on Business Analysis for “anyone wearing the BA hat™”. We believe that business analysis has become a needed skill for every business professional whether or not they have the title Business Analyst. We have made it our goal to enable anyone wearing the BA hat™ to have access to high quality training material and performance support. Please call us at 702-637-4573, email us, or visit our Business Analyst Learning Store if you are interested in other training offers. Amongst other offers, the content of this book is also available as an eCourse on our website. Setting the Stage for Writing Effective Requirements Why Do You Need Better Requirements? Look at the evolution of a typical business solution from the IT perspective. In the beginning, it all seems so simple. We think we know just what the customer wants (a bicycle), and we have a deadline, so let us get started. Well, as we start to define the solution, we wonder whether the customer might need a little horsepower versus just “person-power” on this device, so maybe we should give it a motor. Once we get into design, obviously, safety becomes a concern, so let us put a cage around it, and, of course, we will need some doors to get in and out. There, is that not much better already? Now, developers love to try the latest and greatest technology, and to them, it is only reasonable that the customer might want to go off-road, like really, really fast, so why not give him the wings he deserves? Finally, since nobody told the testers what to test for, their first test is to try the thing outside the atmosphere, which it would fail if the developers did not quickly attach external fuel tanks. Now, we are cooking with gas and ready to wow the customer with our whiz-bang solution. There is only one small problem, OOOOPS! The customer wanted a simple kid’s tricycle. Looks like we did not really grasp the situation, so while we are at it, we need to explain to our customer why we are 5,000,000% over budget and just a couple of centuries overdue. What is the real problem here? Comprehension and communication, or rather, lack of both. Effectively captured and managed requirements could have avoided this entire mess. So what other good and great things would happen if we had effective, high-quality requirements? The Benefits of Effective Requirements Higher return on technology investments You would expect to see a much better ROI (return on investment) for our development costs. Studies have shown that between a 2-1 and a 10-1 ROI is realistic on IT projects with the right parameters and effective requirements. Increased ability to realize business opportunities Actually, good requirements also improve the business community’s ability to realize new business opportunities because IT is less busy reacting to the problems that bad requirements in previous releases created. Faster reaction to changing business situations If you base your software on good requirements, the business could also react more quickly to the evolving business environment. Decreased frustration and stress for all involved Better requirements would in turn reduce the levels of frustration and stress for everyone from the boardroom to the bathroom. Reduced misunderstandings in communication If the requirements were doing their job, they would improve communications among the stakeholders and thereby reduce misunderstandings. Business perspective has priority over technology Actually giving the business side priority over the technology side might sound like risky business from the IT perspective, but for the business community, this might actually right the ship and restore order to their world that has been lacking since we invented computers. Earlier delivery of business system Fewer unneeded features Lower defect rate Compared with all of the abovementioned benefits, the final 3 almost seem trivial, but, trust me, these three alone would easily pay for the time spent up front many times over. Getting to these effective, high-quality requirements does appear to be non-trivial given that our industry has been struggling with this issue for decades. What is the problem here? Why is it so difficult? Managing Uncertainty What you as the individual-responsible-for-defining-requirements are fighting is a little thing called the “Uncertainty Principle”. If you happen to be knowledgeable about quantum physics, this may sound like old hat to you, but you may be surprised about our take on this. For normal people (i., us non-quantum-physicists), this definition of the uncertainty principle might even be understandable. In the early days of any project, uncertainty may just be the only thing you have in abundance. The process of doing the project is actually one of reducing that uncertainty. Not to eliminate it, unfortunately, because that is impossible; there will always be some uncertainty. (According to a German saying, “Theory is when you know everything and nothing works. Reality is where everything works and you do not know why!”) There will always be some uncertainty, some of which you are aware and some you do not even know about. The real problem here is the pace at which the project reduces uncertainty. The green line shows how we expect uncertainty to drop. As you see, it drops very rapidly at the beginning (this is what we call the “analysis” phase) and then at some point starts to level off. At that point, further analysis is useless, so it is time to “Start Development”.