Sample assessment 2 FOR BUSSINESS PDF

Preview

Summary

For the case study information provided in this assessment, you need to summarise:
● the established (written) vision and mission of the organisation
● current practices of the organisation and, in particular, whether they support the mission objectives of the organisation, or point to...

Description

Your tasks: 1. Develop an organisation chart for the Diamond Video Rentals Company, presented in a word Processor document (e.g. MS Word).

Owner John Vandrine

System Analyst Andrian and Budi Hartono

Project Manager Mary Adams

Supervisor Deb Papadopoulos

Staff Paul Trang

Accountant Ted Sloan

Staff Danny jones

Supervisor Dawn Schultz

Staff Mae Willis

Staff Terry De Santo

2. Create a document confirming the networking requirements, including but not limited to: 1. The number of new users 2. Current networking equipment used 3. Current licenses available for the different software needed 4. Any other information that may be needed to plan the network additions.

Requirements outline for the new Office The new office will have the following staff: -

1 office assistant/customer service clerk 1 manager 6 sales staff

You will need to install a LAN for the new office. The manager has requested the following: -

Microsoft Windows XP Professional as the workstation operating system

-

Microsoft Office XP to be installed on all the workstations Anti-virus software to be installed on all the workstations Accounting software to be installed

The manager has also requested to be able to do the following: -

Share folders and resources on the network Print to one printer from all of the workstations on the network Share an Internet connection

3. Derive a Requirement Elicitation Process for IT Solutions which could be applied to analyse Diamond 1.1 Prepare for Elicitation

Purpose

Ensure all needed resources are organized and scheduled for conducting the elicitation activities.

Input

Business Need, Solution Scope and Business Case, Stakeholder List, Roles, and Responsibilities.

Techniques

Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire.

Stakeholders Output

All Stakeholders, Project Manager. Scheduled Resources: This includes the participants, the location in which the elicitation activity will occur, and any other resources that may be required. Supporting Materials: Any materials required to help explain the techniques used or perform them.

1.2: Conduct Elicitation Activity Purpose

Meet with stakeholders to elicit information regarding their needs.

Input

Business Need, Organizational Process Assets, Requirements Management Plan, Scheduled Resources, Solution Scope and Business Case, Supporting Materials. Data Dictionary and Glossary, General Techniques: Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire.

Techniques

Stakeholders

Customer, Domain SME, End User, Supplier and Sponsor, Implementation SME, Operational Support, Project Manager, Supplier and Tester, Regulator.

Output

Elicitation Results: May include documentation appropriate to the

technique and capture the information provided by the stakeholder 1.3: Document Elicitation Results Purpose

Record the information provided by stakeholders for use in analysis

Input

Includes the information provided by stakeholders that will be recorded and structured.

Techniques

Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Problem Tracking, Prototyping, Requirements Workshops, Survey/Questionnaire.

Stakeholders

Business Analyst.

Output

Requirements [Stated]: Described from the perspective of the stakeholder. Stated requirements describe the stakeholder’s need from the stakeholder’s perspective. Stakeholder Concerns: Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information.

1.4: Confirm Elicitation Results

Purpose

Input

Validate the stated requirements expressed by the stakeholder match the stakeholders’ understanding of the problem and the stakeholder’s needs. Requirements [Stated, Unconfirmed], Stakeholder Concerns [Unconfirmed].

Techniques

Interviews, Observation.

Stakeholders

Identical to Stakeholder Concerns for all practical purposes, including use as an input to other tasks.

Output

Requirements [Stated, Confirmed]: Identical to Requirements [Stated] for all practical purposes, including use as an input to other tasks

2. Conclusion

Eliciting requirements is not an isolated or compartmentalised activity. Typically, requirements are identified throughout the elicitation, analysis, verification and validation activities. To fully examine and define the requirements a combination of complementary elicitation techniques is typically used. A number of factors (the business domain the corporate culture and environment, the skills of

the analyst and the requirements deliverables that will be created guide which techniques will be used.

4. Develop a Stakeholder Requirement Analysis Process for IT Solutions considering Diamond Video Rental’s 1. Stakeholder Requirement Analysis Description/purposes of this process 1.1. Prioritise requirements

Purpose

Minimize risk during development so that the most important or high risk requirements are implemented first.

Input

Business Case • Business Need • Requirements • Requirements. Management Plan • Stakeholder List MoSCoW- Must Should Could Won’t What are the factors/criteria to be considered for this task?

Techniques Elements Output

Assess Proposed Solution • Allocate Requirement, Validate Solution • Requirements Management & Communication

1.2: Organise requirements Purpose

The purpose of organising requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives.

Input Techniques

Organizational Process Assets Inputs • Requirements • Solution Scope Data Flow Diagrams, Data Modelling, Functional Decomposition, Organisation Modelling, Process Modelling, Scenarios and Use Cases, Scope Modelling, User Stories

Elements

Follow organisational standards that describe the types of requirements Use simple, consistent definitions for each of the types of requirements described Document dependencies and interrelationships among requirements Produce a consistent set of models and templates to document the requirements

Output

Requirements Structure: The output of this task is an organised structure for the requirements and a documented set of relationships between them.

1.3 Specify and model requirements Purpose

Input Techniques

Elements

The purpose of this task is to analyse expressed stakeholders desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams, and formal methods. Requirement stated, requirement-structure Acceptance and Evaluation Criteria Definition , Business Rules Analysis, Data Dictionary and Glossary, Data Flow Diagrams, Data Modelling, Functional Decomposition, Interface Analysis, Metrics and Key Performance Indicators , Non-functional Requirements Analysis, Organisation Modelling, Process Modelling, Prototyping, Scenarios and Use Cases, Sequence Diagrams, State Diagrams, User Stories -

Output

Express one and only one requirement at a time. Avoid complex conditional clauses. Do not assume your reader has domain knowledge. Use terminology that is consistent. Express requirements as a verb or verb phrase. Write in the active voice, clearly describing who or what is responsible for fulfilling the requirement. Use terminology familiar to the stakeholders who must review or use the requirement.

Requirements: Analysed Modeled and specified requirements are produced by this task

1.4: Define assumptions and constraints Purpose

Identify factors other than requirements that may affect which solutions are viable.

Input

Stakeholder Concerns-Assumptions and constraints are identified through elicitation from stakeholders

Techniques Elements Output

Problem Tracking, Risk Analysis Assumptions, Business Constraints, Technical Constraints Assumptions and Constraints- Assumptions and constraints will limit potential solution options and will be monitored for potential changes.

1.5 Verify requirements Purpose

to ensure that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.

Input

- Requirements [Any Except Stated]

Techniques

General Techniques(Problem Tracking, Structured Walkthrough),

Elements Output

Checklists Characteristics of Requirements Quality, Verification Activities Requirements [Verified]: Verified requirements are of sufficient quality to allow further work based on those requirements to be performed.

1.6 Validate requirements Purpose

To ensure that all the requirements support the delivery of value to the business, fulfil its goals and objectives and meet a stakeholder need.

Input

Business Case: The business case describes the overall business objectives and measurements that the solution is expected to deliver. To be valid, a requirement must contribute directly or indirectly to the business case. Other business requirements, including the business need, required capabilities, and solution scope may also be used for validation.

Techniques

Elements

Output

-

Acceptance and Evaluation Criteria Definition Metrics and Key Performance Indicators Prototyping Risk Analysis Structured Walkthrough

- Identify Assumptions - Define Measurable Evaluation Criteria - Determine Business Value - Determine Dependencies for benefits Realization - Evaluate Alignment with Business Case and Opportunity Cost Requirements [Validated]: Validated requirements are those that can be demonstrated to deliver value to stakeholders and are aligned with the business goals and objectives. If a requirement cannot be validated, it does not benefit the organisation, does not fall within the solution scope, or both.

2 Conclusion Requirement Analysis describes the tasks and techniques used by a business analysis to analyse stated requirements in order to define the required capabilities of a potential solution that will fulfil stakeholder needs. It covers the definition of stakeholder groups and solution requirements, which describe the behaviour of solution components in enough detail to allow them to be constructed. The tasks in this knowledge area apply to both stakeholders and solution requirements. 5. Develop a hardware evaluation sheet (use the template provided) detailing products from the

different vendors (suppliers) that are identified for the above equipment. Identify the networking Equipment (not workstations or server) that will be needed for the new site. Identify at least TWO Suppliers for this equipment and get prices and details of availability. Suppliers

Equipment details

1

2

Hardware Cost Software Cost Delivery Fees Installation Fees

$950 $300 $100 $200

$900 $250 $50 $200

Total Fees

$1550

$1400

Construction Period Hardware Warranty Free Software Updates Emergency Service customizations Further Additions Further Additions Fees Company Reliability Overall Rating

20 Working Days 2 Years 2 Years 24 Hours Yes Yes No 4 4

20 Working Days 1 Year 2 Years 24 Hours No No $100+Features 3 3

Rating:5 = Excellent

4 = Very good

3 = Good

2 = Bad

1 = Very bad

Conclusion: we may choose the supplier2 even though the cost is higher, but they are reliable and the costs are acceptable.

6. Develop a network installation plan for the new North Sydney office, in which you: 5. Identify the components required to meet the technical requirements of the user’s network. 6. Prioritise the tasks involved and contingency plans to achieve minimum business disruption Or delay with the installation. 7. Identify the appropriate people and obtain approval for plans including security clearance And schedule.

Installation Plans NO

Tasks

Responsible

Approval

1

Hire Network Engineer/Designer and Network Support

Andrian and Budi Hartono – IT Solutions

John Vandrine

Network Engineer

Andrian and Budi Hartono – IT Solutions

Network Support

Network Engineer

Network Support

Network Engineer

Network Support

Network Engineer Andrian and Budi Hartono – IT Solutions

2

Provide LAN for office Install computers and organize computers position in the office Install Software and Hardware for the computers Connect computers to the internet

3 4 5

Train Office Staff how to use the computers

6

Network Support

7. Develop a Test Plan for the above installation. The test plan should: 8. List the function or service to be tested, and within each function or service, list items to be Tested in sequence 9. List the procedure to test each item and the expected results of the test procedure 10. Provide for documenting actual test results with comments Also provide examples to show how the test plan will work.



Unit Testing

Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Development Manager: ensures that proper analysis and planning is done for the unit testing phase Technical Services Manager: ensures that proper analysis and planning is done for performance testing Application Test Manager: ensures that proper analysis and planning is done for all other test phases



Security

The system can be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Security testing is a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended. Due to the logical limitations of security testing, passing security testing is not an indication that no flaws exist or that the system adequately satisfies the security requirements.

Typical security requirements may include specific elements of confidentiality, integrity, authentication, availability, authorization and non-repudiation. Actual security requirements tested depend on the security requirements implemented by the system. Security testing as a term has a number of different meanings and can be completed in a number of different ways. As such a Security Taxonomy helps us to understand these different approaches and meanings by providing a base level to work from.



Integration Test

Integration testing is done to be certain that modules and functions are going to work properly in the interface. Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

The following list of questions will help guide evaluation of the completeness of integration test conditions recorded on the integration testing template. This list can also help determine whether test conditions created for the integration process are complete. 1. Is an integration test developed for each of the following external inquiries? - Record test? - File test? - Search test? - Match/merge test? - Attributes test? - Stress test? - Control test? 2. Are all interfaces between modules validated so that the output of one is recorded as input to another?

3. If file test transactions are developed, do the modules interface with all those indicated files? 4. Is the processing of each unit validated before integration testing? 5. Do all unit developers agree that integration test conditions are adequate to test each unit’s interfaces? 6. Are all software units included in integration testing? 7. Are all files used by the software being tested included in integration testing? 8. Are all business transactions associated with the software being tested included in integration testing? 9. Are all terminal functions incorporated in the software being tested included in integration testing?

8. Document change impact analysis for Diamond Video Rental using following template: General Information:

General Information includes name of the project and owner

Impact Summary:

Impact Summary includes a descriptive statement of the change and detailed description of the impact listed

Impacted Stakeholders:

Impacted Stakeholders are assessed for the level of impact they may experience: High: The change has significant impact to the stakeholder including new processes, changed job expectations, and/or new ways of doing work Medium: The change has a noticeable impact to the stakeholder but the job and /or way of doing work fundamentally remains the same Low: The change may be recognized by the stakeholder but does not directly change the way of doing work

Change:

This section asks what kind of change is taking place; Process: what will change with respect to current activities, workflows and procedures People: who will perform new/revised processes, workflows, activities Tech/Tools: what tools will be needed and how

will these tools be used Change Management Needs:

This section outlines the key change management needs: Communications: list potential communication and socialisation efforts needed due to the change Training/Learning: list potential training/learning needed due to the change Organisational/HR: list any HR activities needed due to the change

Comments:

Additional comments pertaining to change may be documented

11. Document the business requirements for Diamond Video Rentals in a Business Requirements Document (BRD) format. 12. Your BRD report is to summarise your findings and is required to be outlined as specified Below: 13. Cover page identifying all team members

Team Members: John Vandrine – Owner of Diamond Video Rentals Andrian and Budi Hartono – System Analyst (ITS Solutions) Mary Adams – Project Manager John Alone - Network Engineer Cena Forever – Network Support

14. Version Control and Signoff

Version Control & Sign Off Version Control: Monday 3rd February 2017, 11am Monday 9th February 2017, 3:30pm Sign Off: July 2018

0.1 1.1

Initial document Initial System

15. Table of Contents

Contents Version Control Sign...