75645 Topic documenting the project life cycleNumber of Pages.docx

75645 Topic: documenting the project life cycle
Number of Pages: 4 (Double Spaced)
Number of sources: 1
Writing Style: APA
Type of document: Coursework
Academic Level:Undergraduate
Category: Computer Science
Language Style: English (U.S.)
Order Instructions: Attached
Well-written project documentation clarifies intent, documents
decisions and results, and allows project managers to assess
project progress (and report it, as necessary, to project
stakeholders) at every step of the project lifecycle.
For this assignment, you will create two examples of project
documentation that align with the Project Plan Draft assignment
you completed in Week 1. The documentation you will create
for this assignment aligns with the initiation and planning
phases of a project.

If you chose the waterfall methodology for your Week 1 Project
Plan Draft assignment, create the following:
A business requirements document, or BRD: Use the Business
Requirements Template as the basis for your BRD.
A work breakdown schedule, or WBS: Use the Work Breakdown
Structure (WBS) Example document as the basis for your WBS.
Alternatively, if you chose the Agile methodology for your
Week 1 Project Plan Draft assignment, create the following:
A product requirements document, or PRD: Read "Product
Requirements Documents, Downsized" for assistance in creating
this document.
User stories/scenarios and acceptance criteria: Review "Agile
Requirements Snail: Feature to User Story to Scenario" for help
in creating this document. Then use the Scenarios and COS tabs
located in User Scenarios And Acceptance Criteria Example as
the basis for your user stories/scenarios and acceptance criteria.
Submit your completed BRD and WBS, or your completed PRD
and user stories/scenarios with acceptance criteria.
CSCI 561 DB Standardized Rubric
50 Points
Criteria
Levels of Achievement
Content
Advanced
Proficient
Developing
Not present

Thread (19 pts.)
Student effectively answers the questions with supporting
material from the week’s reading with thoughtful analysis.
Christian worldview integration found, supported by scripture.
19 to 17 points*
Student’s post effectively answers both questions in the
discussion board by thoroughly analyzing material presented by
the course readings (internal sources) as well as other
academically approved sources (external). Post shows a
thorough interaction with material in a thought-provoking
manner to encourage class interaction.
16 points*
Student’s post effectively answers the key points of both
questions in the discussion board. Post reveals interaction with
course readings (internal) sources or other academically
approved (external) sources. Post shows proficient interaction
with material in logical manner so as to encourage class
interaction.
15 to 1 points*
Student’s post answers all or most of the key points of both
questions in the discussion board. Post reveals interaction with
some course (internal) sources or other (external) sources. Post
shows moderate interaction with material in logical manner
which may or may not promote class interaction.
0 points
No post was made for this thread.
Reply 1 (8 pts)
Student commentary adds value to the ongoing conversation,
supports thoughts with academic material. Christian
worldview integration found, supported by scripture.
8 points*
Student’s reply adds notable depth to the ongoing conversation
and encourages collaborative discussion among peers in a
thought-provoking way. Student supports their thoughts with
both course readings (internal sources) and other academically
approved sources (external). Biblical integration found.

7 points*
Student’s reply adds some depth to the ongoing conversation
proficient way. Student supports their thoughts with either
course readings (internal sources) or other academically
6 to 1 points*
Student’s reply adds minimal depth to the ongoing conversation
among peers in a thought-provoking way. Student supports their
thoughts with either course readings (internal sources) or other
sources (external). Biblical integration may or may not be
found.
0 points
No initial reply was made for this thread.
Reply 2 (8 pts)
Student commentary adds value to the ongoing conversation,
supports thoughts with academic material. Christian
worldview integration found, supported by scripture.
8 points*
Student’s reply adds notable depth to the ongoing conversation
course readings (internal sources) or other academically
7 points*
Student’s reply adds some depth to the ongoing conversation
either course readings (internal sources) or other academically
6 to 1 points*
Student’s reply adds minimal depth to the ongoing conversation
among peers in a thought-provoking way. Student supports their
thoughts with either course readings (internal sources) or other
sources (external). Biblical integration may or may not be
found.

0 points
No second reply was made for this thread.
Structure
Advanced
Proficient
Developing
Not present
Thread (5 pts)
Post should be at least 350 words with proper APA formatting
elements and proper grammar and spelling.
5 points*
Post was between 350 and 700 words and exhibited solid APA
formatting of paragraphs, citations and references. No grammar
or spelling issues found.
4 points*
Post was at least 350 words and exhibited only minor APA
formatting issues. Minor grammar or spelling issues found that
do not detract from the reader’s ability to comprehend the post.
3 to 1 points*
Post was between 175 and 350 words. Student attempts to
illustrate proper APA form in the post. Grammar or spelling
issues were notable but did not prevent reader from
understanding the key aspects of the post.
0 points
Post was less than 175 words or did not get posted at all or was
grammatically difficult to follow.
Reply 1 (5 pts)
Reply should be at least 150 words with proper APA formatting
5 points*
Reply was between 150 and 300 words and exhibited solid APA
formatting of paragraphs, citation, and references. No grammar
or spelling issues found.

4 points*
Reply was at least 150 words and exhibited only minor APA
3 to 1 points*
Reply was at least 100 words. Student attempts to illustrate
proper APA form in the post. Grammar or spelling issues were
notable but did not prevent the reader from understanding the
key aspects of the post.
0 points
Reply was less than 100 words or did not get posted at all or
was grammatically difficult to follow.
Reply 2 (5 pts)
Reply should be at least 150 words with proper APA formatting
5 points*
Reply was between 150 and 300 words and exhibited solid APA
formatting of paragraphs, citation, and references. Reply
content is fundamentally different than the first reply. No
grammar or spelling issues found.
4 points*
Reply was at least 150 words and exhibited only minor APA
Reply content was fundamentally different than the first reply.
3 to 1 points*
Reply was at least 100 words. Student attempts to illustrate
proper APA form in the post. Grammar or spelling issues were
notable but did not prevent the reader from understanding the
key aspects of the post. Reply content may or may not be
fundamentally different than first reply.
0 points
Reply was less than 100 words or did not get posted at all or
was grammatically difficult to follow. Reply was simply a
copy/paste of the first reply with little or no content change.

*Please see the Levels of Achievement Points spreadsheet for
standardized point values based off your school/department’s
grading scale.
CMGT/410 v19
Business Requirements Template
CMGT/410 v19
Page 13 of 14Business Requirements TemplateHow to Use This
Document
This document is a template for creating a Business
Requirements Document (BRD); it includes instructions and
examples for guidance. As you complete your BRD using the
template, only include sections pertinent to your project.Table
of Contents
How to Use This Document1
Table of Contents1
1.Executive Summary2
1.1Project Overview2
1.2Purpose and Scope of this Specification2
2.Product/Service Description3
2.1Product Context3
2.2User Characteristics3
2.3Assumptions3
2.4Constraints3
2.5Dependencies3
3.Requirements4
3.1Functional Requirements4
3.2User Interface Requirements5
3.3Usability5
3.4Performance6
3.4.1Capacity6
3.4.2Availability6
3.4.3Latency6
3.5Manageability/Maintainability6

3.5.1Monitoring6
3.5.2Maintenance6
3.5.3Operations7
3.6System Interface/Integration7
3.6.1Network and Hardware Interfaces7
3.6.2Systems Interfaces7
3.7Security8
3.7.1Protection8
3.7.2Authorization and Authentication8
3.8Data Management8
3.9Standards Compliance9
3.10 Portability9
4.User Scenarios/Use Cases9
5.Deleted or Deferred Requirements9
6.Requirements Confirmation/Stakeholder Sign-Off10
Appendices11
Appendix A: Definitions, Acronyms, and Abbreviations11
Appendix B: References11
Appendix C: Requirements Traceability Matrix12
Appendix D: Organizing the Requirements131. Executive
Summary
1.1 Project Overview
Describe this project or product and its intended audiences, or
provide a link or reference to the project charter.
1.2 Purpose and Scope of this Specification
Describe the purpose of this specification and its intended
audience. Include a description of what is within the scope what
is outside of the scope of these specifications.
Example:
In Scope
This document addresses requirements related to Phase 2 of
Project A:
· Modification of Classification Processing to meet legislative
mandate ABC

· Modification of Labor Relations Processing to meet legislative
mandate ABC
Out of Scope
The following items in Phase 3 of Project A are out of scope:
· Modification of Classification Processing to meet legislative
mandate XYZ
· Modification of Labor Relations Processing to meet legislative
mandate XYZ
(Phase 3 will be considered in the development of the
requirements for Phase 2, but the Phase 3 requirements will be
documented separately.)2. Product/Service Description
In this section, describe the general factors that affect the
product and its requirements. This section should contain
background information, not state specific requirements
(provide the reasons why certain specific requirements are later
specified).
2.1 Product Context
How does this product relate to other products? Is it
independent and self-contained? Does it interface with a variety
of related systems? Describe these relationships or use a
diagram to show the major components of the larger system,
interconnections, and external interfaces.
2.2 User Characteristics
Create general customer profiles for each type of user who will
be using the product. Profiles should include:
· Type of user (e.g., student, faculty, staff, other)
· Experience of the user
· Technical expertise level of the user
· Other general characteristics of the user that may influence the
product2.3 Assumptions
List any assumptions that affect the requirements, for example,
equipment availability, user expertise, etc. For example, a
specific operating system is assumed to be available; if the
operating system is not available, the Requirements

Specification would then have to change accordingly.
2.4 Constraints
Describe any items that will constrain the design options,
including:
· Parallel operation with an old system
· Audit functions (audit trail, log files, etc.)
· Access, management, and security
· Criticality of the application
· System resource constraints (e.g., limits on disk space or other
hardware limitations)
· Other design constraints (e.g., design or other standards, such
as programming language or framework)
2.5 Dependencies
List dependencies that affect the requirements.
Examples:
· This new product will require a daily download of data from
X.
· Module X needs to be completed before this module can be
built. 3. Requirements
Describe all system requirements in enough detail for designers
to design a system satisfying the requirements, and for testers to
verify that the system satisfies requirements.
Organize these requirements in a way that works best for your
project. See Appendix D: Organizing the Requirements for
different ways to organize these requirements.
Describe every input into the system, every output from the
system, and every function performed by the system in response
to an input or in support of an output. (Specify what functions
are to be performed on what data to produce what results at
what location for whom.)
Each requirement should be numbered (or uniquely identifiable)
and prioritized.
See the sample requirements in Section 3.1, Functional
Requirements and Section 3.6, System Interface/Integration, as

well as the following example priority definitions which are
intended as a guideline to prioritize requirements:
· Priority 1 – The requirement is a “must have” as outlined by
policy/law.
· Priority 2 – The requirement is needed for improved
processing, and the fulfillment of the requirement will create
immediate benefits.
· Priority 3 – The requirement is a “nice to have”, which may
include new functionality.
It may be helpful to phrase the requirement in terms of its
priority, e.g., "the value of the employee status sent to DIS must
be either A or I" or "it would be nice if the application warned
the user that the expiration date was 3 business days away".
Another approach would be to group requirements by priority
category.
A good requirement is:
· Correct
· Unambiguous (All statements have exactly one interpretation.)
· Complete (Where TBDs are absolutely necessary, document
why the information is unknown, who is responsible for
resolution, and the deadline.)
· Consistent
· Ranked for importance and/or stability
· Verifiable (Avoid soft descriptions like “works well” or “is
user friendly”; use concrete terms and specify measurable
quantities.)
· Modifiable (Evolve the Requirements Specification only via a
formal change process, preserving a complete audit trail of
changes.)
· Does not specify any particular design
· Traceable (Cross-reference with source documents and
spawned documents.)3.1 Functional Requirements
In the example below, the requirement numbering has a scheme
- BR_LR_0## (BR for Business Requirement, LR for Labor
Relations). For small projects, simply BR-## would suffice.
Keep in mind that if no prefix is used, the traceability matrix

may be difficult to create (e.g., no differentiation between '02'
as a business requirement vs. a test case).
The following table is an example format for requirements.
Choose whatever format works best for your project.
Example:
Req #
Requirement
Comments
Priority
Date Received
SME Reviewed/Approved
BR_LR_05
The system should associate a supervisor indicator with each
job class.
Business Process = “Maintenance
3
7/13/16
Bob Dylan, Mick Jagger
BR_LR_08
The system should handle any number of fees (existing and
new) associated with unions.
Business Process = “Changing Dues in the System”
An example of a new fee is an initiation fee.
2
7/13/16
BR_LR_10
The system should capture and maintain job class status (i.e.,
active or inactive)
Business Process = “Maintenance”
Some job classes are old and are no longer used. However, they
still need to be maintained for legal, contract and historical
purposes.
2
7/13/16
Bob Dylan, Mick Jagger3.2 User Interface Requirements

In addition to functions required, describe the characteristics of
each interface between the product and its users (e.g., required
screen formats/organization, report layouts, menu structures,
error and other messages, or function keys).
3.3 Usability
Include any specific usability requirements. (See
http://www.usabilitynet.org/.)
Example:
Learnability
· The user documentation and help should be complete.
· The help should be context sensitive and explain how to
achieve common tasks.
· The system should be easy to learn.3.4 Performance
Specify static and dynamic numerical requirements placed on
the system or on human interaction with the system:
· Static numerical requirements may include the number of
terminals to be supported, the number of simultaneous users to
be supported, and the amount and type of information to be
handled.
· Dynamic numerical requirements may include the number of
transactions and tasks and the amount of data to be processed
within a certain time period for both normal and peak workload
conditions.
All of these requirements should be stated in measurable form.
For example, "95% of the transactions shall be processed in less
than 1 second" rather than “an operator shall not have to wait
for the transaction to complete”.3.4.1 Capacity
Include measurable capacity requirements (e.g., the number of
simultaneous users to be supported, the maximum simultaneous
user load, per-user memory requirements, expected application
throughput).3.4.2 Availability
Include specific and measurable requirements for:
· Hours of operation
· Level of availability required
· Coverage for geographic areas

· Impact of downtime on users and business operations
· Impact of scheduled and unscheduled maintenance on uptime
and maintenance communications procedures
· Reliability (e.g., acceptable mean time between failures
(MTBF), or the maximum permitted number of failures per
hour)3.4.3 Latency
Include explicit latency requirements, e.g., the maximum
acceptable time (or average time) for a service request.
3.5 Manageability/Maintainability3.5.1 Monitoring
Include any requirements for product or service health
monitoring, failure conditions, error detection, logging, and
correction.3.5.2 Maintenance
Specify attributes of the system that relate to ease of
maintenance. These requirements may relate to modularity,
complexity, or interface design. Requirements should not be
placed here simply because they are thought to be good design
practices.3.5.3 Operations
Specify any normal and special operations required by the user,
including:
· Periods of interactive operations and periods of unattended
operations
· Data processing support functions
· Backup and recovery operations
· Safety considerations and requirements
· Disaster recovery and business resumption3.6 System
Interface/Integration
Specify the use of other required products (e.g., a database or
operating system), and interfaces with other systems (e.g.,
UWHires package interfaces with PubCookie and ODS, HEPPS
system interfaces with Budget system). For each interface,
define the interface in terms of message format and content. For
well-documented interfaces, simply provide a reference to the
documentation.
Outline each interface between the product and the hardware or
network components of the system. This includes configuration

characteristics (e.g., number of ports, instruction sets), what
devices are to be supported, and protocols (e.g., signal
handshake protocols).3.6.1 Network and Hardware Interfaces
Specify the logical characteristics of each interface between the
product and the hardware or network components of the system.
This includes configuration characteristics (e.g., number of
ports, instruction sets), what devices are to be supported, and
protocols (e.g., signal handshake protocols).3.6.2 Systems
Interfaces
Specify the systems interface requirements.
Example:
System1-to-System2 Interface
The <external party> will create and send a fixed length text
file as an email attachment to [email protected] to be imported
into the System2 system for payroll calculation. This file must
be received on EDIT day by 4:00 PM in order to be processed in
the EDIT night run. The requirements below document the file
specifications, data transfer process, and specific schedule. This
file is referred to as "FileName" in this document.
File Structure and Format
A1. The FileName file is a fixed length text file.
A2. The FileName file is an unformatted ASCII file (text-only).
A3. The FileName file contains a batch totals record and several
detail records.
File Description: Batch Totals Record
A4. The batch totals record can be placed at the beginning, in
the middle, or at the end of the file.
A5. The batch totals record contains the following:
· Record Type (value: XA)
· Process Type (value: A)
· Batch Number (3 digit number assigned by Payroll Dept)
· Origin Code (AIG)
· Total number of detail records
· Total deduction amount
File Description: Detail Records
A6. The FileName file contains a row for each record meeting

xxx criteria.
A7. Each row in the FileName file contains the following fields,
comma-delimited and encased in double-quotes where the data
includes commas or spaces:
· Employee ID
· Record Type
· Process Date (MMDDYY)
· XYG Number
· Element Code
· Amount
· Amount Sign
· Year Flag
· Total Amount
· Total Amt Sign
3.7 Security3.7.1 Protection
Specify the factors that will protect the system from malicious
or accidental access, modification, disclosure, destruction, or
misuse.
Example:
· Encryption
· Activity logging, historical data sets
· Restrictions on intermodule communications
· Data integrity checks3.7.2 Authorization and Authentication
Specify the Authorization and Authentication factors. Consider
using standard tools such as PubCookie.
3.8 Data Management
Specify the requirements for any information that is to be
placed into a database, including:
· Types of information used by various functions
· Frequency of use
· Data access rules
· Data entities and relationships
· Integrity constraints
· Data retention

· Valid range, accuracy, and/or tolerance
· Units of measure
· Data formats
· Default or initial values
3.9 Standards Compliance
Specify the requirements derived from existing standards,
policies, regulations, or laws (e.g., report format, data naming,
accounting procedures, audit tracing). For example, this could
specify the requirement for software to trace processing
activity. Such traces are needed for some applications to meet
minimum regulatory or financial standards. An audit trace
requirement may, for example, state that all changes to a payroll
database must be recorded in a trace file with before and after
values.3.10 Portability
If portability is a requirement, specify attributes of the system
that relate to the ease of porting the system to other host
machines and/or operating systems.
Example:
· Percentage of components with host-dependent code
· Percentage of code that is host dependent
· Use of a proven portable language
· Use of a particular compiler or language subset
· Use of a particular operating system
· The need for environment-independence (The product must
operate the same regardless of operating systems, networks,
development, or production environments.)4. User
Scenarios/Use Cases
Provide a summary of the major functions that the product will
perform. Organize the functions to be understandable to the
customer or a first time reader. Include use cases and business
scenarios, or provide a link to a separate document (or
documents). A business scenario:
· Describes a significant business need
· Identifies, documents, and ranks the problem that is driving
the scenario

· Describes the business and technical environment that will
resolve the problem
· States the desired objectives
· Shows the “actors” and where they fit in the business model
· Is specific, measurable, and uses clear metrics for success5.
Deleted or Deferred Requirements
Identify any requirements that have been deleted after approval
or that may be delayed until future versions of the system.
Example:
Req #
Business Requirement
Status
Comments
PRI
Date Reviewed
SME Reviewed/Approved
BR_LR_01
The system should validate the relationship between Bargaining
Unit/Location and Job Class.
April 2005: Deleted.
This requirement has been replaced by BR_LR_036 and
BR_CC_33.
Business Process = “Assigning a Bargaining Unit to an
Appointment”
1
7/13/04
BR_LR_02
The system should validate that the supervisor indicator is
correct according to job class.
Deferred to Phase 2B: 3/29/2005
April 2005: Deferred to Phase 2B.
Appointment”
3
7/13/04

BR_LR_03
The system should derive the bargaining unit code, union code,
and supervisor indicator from the job class code and location.
April 2005: Deleted.
Replaced by BR_LR_16 and BR_LR_17.
Appointment”. This will eliminate the need, typically, for the
user to enter the bargaining unit code, union code, and
supervisor indicator.
1
7/13/04
Bob Dylan, Mick Jagger6. Requirements
Confirmation/Stakeholder Sign-Off
Include documentation of the approval or confirmation of the
requirements.
Example:
Meeting Date
Attendees (Name and Role)
Comments
7/13/17
Bob Dylan, Labor Relations SME
Mick Jagger, Labor Relations SME
Ringo Starr, Technical Project Manager
Debbie Harry, Technical Analyst
Janis Joplin, Technical Analyst
Fred Meyer, Project Manager
Confirmed BR_LR_01 – BR_LR_15
08/15/17
Bob Dylan, Labor Relations SME
Mick Jagger, Labor Relations SME
Ringo Starr, Technical Project Manager
Deferred / Deleted: BR_LR_01 - BR_LR_04, BR_LR_07,
BR_LR_12, BR_LR_14, BR_LR_15, BR_LR_06, BR_LR_17
Appendices
The appendices are not always considered part of the actual

Requirements Specification and are not always necessary. They
may include:
· Sample input/output formats, descriptions of cost analysis
studies, or results of user surveys
· Supporting or background information that can help the
readers of the Requirements Specification
· A description of the problems to be solved by the system
· Special packaging instructions for the code and the media to
meet security, export, initial loading, or other requirements
When appendixes are included, the Requirements Specification
should explicitly state whether or not the appendixes are to be
considered part of the requirements.Appendix A: Definitions,
Acronyms, and Abbreviations
Define all terms, acronyms, and abbreviations used in this
document.Appendix B: References
List all documents and other materials referenced in this
document.Appendix C: Requirements Traceability Matrix
The following trace matrix examples show one possible use of
naming standards for deliverables (FunctionalArea-DocType-
NN). The number has no other meaning than to keep the
documents unique. For example, the Bargaining Unit
Assignment Process Flow would be BUA-PF-01.
Example 1:
Business Requirement
Area
Deliverables and Status
BR_LR_01
The system should validate the relationship between Bargaining
Unit/Location and Job Class.---Comments: Business Process =
"Assigning a Bargaining Unit to an Appointment" (Priority 1)
BUA
· BUA-CD-01:Assign BU Conceptual Design
· Status: Accepted
· BUA-PF-01:Derive Bargaining Unit-Process Flow Diagram
· Status: Accepted
· BUA-PF-01:Derive Bargaining Unit-Process Flow Diagram

· Status: Accepted
BR_LR_09
The system should provide the capability for the Labor
Relations Office to maintain the job class/union relationship.---
Comments: Business Process = "Maintenance" (Priority 1)
BUA
· BUA-CD-01: Assign BU Conceptual Design
· Status: Accepted
· BUA-PF-02: BU Assignment Rules Maint Process Flow
Diagram
· Status: Ready for Review
Example 2:
BizReqID
CD01
CD02
CD03
CD04
UI01
UI02
UCT01
UCT02
UCT03
TC01
TC02
TC03
TC04
BR_LR_01
X
X
X

X
X
BR_LR_09
X
X
X
X
X
X
BR_LR_10
X
X
X
X
BR_LR_11
X

Appendix D: Organizing the Requirements
This section is for information only as an aid in preparing the
Requirements section of the document.
Detailed requirements tend to be extensive. Give careful
consideration to your organization scheme. Some examples of
organization schemes are described below:
By System Mode
Some systems behave quite differently depending on the mode
of operation. For example, a control system may have different
sets of functions depending on its mode: training, normal, or
emergency.
By User Class
Some systems provide different sets of functions to different
classes of users. For example, an elevator control system
presents different capabilities to passengers, maintenance
workers, and fire fighters.
By Objects
Objects are real-world entities that have a counterpart within
the system. For example, in a patient monitoring system, objects
include patients, sensors, nurses, rooms, physicians, medicines,
etc. Associated with each object is a set of attributes (of that
object) and functions (performed by that object). These
functions are also called services, methods, or processes. Note
that sets of objects may share attributes and services. These are
grouped together as classes.
By Feature

A feature is an externally desired service by the system that
may require a sequence of inputs to affect the desired result.
For example, in a telephone system, features include local call,
call forwarding, and conference call. Each feature is generally
described in a sequence of stimulus-response pairs, and may
include validity checks on inputs, exact sequencing of
operations, responses to abnormal situations, including error
handling and recovery, effects of parameters, and relationships
of inputs to outputs, including input/output sequences and
formulas for input to output.
By Stimulus
Some systems can be best organized by describing their
functions in terms of stimuli. For example, the functions of an
automatic aircraft landing system may be organized into
sections for loss of power, wind shear, sudden change in roll,
vertical velocity excessive, etc.
By Response
Some systems can be best organized by describing all the
functions in support of the generation of a response. For
example, the functions of a personnel system may be organized
into sections corresponding to all functions associated with
generating paychecks, all functions associated with generating a
current list of employees, etc.
By Functional Hierarchy
When none of the above organizational schemes prove helpful,
the overall functionality can be organized into a hierarchy of
functions organized by common inputs, common outputs, or
common internal data access. Data flow diagrams and data
dictionaries can be used to show the relationships between and
among the functions and data.
Additional Comments
Whenever a new Requirements Specification is contemplated,
more than one of the organizational techniques given above may
be appropriate. In such cases, organize the specific
requirements for multiple hierarchies tailored to the specific
needs of the system under specification.

There are many notations, methods, and automated support tools
available to aid in the documentation of requirements. For the
most part, their usefulness is a function of organization. For
example, when organizing by mode, finite state machines or
state charts may prove helpful; when organizing by object,
object-oriented analysis may prove helpful; when organizing by
feature, stimulus-response sequences may prove helpful; and
when organizing by functional hierarchy, data flow diagrams
and data dictionaries may prove helpful.
Copyright© 2018 by University of Phoenix. All rights reserved.
CMGT/410 v19
Title
ABC/123 vX
Page 2 of 2Work Breakdown Structure (WBS) Example
Project estimate: 124 hours: Small Business Website
Development 1. Research – 16 hours
1.1 Competitive analysis – 6 hours (approver)
1.2 Build requirements – 10 hours (technical writer)
2. Design – 24 hours
2.1 Prototype #1
2.1.1 Create first version of prototype – 8 hours (graphic
designer)
2.1.2 Gather feedback – 4 hours (approver)
2.2 Prototype #2
2.2.1 Create second version of prototype – 8 hours
(graphic designer)
2.2.2 Gather feedback – 3 hours (approver)
2.2.4 Get approval to move forward with prototype – 1 hour
(approver)
3. Program – 80 hours
3.1 Feature coding – 40 hours (programmer)
3.2 Integration coding – 20 hours (programmer)
3.3 Add content – 20 hours (content creator)

4. Test – 4 hours
4.1 Component testing – 2 hours (programmer)
4.2 Full site testing – 2 hours (approver)
Copyright© 20XX by University of Phoenix. All rights
reserved.
Sheet1NameDurationStartEndResoursesNotesProduct User Data
Tracking app90 days3/22/197/9/19Appication that obtrains user
data such aslosses and profits, good or bad trades inclusing
information gathered from trusted sites then processes the
information through a algorithm that will suggest better or safer
future trade options.Project Setting 6 days3/22/193/27/19Deside
resourses needed2 days3/22/193/24/19Product Owner, Project
managerDefine project goals1 day3/25/193/26/19Lead Research
Analystsetup work areas2 days3/27/199/29/19technical
AdminResearch reliable sources3 days3/29/194/1/19Scrum
MasterUser interface6 days4/1/194/7/19Design User Interface2
days4/7/194/9/19Lead ProgrammerBuild User Interface3
days4/9/194/12/19ProgrammerTest User Interface1
day4/12/194/13/19Test EngineerUAT for UI1
day4/13/194/14/19Test Engineer, Product OwnerFix Issues
From UAT Testing1 day4/14/194/15/19ProgrammerUser-Input
Integration15 days4/16/195/1/19Import Stock Info Into A
Database8 days5/2/195/10/19Lead Research Analyst,
ProgrammerEnable Database To allow User-Input4
days5/11/195/15/19ProgrammerTest UI For User-Input1
day5/16/195/17/19Test EngineerUAT for UI for User-Input1
day5/18/195/19/19Test EngineerFix Issues From UAT Testing1
day5/20/195/21/19ProgrammerAlgorith Implementation17
days5/22/196/8/19Algorithm Research5 days6/9/196/14/19Lead
Research AnalystCode Algorithm Into Database/User-Input10

days6/15/196/25/19Lead ProgrammerTest Algorithm1
day6/26/196/27/19Test EngineerFix Algorithm Issues1
day6/28/196/29/19ProgrammerClient Reports6
days6/29/197/4/19Design Reports1 day7/5/197/6/19Reporting
DeveloperBuild Reports2 days7/7/197/9/19Reporting
DeveloperTest Reports1 day7/10/197/11/19Test EngineerUAT
For Reports1 day7/12/197/13/19Test Engineer, Product
OwnerFix Issues for Reports1 day7/14/197/15/19Reporting
Developer, ProgrammerCross Platfrom Support6
days7/16/197/22/19Design Cross Platfrom Support2
days7/23/197/25/19Technical Admin, Lead ProgrammerBuild
Cross Platform Support2 days7/26/197/28/19Technical Admin,
Lead ProgrammerTest Cross Platform Support1
day7/29/197/30/19technical Admin, Test EngineerUAT for
Cross Platfrom Support1 day7/31/198/1/19technical Admin,
Test EngineerProject End2 days8/2/198/4/19Obtain Final Client
Signoff1 day8/5/198/6/19Project Manager, Project
OwnerProvide Project Report1 day8/6/198/7/19Project Manager,
Project OwnerProject End0 days8/9/198/9/19Project Manager,
Project Owner
Running head: PROJECT METHODOLOGY SELECTION AND
RATIONALE 1
PROJECT METHODOLOGY SELECTION AND RATIONAL 5
Project Methodology Selection and Rationale
James Moring

University of Phoenix
Mr. Robert Duffer
February 22, 2019
Project Methodology Selection and RationaleRationale to
Course Questions
1. The most appropriate project characterized by innovation,
loosely defined requirements, and high risk.
Typically, agile methodology is the most appropriate for
innovative-based projects since they deal with products already
established, thereby, making improvements (Lots, 2018). In this
case, if a new product needed to be designed from a scratch,
waterfall methodology would be most fitting. In addition, agile
methodology has been selected due to the fact that the current
project has high risk and thus, the methodology is more suitable
in meeting its fluctuating needs (Lots, 2018).
2. The most appropriate for a project characterized by
comprehensively defined requirements and low risk.
Waterfall is the most suitable methodology for a project
regarded to be of low risk and broadly defined requirements. In
this case, a straightforward plan is prepared needing minimum
requirements as they have already been spelled out before the
start of the project (Lots, 2018).
3. Describing Agile Methodology’s: project manager, project
sponsor, business analyst, and scrum master.
Generally, a project manager deals with everyday challenges of
project implementation such as planning for meetings, ensuring
that different individuals focus on their roles and
responsibilities as well as engage planning processes, develops
reports and project progress (Lucidchart Content Team, 2018).
Nevertheless, the processes of planning on track progress is
never considered to be a significant role within the waterfall
methodology (Lots, 2018).
The most significant role of a project sponsor is to offer
concerned teams with clearly defined project visions or goals
(Lucidchart Content Team, 2018). Additionally, project
sponsors ensure that resources needed for the completion of

projects are not only available but also accessible. Project teams
are also provided with sufficient political support for the
purposes of maintaining focus during project implementation
(Lots, 2018).
On the other hand, a business analyst develops and utilizes
technical solutions towards any identified business problems in
addition to advancing the sales efforts of the company.
Typically, such a role is considered important since different
project processes are investigated more closely (Lots, 2018). A
scrum master may be considered as a middleman between
individuals working under diverse tasks who ensured that agile
principles and values are absorbed throughout project
implementation.
As compared with agile methodology, a project manager is
required to allocate different roles and responsibilities
appropriately in the waterfall methodology. More importantly,
the manager overlooks the entire project to ensure that all
requirements are met (Lots, 2018). A project sponsor offers
vision and goals to the team members including access to
resources as well as sufficient political support required for the
completion of diverse roles within project implementation
process (Lucidchart Content Team, 2018).
A business analyst makes use of their technical skills in
offering solutions to all identifiable technical challenges
(Sacolick, 2018). By doing so, a business analyst ensures that
all processes are closely monitored and any problems
investigated to achieve best results. Finally, a program manager
is tasked with providing guidance and thus, oversees all
programming processes utilized during product progress in
order to prepare a comprehensive report to the project manager
(Lucidchart Content Team, 2018).
4. Project, project life cycle, and software development life
cycle and how the project’s software development life cycle
differ from the project life cycle?
A project is a collaborative or individual enterprise carefully
designed and planned for purposes of achieving established

goals or visions. On the other hand, a project life cycle (PLC) is
characterized by four main phases such as in instigation,
planning, execution and finally closure and may repeat itself or
considered complete based on project goals (Lucidchart Content
Team, 2018). A software development life cycle (SDLC) is
considered to be the process widely utilized within the software
industry for the aims of developing, designing and testing
software. Also, the cycle contains seven main steps that include;
defining, planning, designing, development, testing, deployment
as well as maintenance (Sacolick, 2018).
References
Lots, Mary. (2018). Waterfall vs. Agile: Which is the Right
Development Methodology for your Project? Retrieved from >
https://www.seguetech.com/waterfall-vs-agile-methodology.
Date Accessed. February 23, 2019.
Lucidchart Content Team. (2018). What the Waterfall Project
Management Methodology Can (and can’t) Do for You.
Retrieved from > https://www.lucidchart.com/blog/waterfall-
project-management-methodology. Access Date. February 23,
2019.
Sacolick, Isaac. (2018). What is Agile Methodology? Modern
Software Development Explained. Retrieved from>
https://www.infoworld.com/article/3237508/agile-
development/what-is-agile-methodology-modern-software-
development-explained.html. Date Accessed. February 23, 2019.

Product Requirements DOcumentStock user data tracking app
What is It?
The apps goal is to create a environment for users that can help
them make better trade decisions based on past trades and
trends to give the user a better understanding on why they took
a loss or a gain in short the app will cater more to the immature
trader but is not limited and even the best traders in the world
would benefit from using the app.
Who is it for?
· Our main target audience would be newer traders who trade
mainly on their phones using apps such as Robinhood and
Webull.
· Veteran traders who don’t have time to track all trading data.
· Overall, we would want anyone who trades and wants to learn
from successes and failures.
Why build it?
Currently there are no algorithm-based learning systems to help
traders learn why the choses they are making might be good or
bad and a lot of hardworking people lose a lot of their money on
the stock market everyday our app would time teach the user to
minimize losses and maximize gains.
Sales Model.
· Subscription based
· $5.99/month for detailed reports of each trade, news, and
suggestions on when the optimal times they should have bought
and sold their position.

· $9.99 a month (All 5.99 features) with added trade suggestions
based on the types of trade the algorithm shows the user is most
likely to make a profit on. For example if the user is a day
trader and a random pharmaceutical is being extremely volatile
and has risen 250% in the past 3 days it would suggest to the
user to short and when to close the position.
User Story’s/Scenarios.
User Story/Scenario
Given (precondition)
When (trigger)
Then (result)
User Starts a trade.
User has linked trading account to our app
When user makes a trade
Algorithm tracks user data
User makes a suggested trade
User makes a trade based on algorithms suggestions
When algorithm sell requirement is met
Notification gets sent to user’s phone suggesting to make a
trade
User gets suggested a trade if user has unused balance
User has a certain amount of money not invested
When Algorithm has found a good trade suggestion based on
news, stock trends, or sudden volatility.
Notification gets sent to user’s phone suggesting the following
trade suggestion

75645 Topic documenting the project life cycleNumber of Pages.docx

75645 Topic documenting the project life cycleNumber of Pages.docx

Recommended

Recommended

More Related Content

Similar to 75645 Topic documenting the project life cycleNumber of Pages.docx

Similar to 75645 Topic documenting the project life cycleNumber of Pages.docx (15)

More from sleeperharwell

More from sleeperharwell (20)

Recently uploaded

Recently uploaded (20)

75645 Topic documenting the project life cycleNumber of Pages.docx