Tải bản đầy đủ (.pdf) (58 trang)

1631 assignment grade D

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.11 MB, 58 trang )

<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

<small>dss </small>

<b>ASSIGNMENT 02 FRONT SHEET </b>

<b>Qualification BTEC Level 5 HND Diploma in Computing </b>

<b>Unit number and </b>

<b>title <sup>Unit 09: Software Development Life Cycle </sup></b>

<b>Submission date <sup>Date Received 1st </sup></b>

<b>Student Name Student ID </b>

<b>Student declaration </b>

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.

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

<b>Internal Verifier’s Comments: </b>

<b>Signature & Date: </b>

<small> </small>

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

<b>Assignment Brief 02 (RQF) </b>

<b>Higher National Certificate/Diploma in Business </b>

<b><small>Student Name/ID Number: </small></b>

<b><small>Unit Number and Title: Unit 09: Software Development Life Cycle </small></b>

<small>● The submission is in the form of 1 document. </small>

<small>● You must use the Times font with 12pt size, turn on page numbering; set line spacing to 1.3 and margins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation and references must follow the Harvard referencing style. </small>

<i><small>Submission: </small></i>

<small>● Students are compulsory to submit the assignment in due date and in a way requested by the Tutor. ● The form of submission will be a soft copy posted on </small>

<small>● Remember to convert the word file into </small><b><small>PDF</small></b><small> file before the submission on CMS. </small>

<i><small>Note: </small></i>

<small>● The individual Assignment must be your own work, and not copied by or from another student. ● If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you must </small>

<small>reference your sources, using the Harvard style. </small>

<small>● Make sure that you understand and follow the guidelines to avoid plagiarism. Failure to comply </small>

<i><small>this requirement will result in a failed assignment. </small></i>

<b><small>Unit Learning Outcomes: </small></b>

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

<b><small>LO3 Undertake a software development lifecycle. </small></b>

<b><small>LO4 Discuss the suitability of software behavioural design techniques.</small></b><small> </small>

<b><small>Assignment Brief and Guidance: </small></b>

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

<b><small>Tasks </small></b>

<small>At this stage, you have convinced Tune Source to select your project for development. Complete the following tasks to analyse and design the software. </small>

<b><small>Task 1 – Analysis (1) </small></b>

<small>1. Identify the stakeholders, their roles and interests in the case study. </small>

<small>Review the requirement definition of the project. Clearly indicate which stakeholder(s) provide what requirements. </small>

<i><small>Word limit: 150 – 200. </small></i>

<small>Identify FRs and NFRs of Tune Source Project. </small>

<small>Discuss the relationships between the FRs and NFRs. </small>

<i><small>Word limit: 300 – 400 words. </small></i>

<small>2. Discuss the technique(s) you would use to obtain the requirements. </small>

<small>If needed, you may state suitable additional assumptions about the project in order to justify the technique(s) that you choose. </small>

<i><small>Techniques: JAD, Interview, Observation, etc. </small></i>

<i><small>Demonstrate how to collect requirements based on chosen technique. Word limit: 700 – 1000. </small></i>

<small>3. Discuss how you would trace these requirements throughout the project by using Requirement Traceability matrix. You will have to provide real usage of it. </small>

<i><small>Word limit: 400 – 500 words. </small></i>

<b><small>Task 2 – Analysis (2) </small></b>

<small>Analyze the requirements that you identified in Task 1 using a combination of structural and behavioral modelling techniques that you have learnt. </small>

<i><small>Scope: You only need to construct following items for the system. You will have to include: </small></i>

<small>• Use Case Diagram for the whole system. • Use Case specification for 2 Use cases. • Context Diagram for the whole system. </small>

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

<small>• Data Flow Diagram – Level 0 for the whole system. • ERD for the whole system. </small>

<small>For each diagram, you will have to explain properly. </small>

<i><small>Word limit: 1000 – 1200 words. </small></i>

<b><small>Task 3 – Design </small></b>

<small>Based on the analysis result, discuss how you would conduct the design phase: </small>

<small>1. Discuss how the user and software requirements are addressed in the design phase. </small>

<small>• You will explain how Mock-up, and Wireframe are used in the project. You should include some of the mockup or wireframe (at least 5) design of the Tune Source project to justify that it matches users’ requirements. </small>

<small>• You will explain which architecture (client – server, n-tier, microservices, etc.) is suitable for the project with clear illustrations and why. </small>

<small>• Then you will address which technical solution stack could be suitable to implement the project with clear explanations. </small>

<small>2. Discuss how activity diagram and pseudocode are used to specify the software behaviour. </small>

<small>3. Discuss how UML state machine can be used to specify the software behaviour. Differentiate between FSM and extended FSM using the case study. </small>

<small>4. Discuss how the data-driven approach improves the reliability and effectiveness of software. </small>

<i><small>Word limit: 800 – 1500. </small></i>

<b><small>Task 4 – Software quality management </small></b>

<small>1. Discuss two software quality attributes that are applicable to the project. </small>

<small>2. Discuss two quality assurance techniques that can help improve the software quality in the project. 3. Discuss how the design techniques and approaches that you have used can help improve the software </small>

<small>quality. </small>

<i><small>Word limit: 400 – 1500. </small></i>

<small> </small>

<b><small>Learning Outcomes and Assessment Criteria (Assignment 02): </small></b>

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

<small>tools/techniques to carry out a software investigation and create supporting </small>

<small>documentation. </small>

<b><small>M3 Analyse how software </small></b>

<small>requirements can be traced throughout the software </small>

<b><small>P7 Explain how user and </small></b>

<small>software requirements have been addressed. </small>

<b><small>M5 Suggest two software </small></b>

<small>behavioural specification methods and illustrate their use with an example. </small>

<small>of how data driven software can improve the </small>

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

<b>TABLE OF CONTENTS </b>

<small>INTRODUCTION ...11 </small>

<small>P5: UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED: ...11 </small>

<small>I. Identify the stakeholders, theirs roles and interests in the case study: ... 11 </small>

<small>1. Introduction: ... 11 </small>

<small>2. Identify the stakeholders, theirs roles and interests: ... 12 </small>

<small>3. Requirement definition of the project (FRs and NFRs): ... 13 </small>

<small>4. List out the detailed FRs and NFRs in Tune Source project: ... 14 </small>

<small>5. Relationships between the FRs and NFRs: ... 15 </small>

<b><small>II. Discuss the technique(s) you did use to obtain the requirements: ... 16 </small></b>

<small>I. Introduction to Requirements Management: ... 22 </small>

<small>II. Requirements Traceability Overview: ... 22 </small>

<small>7. Compliance and Audit: ... 25 </small>

<small>III. Traceability Matrix for Tune Source project: ... 26 </small>

<small>P6: USE APPROPRIATE SOFTWARE ANALYSIS TOOLS/TECHNIQUES TO CARRY OUT A SOFTWARE INVESTIGATION AND CREATE SUPPORTING DOCUMENTATION ... 27 </small>

<small>I. Introduction: ... 27 </small>

<small>II. Techniques for structured analysis and design: ... 27 </small>

<small>1. Data Flow Diagram (DFD): ... 27 </small>

<small>2. Entity Relationship Diagram (ERD): ... 28 </small>

<small>3. Flowchart: ... 29 </small>

<small>4. Pseudocode: ... 30 </small>

<small>P7: EXPLAIN HOW USER AND SOFTWARE REQUIREMENTS HAVE BEEN ADDRESSED ... 32 </small>

<small>I. Introduction about the Use case and use case diagram: ... 32 </small>

<small>II. Apply for Tune Source System: ... 33 </small>

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

<small>1. Major Usecases diagram: ... 33 </small>

<small>2. Elaborating the Usecase diagram: ... 34 </small>

<small>M5: SUGGEST TWO SOFTWARE BEHAVIOURAL SPECIFICATION METHODS AND ILLUSTRATE THEIR USE WITH AN EXAMPLE ... 36 </small>

<small>M6: DIFFERENTIATE BETWEEN A FINITE STATE MACHINE (FSM) AND AN EXTENDED-FSM, PROVIDING AN APPLICATION FOR BOTH ... 43 </small>

<small>I. Finite State Machine (FSM): ... 43 </small>

<small>III. Difference between FSM and EFSM in the context of the Tune Source application: ... 45 </small>

<small>D4: PRESENT JUSTIFICATIONS OF HOW DATA DRIVEN SOFTWARE CAN IMPROVE THE RELIABILITY AND EFFECTIVENESS OF SOFTWARE ... 46 </small>

<small>I. Definition of Data-Driven Software: ... 46 </small>

<small>II. Data-Driven Software for Improvement of Reliability and Effectiveness: ... 47 </small>

<small>III. Improving the Dependability and Effectiveness of the Tune Source Software using Data-Driven Approach: ... 49 </small>

<small>M4: DISCUSS TWO APPROACHES TO IMPROVING SOFTWARE QUALITY... 50 </small>

<small>I. Discuss software quality attributes that are applicable to the project: ... 50 </small>

<small>1. Introduction: ... 50 </small>

<small>2. Software Quality Attributes:... 50 </small>

<small>3. Software Quality Attributes Applicable to Tune Source: ... 51 </small>

<small>II. Discuss two quality assurance techniques that can help improve the software quality in the project ... 51 </small>

<small>1. Introduction: ... 51 </small>

<small>2. Quality Assurance Techniques: ... 52 </small>

<small>3. Conclusion: ... 53 </small>

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

<small>D3: CRITICALLY EVALUATE HOW THE USE OF THE FUNCTION DESIGN PARADIGM IN THE </small>

<small>SOFTWARE DEVELOPMENT LIFECYCLE CAN IMPROVE SOFTWARE QUALITY ... 53 </small>

<small>I. Definition of Function Design Paradigm: ... 53 </small>

<small>II. Use of Function Design Paradigm in the Software Development Lifecycle to Improve Software Quality:</small>

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

<b>TABLE OF FIGURES </b>

<i>Figure 1: Interview ... 16 </i>

<i>Figure 2: Joint Application Development ... 17 </i>

<i>Figure 3: Questionnaires Technique ... 18 </i>

<i>Figure 4: Document Analysis ... 19 </i>

<i>Figure 5: Observation Technique ... 20 </i>

<i>Figure 6: Requirements Management. ... 22 </i>

<i>Figure 7: Data Flow Diagram (DFD) of user ... 27 </i>

<i>Figure 8: Data Flow Diagram of Admin ... 28 </i>

<i>Figure 9: Entity Relationship Diagram (ERD) ... 28 </i>

<i>Figure 10: Flowchart of Sign in ... 29 </i>

<i>Figure 11: Flowchart of Add to MyList ... 29 </i>

<i>Figure 12: Pseudocode of Sign in Process ... 30 </i>

<i>Figure 13: Pseudocodes’ MainMenu of Tune Source system ... 31 </i>

<i>Figure 14: Online shopping UML use case diagram example ... 32 </i>

<i>Figure 15: Main Usecase diagram ... 33 </i>

<i>Figure 16: Elaborating diagram 1... 33 </i>

<i>Figure 17: Elaborating diagram 2... 34 </i>

<i>Figure 18: Elaborating diagram 3... 34 </i>

<i>Figure 19: Syntax in Python code ... 35 </i>

<i>Figure 20: Pseudocode Example ... 36 </i>

<i>Figure 21: Flowchart example ... 38 </i>

<i>Figure 22: Applying flowchart at Tune Source ... 40 </i>

<i>Figure 23: Pseudocode of "Add to MyList" process ... 41 </i>

<i>Figure 24: Data-Driven Software ... 45</i><small> </small>



<b>TABLE OF TABLES</b> <i>Table 1: List the Tune Source project's stakeholders, roles, and interests. ... 13 </i>

<i>Table 2: Requirements for Tune Source project of stakeholders ... 14 </i>

<i>Table 3: Interview note 1 ... 21 </i>

<i>Table 4: Interview note 2 ... 21 </i>

<i>Table 5: Traceability Matrix for Tune Source project ... 26 </i>

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

<i>Table 6: Table comparing FSM with EFSM in the context of the Tune Source application ... 44 </i>

Businesses frequently rely on software solutions to handle their particular demands and improve their operations in today's quickly expanding technological world. This article digs into a thorough software analysis performed to meet a specific business requirement. Stakeholder identification, requirement definition, software requirement analysis, user requirement addressing, behavioral specification methods, differentiation of state machine models, exploration of data-driven software benefits, and examination of software quality improvement approaches are all part of the analysis. The major goal of this study is to offer a comprehensive knowledge of the software analysis methodology and its results. We want to do this by identifying the stakeholders engaged in the case study and explaining their roles, responsibilities, and interests. Furthermore, we will dig into the complexities of software requirements, investigating how they may be efficiently tracked across the software development lifecycle. We will also use relevant software analysis tools and procedures to back up our results and conclusions.

This software analysis is significant because of its capacity to bridge the gap between business demands and software development. We can lay a firm basis for requirement formulation and future software development by completely knowing the stakeholders and their expectations. The investigation also sheds light on how software requirements may be efficiently managed, tracked, and

<b>incorporated into the development process. </b>

<b>P5: UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED: </b>

I. Identify the stakeholders, theirs roles and interests in the case study:

<b>1. Introduction: </b>

Requirements engineering (RE) refers to the process of generating, documenting, and managing requirements during the engineering design process.

Requirement engineering provides services such as understanding what the customer wants, analyzing the need and assessing feasibility, negotiating a reasonable solution, clearly specifying the solution, validating the specifications, and managing the requirements as they are transformed into a working system. Thus, requirement engineering is the systematic use of tried-and-true concepts, processes, tools, and notation to define the expected behavior and constraints of a proposed system. We will identify the Tune Source project stakeholders, their duties, and their interests in this work. Stakeholders are individuals or groups who have an interest or influence in the project and who may

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

effect or be affected by its outcomes. Understanding the stakeholders and their roles is critical for effective project management and requirement gathering.

2. Identify the stakeholders, theirs roles and interests:

<b> Stakeholders Roles Interests </b>

Their interests include boosting sales income and profitability, extending the customer base, attracting customers by exploiting the unique collection of rare and hard-to-find music, and maintaining a competitive position in the market niche. They are also concerned with the company's long-term growth and sustainability.

Carly is passionate about increasing sales through efficient marketing tactics, improving the company's marketing skills, satisfying client requests and preferences, and gaining a competitive edge in the music business. Her primary goal is to raise brand awareness, acquire new consumers, and retain existing ones through focused marketing initiatives.

The IT department is concerned with the effective deployment and integration of the new system, as well as with the efficient administration of digital music downloads and the support and maintenance of the technical infrastructure. They want to make sure Tune Source's digital platform runs smoothly, securely, and reliably.

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

<b>4 Customers </b> Tune Source

Customers want an easy and intuitive music search experience, access to a wide range of rare and hard-tofind music, the ability to listen to music samples before purchasing, a smooth and convenient purchasing

process, access to digital music downloads, and options such as subscription accounts and gift cards. Their interests concentrate around discovering and acquiring music in a user-friendly and personalized manner.

<i>Table 1: List the Tune Source project's stakeholders, roles, and interests. </i>

3. Requirement definition of the project (FRs and NFRs):

In this section, I'll go over the requirements for the Tune Source project in great depth. I'll also outline the project implementation functionalities (FRs and NFRs) that must be added to Tune Source's required product:

• Look for music in our digital music database and listen to music samples. • Buy individual downloads for a set fee each download.

• Set up a customer membership account with unlimited downloads for a monthly price. • Purchase gift cards for music downloads.

Following the enumeration of capabilities, I will list out the FRs and NFRs (functional requirements and non-functional requirements) and prepare a table of presenting requirements for Tune Source project stakeholders.

a) FRs (Functional Requirements):

• The system should allow users to search for music in the digital music archive using multiple criteria such as artist, album, genre, and keywords.

• Music sample playback: Before making a purchase, users should be able to listen to brief music samples.

• Individual music downloads should be available for purchase: Users should be able to purchase and download individual music songs.

• Limitless music download subscription account: The system should include a subscription option for limitless music downloads.

• Purchase music download gift cards: Users should be able to purchase digital music download gift cards.

b) NFRs (Non-Functional Requirements):

• Usability: The system's interface should be simple and easy to use.

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

• Performance: The system should be quick and responsive even when there is a high volume of users.

• Security: The system should safeguard consumer data and ensure safe payment transactions. • Reliability: The system should have as few downtime and faults as possible.

• Scalability refers to the system's capacity to accommodate rising demand and user traffic. c) Table of presenting requirements for Tune Source project stakeholders:

The need for entrepreneurs is to fulfill business goals while decreasing mistakes and enhancing user experience quality. And, of course, everything must be completed within the agreed-upon time range in order for the product to be distributed on time.

<b>2 Carly Edwards </b>

(Assistant Vice President,

Marketing)

This initiative was established to increase sales by allowing customers to purchase digital music downloads through our in-store kiosks and online through our website.

Customers will be able to find and buy digital music downloads over the Web or in-store kiosks. The project will include the five elements mentioned in the previous report.

<b>3 IT Department </b> To continually develop the Tune Source project, increase quality, and fulfill all five distinct functions for the Tune Source project on time and without error, the IT team must be able to assist and interact with one another.

<b>4 Customers </b> Customers demand high-quality products with a strong user interface and experience, as well as the option to provide suggestions and comments on how to improve and update the product to meet their needs.

Furthermore, in order to release on time, the product development team must be trustworthy.

<i>Table 2: Requirements for Tune Source project of stakeholders </i>

4. List out the detailed FRs and NFRs in Tune Source project: a) FRs (Functional Requirements):

• Music search capabilities for the digital music archive: The system must allow users to search for songs or albums based on parameters such as artist name, genre, album title, or song title. Users should obtain quick, accurate, and relevant search results.

• Music sample playback: The system should allow consumers to listen to small samples of songs before purchasing them. The playback function should provide a consistent and uninterrupted experience, allowing consumers to assess the quality of the music and make educated selections.

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

• Individual song or album downloads: Users will be able to pick and purchase individual songs or albums for download. The system should make the transaction process as simple and safe as possible, including payment alternatives and confirmation of successful downloads.

• Unlimited downloads through subscription account: The system must include a subscriptionbased account option that allows users to access an unlimited number of downloads from the digital music library. Subscription management should be simple and easy to use, allowing users to upgrade, renew, or cancel their subscriptions as needed.

• Purchase gift cards for digital music downloads: The system must facilitate the purchase of gift cards that can be redeemed for digital music downloads. Users should be able to customise and give gift cards to recipients, who will then be able to use them to purchase music from the Tune Source platform.

b) NFRs (Non-Functional Requirements):

• Usability: The user interface must be straightforward and simple to use in order to provide a favorable user experience. Users should be able to identify and use needed functions quickly, with clear instructions and a low learning curve.

• Performance: The system must be extremely responsive, delivering rapid search results, smooth music playback, and speedy transaction processing. It should be able to handle several concurrent user requests without experiencing substantial delays or performance degradation.

• Security: The system must utilize strong security measures to safeguard user information, such as personal information and payment information. To protect the confidentiality and integrity of sensitive information, secure encryption algorithms and authentication processes should be used. • Reliability: The system must be very reliable, with little downtime and system faults. It should be

available to users at all times, with regular maintenance and proactive monitoring to handle any possible issues as soon as they arise.

• Scalability: The system must be scalable in order to meet rising user demand and manage expanding amounts of music material. It should be able to dynamically scale resources in order to maintain optimal performance during peak demand periods.

5. Relationships between the FRs and NFRs:

• Music search functionality (FR) and usability (NFR): The usability criterion guarantees that the music search feature is developed with an intuitive and user-friendly interface, making it easy for users to search for and discover the needed music.

• Performance (NFR) and Music sample playback feature (FR): The performance requirement guarantees that the system can play music samples swiftly and flawlessly without any delays or buffering, giving users with a smooth playing experience.

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

• Purchase individual music downloads (FR) and Performance (NFR): The performance criterion guarantees that the system can efficiently manage concurrent user requests, allowing users to purchase and download music tracks without suffering poor response times.

• Scalability (NFR) and Subscription account for unlimited downloads (FR): The scalability requirement ensures that the system can accommodate an increasing number of users subscribing to unlimited music downloads, allowing the system to handle increased demand and user traffic without performance degradation.

• Purchase music download gift cards (FR) and Security (NFR): The security criterion guarantees that customer information is safeguarded throughout the purchase of music download gift cards, including secure payment transactions to avoid unauthorized access or data breaches.

• Reliability (NFR) and all FRs: The dependability requirement applies to all functional needs, guaranteeing that the system functions with minimal downtime and system failures, delivering a reliable and continuous music browsing, sampling, and purchase experience.

II. <b>Discuss the technique(s) you did use to obtain the requirements:</b>

1. Introduction:

As mentioned before in the definition of requirement, there are both functional (FRs) and nonfunctional (NFRs). Then, in this section, I'll go over the Tune Source project's needs in further depth. I'll also outline the five project-specific functions that must be added to Tune Source's required product:

• Search for music in our digital music library and listen to music samples. • Individual downloads can be purchased for a set fee per download.

• Create a customer subscription account that allows for unlimited downloads in exchange for a monthly price.

• Purchase gift cards for music downloads. 2. Five requirement gathering techniques: a) Interview:

<i>Figure 1: Interview </i>

Conducting one-on-one or group meetings with important stakeholders such as John Margolis, Megan Taylor, Phil Cooper, and Carly Edwards is part of the interview process. The goal is to learn about their viewpoints, expectations, and special needs for the digital music download system.

Pros:

</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">

• Direct and individualized connection with stakeholders enables a thorough awareness of their requirements and expectations.

• Allows for the collection of qualitative data, such as stakeholders' opinions, preferences, and insights, which may not be collected using other methods.

• Allows for real-time explanations and follow-up queries, guaranteeing precise and thorough needs.

• Facilitates stakeholder connection building, encouraging cooperation and stakeholder buy-in. Cons:

• Time-consuming, especially when many interviews with various stakeholders are necessary, which may cause project delays.

• The information received may be impacted by the interviewers' personal biases or restricted viewpoints, necessitating thorough analysis and validation.

• Scaling is difficult for a large number of stakeholders, making it difficult to integrate feedback from all relevant parties.

b) Joint Application Development (JAD):

Conducting collaborative workshops or sessions with stakeholders, including representatives from several departments such as marketing, IT, and other relevant teams, is part of Joint Application Development. The workshops seek to bring stakeholders from all backgrounds together to actively engage in requirements collecting, analysis, and design.

</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">

• Open talks and idea development are facilitated, allowing the discovery of requirements, potential obstacles, and new solutions.

• Allows for real-time agreement and decision-making, eliminating the need for repeated iterations. • Improves stakeholder communication and understanding, promoting a shared vision for the

project. Cons:

• JAD sessions need devoted time and resources, which may limit stakeholder availability.

• It might be difficult to handle opposing viewpoints and requirements, demanding expert facilitation.

• Some stakeholders may not be comfortable or successful in a group environment, therefore this may not be appropriate for all stakeholders.

• The success of JAD sessions is strongly dependent on the quality of facilitation and the active participation of all participants.

c) Questionnaires:

Questionnaires entail sending organized sets of questions to important stakeholders such as customers, staff, and key personnel at Tune Source. The goal is to acquire particular information on their digital music download system preferences, expectations, and requirements.

<i>Figure 3: Questionnaires Technique </i>Pros:

• Allows for a bigger sample size, allowing for a more comprehensive knowledge of stakeholder requirements and preferences.

• Can be disseminated remotely, making participation by stakeholders more convenient. • Provides organized and uniform replies, making data analysis and comparison easier.

• Allows stakeholders to submit comments at their leisure, without requiring real-time involvement.

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

• To guarantee clarity and relevancy, questions must be carefully designed and formulated.

• Inability to capture complex or unexpected needs that may develop during a face-to-face dialogue. d) Document Analysis:

Document analysis entails evaluating current documents such as sales data, customer comments, and business strategies to get insights into the digital music download system's business demands and requirements.

<i>Figure 4: Document Analysis </i>

Pros:

• Using accessible data, provides a full overview of the company environment, existing procedures, and consumer feedback.

• Provides access to historical data and trends, enabling for educated decision-making and pattern detection.

• Can reveal previously reported hidden requirements or holes in the present system.

• Can aid in the alignment of the project with corporate goals and strategies defined in business plans.

Cons:

• Depends on the availability and quality of current records, which may be partial, out of date, or not focused on the unique needs of the new system.

• It may not capture tacit knowledge or unrecorded information, necessitating further investigation using other methodologies.

• To guarantee accuracy and relevance to the project, the information received from the papers must be carefully interpreted and validated.

e) Observation:

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

Observation entails seeing users or stakeholders engage with the present system or conduct relevant activities. By watching their behaviors and reactions, this approach seeks to get insights about their behavior, pain areas, and requirements.

<i>Figure 5: Observation Technique </i>

3. Conclusion:

I carefully studied and decided on the interview process to employ after presenting the ways for supporting the team in obtaining customer demands. Because I feel that this Tune Source project only needs to create new features and maintain the system, I do not believe that it needs to invest a lot of time and money in other areas.

This is a time-saving technique for acquiring extensive information on the customer's interest in and desire to fulfill the request. Additionally, this method allows the team to acquire information quickly and clearly, allowing the Tune Source project to be finished on time. As a Business Analyst (BA), I will have the basic templates described below, which I will make available to everyone. I'll put up reports in the template to assist everyone understand the topic better. Consumer needs are met while interview methods are improved.

Interviewee: John Margolis, Fouders.

Interviewer: Thai Thi Yen Nhi (Business Analysis).

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

Purpose of interview: The purpose of this interview is to elicit additional information and

requirements from the founder in order to better visualize the Tune Source project's system and to learn more about this founder's interest in the Tune Source project in order to chart a future development path for the Tune Source project.

Summary of interview: To summarize, all necessary information is available to summarize and communicate to Tune Source project stakeholders in order for them to be informed of the project's timeline. Furthermore, by utilizing this data, it is possible to aid everyone on the team in selecting what to prioritize in order to properly plan the work so that a high-quality and trustworthy system for the Tune Source project can be built.

<i>Table 3: Interview note 1 </i>

Interviewee: Carly Edwards (Assistant Vice President, Marketing). Interviewer: Thai Thi Yen Nhi (Business Analysis).

Purpose of interview: The purpose of this interview is to acquire investment and financial

information, as well as further information about investing in the Tune Source project and how it may be accomplished, with revenue as projected or greater. At the same time, they learned about the two parties' future business plan path to better build the Tune Source project, resulting in larger income as well as enhanced reputation, prestige, and quality.

Summary of interview: In summary, there is almost all information on funding and investment in the Tune Source project, as well as more information about the future strategic approach for developing further Tune Source initiatives.

<i>Table 4: Interview note 2 </i>

<b>M3: ANALYSE HOW SOFTWARE REQUIREMENTS CAN BE TRACED THROUGHOUT THE SOFTWARE LIFECYCLE. </b>

Software requirements are critical in determining a software system's operation and performance. It is critical to properly track and manage these requirements throughout the software lifecycle. Establishing explicit linkages between requirements and other documents, such as design guidelines and test cases, is required. Organizations may guarantee that requirements are satisfied and appropriately implemented in software systems by tracking them. A traceability matrix is a popular requirement tracking tool because it allows you to visualize the links between requirements, design elements, implementation components, and test cases. Tracing software requirements with a traceability matrix is critical in the Tune Source project to satisfy customer expectations and retain competitiveness. Overall, tracking software requirements across the software development lifecycle is critical for successful software development initiatives.

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

I. Introduction to Requirements Management:

<i>Figure 6: Requirements Management. </i>

Requirements management is a fundamental part of software development that entails identifying, documenting, organizing, and managing software needs throughout a project's lifespan. It includes the procedures and actions required to ensure that requirements are gathered, assessed, verified, and managed successfully in order to fulfill the goals of stakeholders and accomplish project objectives. The major purpose of requirements management is to provide clear and unambiguous communication among project stakeholders such as clients, end users, developers, and testers. It seeks to close the gap between business requirements and technical execution by identifying and prioritizing requirements in an organized and methodical manner.

Several critical actions are involved in effective requirements management, including requirements elicitation, documentation, verification, and validation. It also entails managing requirement modifications, establishing traceability between requirements and other project artifacts, and staying on track with project goals and objectives.

To summarize, requirements management is critical to the success of software development projects because it ensures that requirements are correctly defined, documented, monitored, and managed throughout the project lifetime. It allows for effective communication, stakeholder cooperation, and alignment with project objectives, resulting in the delivery of high-quality software solutions. II. Requirements Traceability Overview:

1. Requirements Traceability:

The process of methodically monitoring and connecting requirements across the software development lifecycle is known as requirements traceability. It guarantees that every need is taken into consideration, from identification to implementation, testing, and verification. Establishing and maintaining linkages between requirements and other artifacts like as design papers, code modules, and test cases is required. Organizations get insight into the progress of requirement realization, check requirement fulfillment, enable impact analysis and change management, provide complete test coverage, and give evidence of compliance and auditability by using requirements traceability. Overall, requirements traceability improves project transparency, collaboration, and the effective delivery of a software system that fulfills the required specifications.

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

<b>2. Foward Tracebility: </b>

Forward traceability connects requirements to downstream artifacts including design papers, source code, and test cases to guarantee that needs are met effectively in following development phases. a) Benefits:

• Reduces the risk of missing or incomplete requirements by ensuring that each requirement has a clear path to implementation and testing.

• Improves project management by giving visibility into the status of requirement implementation. • Allows for impact analysis by detecting potential downstream consequences of requirement

modifications. b) Challenges:

• Throughout the development process, requirements and associated artifacts must be tracked consistently and accurately.

• It is dependent on the availability and accessibility of artifacts, which may be spread across several

<b>tools or repositories. </b>

3. Backward Tracebility:

Backward traceability connects system aspects like as design components, code modules, and test cases to the initial requirements they address, allowing for traceability and verification of requirement compliance.

a) Benefits:

• Checks the system's completeness by verifying that each requirement has a matching implementation or test case.

• Facilitates impact analysis by highlighting system elements' upstream dependencies and the potential consequences of modifications.

• Helps in change management by providing a clear picture of the affected requirements and system parts.

b) Challenges:

• As the system changes, it is necessary to maintain accurate and up-to-date traceability relationships between artifacts.

• It may be time-consuming and resource-intensive, particularly in big projects with many needs

<b>and system aspects. </b>

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

<b>4. Bidirectional Traceability: </b>

Bidirectional traceability creates both forward and backward linkages between requirements and associated artifacts, allowing for a complete picture of the relationships and dependencies. a) Benefits:

• By recording the links between requirements, design, implementation, and testing, it ensures consistency and integrity.

• Allows for tracing in both directions to examine the effects of changes on requirements and system elements, which simplifies impact analysis.

• By giving a comprehensive grasp of the ramifications of changes, it facilitates effective change management and risk mitigation.

b) Challenges:

• To keep traceability linkages correct and up to date, they must be tracked and maintained diligently throughout the project lifecycle.

• Large-scale projects with various criteria and interrelated artifacts might be difficult to manage.

<b>5. Impact Analysis: </b>

Impact analysis evaluates the possible implications of requirement modifications on associated artifacts such as design, code, and test cases.

<b>a) Benefits: </b>

• Aids decision-making by assisting stakeholders in understanding the ramifications and risks connected with proposed changes.

• Allows for optimal resource allocation by identifying the precise regions affected by changes. • Supports change management procedures by providing a foundation for analyzing and managing

change requests.

<b>b) Challenges: </b>

• To effectively estimate the impact of modifications, a full grasp of the linkages between requirements and other artifacts is required.

<b>• It is dependent on the availability of complete and up-to-date traceability information. 6. Test coverage: </b>

Test coverage analysis connects test cases to the exact criteria they are meant to confirm, ensuring that all requirements are thoroughly verified.

</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">

<b>a) Benefits: </b>

• This ensures that all requirements have related test cases, lowering the risk of untested or missed functionality.

• Provides evidence of testing effort thoroughness and conformance with stated parameters. • Allows for gap analysis by identifying regions with insufficient test coverage, allowing for

targeted testing upgrades.

<b>b) Challenges: </b>

• Accurate mapping between test cases and requirements is required, which may be difficult to design and maintain.

<b>• Effective test case management and documentation techniques are required. 7. Compliance and Audit: </b>

Traceability records provide as evidence of compliance with requirements, making them useful for regulatory standards or contractual responsibilities.

• Ensures traceability from requirements to verification operations, facilitating quality assurance and certification procedures.

<b>b) Challenges: </b>

• Traceability data must be accurate and thorough, and conveniently available for audit reasons. • Ensures that documentation and traceability artifacts are kept up to date throughout the project's

<b>lifespan. </b>

To summarize, requirements traceability is an important approach in software development. It entails recording and linking requirements in a systematic manner throughout the project lifecycle to provide transparency, support effective communication, limit risks, enable change management, and verify requirement satisfaction. Organizations may improve project performance and deliver software solutions that satisfy business objectives by creating and maintaining traceability linkages between requirements and other artifacts.

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">

III. Traceability Matrix for Tune Source project:

A traceability matrix is a tool for establishing and visualizing links between project artifacts such as requirements, design elements, test cases, and other relevant components. It aids in tracking requirement coverage and traceability throughout the software development lifecycle.

The Tune Source project's traceability matrix is divided into the following columns: "Requirement ID", "Requirement Description", "Design Elements", "Code Module" and "Test Cases".

Requirement ID

Requirement Description Design Elements Code Module Test Cases

R01 Search for music in the digital archive.

Search UI SearchModule T01

R02 Play some music samples Media player UI MediaPlayer T02 R03 Buy individual downloads Shopping cart UI PaymentModule T03

Gift card UI PaymentModule T05

<i>Table 5: Traceability Matrix for Tune Source project </i>

Each row in the matrix reflects a unique demand for the project. Each need has a unique identification in the "Requirement ID" column, and each requirement has a brief description in the "Requirement Description" column.

The design components or modules that address each criteria are specified in the "Design Elements" column. These design aspects serve as the framework for putting the requirements into action. The "Code Module" column identifies the exact code modules or components that are in charge of implementing each requirement. It facilitates tracking the development work involved with meeting the requirements.

The test cases connected with each criterion are listed in the "Test Cases" column. These test cases are intended to check the functionality and performance of the code modules that have been implemented.

The project team may quickly monitor and create the linkages between requirements, design components, code modules, and test cases by creating this traceability matrix. Throughout the software development lifecycle, this enables effective change management, impact analysis, and

<i>requirement fulfillment verification. </i>

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

<b>P6: USE APPROPRIATE SOFTWARE ANALYSIS TOOLS/TECHNIQUES TO CARRY OUT A SOFTWARE INVESTIGATION AND CREATE SUPPORTING </b>

<b>DOCUMENTATION. </b>

I. Introduction:

Continuous software development and improvement are required to fulfill the different demands of users and assure the success of an entertainment application. The FMS (Free Music Streaming) software was designed to give users with a platform for listening to music and relaxing.

A combination of structural and behavioral modeling approaches will be used in the software research process. Data Flow Diagrams (DFD), Entity-Relationship Diagrams (ERD), Flowcharts, and Pseudocode are some of the techniques used. These strategies will aid in understanding the structure, data flow, and process flow of the system, resulting in improved functionality and user experience. II. Techniques for structured analysis and design:

<b>1. Data Flow Diagram (DFD): </b>

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

<i>Figure 7: Data Flow Diagram (DFD) of user </i>

This is a Data Flow Diagram that displays the procedure followed by the user in Tune Source's system while purchasing a Gift Card. I'll explain more; first, you can see that the consumer must join in with an existing user account, then pick Gift Cards with his account, then select the Gift Card category, and finally click to add to cart. They will next read the Gift Card details as well as the payment method used when purchasing the Gift Card. The customer will choose a payment option for the Gift Card after reading. Finally, once you've purchased the Gift Card, make your payment and go through the invoice.

<i>Figure 8: Data Flow Diagram of Admin </i>

This diagram depicts how Admin may add a song. First, admin must enter the title of the song, followed by the name of the performer and the genre of the song, such as pop, lyrical, or country. Finally, the lyrics of the music are provided to assist users in following the substance of the song. The newly uploaded items will be archived.

2. Entity Relationship Diagram (ERD):

</div>

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×