Name: Reviewer (ITEC - Lesson 1)
Rating: 5 (1 reviews)

You are in browse mode. You must login to use MEMORY

Confused? » Read about learn, practice and the various modes

» To start learning, click login

1 / 25

[Front]

People involve in or affected by project activities.

[Back]

Stakeholders

Practice Known Questions

Stay up to date with your due questions

Complete 5 questions to enable practice

Exams

Exam: Test your skills

Test your skills in exam mode

Learn New Questions

Popular in this course

multiple choiceMultiple choice mode

Dynamic Modes

SmartIntelligent mix of all modes

CustomUse settings to weight dynamic modes

Manual Mode [BETA]

Select your own question and answer types

Other available modes

Learn with flashcards

Complete the sentence

Listening & SpellingSpelling: Type what you hear

SpeakingAnswer with voice

Speaking & ListeningPractice pronunciation

TypingTyping only mode

Reviewer (ITEC - Lesson 1) - Leaderboard

0 users have completed this course. Be the first!

No users have played this course yet, be the first

Reviewer (ITEC - Lesson 1) - Details

Levels:

1) Chapter 1 View

Questions:

130 questions

🇬🇧		🇬🇧

People involve in or affected by project activities.

Stakeholders

Taking a holistic or systems view of a project; understand how it is situated within a larger organization.

Project Manager

Undesirable situations that prevent the business from fully achieving its purpose, goals, and objectives.

Problems

Combination of interrelated elements to achieve a common objective.

System Integration

An array of components designed to accomplish a particular objective according to plan.

System

Defines its high-level structure; Defines the structure of software system; usually uses diagrams to illustrates services, components, layers, and interactions.

System Architecture

Ideas and request from employees, managers, or other internal stakeholders can serve as a source for information systems projects.

Internal Stakeholders Initiatives

Competitive pressure, changes in the market landscape, or emerging trends can drive organizations to undertake information systems projects to maintain their market position and relevance.

External Market Forces

Project aimed at reducing operational costs, optimizing resource utilization, or eliminating redundancies may be undertaken to improve the organization's financial performance.

Cost Reduction and Resource Optimization

Is a new requirement that is imposed by management, government, or some external influence.

Directive

A chance to improve the business even in the absence of specific problems.

Opportunity

Proposed by Bolman and Deal

Four Frames Model

Seen as structures with responsibilities, rules and procedure.

Structural Frame

Organizations are seen as arenas, contests, or jungles where one must deal with power and conflict, build coalitions, hone political skills, and deal with internal and external politics.

Political Frame

Organizations are seen as tribes, theaters, or carnivals with the objective of. shaping a culture, building work meaning and team spirit.

Symbolic Frame

Organizations are seen as a group or society with the obligation to satisfy human needs and build positive interpersonal and group dynamics.

Human Resource Frame

Structure helps define the roles and responsibilities of the members of the department, work group, or organization.

Organizational structure

People who do similar tasks, have similar skills and/or jobs in an organization are grouped into a functional structure.

Functional Structure

A mindset where one team hesitates to share information or knowledge with other teams within the same organisation.

'organisational silos'

A type of basic organizational structure that organizes a company based on its different product lines, services, customer groups, or geographical locations.

Divisional Structure

Is a hybrid organizational structure that combines elements of both functional and divisional structures.

Matrix Structure

In this structure, project teams are formed to work on temporary initiatives with specific goals and deadlines.

Project Organization Structure

Is a framework that is used to structure, plan, and control the process of developing an information system.

System Development Methodology

Is a conceptual model that describes the phases involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

System Development Life Cycle

Process of defining clear, discrete activities, and the work needed to complete each activity within a single project.

Project Planning Phase

Understand and document the business needs and the processing requirements of the new system

Analysis Phase

Design the solution system based on the requirements defined and decisions made during the analysis phase.

Design Phase

Ensure that the users are all trained and that the organization is ready to benefit as expected from the use of the system

Implementation Phase

Keep the system running productively during the years following its initial installation. Upgrades or enhancements may be carried out to expand the system’s capabilities

Maintenance Phase

Helps developer to select a strategy to develop the software; has its own set of tools, methods and procedures, which are expressed clearly and defines software development life cycle.

Software Development Paradigm

Is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner.

Waterfall Model

This model leads the software development process in iterations. It projects the process of development in cyclic manner repeating every step after every cycle of SDLC process.

Iterative Model

Provides means of testing of software at each stage in reverse manner.

V – model

Is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product.

Agile Model

Refers to building software application prototypes which displays the functionality of the product under development, but may not actually hold the exact logic of the original software.

Software Prototyping

Are fundamental basis of all the system development processes.

Requirements

Requirements should be written in a way that leaves no room for interpretation or misunderstanding. They should convey a single, clear meaning to all stakeholders.

Clear and Unambiguous

A requirement should encompass all the necessary information, including what needs to be achieved, any constraints, and any necessary conditions for its fulfillment.

Complete

Requirements should not conflict with each other or create contradictions within the project scope. They should work together harmoniously.

Consistent

Requirements should be achievable within the project's constraints, including technical capabilities, budget, time, and resources.

Feasible

A requirement should be specific enough that it can be objectively tested to determine whether it has been met.

Testable

Each requirement should focus on a single aspect or functionality. Avoid combining multiple requirements into a single statement.

Atomic

Requirements should be linked back to their source, whether it's a business need, a stakeholder's request, or a regulatory requirement. This helps maintain a clear connection between the requirement and its origin.

Traceable

Requirements should be ranked by importance or value to guide the development process, especially in cases where not all requirements can be met due to resource constraints.

Prioritized

Requirements should be written in a way that allows for objective verification. There should be a way to determine whether the requirement has been met.

Verifiable

Requirements should be grounded in reality and aligned with the capabilities of the project team and available resources.

Realistic and Achievable

Each requirement should be understood within the context of the overall project goals and objectives.

Contextual

Avoid duplicating requirements. Each requirement should add unique value to the project.

Non-redundant

Use clear and precise language to minimize ambiguity and ensure a shared understanding among stakeholders.

Precise Language

Requirements should allow for some flexibility to accommodate changes that might arise during the project's lifecycle.

Adaptable to Change

Requirements should directly contribute to the achievement of the project's overall business goals and objectives.

Aligned with Business Goals

In this phase, requirements are gathered from stakeholders to identify their needs, expectations, and desired functionalities. Various techniques such as interviews, surveys, workshops, and observations are used to collect information.

Elicitation Phase

In this phase, there is no transformation of the requirements, but simple classification and categorization. For example, requirements may be grouped into functional vs. nonfunctional requirements.

Organization Phase

Once gathered, the requirements are analyzed, refined, and documented in a clear and detailed manner. This phase involves ensuring that the requirements are well-defined, consistent, complete, and feasible.

Analysis Phase

In this phase, the requirements are used as the basis for designing and developing the solution, whether it's a software application, a product, or a system. The solution is implemented, and various testing activities are conducted to ensure that the implemented solution meets the specified requirements.

Implementation and Testing Phase

This represents the requirements as the finished product of the stakeholder requirements team. The requirements are compiled into a requirements list or into some equivalent document format. These collected requirements are then transformed into a specification.

Requirements documentation and specification Phase

Also known as user needs, are statements that describe the needs, expectations, and functionalities that end-users or stakeholders expect from a system, product, or solution.

User Requirements

Describe what the system should do

Functional requirements

Consists of Constraints that must be adhered to during development

Non-functional requirements

Describe the specifications, constraints, and characteristics of the overall system or software being developed.

System requirements

Involve using various techniques and tools to create visual representations or models of the system's functionalities, behavior, structure, and interactions.

Modeling requirements

Is a general purpose modelling language. The main aim of UML is to define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in other fields of engineering.

Unified Modeling Language (UML)

Depict how users interact with the system by illustrating different use cases (user scenarios) and the interactions between users and the system.

Use Case Diagrams

Visualize the flow of activities and actions within a process or use case. They show the sequence of steps and decisions in a graphical format.

Activity Diagrams

Display the interactions between various components, objects, or actors in the system over time. They emphasize the order of events and message exchanges.

Sequence Diagrams

Illustrate the structure of the system by showing the classes, attributes, methods, and relationships between different classes or objects.

Class Diagrams

Are used to model the relationships between different data entities in a database, helping to design the data structure of the system.

Entity-Relationship Diagrams (ERDs)

The users that interact with a system. An actor can be a person, an organization, or an outside system that interacts with your application or system. They must be external objects that produce or consume data.

Actors

Use case diagrams can show relationships between use cases, such as "include" and "extend" relationships, which depict how one use case incorporates or extends the behavior of another.

Relationships

A specific sequence of actions and interactions between actors and the system. A system may also be referred to as a scenario.

System

Shows that one use case includes the functionality of another use case.

Include Relationships

Illustrates optional behavior that can be added to a base use case.

Extend Relationships

Different types of architecture are used to address various aspects of a system's structure, behavior, and implementation.

System architectural types

Focuses on describing the high-level functions, capabilities, and interactions of a system's components or modules. It defines the major functionalities of the system and how they are related.

Functional architecture

Addresses the physical components, resources, and infrastructure needed to implement a system.

Physical architecture

Encompasses the underlying technologies, software frameworks, programming languages, and design patterns used to build the system.

Technical architecture

Refers to the logical organization of a distributed system into software components.

Software architecture

Components are organized in layers. Components on a higher layer make down-calls (send requests to a lower layer). While lower layer components can make upcalls (send requests up), they usually only respond to higher layer requests.

Layered Architecture

Objects form the foundation of encapsulating services into independent units leading to the development of SOAs. Services are self-contained, independent objects that make use of other services.

Service-Oriented Architecture

Are smaller than services in an SOA, less tightly coupled, and more lightweight.

Microservices

Are formed by services or processes running on nodes that cannot be easily accounted for. They may connect and disconnect frequently, some may not even use the internet.

Mesh Architecture

System architecture deals with the high-level design and organization of an entire system, which can include hardware, software, networks, databases, and more.

Scope and Scale

System architecture considers how various components and subsystems interact with each other, as well as their relationships and dependencies.

Interactions and Relationships

System architecture includes considerations of both physical elements (hardware devices, servers, data centers) and logical elements (software components, services, data storage) that make up the system.

Physical and Logical Aspects

System architecture addresses non-functional requirements such as scalability, availability, performance, security, reliability, and maintainability at the system level.

Non-Functional Concerns

Software architecture is concerned with how different software components, modules, and services interact with each other to achieve the application's functionalities.

Component Relationships

Software architecture abstracts away the hardware details and primarily concentrates on the logical and functional aspects of the software system.

Abstraction from Hardware

Is the process of defining the elements of a system such as the architecture, modules and components, the different interfaces of those components and the data that goes through that system.

System design

A schematic or stepwise representation of an algorithm.

Flowchart

Used for Process Modelling language.

Business Process Modelling Notation (BPMN)

Used for systems engineering.

Systems Modelling Language (SysML)

To describe software both structurally and behaviourally with graphical notation.

Unified Modelling Language (UML)

To describes the views, models, behavior, and structure of the system.

Architectural design

To represent the data flow, inputs and outputs of the system.

Logical design

Defined as how users add information to the system and how the system represents information back to the user.

Physical design

Is a tool that helps you break down large projects into smaller, easier-to handle stages.

Design process

Whether you found a pattern in negative customer feedback or you have some R&D budget left to spend, the approach stays the same.

Identify the problem you want to solve

At this stage, you’ll figure out the market state, whether any competing products exist or are on their way, and what user needs competitors neglect.

Research the problem in-depth

Start by using “how might we” questions to create a list of ideas.

Ideate possible solutions

So you have your shortlist of ideas. Now, it’s time to put them to the test.

Evaluate and select a promising solution