Unit 09 software development life cycles

Tìm hiểu về quy trình phát triển phần mềm (SDLC) trong Unit 09. Khám phá các giai đoạn, mô hình phổ biến & cách áp dụng SDLC hiệu quả cho dự án của bạn.

• Tác giả: Hoang Van Phat
• Người hướng dẫn: Vo Ngoc Mai
• Trường học: University Of Greenwich
• Chuyên ngành: Computing
• Đề tài: Software Development Life Cycle
• Loại tài liệu: Assignment
• Năm xuất bản: 2020-2021

Tóm tắt

I. Khám phá toàn cảnh vòng đời phát triển phần mềm SDLC

Vòng đời phát triển phần mềm, hay Software Development Life Cycle (SDLC), là một quy trình có cấu trúc được sử dụng trong ngành công nghiệp phần mềm. Quy trình này nhằm mục đích thiết kế, phát triển và thử nghiệm phần mềm chất lượng cao. Mục tiêu chính của SDLC là tạo ra một sản phẩm đáp ứng hoặc vượt qua sự mong đợi của khách hàng, hoàn thành trong thời gian và chi phí dự kiến. Quy trình này cung cấp một khuôn khổ rõ ràng, chia nhỏ quá trình phát triển phức tạp thành các giai đoạn dễ quản lý và có thể kiểm soát. Mỗi giai đoạn trong vòng đời phát triển phần mềm đều có các hoạt động và kết quả đầu ra riêng biệt. Việc tuân thủ một mô hình SDLC giúp các nhóm dự án phối hợp hiệu quả, giảm thiểu rủi ro và đảm bảo tính nhất quán trong suốt quá trình thực hiện. Tài liệu nghiên cứu về dự án Tune Source nhấn mạnh tầm quan trọng của việc áp dụng một SDLC phù hợp để đáp ứng các yêu cầu kinh doanh cụ thể. Việc lựa chọn mô hình SDLC (như Waterfall, Agile, Spiral) phụ thuộc vào bản chất, quy mô và các yêu cầu của dự án. Một SDLC được triển khai tốt sẽ giúp tối ưu hóa nguồn lực, cải thiện giao tiếp giữa các bên liên quan và cuối cùng là nâng cao chất lượng phần mềm.

1.1. Định nghĩa chu trình phát triển phần mềm SDLC

Chu trình phát triển phần mềm (SDLC) được định nghĩa là một chuỗi các bước hoặc giai đoạn được xác định rõ ràng mà các kỹ sư phần mềm tuân theo để phát triển và duy trì một phần mềm. Nó bắt đầu từ việc hình thành ý tưởng ban đầu và kết thúc khi phần mềm được rút khỏi thị trường. Các giai đoạn này thường bao gồm: lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai (coding), kiểm thử, và bảo trì. Mỗi giai đoạn tạo ra các sản phẩm bàn giao (deliverables) cần thiết cho giai đoạn tiếp theo. Ví dụ, giai đoạn phân tích yêu cầu tạo ra tài liệu đặc tả yêu cầu, là đầu vào cốt lõi cho giai đoạn thiết kế. Việc áp dụng SDLC đảm bảo rằng quá trình phát triển không diễn ra một cách hỗn loạn mà tuân theo một lộ trình có hệ thống, giúp dễ dàng theo dõi tiến độ và quản lý chất lượng.

1.2. Tầm quan trọng của SDLC trong các dự án công nghệ

Việc áp dụng vòng đời phát triển phần mềm mang lại nhiều lợi ích chiến lược cho các dự án công nghệ. Trước hết, nó cung cấp một cơ chế kiểm soát chặt chẽ đối với dự án. Các nhà quản lý có thể theo dõi tiến độ, phân bổ nguồn lực và đánh giá rủi ro ở từng giai đoạn cụ thể. Thứ hai, SDLC cải thiện sự minh bạch và giao tiếp giữa các thành viên trong nhóm và với các bên liên quan (stakeholders). Mọi người đều hiểu rõ vai trò, trách nhiệm và kỳ vọng của mình. Cuối cùng, nó là nền tảng để đảm bảo chất lượng phần mềm. Bằng cách tích hợp các hoạt động kiểm thử và xác minh vào từng giai đoạn, các lỗi có thể được phát hiện và sửa chữa sớm, giúp giảm chi phí và thời gian khắc phục.

II. Thách thức khi xác định yêu cầu dự án phần mềm

Giai đoạn xác định yêu cầu là một trong những giai đoạn quan trọng và cũng đầy thách thức nhất trong vòng đời phát triển phần mềm. Thành công của một dự án phụ thuộc rất nhiều vào việc hiểu và ghi lại chính xác nhu cầu của người dùng và doanh nghiệp. Thách thức lớn nhất là việc giao tiếp và thấu hiểu giữa các bên. Các bên liên quan (stakeholders) thường không phải là chuyên gia kỹ thuật và có thể gặp khó khăn trong việc diễn đạt nhu cầu của họ một cách rõ ràng và đầy đủ. Ngược lại, đội ngũ phát triển có thể hiểu sai hoặc bỏ sót các yêu cầu quan trọng do khác biệt về ngôn ngữ chuyên môn. Một thách thức khác là sự thay đổi yêu cầu trong quá trình phát triển. Thị trường biến động, chiến lược kinh doanh thay đổi hoặc phản hồi từ người dùng có thể dẫn đến việc phải điều chỉnh các yêu cầu ban đầu. Nếu không được quản lý cẩn thận, những thay đổi này có thể gây ra "scope creep" (phạm vi dự án bị phình to), làm chậm tiến độ và tăng chi phí. Việc phân biệt rõ ràng giữa yêu cầu chức năng (FRs) và yêu cầu phi chức năng (NFRs) cũng là một bài toán phức tạp nhưng cần thiết để xây dựng một hệ thống toàn diện và hiệu quả.

2.1. Nhận diện các bên liên quan stakeholders và vai trò

Trong dự án Tune Source, việc nhận diện các bên liên quan là bước đầu tiên để thu thập yêu cầu. Stakeholders là bất kỳ cá nhân hoặc tổ chức nào bị ảnh hưởng bởi dự án hoặc có thể ảnh hưởng đến kết quả của dự án. Họ bao gồm khách hàng (người dùng cuối), nhà quản lý dự án, đội ngũ phát triển, nhà đầu tư, và thậm chí cả các cơ quan quản lý. Mỗi bên liên quan có những mối quan tâm, kỳ vọng và vai trò khác nhau. Ví dụ, người dùng cuối quan tâm đến tính dễ sử dụng và các tính năng của sản phẩm, trong khi nhà đầu tư tập trung vào lợi nhuận và hiệu quả chi phí. Việc xác định và phân tích vai trò, quyền lợi của từng stakeholder giúp đảm bảo rằng tất cả các góc nhìn quan trọng đều được xem xét, từ đó xây dựng một bộ yêu cầu toàn diện và cân bằng.

2.2. Phân biệt yêu cầu chức năng FRs và phi chức năng NFRs

Yêu cầu của một hệ thống phần mềm được chia thành hai loại chính: chức năng và phi chức năng. Yêu cầu chức năng (Functional Requirements - FRs) mô tả những gì hệ thống phải làm. Chúng xác định các hành vi, chức năng cụ thể của phần mềm. Ví dụ, trong dự án Tune Source, một FR là "Người dùng có thể tìm kiếm bài hát theo tên, nghệ sĩ và thể loại". Ngược lại, yêu cầu phi chức năng (Non-Functional Requirements - NFRs) mô tả hệ thống phải như thế nào. Chúng xác định các thuộc tính chất lượng như hiệu suất, bảo mật, khả năng sử dụng. Một NFR cho Tune Source có thể là "Thời gian tải trang web không được vượt quá 2 giây, ngay cả khi có 20 triệu người dùng truy cập đồng thời". Việc bỏ qua NFRs là một sai lầm phổ biến, có thể dẫn đến một sản phẩm có đủ chức năng nhưng trải nghiệm người dùng kém và không đáng tin cậy.

III. Hướng dẫn các kỹ thuật phân tích yêu cầu phần mềm hiệu quả

Sau khi thu thập, bước tiếp theo trong vòng đời phát triển phần mềm là phân tích yêu cầu. Giai đoạn này sử dụng các công cụ và kỹ thuật mô hình hóa để làm rõ, cấu trúc và xác thực các yêu cầu đã thu thập. Mục tiêu là tạo ra một mô hình hệ thống rõ ràng, dễ hiểu cho cả đội ngũ phát triển và các bên liên quan. Các kỹ thuật phân tích có cấu trúc giúp trực quan hóa hệ thống từ nhiều góc độ khác nhau. Tài liệu về dự án Tune Source đã minh họa việc sử dụng kết hợp các kỹ thuật mô hình hóa cấu trúc và hành vi. Các công cụ như sơ đồ luồng dữ liệu (DFD) và sơ đồ quan hệ thực thể (ERD) là những phương pháp phổ biến trong phân tích có cấu trúc. Chúng giúp mô tả cách dữ liệu di chuyển trong hệ thống và cách các thực thể dữ liệu liên kết với nhau. Việc phân tích kỹ lưỡng giúp phát hiện các mâu thuẫn, sự mơ hồ hoặc thiếu sót trong các yêu cầu ban đầu, đảm bảo rằng thiết kế hệ thống được xây dựng trên một nền tảng vững chắc, góp phần nâng cao chất lượng phần mềm cuối cùng.

3.1. Sử dụng Sơ đồ luồng dữ liệu DFD để mô hình hóa quy trình

Sơ đồ luồng dữ liệu (Data-Flow Diagram - DFD) là một công cụ đồ họa mạnh mẽ dùng để mô tả luồng chảy của dữ liệu qua một hệ thống. DFD tập trung vào các quy trình hoặc hoạt động xử lý dữ liệu, các kho dữ liệu nơi thông tin được lưu trữ, và các thực thể bên ngoài gửi hoặc nhận dữ liệu. Trong tài liệu về dự án Tune Source, DFD được sử dụng để minh họa các chức năng chính như đăng ký tài khoản, tìm kiếm nhạc và thanh toán. DFD có nhiều cấp độ (level 0, level 1, ...), cho phép phân rã hệ thống từ tổng quan đến chi tiết. Điều này giúp các nhà phân tích và nhà phát triển hiểu rõ hệ thống sẽ xử lý thông tin như thế nào mà không bị sa đà vào chi tiết kỹ thuật cài đặt.

3.2. Thiết kế cơ sở dữ liệu với Sơ đồ quan hệ thực thể ERD

Sơ đồ quan hệ thực thể (Entity-Relationship Diagram - ERD) là một công cụ mô hình hóa dữ liệu, minh họa cấu trúc logic của một cơ sở dữ liệu. ERD xác định các thực thể chính trong hệ thống (ví dụ: Khách hàng, Bài hát, Hóa đơn), các thuộc tính của chúng (ví dụ: Tên khách hàng, Tên bài hát) và mối quan hệ giữa các thực thể đó (ví dụ: một Khách hàng có thể mua nhiều Bài hát). Trong dự án Tune Source, ERD đóng vai trò là bản thiết kế cho cơ sở dữ liệu, đảm bảo dữ liệu được tổ chức một cách hợp lý, nhất quán và hiệu quả. Một ERD được thiết kế tốt giúp loại bỏ sự dư thừa dữ liệu và đảm bảo tính toàn vẹn dữ liệu, là nền tảng cho một hệ thống ổn định và có khả năng mở rộng.

IV. Phương pháp thiết kế hành vi phần mềm UML và Pseudocode

Thiết kế hành vi phần mềm tập trung vào việc mô tả cách các thành phần của hệ thống tương tác với nhau và phản ứng với các sự kiện theo thời gian. Đây là một phần không thể thiếu trong giai đoạn thiết kế của vòng đời phát triển phần mềm. Việc đặc tả rõ ràng hành vi của phần mềm giúp đảm bảo hệ thống hoạt động đúng như mong đợi và đáp ứng được các yêu cầu chức năng. Hai công cụ mạnh mẽ thường được sử dụng để đặc tả hành vi là Ngôn ngữ Mô hình hóa Hợp nhất (UML) và mã giả (Pseudocode). UML cung cấp một bộ các sơ đồ trực quan, trong đó Sơ đồ Use Case và Sơ đồ Trạng thái (State Machine) đặc biệt hữu ích cho việc mô tả hành vi. Sơ đồ Use Case mô tả sự tương tác giữa người dùng (actor) và hệ thống, trong khi Sơ đồ Trạng thái mô tả các trạng thái khác nhau mà một đối tượng có thể trải qua. Pseudocode, mặt khác, là một phương pháp mô tả logic của một thuật toán bằng ngôn ngữ tự nhiên, giúp các lập trình viên dễ dàng chuyển đổi thành mã nguồn thực tế. Trong dự án Tune Source, việc kết hợp các kỹ thuật này giúp làm rõ các quy trình phức tạp, từ đó cải thiện chất lượng phần mềm.

4.1. Đặc tả tương tác người dùng qua Sơ đồ Use Case UML

Sơ đồ Use Case là một phần của UML, tập trung vào việc mô tả chức năng của hệ thống từ góc nhìn của người dùng. Nó xác định các "actor" (người dùng hoặc hệ thống bên ngoài) và các "use case" (các hành động mà actor có thể thực hiện). Ví dụ, trong dự án Tune Source, các actor là 'User' và 'Admin'. Các use case của 'User' có thể bao gồm 'Register', 'Login', 'Search Music', 'Download Music'. Sơ đồ này không đi sâu vào chi tiết kỹ thuật mà tập trung vào việc "hệ thống làm gì" thay vì "hệ thống làm như thế nào". Nó là một công cụ giao tiếp tuyệt vời giữa đội phát triển và các bên liên quan phi kỹ thuật, đảm bảo mọi người có cùng một cách hiểu về phạm vi và chức năng của hệ thống.

4.2. Mô tả logic thuật toán bằng Pseudocode và Flowchart

Trong khi UML mô tả hành vi ở mức độ cao, Pseudocode (mã giả) và Flowchart (lưu đồ) đi vào chi tiết logic của từng chức năng. Pseudocode sử dụng cấu trúc của ngôn ngữ lập trình nhưng được viết bằng ngôn ngữ tự nhiên, giúp mô tả các bước của một thuật toán một cách rõ ràng. Ví dụ, pseudocode cho chức năng đăng nhập trong dự án Tune Source sẽ mô tả các bước: Nhận username và password, kiểm tra thông tin trong cơ sở dữ liệu, nếu đúng thì cho phép truy cập, nếu sai thì thông báo lỗi. Flowchart sử dụng các biểu tượng đồ họa để thể hiện cùng một logic đó. Cả hai công cụ này đều giúp lập trình viên hiểu rõ logic cần triển khai trước khi viết mã, giảm thiểu sai sót và đảm bảo các yêu cầu chức năng được thực hiện chính xác.

V. Bí quyết cải thiện chất lượng phần mềm trong vòng đời SDLC

Chất lượng không phải là một giai đoạn riêng lẻ mà là một yếu tố cần được tích hợp trong toàn bộ vòng đời phát triển phần mềm. Việc cải thiện chất lượng phần mềm đòi hỏi một chiến lược toàn diện, bắt đầu từ việc xác định yêu cầu và kết thúc ở giai đoạn bảo trì. Một trong những bí quyết quan trọng nhất là việc truy vết yêu cầu (requirements traceability). Điều này đảm bảo rằng mỗi yêu cầu của khách hàng được liên kết chặt chẽ với các thành phần thiết kế, các dòng mã và các ca kiểm thử tương ứng. Khi có sự thay đổi, nhóm phát triển có thể dễ dàng đánh giá tác động và đảm bảo không có gì bị bỏ sót. Tài liệu dự án Tune Source cũng nhấn mạnh tầm quan trọng của các kỹ thuật đảm bảo chất lượng (Quality Assurance - QA), như đánh giá ngang hàng (peer review) mã nguồn và thiết kế, cũng như các phương pháp kiểm thử tự động. Việc áp dụng các thuộc tính chất lượng phần mềm, như độ tin cậy (reliability) và hiệu quả (effectiveness), ngay từ giai đoạn thiết kế sẽ giúp tạo ra một sản phẩm cuối cùng mạnh mẽ và bền vững.

5.1. Tầm quan trọng của việc truy vết yêu cầu Traceability

Truy vết yêu cầu là quá trình theo dõi và ghi lại vòng đời của một yêu cầu. Nó cho phép liên kết một yêu cầu từ nguồn gốc ban đầu của nó, qua quá trình phát triển và đặc tả, cho đến khi nó được triển khai và kiểm thử. Lợi ích chính của việc này là quản lý thay đổi hiệu quả. Khi một yêu cầu thay đổi, ma trận truy vết sẽ chỉ ra tất cả các phần của hệ thống (thiết kế, mã nguồn, tài liệu, ca kiểm thử) bị ảnh hưởng. Điều này giúp ngăn ngừa các lỗi không mong muốn và đảm bảo tính nhất quán của hệ thống. Nó cũng là một công cụ mạnh mẽ để xác minh rằng tất cả các yêu cầu đã được đáp ứng, không có yêu cầu nào bị bỏ sót, từ đó trực tiếp nâng cao chất lượng phần mềm.

5.2. Các kỹ thuật đảm bảo chất lượng QA trong dự án

Đảm bảo chất lượng (QA) là một tập hợp các hoạt động được thiết kế để đảm bảo rằng quá trình phát triển tuân theo các tiêu chuẩn đã định. QA không chỉ là kiểm thử sản phẩm cuối cùng mà là một quá trình liên tục. Các kỹ thuật QA hiệu quả bao gồm: đánh giá thiết kế, xem xét lại mã nguồn (code review), kiểm thử đơn vị (unit testing), kiểm thử tích hợp (integration testing), và kiểm thử hệ thống (system testing). Trong bối cảnh dự án Tune Source, việc áp dụng các kỹ thuật này giúp phát hiện sớm các khiếm khuyết. Ví dụ, code review giúp các lập trình viên học hỏi lẫn nhau và tìm ra các lỗi logic trước khi mã được tích hợp. Kiểm thử tự động giúp thực thi lại các bài kiểm tra một cách nhanh chóng và nhất quán, đảm bảo các chức năng cũ không bị hỏng khi thêm tính năng mới.

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

iY UNIVERSITYo Z8 'ÿ GREENWICH SBT EC Higher Nationals in Computing UNIT 09: SOFTWARE DEVELOPMENT LIFE CYCLES ASSIGNMENT 2 Assessor name: VO NGOC MAI Learner’s name: HOANG VAN PHAT ID: GCS190614 Class: GCSO805_PPT Subject code: 1631 Assignment due: Assignment submitt 4 UNIVERSITY of io Yas? GREENWICH “BTEC ° nace win LSID, oon ASSIGNMENT 2 BRIEF Qualification BTEC Level 5 HND Diploma in Computing Unit number Unit 9: Software Development Life Cycle Assignment title Undertake a Software Development Lifecycle Academic Year 2020 — 2021 Unit Tutor Vo Ngoc Mai Issue date Submission date | 22/12/2020 IV name and date Submission Format: Format: The submission is in the form of 1 document You must use font Calibri size 12, set number of the pages and use multiple line spacing at 1. Margins must be: left: 1.25 cm; right: I cm; top: I cm and bottom: I cm. The reference follows Harvard referencing system. Submission Students are compulsory to submit the assignment in due date and in a way requested by the Tutors.

The form of submission will be a soft copy posted on http://cms.vn/ Note: The Assignment must be your own work, and not copied by or from another student or from books etc. If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you must reference your sources, using the Harvard style. Make sure that you know how to reference properly, and that understand the guidelines on plagiarism. [f you do not, you definitely get failed Unit Learning Outcomes: LO3 Undertake a software development lifecycle LO4 Discuss the suitability of software behavioural design techniques Assignment Brief and Guidance: Task1 Now your team had been accepted to create the Software to Tune Source.

As a member of a development team, your task now is to produce the requirements for Tune Source. You also need to specify the technique(s) or processes you used in order to get these requirements. Page 2 422) UNIVERSITYof io Yas? GREENWICH “BT EC ° nace win LSID, oon Task 2 Based on the requirements which established in Task1 provide the following diagrams: Use Case, ERD, DFD. which can help to identify more clearly about the system you are going to implement.

Task 3 Based on your understanding about the Tune Source’s requirements in Task1 and Task 2, show how the requirement can be addressed. Your method could include software behavioural specification methods and reliability and effectiveness of software. Task 4 Your client want to improve the software quality. Create a report which shows how software quality could be improved from tracing requirements and programme design.

Page 3 ‘BTEC 4B UNIVERSITY ot 7 GREENWICH 1. sxxan ASSIGNMENT 2 FRONT SHEET Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 9: Software Development Life Cycle Submission date 22/12/2020 Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name HOANG VAN PHAT Student ID GCS 190614 Class GCS0805_PPT Assessor name VO NGOC MAI Student declaration I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a false declaration is a form of malpractice. Student’s signature PHAT Grading grid | P5 | P6 Page 4 tà UNIVERSITY of 4 ‘7 GREENWICH “BT EC.

e ance wes [GIG seat Summative Feedback: Resubmission Feedback: Grade: Assessor Signature: Date: Page 5 sb) UNIVERSITY 2 GREENWICH “BT EC : e ance wes [GIG seat Internal Verifier’s Comments: Signature & Date: Page 6 4 UNIVERSITY of na ‘BTEC Yas? GREENWICH se °e ASSIGNMENT STRUCTURE GUIDE FOR ASSIGNMENT 2 INDIVIDUAL WORK Output: a written report Unit Learning Outcomes: LO3 Undertake a software development lifecycle. LO4 Discuss the suitability of software behavioural design techniques. Assignment Brief and Guidance: Tasks At this stage, you have convinced Tune Source to select your project for development. Complete the following tasks to analyse and design the software.a) Identify the stakeholders, theirs roles and interests in the case study.

Review the requirement definition of the project. Clearly indicate which stakeholder(s) provide what requirements. Discuss the relationships between the FRs and NFRs.b) Discuss the technique(s) you would use to obtain the requirements. If needed, you may state suitable additional assumptions about the project in order to justify the technique(s) that you choose.

® (M3) Discuss how you would trace these requirements throughout the project. Task 2 — Analysis (2) (P6) Analyse the requirements that you identified in Task 1 using a combination of structural and behavioural modelling techniques that you have learnt. Task 3 — Design Based on the analysis result, discuss how you would conduct the design phase: e (P7) Discuss how the user and software requirements are addressed in the design phase. Page 7 42 UNIVERSITY ° ay GREENWICH “BT EC ° nace win LSID, oon e¢ (M5) Discuss how flow chart and pseudocode are used to specify the software behaviour.

¢ (M6) Discuss how UML state machine can be used to specify the software behaviour. Differentiate between FSM And extended FSM using the case study. e (D4) Discuss how the data-driven approach improves the reliability and effectiveness of software. Task 4 — Software quality management e =(M4.a) Discuss two software quality attributes that are applicable to the project.b) Discuss two quality assurance techniques that can help improve the software quality in the project.

e (D3) Discuss how the design techniques and approaches that you have used can help improve the software quality. Page 8 ‘BTEC 42 UNIVERSITY Yas? GREENWICH nace win LSID, oon Learning Outcomes and Assessment Criteria Pass Merit Distinction LO3 Undertake a software development lifecycle D3 Critically evaluate how the use of the function design paradigm in the software development lifecycle can improve software quality. P5 Undertake a software M3 Analyse how software investigation to meet a requirements can be business need. traced throughout the software lifecycle.

P6 Use appropriate M4 Discuss two software analysis approaches to improving tools/techniques to carry software quality. out a software investigation and create supporting documentation. LO4 Discuss the suitability of software behavioural D4 Present justifications design techniques of how data driven software can improve the reliability and effectiveness of software. P7 Explain how user and M5 Suggest two software software requirements behavioural specification have been addressed.

methods and illustrate their use with an example. M6 Differentiate between a finite state machine (FSM) and an extended- FSM, providing an application for both. Page 9 ° đà UNIVERSITY Su GREENWICH “BT E ° pmax ith 8g. — Table of Contents Unit 09: Software Development Life Cycles ASSIGNMENT 2.

Undertake a softwareinvestigation to meet abusiness need.a) Identify the stakeholders, theirs roles and interests in the case stUd|y. Introduce the stakeholders 2. Identify the stakeholders 2. Definition the stakeholders, their roles and interests 2.

Roles of the stakeholders 2. Benefits of the stakeholders 3. FRs and NFRs 3. Definition of FRs 3.

Definition of NFRs 4. Relationships between the functional requirement and non-functional.b) Discuss the technique(s) you did use to obtain the requiremens. c 22t vn Hye rrn 1. Introduce to the technique 2.

Five requirement gathering techniques 2. Conclusion P6 Use appropriate software analysis tools/techniques to carry out a software investigation and create supporting documentation. Introduction to software analysis tools 26 1. Benefits of Software Analysis Tools 26 1.

Structured analysis and design techniques 29 2.1 DFD Iv0 of Tune Source project 29 2.2 DFD v1 of the Tune Source project 30 2. _ ERD of the Tune Source project 32 2. Flowchart of the Tune Source project 33 Page 10 422) UNIVERSITYof io Yas? GREENWICH “BT EC ° nace win LSID, oon 2. Pseudocode 35 P7 Explain how user and software requirements have been addressed.

Introduction about user and software requirements 36 1. Identifying the Major Use Cases 37 3. Elaborating on the Use Cases 40 3. Register Use Cases 40 3.

Music Use Cases 41 REFERENCES 43 Page 11 4 UNIVERSITY ef io Yas? GREENWICH “BTEC ° pmax ith 8g. Undertake a softwareinvestigation to meet abusiness need.a) Identify the stakeholders, theirs roles and interests in the case study. Introduce the stakeholders In your work or volunteering — or other areas of your life — you may have noticed that some individuals and groups have quite a lot of power in how your organisation is run or how services are provided. Power means the potential to influence but whether people use this power will depend on what interest they have in influencing the organisation.

Some people have little power but a lot of interest in how the organisation is run and what it does. These individuals or groups could be service users, volunteers and employees, funders, the general public or the media, to name a few. These are some of the many stakeholders of an organisation, and they can be very influential in how an organisation meets its mission, how it’s viewed in the community, whether it receives funding, or how well it provides its services. There are many reasons why it is important not to neglect stakeholders: ensuring that people are consulted can help less powerful groups have a voice in decision making but equally, some groups may decide to campaign against a decision made by staff or trustees.

These groups may be powerful enough —or rally enough support — to reverse decisions or to prompt resignations. A recent example of this is a community shop in south-west England where the community argued against the management committee’s decisions and all the committee members felt they had to resign. Identify the stakeholders 2. Definition the stakeholders, their roles and interests A stakeholder is an individual or group that has a legitimate interest in a company, organization, or business.

The Stanford Research Institute defines stakeholders as “those groups without whose support the organization would cease to exist.” Stakeholders can affect or be affected by the actions (or inactions) of a business, and they can exist both within and outside of a business. Page 12 2 UNIVERSITYof a7 GREENWICH "1. A stakeholder is either an individual, group or organization who is impacted by the outcome of a project. They have an interest in the success of the project.Roles of the stakeholders Direct the Management: The stakeholders can be a part of the board of directors and therefore help in taking actions.

They can take over certain departments like service, human resources or research and development and manage them for ensuring success. They Bring in Money: Stakeholders are the large investors of the company and they can anytime bring in or take out money from the company. Their decision shall depend upon the company’s financial performance. Therefore they can pressurize the management for financial reports and change tactics if necessary.

Some stakeholders can even increase or decrease the investment to change the share price in the market and thus make the conditions favorable for them. Help in Decision Making: Major stakeholders are part of the board of directors. Therefore they also take decisions along with other board members. They have the power to disrupt the decisions as well.

They and bring n more ideas a threaten the management to obey them. The stakeholders also have all the powers to appoint senior-level management. Therefore, they are there in all the major decision-making areas. They also take decisions regarding liquidations and also acquisitions.

Corporate Conscience: Large stakeholders are the major stakeholders of the company and have monitored over all the major activities of the company. They can make the company abide by human rights and environmental laws. They also monitor the outsourcing activities and may vote against any business decision if it harms the long term goals of the company. Page 13 42 UNIVERSITY 3 G9) GREENWICH “BT EC pane ot IG csc.

« Other Responsibilities: Apart from the above four major roles they also have some other roles to play in the company. They can identify new areas for market penetration and increased sales. They can bring in more marketing ideas. They also attract other investors like honeybees in the company.