| 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) |
| 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 |
| 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 |
| Spend as little time as possible to validate your idea with a prototype without rushing the process. | Create your prototype |
| It’s time to put your prototype to the test and see if you made any faulty assumptions about your customers. | Test and troubleshoot |
| If your prototype was a huge hit, all that’s left now is to touch up your product and release it to the public. | Make improvements to and release the final product |
| is a process of recording the information for any reference or operational purpose. It helps users, managers, and IT staff, who require it. | Documentation |
| It describes inputs, outputs, and processing logic for all the program modules. | Program Documentation |
| contains all the information needed for processing and
distributing online and printed output. | Operations documentation |
| It includes instructions and information to the users who will interact with the system. For example, user manuals, help guides, and tutorials. | User Documentation |
| serves as the technical specifications for the IS and how the objectives of the IS are accomplished. Users, managers and IS owners need never reference system
documentation. | System Documentation |
| is essential to the development of large, complex engineered systems. | System Integration |
| allows organization to connect legacy systems with other, newer systems. | Legacy system integration: |
| building custom software is not feasible in many cases. Instead, third-party software products may be used, which may need to be integrated with
other systems and applications already in use in the organization. | Third party system integration |
| this type of integration allows businesses, for example across a supply chain, to easily exchange data and knowledge, reducing redundancy. | Business-to-business integration |
| essential in any big-data project is the integration of data origination
from disparate business systems, various sources, and different formats. It allows all data to be combined in a single view to be used for reporting and analysis. | Big data integration |
| connecting various applications, systems, and databases to be integrated in cloud services, enabling access by multiple devices over a network or the internet. | Cloud services integration |
| is designed to manage any and all business processes and automate various backend or back office functions that need not be carried out manually. | Enterprise Resource Planning (ERP) system |
| connection is not system integration in its truest sense. In that the complexity of the functions that can be performed is limited despite the systems functioning as a whole. | Point-to-Point integration |
| differs from the other types of systems integration in the structure that is formed. | Vertical systems integration |
| is very simply a collection of point to point system integrations. In other words, a larger set of simple connections come together to create a star connection. | Star integration |
| refers to achieving systems integration using one specialised subsystem as a common user interface layer which links all the other subsystems. | Horizontal integration |
| encompasses several perspectives and focuses within an organization to align its business processes, information systems, and technology infrastructure. | Enterprise Architecture (EA) |
| This domain focuses on understanding the organization's business operations, strategies, goals, processes, and functions. It defines how the organization operates and interacts with its stakeholders. | Business Architecture |
| deals with the organization's data and information assets. It includes defining data structures, data models, data flows, data governance, and data quality standards. This domain ensures that data is accurate,
consistent, and available for business needs. | Information Architecture |
| is concerned with designing, building, and managing the organization's software applications. | Application Architecture |
| focuses on the infrastructure required to support the organization's applications and services. | Technology Architecture |
| is a comprehensive strategy that outlines how an organization will continue its essential operations during and after disruptive events or incidents. | Business Continuity Plan (BCP) |
| refers to the maximum acceptable downtime that an organization
can tolerate for a specific business function, system, or application
before it must be restored and operational again. | Recovery Time Objective (RTO) |
| Concentrates on defining security controls, policies, and mechanisms to protect the organization's information and technology assets. | Security Architecture |
| Focuses on designing integration solutions to ensure seamless communication and data exchange between different systems. | Integration Architecture |
| Develops detailed technical designs for specific projects or initiatives, ensuring they align with the organization's architecture standards. | Solution Architecture |
| Explores the organization's data sources, structures, and storage, ensuring that data is available, accessible, and consistent. | Data Architecture |
| Deals with designing the physical IT infrastructure, including servers, networks, data centers, and cloud resources. | Infrastructure Architecture |
| refers to the maximum acceptable amount of data loss that an organization can tolerate for a specific business function, system, or application after a disruptive event. | Recovery Point Objective (RPO) |
