Mọi sinh viên phần mềm đều biết về vòng đời phát triển phần mềm.

Chương trình Khoa học máy tính dạy điều đó và mọi người quản lí dự án và người phát triển đều biết rằng họ phải tuân theo các pha vòng đời. Dù bạn là người phát triển mới vào nghề làm việc trên dự án đầu tiên hay là người phát triển có kinh nghiệm, bạn bao giờ cũng tuân theo vòng đời. Ít nhất, theo lí thuyết nhưng trong thực hành, mọi người có thể không phải bao giờ cũng theo nó. Khi họ không có thời gian, họ bỏ qua một pha. Khi dự án bị chậm, người quản lí dự án ra lệnh cho tổ bắt đầu viết mã, bỏ qua pha thiết kế hay nhảy qua pha kiểm thử. Ngay cả khi họ tuân theo các pha vòng đời, họ không kết thúc hoàn toàn nó. Từng pha chấm dứt với việc tạo ra tài liệu hay sản phẩm để ghi lại công việc và quyết định đã được thực hiện. Những tài liệu này phải được kiểm nghiệm về tính đầy đủ trước khi bắt đầu pha tiếp nhưng phần lớn các tổ thường vội vàng đi tiếp thay vì hoàn thành pha tương ứng.

Vòng đời phát triển bao giờ cũng bắt đầu với nhu cầu khách hàng. Đây là lí do tại sao bạn bắt đầu dự án phần mềm. Không có khách hàng, không có dự án. Hiểu nhu cầu của khách hàng là hoạt động quan trọng nhất của dự án phần mềm. Tất nhiên, một số khách hàng thạo việc giải thích nhu cầu của họ nhưng một số lại không. Phần lớn khách hàng sẽ giải thích các vấn đề doanh nghiệp của họ và muốn tổ giải quyết chúng. Để làm điều đó, tổ dự án phải để thời gian để hiểu vấn đề doanh nghiệp nhưng phần lớn các tổ phần mềm lại bỏ qua sự kiện này. Họ lẫn lộn điều khách hàng nói là yêu cầu thực. Không hiểu rõ nhu cầu của khách hàng mà vội phát triển phần mềm là lí do then chốt tại sao dự án phần mềm thường thất bại. Tổ  dự án không biết rằng khách hàng thường diễn đại nhu cầu của họ theo thuật ngữ doanh nghiệp của họ, thỉnh thoảng họ trộn lẫn điều họ cần với điều họ muốn. Thỉnh thoảng họ thậm chí trộn lẫn điều họ muốn với giải pháp họ tin sẽ giải quyết được cho vấn đề của họ.

Để chấm dứt lẫn lộn này, tổ dự án phải có kĩ sư yêu cầu hay người phân tích doanh nghiệp làm việc với khách hàng để hiểu vấn đề của họ và làm tài liệu chúng trong “Tài liệu yêu cầu khách hàng.” Đây KHÔNG phải là bản Đặc tả yêu cầu phần mềm (SRS) như nhiều người phát triển thường nghĩ. Bằng việc viết ra điều khách hàng nói, kĩ sư yêu cầu chứng tỏ việc hiểu về yêu cầu như được khách hàng phát biểu. “Tài liệu yêu cầu khách hàng” này chỉ là bằng chứng rằng nhu cầu khách hàng đã được thu thập và được hiểu. Điều này cho khách hàng cảm giác thoải mái rằng họ đã được lắng nghe và rằng tổ phần mềm có tri thức để làm việc trên giải pháp. “Tài liệu yêu cầu khách hàng” phải được kiểm điểm, phân tích, kiểm ngiệm và chấp thuận bởi khách hàng trước khi nó được biến đổi thành bản “Đặc tả yêu cầu phần mềm” (SRS) điều được viết cho tổ phát triển. Đây là kết quả của pha yêu cầu và chỉ khi nó được kiểm nghiệm đầy đủ và được chấp thuận, tổ mới có thể tiến sang pha tiếp.

Hoạt động kiểm nghiệm yêu cầu là mô tả về cái được sản xuất ra và cách nó sẽ làm việc để đảm bảo rằng tổ hiểu điều khách hàng cần. Thỉnh thoảng điều quan trọng là phát triển bản mẫu ở pha này để cho các yêu cầu có thể dễ dàng được hiểu bởi cả người dùng và người phát triển. Bản mẫu có thể đơn giản là dãy các màn hình được tạo ra cho người dùng thấy hay một ứng dụng nhỏ để trình bày một quan niệm về cách phần mềm sẽ được xây dựng. Điều quan trọng là ở chỗ có thảo luận giữa những người phát triển và khách hàng để phát biểu chính xác các yêu cầu và thoả thuận về cái gì sẽ được sản xuất ra.

Kĩ năng làm việc với khách hàng là kĩ năng quan trọng nhất mà nhiều người phát triển không có. Thảo luận với khách hàng để hiểu nhu cầu của họ và làm tài liệu về các nhu cầu khách hàng không phải là nhiệm vụ dễ dàng. Việc phân tích điều khách hàng nói và phân biệt giữa điều họ cần và điều họ muốn là kĩ năng khác mà nhiều người phát triển không có. Biến đổi các yêu cầu doanh nghiệp của khách hàng thành đặc tả yêu cầu phần mềm là kĩ năng khác mà ít người có. Không may, phần lớn các chương trình đào tạo khoa học máy tính chỉ hội tụ vào tri thức lập trình bỏ qua các hoạt động vòng đời khác. Ngay cả vai trò của kĩ sư yêu cầu (cũng được gọi là người phân tích doanh nghiệp, người phân tích hệ thống) thậm chí không được nhắc tới trong sách giáo khoa trong khi các công ti vẫn mong đợi người phát triển phần mềm hay người quản lí dự án thực hiện chức năng này. Ngày nay chỉ ít chương trình kĩ nghệ phần mềm dạy kĩ năng này. Câu hỏi của tôi là tại sao một vai trò quan trọng mà có thể xác định ra thành công của dự án lại không được dạy kĩ hay không được biết rõ?

—-Enlish version—-

Requirements Engineer

Every software student knows about the software development life cycle. Computer Science program teaches it and every project manager and developer know that they must follow the life cycle phases. Whether you are an entry level developer working on first projects or experienced developer, you always follow the life cycle. At least, in theory but in practice, people may not always follow it. When they do not have time, they skip a phase. When the project is late, project manager orders the team to start coding, ignores design phase or skips testing phase. Even when they follow the lifecycle phase, they did not completely finish it. Each phase ends with the creation of a document or product to record the work and decisions that were made. These documents must be validated for completeness before starting the next phase but most teams often hurrying to move on rather than complete the phase accordingly.

The development life cycle always starts with the customer needs. This is the reason why you start a software project. Without customer, there is no project. Understand customer’s need is the most important activity of software project. Of course, some customers are good at explaining their needs but some are not. Most customers will explain their business problems and want the team to solve it. In order to do that, the project team must takes time to understand the business problems but most software teams often ignore this fact. They confuse what customer said is the real requirements. Without a clear understand of customer’s needs but hurry to develop software is the key reason why software projects often fail. They do not know that customers often express their needs in term of their business, sometime they mix what they need with what they want. Sometime they even mix what they want with solution that they believe will solve their problems.

To stop this confusion, project team must have a requirements engineer or business analyst to work with customers to understand their problems and document them in a “Customer requirements document”. This is NOT a Software Requirements Specification (SRS) as many developers often thought. By write down what the customer say, the requirements engineer demonstrates the understanding of the requirements as stated by the customer. This “Customer requirements document” is only a proof that the customer needs have been collected and understood. This gives the customer a good feeling that they have been listened to and that the software team has the knowledge to work on the solution. The “Customer requirements document” must be reviewed, analyzed, validated, and approved by the customer before it is transformed into a “Software Requirements Specification” (SRS) which is written for the development team. This is the result of the requirements phase and only when it is fully validated and approved, the team can move to the next phase.

A requirements validation activity is a description of what is to be produced and how it will work. To ensure that the team understands what customer needs. Sometime it is important to develop a prototype at this phase so that the requirements can easily be understood by both the users and the developers. The prototype can be as simple as a sequence of screen created for the users to see or a small application to demonstrate a proof of concept on how the software will be built. The important thing is that there is discussion between the developers and the customer to accurately state the requirements and agree what will be produced.

The skill of working with customer is the most important skill that many developers do not have. The discussion with customers to understand their needs and document into customer requirements is not an easy task. The analysis of what customer said and distinguishes between what they need and what they want is another skill that many developers do not have. The transformation of customer business requirements into a software requirements specification is another skill that few have. Unfortunately, most computer science training programs only focus on programming knowledge over other life cycle activities. Even the role of the requirements engineer (also called business analyst, systems analyst) is not even mention in text books as companies still expect software developers or project managers to perform this function. Today only few Software Engineering programs teach this skill. My question is why an important role that can determine a project success is not well taught or well known?