Luokat: Kaikki - development - requirements - risks - brainstorm

jonka Haya ElGhalayini 3 vuotta sitten

263

Capstone Project Inception 2021

This project involves utilizing Mindomo to organize a comprehensive Capstone Project. Teams begin by analyzing the project's Expression of Interest (EOI) and identifying key stakeholders who will influence or be affected by the proposed system.

Capstone Project Inception 2021

CS Capstone Project Proposal 2021

Using Mindomo, teams analyze the EOI of the project, and, together, organize the Capstone Project, identify stakeholders for the proposed system, brainstorm and elicit the business requirements, identify and propose functional areas of the system to be developed and discuss risks associated with the project that must be managed. Teams prepare for the development of the project by setting up required management and development tools.


Feel free to change the mind-map template to customize the ideation space to something that is inspiring to the team.

Using Mindomo, teams analyze the EOI of the project, and, together, organize the Capstone Project, identify stakeholders for the proposed system, brainstorm and elicit the business requirements, identify and propose functional areas of the system to be developed and discuss risks associated with the project that must be managed. Teams prepare for the development of the project by setting up required management and development tools.

Project Setup

Add links to the sub-topics to allow for a single point of access to all development platform and tools used in the project.

VPository Project

Link to the VPository project used to host the Visual Paradigm software model.

BitBucket Team

Link to the BitBucket Team / Project that will contain all repositories created for the project.

MS Team Link

Link to the MS Team used for project communication. This is the Digital Classroom created for the project. All project communication, a collaboration including meetings shall be conducted within this team. Only such communication and collaboration can be evaluated.

Link to the MS Team used for project communication. This is the Digital Classroom created for the project. All project communication, a collaboration including meetings shall be conducted within this team. Only such communication and collaboration can be evaluated.

JIRA Site

Link to the JIRA Site created for managing the project. The supervisor Link to the JIRA Site created for managing the project. The supervisor shall be invited to the site as an administrator.shall be invited to the site as an administrator.

Project Inception Document

Add the link to the Project Inception Document in Office 365 that is shared with the project's Microsoft Team with the supervisor such that version history and individual contribution is accessible to everyone.

Project Risks

Brainstorm the risks relevant to the project. Risks should be describe as precisely as possible in order to allow the team to identify concrete mitigation strategies. 

Brainstorm the risks relevant to the project. Risks should be describe as precisely as possible in order to allow the team to identify concrete mitigation strategies.

Business Risks

Business risks indicate potential negative organizational influences on the project or product or negative influences the product may have on the developing or target organizations.

Project Risks

Project risks affect the development team, the development process and the project plan. 

Project risks affect the development team, the development process and the project plan.

Product Risks

Product risks are risks that affect the suitability of the product.

Product risks are risks that affect the suitability and feasibility of the product which are typically linked with requirements, stakeholders and the domain.

Non-Functional Requirements

Brainstorm the non-functional requirements of the project. Be sure to review typical non-functional requirements as these have a great influence on the architecture of the system and its feasibility. 

Brainstorm the non-functional requirements of the project. Be sure to review typical non-functional requirements as these have a great influence on the architecture of the system and its feasibility.

External Non-Functional Requirements

External non-functional requirements represent external constraints that are relevant to the product or the organization developing or being affected by the product such as relevant legislation, ethical considerations or policies and regulations.

External non-functional requirements represent external constraints that are relevant to the product or the organization developing or being affected by the product such as relevant legislation, ethical considerations or policies and regulations.

Organizational Non-Functional Requirements

Organizational non-functional requirements affect the either the organization developing the product (the student team) or the organization/enterprise that is the target of the product or are affected by the product.

Product Non-Functional Requirements

Product non-functional requirements affect the functionality of the product and indicate qualitative attributes, constraints or integration requirements.

Business Requirements

Identify a coherent series of stories that describe, from a stakeholder perspective, the basic requirements / needs that the system would have to fulfill in order to be a valuable addition in the domain as evidenced by the project mentor’s experience.


Business requirements are not related to the system itself but represent the motivation of WHY the system is needed. Business requirements represent are the result of analyzing the real-world problems identified and formalize which problems will the system focus on and their details.


Business requirements will represent the start for the requirements analysis process. Teams will derive user requirements from here in future assignments. 

Analyze the EOI / RFC and determine the business goals for the system to be developed. Each business goal represents a collection of business requirements.

Identify a coherent series of stories that describe, from a stakeholder perspective, the basic requirements / needs that the system would have to fulfill in order to be a valuable addition in the domain as evidenced by the project mentor’s experience.

Business requirements are not related to the system itself but represent the motivation of WHY the system is needed. Business requirements represent are the result of analyzing the real-world problems identified and formalize which problems will the system focus on and their details.

Business requirements will represent the start for the requirements analysis process. Teams will derive user requirements from here in future assignments.

Identify the business requirements for the system under discussion.

Each requirement is expressed using the 'story format' which identifies the stakeholder as well as the context for each business requirement.

As a , I want to so that I
Business Goal

A business goal represents a collection of business requirements.

Describe the business requirement in a story format:

'As a <business stakeholder>, I want to <business requirement> so that <business goal>'

Describe the user requirement in a story format:

'As an <actor>, I want to <user requirement>, so that <business requirement or an aspect of a business requirement>'

Each user requirement will become a use-case in the requirements model and in the JIRA project.

...

Functional System Requirement 1.1.2

Functional System Requirement 1.1.1

Functional requirements describe how the user will achieve their goals which is what developers have to implement. Functional requirements will represent user-stories that are allocated to a sprint, broken into dev tasks and worked on.

Stakeholders

Identify and describe the role of the domain stakeholders in the proposed project as described by the project mentor. Stakeholders are not for the development process but domain stakeholders (e.g. different types of users, organization, government, licensing bodies, clients etc)


Each member of the team champions a stakeholder in order to ensure that they are considered in project planning, risk management and architecture discussions.


For each stakeholder, brainstorm the answers to the following questions throughout the ideation process:

  1. What are their specific interests in the system?
  2. Do they have specific requirements that are known a priori?
  3. Do they interact with the system?
  4. What functional areas of the system are they most interested in (once functional areas have been determined)?


Identify and describe the role of the domain stakeholders in the proposed project as described by the project mentor. Stakeholders are not for the development process but domain stakeholders (e.g. different types of users, organization, government, licensing bodies, clients etc)

... (other stakeholders)
Stakeholder 1

Identify the stakeholder name (not a a person's name but a role)


Each member of the team champions a stakeholder in order to ensure that they are considered in project planning, risk management and architecture discussions.

Project Overview

Describe the type of system that will be built according to the classifications discussed in Software Engineering. Using subtopics identify the main characteristics of the application and its features. A few paragraphs describing the purpose of the application, the problem it is intended to solve, the feasibility, and the impact of the project.

Team Composition and Roles

Every member of the team plays a significant role in each of the software engineering activities that are carried out. This demonstrates your expertise in conducting the necessary activities to develop a system.

Support

Communication Support

Tools and Device Support

Testing

Test Model Lead

Suggested responsibility of the project owner.

Verification & Validation Champion (by Functional Area)

Suggested responsibility for the functional area champion.

QA Lead

Suggested responsibility for the Risk Analyst.

Construction

Full-Stack Developer

Each team member must fulfill the role of a full-task developer that is responsible for developing UI, code, and unit tests for the code written. Work should be divided such that students can work independently of each other as soon as possible to allow for different rates of development and decrease project management risks.

Integration / DevOps Lead

One team member takes the lead on setting up the integration / dev-ops infrastructure. As integration is a major risk area, this is the suggested responsibility for the Risk Analyst.

Software Architecture

Interaction Model Lead

Deployment Model Lead

Design Model Lead

Suggested responsibility for the Software Architect.

Domain Model Lead

Requirements Model Lead

Software Architect

Suggested responsibility for the SCRUM Master.

Suggested responsibility for the SCRUM Master. The SCRUM master is responsible for the success of the sprint, making sure that all stories are broken down into dev tasks by each developer and that they are carried out correctly. The SCRUM master must recognize and resolve issues that would prevent the sprint from completing successfully. Typically this requires an in-depth understanding of the system which is usually gained by leading the software architecture effort.

Requirements Engineering

Each team member will have a significant role to play in requirements engineering for your project but the requirements analyst will lead this activities.

User Experience Design Lead

A single member of the team shall holder this responsibility which should be assigned to the team member with most experience and interest in UI design, wire-framing and HCI.

A single member of the team shall holder this responsibility which should be assigned to the team member with the most experience and interest in UI design, wire-framing, and HCI.

Functional Area Champion (by Functional Area)

Each member of the team must be responsible for at least one distinct and significant functional area.

Stakeholder Champion (by Stakeholder)

Each member of the team must be responsible for at least one distinct and significant stakeholder.

Requirements / Business Analyst

Suggested responsibility for the Project Owner.

Suggested responsibility for the Project Owner. Leading requirements engineering goes hand in hand with the project management role of a 'project owner'. The PO has to establish priorities of various features, ensure the details are present to allow design and development. The PO also communicates with stakeholders to ensure everyone is on the same page.

Project Management

Each team member should have a project management role. Each of these roles is critical to the success of the project. Review the roles in your sprint retrospectives and change them as necessary if you learn that different members are better suited for different roles.

Risk Analyst

SCRUM Master

Project Owner

Project Abstract

When you think you have enough details, identify the main points that should be covered by your project abstract. A good abstract is concise while describing the motivation/purpose of the project and the main characteristics/components of the solution.

Functional Areas

Identify three (maximum four) major functional areas of the project. Functional areas are used to group user requirements (use-cases) and represent distinct, non-overlapping, highly cohesive and loosely coupled areas of functionality in the project and are the basis of decomposition of the requirements model.


Each member of the team champions a functional area in order to ensure that it is considered in project planning, risk management and architecture discussions.

Identify three (maximum four) major functional areas of the project. Functional areas are used to group user requirements (use-cases) and represent distinct, non-overlapping, highly cohesive and loosely coupled areas of functionality in the project and are the basis of decomposition of the requirements model.

Each member of the team champions a functional area in order to ensure that it is considered in project planning, risk management and architecture discussions.

Functional Area 3
Functional Area 2
Functional Area 1
Main Features

Using subtopics identify the main characteristics of the application and its features. As you progress through your Capstone, keep coming back to this ideation surface when you think of new features.

Name your feature

Identify the name of the feature. Using sub-topics, ideate the benefits, the risks, and various feature characteristics.

Feature detail

Project Name

It doesn't have to be the final name but coming up with a smart project name is fun and challenging. A good project name can go a long way towards the success of the project.

Team Name

Be creative and establish an identity for your team. 

Be creative and establish an identity for your team.