ch 5 new qs.docx

"**Waterfall Project Management**", "**Agile Project Management**", and "**Hybrid Project Management**". The "agile" approach to Project Management is most common in IT projects. It was developed in the software industry in the 1990s. Nonetheless, there are aspects of Digitalization Projects that c...

"**Waterfall Project Management**", "**Agile Project Management**", and "**Hybrid Project Management**". The "agile" approach to Project Management is most common in IT projects. It was developed in the software industry in the 1990s. Nonetheless, there are aspects of Digitalization Projects that can benefit from other approaches, as well: So we'll look at all three\... Waterfall Project Management is the traditional approach to Project Management. It is called the "waterfall" approach because is follows a [linear approach] through a project that is based on an **Initiation** phase, a **Planning** phase, an **Executing and Controlling** phase and a **Closing** phase. Like a waterfall, the project [flows top-down through these phases]. Each phase is dependent on the completion of the previous one, and - at least in theory - there are no jumps back upwards. One of the hallmark features of the waterfall approach is its emphasis on [comprehensive planning at the beginning] of the project, with a view to [minimizing changes] once development begins. Typical projects that are usually carried out with a waterfall framework are construction projects, manufacturing projects, infrastructure projects, and research and development projects, to name a few.\ In each case, the bulk of the planning must be carried out at the beginning of the project rather than\ incrementally. **Waterfall Project Management works excellently in projects [where the project\'s requirements are well understood from the beginning and unlikely to change significantly].** As stated earlier, traditional waterfall project management works excellently for projects where customer requirements are very clear from the beginning. It is less suited for projects where there are large question marks concerning customer \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- User stories are a core element in Agile project management and are used to define and prioritize features or requirements from the end-user\'s perspective. They help teams understand the needs and goals of users, providing a simplified way to break down and plan work. Each user story describes a single functionality or feature in plain language, focusing on the user\'s experience and outcomes, not on technical specifications. n essence, user stories are a practical way of translating user needs into actionable tasks, keeping the development process aligned with business goals and user satisfaction. User stories are a key tool in project management, especially in Agile methodologies, for clearly defining project requirements from the perspective of the end user. Their purpose is to ensure that the development team builds solutions that meet the actual needs of users and stakeholders In project management, **use cases** serve several key purposes, particularly in the context of software development, product design, or system implementation. A use case describes how a system interacts with users or other systems to achieve specific goals. A **use case** in project management refers to a specific scenario or situation where a system, process, or feature is used to achieve a particular goal or outcome. It describes **how users interact with a system** to accomplish something meaningful, typically detailing the steps involved and the roles or actors participating in that scenario. In the context of project management, use cases help define **requirements** for a project by outlining how various stakeholders will interact with the deliverables, processes, or systems being implemented. They are essential for clarifying expectations and guiding the development of project features. In project management, **use cases** are valuable tools for a wide range of stakeholders, each utilizing them for different purposes throughout the project lifecycle. Here\'s a breakdown of who typically needs use cases and how they benefit: Project Managers and Product Owners/Stakeholders and Clients/End Users. \-\-\-\--req anal: - Answering these questions is the main goal of a **Requirements Analysis: What data elements will your new EIS need to function optimally?** - **What will your software need to be able your new EIS need to function optimally?** - **What will your hardware need to be able to do your new EIS need to function optimally?** - **What types of job skills your new EIS need to function optimally?** - **What rules and protocols will your new EIS need to function optimally?** \-\-\-- sys design **Systems design** in the context of **requirements analysis** refers to the process of defining the architecture, components, modules, interfaces, and data of a system based on the identified functional and non-functional requirements. It involves translating the high-level needs (gathered during requirements analysis) into a blueprint or design that can guide the implementation of a system. Here\'s a breakdown of its role: **1. Understanding the Requirements** - **Functional Requirements**: What the system should do (features, behaviors). - **Non-Functional Requirements**: Constraints such as performance, security, scalability, etc. **2. High-Level Design (Architecture)** - **System Architecture**: Deciding on the structure and design of the overall system. For example, whether it will be a client-server model, a microservices architecture, or a monolithic system. - **Technology Stack**: Choosing the technology, platforms, programming languages, and tools based on the requirements. - **Data Flow and Interaction**: Defining how data will flow through the system and how various components will interact. **3. Component Design** - **Modularization**: Breaking down the system into smaller, manageable components or modules. Each component is designed to handle a specific subset of the overall functionality. - **Interfaces**: Defining how different components will interact with each other, including API design, communication protocols, and input/output formats. **4. Data Design** - **Data Modeling**: Creating data models that represent the entities, relationships, and data flows in the system. This could include Entity-Relationship Diagrams (ERDs), database schemas, and data flow diagrams. - **Storage and Access**: Designing the database (e.g., relational, NoSQL) or data stores and specifying how data will be accessed and manipulated. **5. Non-Functional Considerations** - **Performance**: Designing the system to meet the required speed, responsiveness, and throughput. - **Scalability**: Ensuring the system can grow and handle increased loads without performance degradation. - **Security**: Addressing security concerns like data encryption, access control, and authentication mechanisms. - **Reliability**: Designing for fault tolerance, backup, and disaster recovery. **6. User Interface Design** - Defining the **user interface** (UI) and experience (UX) to ensure the system is intuitive and meets user needs. **7. Integration and Communication** - Determining how the system will integrate with other systems or external services, including APIs, third-party tools, or legacy systems. **Importance in Requirements Analysis:** - **Bridging the Gap**: Systems design serves as the bridge between the \"what\" (requirements) and the \"how\" (implementation). It translates user and business needs into a technical framework. - **Preventing Scope Creep**: A well-documented system design helps avoid scope creep by providing clear boundaries for the system\'s features and functionality. - **Ensuring Alignment**: It ensures that the final system is aligned with the expectations and constraints laid out during requirements analysis. In summary, systems design in requirements analysis is a critical phase where abstract needs are turned into actionable, detailed plans that guide development, ensuring the system meets all its goals and constraints. In requirements analysis, **functional** and **non-functional requirements** serve distinct roles in defining what a system should do and how it should perform. Here\'s a breakdown of both: **1. Functional Requirements** Functional requirements specify **what the system should do**. They define the specific behavior or functions of the system. These are typically features or tasks that the system must be able to perform. - **Purpose**: Describes the functionality, services, or tasks that the system must support to meet the business needs. - **Examples**: - A system must allow users to log in using a username and password. - A search function should retrieve results based on user queries. - The system must allow users to add, delete, or update data. - A bank's application must enable customers to transfer funds between accounts. Functional requirements typically include: - Inputs (data the system receives) - Behavior (how the system should process that data) - Outputs (what the system produces) **2. Non-Functional Requirements** Non-functional requirements specify **how the system should perform**. These requirements describe the system's attributes or qualities rather than the specific behaviors. They are often referred to as quality attributes of the system. - **Purpose**: They define constraints on the system\'s performance, reliability, scalability, and other quality factors. These are often measurable. - **Examples**: - **Performance**: The system should respond to user queries within 2 seconds. - **Scalability**: The system must support up to 10,000 concurrent users. - **Security**: User data must be encrypted in transit and at rest. - **Availability**: The system should be available 99.99% of the time. - **Usability**: The system should be easy to navigate, and users should be able to complete a task within 3 clicks. Common categories of non-functional requirements include: - **Performance**: Speed, latency, response times. - **Reliability**: System uptime, fault tolerance, recovery from failures. - **Security**: Authentication, authorization, encryption, privacy. - **Scalability**: Ability to handle increased loads, growth over time. - **Usability**: User interface design, ease of use, accessibility. - **Maintainability**: How easy it is to update, debug, or improve the system. - **Compliance**: Adherence to regulations or standards (e.g., GDPR, HIPAA). **Importance in Requirements Analysis** - **Functional requirements** are crucial to ensure that the system provides the necessary features and capabilities. - **Non-functional requirements** are essential for ensuring the system operates effectively, efficiently, and securely under different conditions. Both types of requirements must be considered to create a comprehensive and well-functioning system. **Functional Requirements do this:** +-----------------------------------------------------------------------+ | Describes what the system should do (features, tasks) | +=======================================================================+ | Business needs and features | +-----------------------------------------------------------------------+ | User authentication, data entry, reporting | | | | Non-functional requirements do this: | | | | Describes how the system should perform or behave | | | | System qualities like performance, security, etc. | | | | Speed, scalability, security, availability | | | | Often qualitative, but can be measured (e.g., response time) | +-----------------------------------------------------------------------+