1.
LeadershipChecklist™
CSS 350: Management Principles
Last modified: 5/30/2014
Team members:
Research ­ ​Rodelle Ladia Jr. User Interface ­ ​Bob Anderson
Organization ­ Sota Ogo Design Architect ­ ​Samuel HyunGyu Kim
Customer Interaction ­ ​Josh Brunner Discussion Facilitator ­ ​Jordan Walker
1 of 23

2. Version History
Version Date of Changes Summary Editors
0.0 April 23, 2014 Initial document Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
0.1 April 24, 2014 ­ Refined documents as
suggested by Professor
Razmov.
­ Added features
Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
0.2 May 30, 2014 ­ Refined operational
concept
­ Refined features
­ Refined lifecycle plan
­ Added detailed
software architecture
­ Added more UIs
­ Added software design
diagrams
Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
2 of 23

3. 1.0 Table of Contents
1.0 Table of Contents
2.0 Operational Concepts and Market Analysis
2.1 Problem Description
2.3 Current Situation
2.3 Competition Analysis
2.4 System Objectives
2.5 Target Audience
2.6 Value Proposition
3.0 System Requirements
3.1 Features
3.1.1 Daily Goals
3.1.2 Leadership Checklist
3.1.3 Individual Reference Tracker
3.1.4 Communication Troubleshooter
3.2 Usage Scenarios
3.2.1 Scenario A: Understanding Leadership
3.2.2 Scenario B: Leading with Others
3.2.3 Scenario C: Assigning Roles
3.3 Non­Functional Requirements
3.3.1 Usability
3.3.2 Reliability/Security
3.3.3 Maintainability
3.3.4 List of Additional Non­Functional Requirements
3.4 Functional Requirements
4.0 Tools and Technologies
4.1 High­level Technical Description
4.2 High­level Software Architecture/Design
4.2.1 Application language
4.2.2 Server OS
4.2.3 Database System
4.2.4 Web Server and Web Language
4.2.5 Third party libraries
4.2.6 Architectural Style
4.2.7 Assumptions and trade­off on Software Design
4.2.8 Alternative designs
4.3 High­fi UI­mockups
Figure 4.3.1 Tab Selecting Interface
Figure 4.3.2 Mock up for Welcome Screen
Figure 4.3.3 Individual Reference Tracker
Figure 4.3.4 Communication Troubleshooter
3 of 23

4. 4.4 High­level Design Diagrams
4.4.1 Domain Diagram
4.4.2 System architecture diagram
5.0 Lifecycle Plan
5.1 Stakeholders
5.1.1 Stakeholder Communication
5.1.1.1 Developers
5.1.1.2 Testers
5.1.1.3 Leaders in wild
5.1.1.4 Users
5.1.1.5 Investors
5.2 Objectives
5.3 Responsibilities
5.3.1 Team Description
5.4 Schedules/milestones
5.5 Development Methodology
5.6 Resources
5.7 Maintenance Plan
6.0 Feasibility Rationale
6.1 Project Risks
8.0 Bibliography
9.0 Appendix
9.1 Self Assessment
I. Business­related aspects
II. Project management­related
III. Risks and assumptions
IV. Feature­related
V. Tools and technologies
VI. Related work
VII. Overall presentation
4 of 23

5. 2.0 Operational Concepts and Market Analysis
2.1 Problem Description
People realize that leadership is a necessary part of functioning in a team but often do not
have the training or knowledge of how to be a successful leader. Leadership, like any skill,
can be improved over time with practice.
2.3 Current Situation
Currently available tools for improving leadership abilities are expensive, time­consuming, or
overly generic. Leadership seminars and classes focus on general topics and do not allow
users to practice improving their leadership over long periods of time. LeadershipChecklist™
is a unique solution that provides guided resources that help improve leadership.
2.3 Competition Analysis
We identified competitors listed in Table 2. As looking at our competitors’ applications,
LeadershipChecklist™ advances in providing suggestions according to each user’s situation.
Table 2: List of competitors
Name Brief description
The Leadership Challenge Mobile Tool
By Wiley Publishing
A mobile app for learning leadership skills by
providing mini­lectures
Leadership Development
By Smart Media Innovations Pty Ltd
A mobile app that provides news stories that
are related to leadership skills to help users
develop leadership skills
Personal Leadership App
By Dale Carnegie & Associates, Inc.
A mobile app that provides on­demand
leadership seminars.
KPMG Thought Leadership
By KPMG International Cooperative
A mobile app that provides leadership
issues/stories around the world
How2Lead 2.0
By The Ken Blanchard Companies
A mobile app that provides a news feed that
focuses on leadership tips
2.4 System Objectives
An application that allows users to improve their leadership ability without any formal training
or need for leadership authority. The latest research in leadership is used to improve what
information and how that information is presented to the user. To address time commitment
issues, the application provides just that; a detailed analysis and articles are presented which
can be expanded as necessary. The application allows users to improve their leadership over
5 of 23

6. time by providing daily goals and the ability to track their progress in developing leadership
characteristics.
LeadershipChecklist™ has sections and subsections which allow for detailed expandable
examples and explanations. The application allows users to track their performance in specific
leadership characteristics and provide goals. It provides resources such as checklists for new
projects and recommends feedback.
2.5 Target Audience
Our target audience is anyone looking to make a habit of improving their leadership without
the significant time investment required by seminars and/or classes. Our main target age is
between 20 to 40. Using our app, our users are able to track their progress and learn about
their leadership skills while doing so. Those looking to improve their leadership abilities by
becoming inspired to learn about the latest techniques will find our app extremely useful.
2.6 Value Proposition
For anyone who looking to make a habit of improving their leadership without the significant
time investment, LeadershipChecklist™ is an application that allows users to improve their
leadership without any formal training or need for leadership authority. Unlike classes and
seminars, this product inexpensive, customizable, and flexible around the user’s schedule.
6 of 23

7. 3.0 System Requirements
3.1 Features
This section contains the essential features for our system. It outlines what the features are as
well as describes them more in depth. You can find usage scenarios of the features listed
below in section ​3.2 Usage Scenarios​.
3.1.1 Daily Goals
The ​Daily Goals​ feature is a box on the welcome screen of the app that presents goals that
reflect leadership best practices. The daily goal feature will help the user to build upon their
existing skills while teaching new skills. For example, to improve the user’s ability to
communicate, a daily goal may be to ask team members for feedback on their communication
style. Asking for feedback is an effective method for practicing communication (​Stanonik​) and
helps to improve a user’s leadership skills.
3.1.2 Leadership Checklist
Any new project started by a team can be difficult. With our system, the user is able to go
through a checklist of tasks that reflect the best practices in leadership and is given
information about why these tasks reflect best practices.
For example, leaders must have a vision and be able to communicate that vision. The
checklist explicitly asks the user if the project’s vision is clearly stated and provide sub­lists
that help to clarify that vision. This feature interacts with the daily goals feature by providing a
goal for the user to assess how well that vision is communicated by asking team members if
they understand the vision and rating how well that person’s understanding matches with the
user’s understanding of the vision.
Inspiring and motivating team members is also a best practice related to leadership. ​When
team members are able to have control over their own situation, it helps them to focus on the
task and increases the amount of effort and persistence in achieving a unified goal (​United
States​).​ To reflect this best practice, the application explicitly asks if team members have
been assigned specific roles that provide them ownership over a piece of the project. The
application can provide a possible list of responsibilities and descriptions and may interact
with the individual reference tracker by suggesting roles that are tailored towards a team
member’s personality type.
3.1.3 Individual Reference Tracker
Every added team member will contain a notes section for the user to keep track of certain
bits of information. The notes will include personality tests(such as MBTI, Myers Briggs, etc.),
personal notes from the leader such as the member’s abilities and skills, preferences, trigger
words, etc. This feature provides richer decision making when the leader wants to assign
7 of 23

8. roles through ​Leadership Checklist​. For example, if the user want to do “Assign Roles” for the
certain member, the reference will give information to the leader about what kind of roles fit
better for the member.
3.1.4 Communication Troubleshooter
Users identify problems when communicating with others and the application provides
resources, checklists, or possible steps that can be taken to further identify and solve the
problem. Communication is an important aspect of leadership. Therefore, this application can
provide guidance for the user who would, otherwise, not have the time to look up the answer.
3.2 Usage Scenarios
This section contains examples of usage scenarios. Specifically, they depict actual usage
scenarios of a few of our essential features, as per mentioned in section ​3.1 Essential
Features​.
3.2.1 Scenario A: Understanding Leadership
Jake is a software developer for his CSS 497 team. He’s on a team of 6 other members and
would like to focus his 497 project towards developing his leadership skills on a software
development team. Using the ​Leadership Checklist ​feature of the app, he’s able to not only
learn how his interactions with the team artifacts influence other’s decisions, but he’s able to
see when and where he might be overstepping other people’s roles ­ bringing the entire team
progress down. Using ​Leadership Checklist​, Jake learns that overstepping member’s roles
does not reflect the behavior of a true leader.
3.2.2 Scenario B: Leading with Others
Janet is the project manager of a similar CSS 497 project as the one mentioned in section
3.2.1 Scenario A​. She’s always been the driving force of every one of her team projects
throughout her university courses. With the ​Leadership Checklist​ feature, she realizes that
she’s not fostering an environment for her peers on the team to improve their skills. After
logging her progress, the ​Daily Goals​ feature lets her know, through notifications, that she
seems to be a strong participant in the team. ​Daily Goals​ suggests a goal to encourage other
team members to participate in team activities. The suggestions provided let Janet know that
doing all the work isn’t characteristics of a strong leader. Janet is so thankful to have learned
more about team leadership while not having to go far out of her way to do so.
3.2.3 Scenario C: Assigning Roles
Jayce is the project manager of a small game development team with two developers, two
graphic designers, and one QA engineer. He has been taking notes about the personality and
preference of each members. One of the designers, Kimberly is very good at creative work,
but relatively weak at detailed painting. The other designer Wade is less creative, but very
good at realistic detailed work. New characters are needed for the new game project they
have just started a week ago. Jayce want to execute “Assign Jobs” to both of designer. There
is a button that directly shows the notes that he had been taking for the members. Referring to
8 of 23

9. the note, Jayce assigned “Concept Art” job to Kimberly, and “Props and Clothes Design” to
Wade.
3.3 Non­Functional Requirements
3.3.1 Usability
The goal of the application is to provide quick references to information to help solve
problems faced by those trying to improve their leadership abilities. The application should
provide relevant information based not only on what the user is actively searching for, but for
problems that can arise from common sources of conflict (for example, personality clashes or
lack of communication). Without a usable interface, the user does not have access to the
information they need and the value of the application drops dramatically.
3.3.2 Reliability/Security
The application stores sensitive data about the user and the user’s views on project team
members. This information is built up over time and would be very hard to replace if lost. The
sensitive nature of the data limits the use of traditional, online data storage and backup
schemes. The information should be transferred securely by encrypted way.
3.3.3 Maintainability
Providing leadership feedback tailored to specific situations is an ongoing field of study. The
application needs to be able to quickly integrate new information gained from research so that
users are being given the most relevant information in improving their leadership abilities.
3.3.4 List of Additional Non­Functional Requirements
ID Non­Functional Requirement Priority
NF1 The app must be build upon low­coupled modules High
NF2 The app must support unit testing for each module High
NF3 The app must enforce secure practices from its users High
NF4 The app use a secure connection (encrypted connection such as HTTPS) when the
data is transferred between a mobile device and web server
High
NF5 The app must provide its service 24 hours a day High
NF6 The app must support popular mobile devices Medium
NF7 The app must have readable font sizes Medium
NF8 The app must provide maintainable contents management system for updating new
contents by an administrator
Medium
3.4 Functional Requirements
ID Functional Requirement Priority
9 of 23

10. F1 Users can create new projects High
F2 Users receive feedback on how to act as a leader for a project High
F3 Users can assign team members to projects High
F4 Users can assign roles to team members on a project High
F5 Users can enter a textual version of the vision for the project High
F6 Users can plan meetings High
F7 Users will be able to set up a user name associated with their email High
F8 Users will have a profile page associated with their user name High
F9 A user’s private notes are encrypted and require the user password to decrypt High
F10 The user’s data is periodically saved to the phone’s memory High
F11 Users will be able to give the product owner feedbacks about the app High
F12 Users can add and reference notes of individuals on a team Medium
F13 Users receive leadership advice based on an team members’ personality style Medium
F14 Users can access a mailbox function to send and reply to team members Medium
F15 App contains a database that contains daily tips Medium
F16 Daily tips provide are tailored to the user’s project Medium
F17 The app will provide the ability for users with seeing disabilities to enlarge font
size
Medium
F18 Users are sent project reminders for their individual projects Low
F19 Users can view a visualization of their projects and progress Low
10 of 23

11. 4.0 Tools and Technologies
4.1 High­level Technical Description
The main value of the program is in the information that is presented to the user. Mobile
application development (using Java) allows us to use a familiar framework for developing a
user interface that can access the information provided by research into leadership training.
4.2 High­level Software Architecture/Design
The following sub­sections aim to identify the software architecture that should be
implemented upon approval of this project’s proposal.
4.2.1 Application language
This application will be written in different languages depending on the environment in which
the application will need to operate. For the initial implementation (which will be on Android
devices), the application will be written in Java. For future implementations (currently
unplanned), on IOS the application will be written in Objective­C, and on Windows Phone OS
the application will be written in C#.
4.2.2 Server OS
This application will pull all of it’s user information and leadership information from a central
server. This server will use Windows Server 2012 as its operating system.
4.2.3 Database System
The information utilized by this application will be stored in a Microsoft SQL 2012 database
which will be maintained with an administrative web front­end.
4.2.4 Web Server and Web Language
In order to maintain the database and add leadership information, there will be an
administrative web front­end hosted by Microsoft IIS and programed in ASP.NET 4.5.
4.2.5 Third party libraries
Due to the simplicity of this app it is feasible for us to complete this project without the use of
third party libraries, so the majority of the work will be done from scratch in order to maintain
control of our codebase.
4.2.6 Architectural Style
Because of the nature of the web­based application, the software will be build based on two
main architectural styles, Model­View­Controller (MVC) and Representational state transfer
(REST), for the server­side application.
4.2.7 Assumptions and trade­off on Software Design
Table 4­1 shows assumptions and trade­offs for specific technologies chose.
11 of 23

12.
Table 4­1: Assumptions and trade­offs
Assumptions Trade­offs
Mobile languages
(C#, Objective­C,Java)
Although using a common language for all the mobile platforms
(by using a build tool such as PhoneGap) is cheaper in terms of
the labor costs, it is much better to use mobile specific
languages to increase the app performance.
Windows Server 2012 Many popular web services are using linux­based OS for a
server so there might be fewer information about the web
development; however, Windows server 2012 is more reliable
than others according to our experiences.
4.2.8 Alternative designs
There are many alternative designs we could have gone with for this system, but overall we
believe the path we have chosen is the best. The main difference between the design we
chose to go with and the bulk of the other possible designs is the use of a Windows Server
backend instead of a Linux backend. Going with a Linux backend obviously would have
changed a lot about our system simply because its toolchain is almost entirely detached from
Windows. The main reason we decided to figuratively “bite the bullet” and go with a Windows
based system is Windows offers a lot of support for their systems and Linux being a mainly
open sourced entity does not offer support. The support that Microsoft offers for Windows
could prove to be invaluable in a time of need for our software.
12 of 23

13. 4.3 High­fi UI­mockups
Figure 4.3.1 Tab Selecting Interface
Figure 4.3.1 shows how user can jump among the main features. On
any screen, if the user swipe the screen from left to right, it will show
the current tab and tabs that user can jump.
Figure 4.3.2 Mock up for
Welcome Screen
Figure 4.3.2 shows the tips of
the day and the daily checklist
for leadership. as soon as the
user clicks tips or a certain
role, the details will appear on
the screen.
13 of 23

14. Figure 4.3.3 Individual Reference Tracker
Figure 4.3.3 belongs to the main feature Individual Reference Tracker.
The user can add individual references for coworkers. This references
will be used for decision making with the person.
Figure 4.3.4 Communication Troubleshooter
Figure 4.3.4 shows Communication Troubleshooter which will provide
the recommended steps for the user who meets communication
problem. The user can choose the type of the communication problem,
and according to the problem, the application will show the suggestions
that can help solving the communication problem.
14 of 23

15. 4.4 High­level Design Diagrams
This section identifies the modules and components of our software on a high level. Many of
the parts required to make this system are listed here along with basic information about how
these parts of the system interact with each other. Furthermore, this section of the document
considers other possible designs for this system and identifies why the chosen system might
be better
4.4.1 Domain Diagram
Figure 4­1 ​depicts​ ​the high level components of the system and roughly how they interact with
each other in the form of a domain diagram.
Figure 4­2: Domain Diagram
15 of 23

16. 4.4.2 System architecture diagram
Figure 4­2 shows the high level components of the system. Between Mobile devices and the
web server, user information and dynamic contents will be transferred.
Figure 4­2: System architecture diagram
16 of 23

17. 5.0 Lifecycle Plan
5.1 Stakeholders
This section contents a list of stakeholders.
● Developers
● Testers (and QA)
● Leaders in wild
● Users
● Investors
5.1.1 Stakeholder Communication
As with any project’s success, communication with stakeholders throughout the process is
very crucial. Since we’ve suggested that the SCRUM methodology is used throughout
implementation, communication with the stakeholders will occur at minimum on a monthly
basis.
5.1.1.1 Developers
For the developers, communication will be on a daily basis. This is because development and
communication in an environment where open dialogue is encouraged. It is proven that this
kind of environment supports high levels of productivity.
5.1.1.2 Testers
For the testers, communication will be on a weekly basis. Since it is up to the testers to
ensure that the work that the developers are doing is working in a manner that is appropriate
to uphold the company’s reputation. Therefore, it is vital that the testers are able to
communicate with the developers at least one day a week.
5.1.1.3 Leaders in wild
Since our application focuses on providing useful leadership tips and recommendations, it’s
important to maintain a reliable level of leadership expertise being recommended to our app.
However, since leadership styles is not something that changes on a daily basis,
communication with actual leaders is only required on a monthly basis.
5.1.1.4 Users
Users can communicate with the product owner via our app by a feedback function. This
happens when users notice any issues or improvements of the app.
5.1.1.5 Investors
As we plan on using the SCRUM methodology, we encourage the investors to attend
meetings that will be held at the beginning of Sprint and at the end of Sprint. Opinions are
welcomed during the meetings.
17 of 23

18. 5.2 Objectives
Ensure that high quality systems are delivered, provide strong management controls, and
maximize the productivity of the systems. We aim to be able to deliver a product that helps its
user to learn more about their leadership skills as well as motivate them to explore new
attributes of strong leaders.
5.3 Responsibilities
This section explains what type of professionals we need to complete this project.
5.3.1 Team Description
Table 5­1 shows the team organization and job descriptions for this project.
Table 5­1: Team organization and Job descriptions
Title Role Description
of duties
Qualification Number of
Employees
Scrum Master
Organizing
and leading
the group
Keep the Scrum
going in the
right direction
and on time.
2+ years recent web/mobile
development project
experience and 1+ years
project management
experience
1
Lead Developer
Architecture
and Design
Choices
Lead the
development
team as well as
developing
5+ years recent web/mobile
development project
experience
1
Junior
Developer
Software
Development
develop/implem
ent the
functions
1+ years recent web/mobile
development project
experience
2
Lead Designer
Customer
Interaction
Lead the design
team as well as
designing
5+ years recent web/mobile
development project
experience
1
Junior Designer
Usability
Design
Design the
interface of the
system
2+ years recent web/mobile
development project
experience
1
Quality
Assurance
Intern
Clarifying
and
Summarizing
Test the service 1+ years recent web/mobile
development project
experience
1
Total: 7
18 of 23

19. 5.4 Schedules/milestones
Table 5­2​ shows milestones and tentative schedule for the project's implementation over the
course of one year worth of development.
Table 5­2: Schedules and milestones
Milestones Description Milestone Criteria Planned Date
M0 Start Project Budget Release Month 1
Requirements
Validation
Focus group studies used to validate
and refine final feature requirements.
Month 1­2
Complete high­level
design and research
Pile requirements up in Product
backlog and Sprint backlog.
Month 2­3
Customer Approval
and design changes
Meet with the customer/s and get their
written approval of the design
Month 3
M1 Start Construction
Iterations
Sprint starts Month 3
M2 Launch version alpha Testable application is released to
internal testers to receive feedback
Month 6
M3 Launch version beta Fully functional application is released
to the public (some bugs may still exist)
Month 8
M4 Launch version 1.0 Fully functional application “bug­free” is
released to the public
Month 10
M5 Maintain and evolve
the software
New research is consistently added to
the database, and new features are
added
Month 11 ­
N/A
M6 Retirement “Get off my lawn!” N/A
5.5 Development Methodology
During implementation, we suggest that the SCRUM management process is used.
5.6 Resources
Six months is needed to validate user requirements and develop an initial prototype, and an
additional six months is required to fully assemble the knowledge database and polish the
user interface. The actual program isn’t complex, and the user interaction with the program is
highly dependent on the presentation of available research.
5.7 Maintenance Plan
As a maintenance plan for this system, we propose that new features are added to the
backlog during the monthly meetings that the stakeholders shall have. Any issues or bugs that
arise, shall be dealt with according to their priority in the backlog.
19 of 23

20. 6.0 Feasibility Rationale
6.1 Project Risks
This section is a depiction of the risks that our team has identified. ​Table 6­1​ shows a table of
risks and their mitigation procedures. In addition, each risk has characteristic associated with
it. These characteristics are Probability, Impact, and Exposure.
Table 6­1: Project Risk Descriptions
Probability Description Mitigation Impact Exposure
Probable If the app crashes, there’s a
risk of the user’s input not
being saved properly. This
might result in data loss.
Create an autosave
feature in the app
to handle
interruptions
Serious Medium
Probable If ​Daily Goals​ suggests things
to the user that does not
improve their perception of
leadership.
All ​Daily Goals​ are
to reflect the latest
in leadership
research.
Serious High
Probable If we as a team can’t complete
our project proposal by the
deadline, the project will never
see the light of day.
Careful planning
and organization by
the team will result
in completion.
Critical Intolerable
20 of 23

21. 8.0 Bibliography
Angier, Michael. "Top Ten Ways to Inspire Others to Be Their Best." "Top Ten Ways to Inspire
Others to Be Their Best" by Michael Angier. Success Networks International, n.d.
Web. 29 Apr. 2014.
Garcia, Helio. "How to Use Communication to Build Trust and Inspire Loyalty, as Well as Lead
Effectively." How to Use Communication to Build Trust and Inspire Loyalty, as Well as
Lead Effectively. American Management Association, 17 Sept. 2012. Web. 29 Apr.
2014.
Martin Luther King Jr. "I Have a Dream." Martin Luther King I Have a Dream Speech ­
American Rhetoric. 28 Aug. 1963. Web. 28 Apr. 2014.
"Organizational Assessment: How Does a Company Conduct a Training­needs Analysis?"
SHRM. Society for Human Resource Management​, 27 Nov. 2012. Web. 01 May 2014.
Rafferty, Alannah E., and Mark A. Griffin. "Dimensions of Transformational Leadership:
Conceptual and Empirical Extensions." ​The Leadership Quarterly ​15.3 (2004):
329­354. Web.
S­Cool. "Management, Leadership, Motivation and Communication." GCSE Revision and A
Level Revision. S­cool, 16 Sept. 2010. Web. 29 Apr. 2014.
Shambaugh, Rebecca. "Five Tips on How to Inspire Your Employees in Challenging Times."
Hiring, Recruiting and Staffing Solutions. Monster.com, n.d. Web. 29 Apr. 2014.
Silverstein​, Barry. “Best Practices: Motivating Employees: Bringing Out the Best in Your
People”. New York:HarperCollins Publishers, 2007.
Stanonik, Rebecca. "Better Business Center." Better Business Center. Torkusa.com, 10 Oct.
2013. Web. 29 Apr. 2014.
United States. “Army Leadership: Field manual 6­22.” Washington, DC. Headquarters,
Department of the Army. 12 Oct. 2006 Web. 1 May 2014
21 of 23

22. 9.0 Appendix
9.1 Self Assessment
I. Business­related aspects
name: brand
whole product
market analysis Market analysis is the next
crucial point in this project by
doing market research. By
doing so we should be able
to create concrete marketing
strategy to be financially
successful.
communication plan with
stakeholders
II. Project management­related
time frame (full life­cycle)
resource description
(people, etc.)
milestones
support/maintenance plans
after shipping
progress been made since
the last deliverable: is it
sufficient?
III. Risks and assumptions
how critical each one is
corresponding mitigation
plans
22 of 23

23. IV. Feature­related
­­ most critical functional and
non­functional requirements
­­­ which ones do
stakeholders need the most?
UI In the current UIs, They
don’t cover small functions
like user feedback, so the
next step will be identifying
all the required UIs for this
project.
V. Tools and technologies
includes a description of
technologies to be used
overall architecture/design,
use of frameworks
feasibility taken into
consideration (if starting
from scratch, if using 3rd
party libraries, etc.)
VI. Related work
What others have done /
found before?
Why (and where) yours is
better?
VII. Overall presentation
professionalism, style, TOC,
CRAP principles
23 of 23