Business Analysis Project 2015

UWECZACH SMITHALEX HART

MICHAEL MACALALADSAMUEL GRITZMACHER

May 12, 2015IS 310.001

Lost and Found

Automated Improvements to the ECCHA Lost and Found System

1

Contents

1. Introduction.................................................................................................................................5

2. Positioning...................................................................................................................................5

2.1 Problem Statement........................................................................................................................5

2.2 Product Position Statement...........................................................................................................6

3. Stakeholder and User Descriptions.............................................................................................6

3.1 Stakeholder Summary....................................................................................................................6

3.2 User Summary...............................................................................................................................7

3.3 User Environment..........................................................................................................................7

3.4 Key Stakeholder or User Needs.....................................................................................................7

3.5 Alternatives and Competition........................................................................................................8

4. System Overview.........................................................................................................................9

4.1 System Perspective........................................................................................................................9

4.2 Assumptions, Constraints, and Dependencies.............................................................................10

4.3 System Features..........................................................................................................................10

4.4 High-level System Requirements.................................................................................................10

5. Project Risk List........................................................................................................................11

6. Requirements Analysis..............................................................................................................11

6.1 Requirements Elicitation Plan......................................................................................................11

6.2 Business Requirements................................................................................................................12

6.3 User and Functional Requirements..............................................................................................12

6.4 Nonfunctional Requirements.......................................................................................................13

6.5 Common Information..................................................................................................................18

7. Use-Case Diagram and Specifications.......................................................................................19

7.1 Use Case Diagram........................................................................................................................19

7.2.1 Generate Reports.....................................................................................................................19

7.2.1.1 Brief Description....................................................................................................................19

7.2.2 Flow of Events...........................................................................................................................19

2

7.2.2.1 Basic Flow..............................................................................................................................19

7.2.2.2 Alternative Flows...................................................................................................................20

7.2.2.2.1 System Can Not Generate Report.......................................................................................20

7.2.2.2.2 System Can Not Access Excel..............................................................................................20

7.2.3 Special Requirements...............................................................................................................20

7.2.3.1 Timely completion.............................................................................................................20

7.2.4 Preconditions............................................................................................................................20

7.2.4.1 The System is functioning and ready to use...........................................................................20

7.2.4.2 The computer is powered on, user accesses Lost and Found page....................................20

7.2.4.3 The computer is powered on, user accesses Excel.............................................................20

7.2.5 Post conditions.........................................................................................................................20

7.2.5.1 All necessary data fields have been filled, and the user submits the information.............20

7.2.5.2 Notification window displayed upon completion..............................................................21

7.2.6 Extension Points.......................................................................................................................21

7.3.1 Enter Animal Information.........................................................................................................21


7.3.2 Flow of Events...........................................................................................................................21

7.3.2.1 Basic Flow..............................................................................................................................21


7.3.2.2.1 System Can Not Access Website.........................................................................................21

7.3.2.2.2 System Cannot Submit Form..............................................................................................21



7.3.4 Preconditions............................................................................................................................22

7.3.4.1 The System is functioning and ready to use.......................................................................22


7.3.5 Post conditions.........................................................................................................................22




7.4.1 Enter Owner Information..........................................................................................................22


7.4.2 Flow of Events...........................................................................................................................23

7.4.2.1 Basic Flow..............................................................................................................................23

3


7.4.2.2.1 System Can Not Access Website.........................................................................................23

7.4.2.2.2 System Cannot Submit Form..............................................................................................23



7.4.4 Preconditions............................................................................................................................23

7.4.4.1 The System is functioning and ready to use.......................................................................23


7.4.5 Post conditions.........................................................................................................................24




8. Business Rules and Entity Relationship Diagram.....................................................................24

8.1 Entity Relationship Diagram.........................................................................................................25

8.2 Business Rules..............................................................................................................................26

8.3 Sample Data Tables......................................................................................................................26

9. Data Flow Diagrams..................................................................................................................27

9.1 Context Level Diagram.................................................................................................................28

9.2 Level 0 Diagram...........................................................................................................................29

9.3 Level 1 of Process 1......................................................................................................................30

9.4 Level 1 of Process 3......................................................................................................................31

10. Prototype Mock-ups.................................................................................................................32

10.1. Lost and Found Menu...............................................................................................................32

10.2 User Sign-in Screen....................................................................................................................33

10.2 Generate Reports Form.............................................................................................................33

11. Transition Plans.......................................................................................................................34

11.1. Test Plan...................................................................................................................................34

11.1.1 Component Testing.................................................................................................................34

11.1.2 Integration Testing..................................................................................................................34

11.1.3 System Testing........................................................................................................................34

4

11.1.4 Acceptance Testing.................................................................................................................35

11.2 Implementation Plan.................................................................................................................35

11.3 Training Plan..............................................................................................................................36

11.3.1 Eau Claire Humane Society Staff.............................................................................................36

12. Appendices..............................................................................................................................37

12.1 Revision History.........................................................................................................................37

12.2 Reference Materials...................................................................................................................38

12.3 Glossary.....................................................................................................................................38

5

1. IntroductionThe purpose of this document is to examine and describe the needs, risks, and key attributes of the Lost and Found system for the ECCHA. The objective of this project is to create an efficient Lost and Found system for the ECCHA that allows users to quickly and effectively locate a lost animal. The system will cut down time for users, improve detailed information within the online database, reduce human error in documentation, and reduce retention rates of lost animals which in turn will reduce costs at the ECCHA. Upon implementation, users will be provided with an easy to use, efficient online database that allows them to quickly search and detect an animal with no confusion. The details regarding how this Lost and Found system will justify these needs are presented in the document below. It describes stakeholder roles, contributions, responsibilities, system requirements, associated risks, use-case diagram and specifications, data flow diagram, entity relationship diagram, prototype mockups, our transition plans, and an appendix.

2. PositioningThe current problems and solutions will be discussed further in this section. An improvement in the lost and found system would increase the efficiency of the ECCHA in helping owners find their animals.

2.1 Problem StatementThis project has been started in order to increase efficiency and limit the time animals spend on the Lost and Found page. This project will determine how to communicate effectively and in a timely manner with those searching for an animal, by further developing online notifications and detecting potential matches.

The problem of Animal retention rate for lost and found is too high which

affects Owners who are without their animals, which in turn raises costs for ECCHA.

the impact of which is Shelter space and resources at ECCHA become limited and owners remain unhappy.

A successful solution would be

Improve Lost and Found webpage, request detailed pictures of members’ animals, and maintain records of previous Lost and Found animals.

6

2.2 Product Position StatementThis project will improve the lost and found system in the organization. The intent of this project is to decrease the time animals spend in the Lost and Found system, reduce costs, and increase efficiency of resources.

For The Eau Claire County Humane Association,who Need to increase the effectiveness of the Lost and

Found System.the Lost and Found system

Is a system to manage Lost and Found animals,

that Will increase animals being reunited with owners by 20% (guidestar.com)

Unlike The current paper system,our product Will make the system more effective, while also

increasing user friendliness.

3. Stakeholder and User DescriptionsThe section below identifies the stakeholders that will be effected by the changes suggested. The roles of each stakeholder and users, system requirements, and the system needs are described below.

3.1 Stakeholder SummaryThe following table represents the indirect users of the Lost and Found system and their responsibilities.

Role: Description: Responsibilities for the project or system

Donors Donors will provide the funding for the ECCHA.

Provide funds for the ECCHA

Board of Directors Board of directors make budget and project decision.

Decide if the system is funded

7

3.2 User SummaryThis table describes the users who are directly impacted by our system. Each user role, description of the role, and how they will directly use the system is presented below.

Role Description How this role will use the system

Employee Impute and manage animal data -Enter customer/ animal information onto online data base-Produce reports

Manager Oversee the use of the system and review its overall effectiveness

-View turnover data -Maintain accurate records

Animal owner Gives the system the description of their animal

-Enter animal information

3.3 User EnvironmentThe following list contains environmental characteristics relevant to the improvement of the Lost and Found system:- Three to five people would be expected to access the system simultaneously- Each task should take no more than five minutes- Window 7 and office 2010 are the current systems- Each employee will have access to the system with a username and password- Our system would need to get integrated with Pet Point- Potentially incorrect animal description based on understanding of animals- Requires manual entry of information- Animal fur present

3.4 Key Stakeholder or User NeedsDiagramed in the table below are the stakeholder/user needs, priority of concern, and the solutions. The needs are prioritized on a scale from 1-10, with 10 being the most important.

Need Priority Concerns Current Solution Proposed SolutionsCompile and enter animal information

9 Human error in data entry could cause animal owners difficulty in recognition of their animal

Manual with pencil and paper

Expand database of animal pictures, request member’s animal pictures, and maintain files of previously lost animals.

Update records 8 Human error in data entry could cause animals to remain at the ECCHA

Manual with pencil and paper

Digital records repository with ability to update along with paper and pencil.

Generate reports 8 Inadequacy data will lead to incorrect reports

Obtain information from binder

A searchable system with ability to filter

8

3.5 Alternatives and CompetitionThe following is an analysis and comparison of what the ECCHA currently uses to keep track of their animals, switching to another online database (iShelters), or our lost and found system. Each system will be compared and evaluated using a weighted decision table.

Currently, the ECCHA uses a mix of paper documentation, and a computer database called “PetPoint.” When an animal comes in, it is first examined by an employee. Next, they hand document all the necessary attributes of the animal on a lost and found report. Then, the employee or volunteer manually enters in this information into their computer database, and if possible, includes a picture of the animal. From there, the animal’s information is retrievable from either the paper documents, or the PetPoint database. One of the main issues of the current system is its accuracy. The key problem the ECCHA faces is correctly identifying the breed of the animal. Also, the system results in an inefficient use of time. The time spent handwriting the animal’s information, and then manually entering this information, is redundant and can be improved.

One alternative the ECCHA has to this system, is to completely transition to a different online database. Although definitely an option, this alternative isn’t necessarily cost or time effective. These systems can range anywhere from $200 to $2500 a month. Also, the capabilities and attributes of these systems vary greatly. These systems will either offer not enough to the ECCHA, or more than they could ever use. Although this would possibly save the ECCHA money in the long run by completely eliminating the use of Lost and Found documents, the implementation costs and time needed to train employees, just doesn’t compare to our proposed system.

Given these options, our Lost and Found system is the optimal alternative. The improved Lost and Found system streamlines efficiency, and drastically reduces user error. Our system tailors to what the ECCHA currently uses, so it will take little time to implement, and present an easy learning curve. By using an easy to find breed selector, and reducing the amount of time needed to input the animal’s information, the Lost and Found system is the best alternative available to the ECCHA.

The following table weighs the needs of the organization and ranks each task 0-5 depending on the ability of the system to meet or handle that requirement or constraint. (See Next Page)

Criteria No Action Online Proposed System

9

AlternativeRequirements Weight Rank Score Rank Score Rank ScoreInterface with PetPoint

15 4 60 0 0 5 75

Drop-down menus

10 0 0 1 10 5 50

Provide detailed animal information

15 2 30 2 30 4 60

Reduce user error 7 3 21 1 7 4 28Inform users of matches

10 1 10 3 30 5 50

Track animal numbers

3 1 3 3 9 3 9

ConstraintsTechnology limitations

5 5 25 3 15 4 20

Scarcity of donations

5 4 20 2 10 2 10

Cost of implementation

20 5 100 1 20 3 60

System learning curve

10 5 50 2 20 3 30

Total 100 319 151 392

4. System OverviewThis section contains the assumption perspectives dependencies, features, constraints, and high level requirements for the system.

4.1 System Perspective

The system proposed will be an addition on to the current system of PetPoint. The system will bridge an information gap between the users and PetPoint. This will be a public system for use by the employees of the ECCHA to post found animals and also by the public to post a lost animal.

4.2 Assumptions, Constraints, and DependenciesThe following are a list of assumptions, constraints, and dependencies important for implementing the Lost and Found system.

10

AssumptionsThe following list of assumptions are vital to properly implement the system:- The system will be maintained and updated - Staff will adapt and learn new system components- The system will be developed by students- There are sufficient resources and timeframes needed to complete the project- Staff hours and roles will remain the sameConstraints Below are a list of constraints that our system must comply with:- Technology availability can be limited at times- Only three to five users can access the system simultaneously Dependencies Below is a list of dependencies the Lost and Found system is reliant upon:- ECCHA must provide time to train staff- The Lost and Found system will continue to integrate with PetPoint- Microsoft Office 2010 or higher is required- The system will be secure so that only ECCHA staff can make changes

4.3 System FeaturesThe following shows features of the LFS and the priority associated with each. The scale ranges from 1-10 with 10 being the most important.

System Features PriorityInform users of possible matches 10Connect to PetPoint 10Assisting users with accurate data input via dropdown menus. 9Retain information after match has been made 7Track annual and season animal numbers 4

4.4 High-level System Requirements The table below is a table of the specific high level requirements that the system requires to function. The requirements are ranked in priority with 1 being the lowest and 10 being the highest.

System Requirements PriorityHard Drive Containing 250GB 10Internet access 10Compatibility with PetPoint 10Computer system cannot come in direct contact with animals

10

Windows 7 Compatibility 92 GB of RAM Memory 8Core i3 2.0 Ghz Processor 6

5. Project Risk List

11

The following table contains a list of possible risks as well as mitigation strategies. The ranking from 10 (largest project impact) to 1 (least project impact) shows the importance of each risk.

Priority

Risk Description and Impact Mitigation Strategy and/or Contingency Plan

10 Does not find the LFS to be necessary or beneficial, the Board of Directors may not approve funding.

Provide more facts and estimates to the Board to show the importance of the LFS

10 There is insufficient funding. Reorganize funding and donations as well as restructure components of system to be cheaper

8 Donors may not provide enough funding. Continue to raise awareness and request donations through events, emails, and other donation techniques

7 Users don’t like change. Describe how the system will benefit compared to other systems. Show how will reduce work load and paper work.

7 Cannot find an efficient way to track lost and found data.

Propose solutions that draw from systems with similar data and product flows from other companies.

6 Time needed to maintain the system makes users reluctant to use.

Show users how the time taken to maintain the system can positively impact the community. Weighted decision table.

6 Developer unclear of scope and needs of the LFS. Clarify or get new developer.

6. Requirements AnalysisThe following section illustrates the necessary requirements needed to successfully implement the Lost and Found system. It contains the elicitation plan, business requirements, user and functional requirements, and non-functional requirements.

6.1 Requirements Elicitation PlanIn order to elicit requirements for the Lost and Found System, our group aims to develop a survey that will be provided to the members and customers of the ECCHA. We will send an email to our customers and members with the survey attached, as well as ask those who come into the Humane Association to take a minute to fill out the survey. The purpose of the surveys, which will be written and conducted by ‘Mike and Alex, will be to identify the aspects of the current Lost and Found system that are working, and which aspects of the system they would like improved or changed. There will be 25 surveys filled out by customers, members, and employees which will consist of 15 questions each. Resources needed include the questionnaire template and an appropriate timeframe of 10 minutes to survey. Along with the surveys, our group will conduct a few brief interviews. Zach and Sam will be conducting the interviews on two current ECCHA employees and Karen herself. We will be selecting the employees based on their involvement in the Lost and Found process. Due to the employees’ tight schedules, Sam

12

will be emailing Karen at ECCHA in order to set up a time that is convenient for her employees. Zach and Sam will be preparing several questions ahead of time and will bring a journal to take detailed notes. Resources needed for this technique include copies of the interview questions template and email access to Karen.

6.2 Business RequirementsThe following statement explains our requirements and how the system will impact the Humane Association.Business Requirement StatementThe purpose of The Lost and Found System is to create a unified system that automatically interfaces with PetPoint so that animal reports are more easily generated, files and lost animal history are more easily accessed, and less paper is used on animal files.

6.3 User and Functional RequirementsThe following table shows the user and functional requirements for the Lost and Found System. It describes the different steps users will need to take, and what the Lost and Found System needs to do to support those steps. We used Relationship to Other Requirements method because our system needs to be able to interface and meet requirements of PetPoint. Examples of this include being able to match the data entry fields with correct information even though we would like to incorporate a dropdown menu for breeds. If our system cannot accurately enter data into PetPoint it becomes useless. As well, we used MoSCoW analysis to document the rankings.

M = Must be included in the systemS = Should be included in the systemC = Could be included in the systemW = Won’t be included in the systemColumn Header Key: CI = Common Information Identifier, ST = Status Status Column Key: A = Accepted C = Changed since last review, N (or Blank) = New since last review.

ID User and System Functional Requirement Statements CI [Ranking] STUser Role

Owner/ Employee

Goal U2 Enter Animal Information CI2 M NU2.1 User selects Lost and Found U2.1F1 System displays home page with option barsU2.2 User selects animal breed U2.2F1 System displays pictures of breed optionsU2.3 User enters animal information CI2 U2.3F1 System displays online “Lost” form which displays

information regarding the lost animalU2.4 User attaches detailed photos of lost animal U2.4F1 System provides upload linkU2.5 User submits form U2.5F1 System displays submit button

13

User Role

Owner/ Employee

Goal U3 Enter Owner Information M NU3.1 User selects Lost and Found U3.1F1 System displays home page with option barsU3.2 User selects Owner Information U3.2F1 System displays pictures of breed optionsU3.3 User enters Owner information U3.3F1 System displays online “Lost” form which displays

information regarding the lost animalU3.5 User submits form U3.5F1 System displays submit buttonUser Role

Manager

Goal U4 Generate Reports M AU4.1 Select Manager Tasks A U4.1F1

System displays home page with option bars A

U4.2 Validate User A U4.2F1

System displays “Username and password” A

U4.2F2

User is an authorized user CI1 N

U4.3 User selects generate reports A U4.3F1

System displays managers reports in excel A

6.4 Nonfunctional RequirementsThe following are the nonfunctional requirements necessary for the Lost and Found system to function upon implementation.

ID Nonfunctional Requirement Statements CI STOPERATION Requirements: How well does the system perform for daily use?Access Security How well is the system guarded against unauthorized access?The extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.

N-ACS1 Employees will be provided with authorized user names as well as passwords.

CI1 C

N-ACS2 An email address will be connected with employees’ accounts. CN-ACS3 Each password is to be changed every six months by each

authorized user. If user names or passwords are forgotten, the information will be sent to the email address of the user.

CI1C

N-ACS4 Passwords will not be shown at any point in time during the login process.

A

14

ID Nonfunctional Requirement Statements CI STN-ACS5 Non-authorized users will not be required to enter a user name or

password to make entries. However, non-authorized users will not be able to change any data currently in the system.

CI1A

N-ACS6 Each unsuccessful attempt by an employee to log in shall be recorded on an audit trail.

A

N-ACS7 If an authorized user is logged in but idle for longer than 20 minutes, they will be automatically logged out.

CI1 A

Availability How dependable is the system during normal operating times?The degree to which users can depend on the system to be up (able to function) during “normal operating times.”

N-AVL1 The Lost and Found System will be available to users 24 hours per day, 7 days per week.

A

N-AVL2 In the case of maintenance or system outages, users will be notified via email prior to the outage.

A

N-AVL3 The Lost and Found system shall maintain 99% up time AN-AVL4 If necessary, maintenance will always be conducted during low

peak hour times of after 1am and before 5am. A

Efficiency How fast can it process? How many can be processed? How well does the system respond?The extent to which the software system handles capacity, throughput, and response time.

N-EFC1 The initial system shall be able to handle each data entry in less than one second, and the full data form in less than five seconds.

C

N-EFC2 Any interface between the user and the system shall take no more than five seconds.

A

N-EFC3 Once an entry has been in the system two weeks, it will be removed from the Lost and Found section, and moved to the Adoption section of the system.

A

N-EFC4 The initial system shall have an available storage space of 2TB. AN-EFC5 The system shall produce a storage capacity warning notification

when the 70% capacity threshold is crossed. A

N-EFC6 The system will be able to accommodate 10 users simultaneously at any given time.

A

Integrity How accurate and authentic are the data?The degree to which the data maintained by the software system are accurate, authentic, and without corruption.

N-INT1 Any entry made by an authorized user to the system will be reviewed by another authorized user or manager before the entry is submitted.

CI1 A

N-INT2 To avoid total loss due to an unexpected system failure, each entry will be saved to a word document prior to being submitted.

A

N-INT3 Data shall be added, updated, or removed on a daily basis as to avoid inaccurate or irrelevant data.

A

N-INT4 Any corrupt data submitted by a non-authorized user, such as data that is obviously inaccurate, shall be removed by an employee or manager immediately upon finding.

CI1 A

N-INT5 The system will be screened weekly to ensure Lost and Found submissions by owners are legitimate.

C

Reliability How immune is the system to failure?The extent to which the software system consistently performs the specified functions without failure.

N-REL1 Managers or directors will be notified as to any system outages. A

15

ID Nonfunctional Requirement Statements CI STN-REL2 The rate of entry failure shall be 1/1000 (1 occurrence in 1000

days). Failure means the system fails to save an entry of a lost animal.

A

N-REL3 The mean time to failure of the system timing out shall be 1/1000 (1 occurrence in 1000 entries). Failure means the system must cancel the current process and allow the user to re start.

A

N-REL4 After five unsuccessful login attempts, the system will recognize an unauthorized user and freeze the system until a manager logs in and unfreezes the system.

CI1 A

N-REL5 If the system fails to accept a Lost and Found submission, an error box will appear to notify the user.

A

N-REL6 A basic system functions test will be performed every week to ensure all aspects are working as intended.

C

Survivability How resilient is the system from failure?The extent to which the software system continues to function and recovers in the presence of a system failure.

N-SRV1 If information submitted by a user fails to update, the user will immediately receive an email with a notification.

A

N-SRV2 In the case of a system failure, users that have submitted information will be informed that their entries will be recovered and posted again.

A

N-SRV3 The system will be inspected once every 12 months in order to ensure efficiency and resistance to failure.

A

N-SRV4 Employees and managers are authorized to perform system recovery procedures.

A

N-SRV5 The system is able to function on minimal hardware requirements. Thus increasing its longevity.

A

Usability How easy is it to learn and operate the system?The ease with which the user is able to learn, operate, prepare inputs, and interpret outputs through interaction with a system.

N-USE1 The system will take no more than 15 minutes to learn and operate.

A

N-USE2 Non-authorized users will be able to recognize and figure out how to use the system within five minutes.

CI1 A

N-USE3 Authorized users will be required to arrive to the ECCHA early on the first day of the system implementation for a 15 minute training session.

CI1 A

N-USE4 Users shall be able to fill out a form in the system within five minutes.

A

REVISION Requirements: How easy is it to correct errors and add functions?Flexibility How easy is it to modify to work in different environments?The ease with which the software can be modified to adapt to different environments, configurations, and user expectations.

N-FLX1 No piece of text that might be displayed to a user shall reside in program source code. Every piece of text that a user might see must be modifiable without changing source code.

A

N-FLX2 The system will be able to function with updated versions of Microsoft products.

A

16

ID Nonfunctional Requirement Statements CI STN-FLX3 The system will be updated whenever PetPoint is updated to stay

updated.A

N-FLX4 The system will have the ability to be able to have language changed at the request of the user.

A

N-FLX5 The ability to add a mobile version can be made available at the users request

A

N-FLX6 The report customization options must be flexible to respond to the user’s needs.

A

Maintainability How easy is it to upkeep and repair the system?The ease with which faults in a software system can be found and fixed.

N-MNT1 The maintenance log shall be stored within the system to record updates made to the system.

A

N-MNT2 A system development team member who has at least one year of experience supporting software applications shall be able to add a new product feature with no more than one week of labor

A

N-MNT3 The system shall not be shut down for maintenance more than once in a 24-hour period.

A

N-MNT4 The system will run a self-check every three months to determine any problems that could arise

A

N-MNT5 The system shall not be shut down for maintenance more than once in a 24-hour period.

A

N-MNT6 The system source code is properly documented so changes can be easily made.

A

Scalability How easy is it to expand or upgrade the system’s capabilities?The degree in which the system is able to expand its processing capabilities upward and outward to support business growth.

N-SCL1 The effort needed to administer the system shall not have a significant increase due to an increase in the number of animals.

C

N-SCL2 The system will be usable on computer as well as all mobile applications.

C

N-SCL3 Adding extra functionalities will not make the system itself less functional.

A

N-SCL4 The elapsed duration of time required to produce any statement or report showing information about transactions shall be based upon how much data is presented rather than the total quantity of stored data

A

N-SCL5 When a new version of the system is released, it shall be available to be upgraded from any previous version

A

N-SCL6 The system does have the ability to increase the possible amount of users.

A

Verifiability How easy is it to show the system performs its functions?The extent to which tests, analysis, and demonstrations are needed to prove that the system will function as intended.

N-VER1 Users of the system should participate in system reviews that will occur on a monthly basis

C

17

ID Nonfunctional Requirement Statements CI STN-VER2 Software alpha testing will require the use of a test database with

data extracted from the production database. This test database will be deleted after successful implementation of the software system.

A

N-VER3 The system will be pre-tested by users after the alpha testing phase to validate system requirements are being satisfied.

A

N-VER4 User manuals will be available to users. Definitions and step-by step instructions of the system’s main functions will be highlighted.

A

N-VER5 If the system fails before the authorized user saves all new animal and owner inputs, the system shall be able to recover all changes updated up to one minute prior to the failure

CI1 A

TRANSITION Requirements: How easy is it to adapt to changes in the technical environment?Interoperability How easy is it to interface with another system?The extent to which the software system is able to couple or facilitate the interface with other systems.

N-IOP1 The system must be able to interface with PetPoint’s data entry fields.

A

N-IOP2 The system must not display images offensive to possible users. AN-IOP3 The system must use English as its common display language to

increase effectiveness and reduce errors in processing.A

N-IOP4 Non-authorized users will not be able to generate reports from the data.

CI1 A

N-IOP5 Reports generated can be exported to applicable Microsoft Applications.

A

N-IOP6 Upgrades to the system will not interfere with ability to interface with PetPoint.

A

N-IOP7 System will be able to convert paper records to digital via scanning them into the system.

A

Portability How easy is it to transport?The ease with which a software system can be transferred from its current hardware or software environment to another.

N-POR1 Time Zone will need to be set each time the system is implemented or updated.

A

N-POR2 Product will be customizable upon implementation to meet user’s needs.

A

N-POR3 Product will have both computer and mobile/tablet capabilities. AN-POR4 System must be able to function on windows 7 and up operating

systems as well as Android and iOS mobile operating systems. A

N-POR5 Software should also save to a “Cloud” server for offsite backup. AN-POR6 All time references will be based off of the time zone which the

system was implemented in.A

N-POR7 The system will be able to have limited function when not connected to the internet.

A

Reusability How easy is it to convert for use in another system?The extent to which a portion of the software system can be converted for use in another.

N-REU1 Product can be implemented as a subsystem if an overarching management system is implemented.

A

18

ID Nonfunctional Requirement Statements CI STN-REU2 Will be designed to adhere to HyperText Markup Language(HTML)

guidelines and standardsA

N-REU3 Current hard copies from ECCHA will be scanned into the system. AN-REU4 Database will be easily moved to other storage forms in future

hardware updatesA

N-REU5 System will be coded to work with the most common operating systems

A

6.5 Common Information

ID Named Information Definition or Businesses Usage / Business elements

CI1 Authorized User The Lost and Found System displays two text fields with labels “Username” and “Password.” A user becomes authorized upon successful completion of the login.

CI2 Animal Information Animal information includes sex, species, breed, age, color, weight, and name

7. Use-Case Diagram and Specifications

19

The below sections illustrate the relationships between the users and the systems of the use case. The use case diagram and the use case specifications describe how the system and the users interact.

7.1 Use Case DiagramThe following section illustrates the use case diagram, (Figure 1) and the specifications of the major use case within the Lost and Found System. The major use cases are Fill out lost form, enter animal information, enter owner information, and generate reports

7.2.1 Generate ReportsBelow is documentation describing the generate reports use case

7.2.1.1 Brief DescriptionGenerating reports is a necessary function for keeping track of lost and found animals. The manager is able to generate reports to keep track of animal information so that they can present the information to stock holders, and keep statistics accurate.

7.2.2 Flow of EventsThe following are the basic and alternative flows for navigating the generate reports use case

7.2.2.1 Basic Flow Below is the basic flow of events, or the most common path, through the generate reports use case

1. Use Case begins when the user attempts to log into the Manager section.2. Use Case: Validate User is performed.3. User Selects generate reports.4. User selects information to be included in report using filters.5. The system generates report from selected data.6. The system displays the reports in Excel.7. The use case ends successfully

20

7.2.2.2 Alternative FlowsBelow are some examples of alternative flows from the basic flow described above for the use case Generate Reports.

7.2.2.2.1 System Can Not Generate Report1. User Selects generate reports.2. The system shows an error message that says “System Can Not Generate Report”.3. System returns to step 3.

7.2.2.2.2 System Can Not Access Excel1. The system generates reports for the lost and found animals.2. The system shows an error message that says “Can Not Access Excel”.3. The system returns back to step 4.

7.2.3 Special RequirementsThere is one special requirement that needs to be fulfilled for our system to operate successfully

7.2.3.1 Timely completionThe system will need to be able to generate report information and be able to open excel with Information present within 30 seconds of activating the system.

7.2.4 PreconditionsThe following are preconditions necessary prior to generating reports in the system.

7.2.4.1 The System is functioning and ready to useThe system has a secure connection to the internet, system is up to date and ready for user input.

7.2.4.2 The computer is powered on, user accesses Lost and Found page.The user must enter the correct URL to navigate to the webpage and access Lost and Found tab.

7.2.4.3 The computer is powered on, user accesses Excel.The user must open Excel to view the generated reports.

7.2.5 Post conditionsThe following list of post conditions are possible states the system can be in following the completion of the use case.

7.2.5.1 All necessary data fields have been filled, and the user submits the information.Files have been updated.

21

7.2.5.2 Notification window displayed upon completion. The user is notified that their submission was successful and is given the option to continue or exit.

7.2.6 Extension PointsNo extension points can be identified, as the Generates Report use-case does not include extends relationships.

7.3.1 Enter Animal InformationBelow is documentation describing the Enter Animal Information use case.

7.3.1.1 Brief DescriptionEntering Animal Information is a necessary function for the lost and found process. By entering and maintaining thorough and complete animal information the better the matches the system can return.

7.3.2 Flow of EventsThe following are the basic and alternative flows for navigating the enter animal information use case.

7.3.2.1 Basic Flow Below is the basic flow of events, or the most common path, through the enter animal information use case.

1. The use Case begins when the user opens the website.2. User enters the animal information into the appropriate fields.3. Use Case: Enter Owner Information.4. User submits form.5. The use case ends successfully.

7.3.2.2 Alternative Flows

Below are some examples of alternative flows from the basic flow described above for the use case Enter Animal Information.

7.3.2.2.1 System Can Not Access Website1. User attempts to access website.2. The system shows an error message that says “System Can Not Access Page”.3. System returns to step 3.

7.3.2.2.2 System Cannot Submit Form1. Starts at step 4.2. System fails to upload file.3. System prompts user to try again.

22

7.3.3 Special RequirementsThere is one special requirement that needs to be fulfilled for our system to operate successfully.

7.3.3.1 Timely completionThe system will need to be able to process submitted information in less than 15 seconds due to the simple format of the entered data as text.

7.3.4 PreconditionsThe following are preconditions necessary prior to entering animal information in the system.




7.3.5.1 All necessary data fields have been filled, and the user submits the information.Animal information files have been updated.

7.3.5.2 Notification window displayed upon completion. The user is notified that their submission was successful and is given the option to continue to the home page or exit.

7.3.6 Extension PointsNo extension points can be identified, as the Enter Animal Information use-case does not include extends relationships.

7.4.1 Enter Owner InformationBelow is documentation describing the enter owner information use case.

7.4.1.1 Brief DescriptionEntering Owner Information is a necessary function for reconnecting lost and found animals. By providing accurate contact information the owners of the animal can be notified when an animal matching their lost animal’s description is found.

23

7.4.2 Flow of EventsThe following are the basic and alternative flows for navigating the Enter Owner Information.

7.4.2.1 Basic Flow Below is the basic flow of events, or the most common path, through the enter owner information use case.

1. The use Case begins when the user opens the website.2. Use Case: Enter Animal Information.3. User enters owner information into the appropriate fields.4. User submits form.5. The use case ends successfully.

7.4.2.2 Alternative FlowsBelow are some examples of alternative flows from the basic flow described above for the use case Enter Owner Information.

7.4.2.2.1 System Can Not Access Website1. User attempts to access website.2. The system shows an error message that says “System Can Not Access Page”.3. System returns to step 3.

7.4.2.2.2 System Cannot Submit Form1. Starts at step 4.2. System fails to upload file.3. System prompts user to try again.

7.4.3 Special RequirementsThere is one special requirement that needs to be fulfilled for our system to operate successfully.

7.4.3.1 Timely completionThe system will need to be able to process submitted information in less than 15 seconds due to the simple format of the entered data as text.

7.4.4 PreconditionsThe following are preconditions necessary prior to entering owner information in the system.



24


7.4.5.1 All necessary data fields have been filled, and the user submits the information.Owner information files have been updated.

7.4.5.2 Notification window displayed upon completion. The user is notified that their submission was successful and is given the option to continue to the home page or exit.

7.4.6 Extension PointsNo extension points can be identified, as the Enter Owner Information use-case does not include extends relationships.

8. Business Rules and Entity Relationship DiagramThe Following diagram shows each entity from the Lost and Found database and illustrates the business rules as connections between entities. This diagram also displays the attributes that are included in each entity. Primary and foreign keys are identified with a “PK” or “FK” button respectively.

25

8.1 Entity Relationship Diagram

26

8.2 Business RulesThe following business rules explain the relationship of each entity from the Entity Relationship Diagram.

Owner and AnimalEvery owner may own one or more animals.Every animal is owned by an owner.

Owner and PhoneEvery owner has one or more phone numbers.Every phone number belongs to one owner.

Owner and EmailEvery owner has one or more emails.Every email belongs to one owner.

Owner and Address Every owner must have one address.Every address has one or more owners.

8.3 Sample Data Tables

Owner ID Last Name First Name Address ID1 Johnson Joey 132 O’Neil Neil 113 Brown Molly 124 Zuckerberg Marcus 125 Winfrey Oprah 14Animal ID Name Age Weight Sex Species Breed Owner ID123 Boots 2 10 F Cat Tabby 3124 Mr. Pickles 4 12 M Cat Siamese 4125 Gary 14 95 M Dog German

Shepherd2

126 Claire 8 20 F Rabbit Flemish Giant

5

127 Steve 5 75 M Dog Irish Setter

1

128 Tina 5 362 F Llama Ccara 5

Address ID Street City State Zip11 516 ½ Menominee St. Eau Claire WI 5470112 427 Niagara St. Eau Claire WI 5470213 454 Summit Ave. Eau Claire WI 5470114 1111 Rich Dr. Eau Claire WI 54701

27

Email ID Email Address Type (W,H) Primary Owner ID21 [email protected] H Y 422 [email protected] W N 323 [email protected] H Y 224 [email protected] H Y 325 [email protected] W Y 526 [email protected] H Y 1

Phone ID Phone Number Type (H, C, W) Primary Owner ID1111 715-222-3333 H Y 12222 715-123-4567 C Y 23333 715-236-9840 W Y 44444 612-222-9666 C Y 55555 715-609-6196 W N 56666 952-911-0911 W Y 3

9. Data Flow DiagramsThe Data Flow Diagram is a graphical representation of the proposed lost and found system. Each of the following is an illustration of the flow of data within the lost and found system at various levels of decomposition.

mailto:[email protected]




28

9.1 Context Level DiagramThe context level diagram (Figure 1) shows an overview of the system and the flow of data within the Lost and Found System. This Level shows how each actor effects the system from a top down perspective. It also shows what the system gives to each actor involved in the system.

Figure 1: Context Level Diagram

29

9.2 Level 0 DiagramThe level 0 diagram (Figure 2) displays the movement of data in and out of the system. The level of the diagram shows how the system interacts with the data stores. The other main feature of this level is that it shows how the data is transformed between the processes.

Figure 2: level 0 Diagram

30

9.3 Level 1 of Process 1The data flow diagram (Figure 3) decomposes the Process Information process. This level of the

diagram shows what happens within the process of enter information. It shows where the data directly goes and what happens to it in the specific parts of the process of enter information.

Figure 3: Level 1 diagram

31

9.4 Level 1 of Process 3The data flow diagram (Figure 4) decomposes the Generate reports process. . This level of the

diagram shows what happens within the process of generate reports. It shows where the data directly goes and what specific information is used in certain parts inside of the process generate reports.

Figure 4: level 1 diagram

32

10. Prototype Mock-ups

The following sections illustrate prototype mock-up screens. These prototypes display the process the user will follow when using the Lost and Found System. Each form will be provided with introductory text to explain what the user is seeing.

10.1. Lost and Found MenuThis is the main Lost and Found form that users will interact with. The user will interact with drop-down menus and text boxes to enter the required information. There will also be an area to upload images of their pet.

33

10.2 User Sign-in ScreenFrom this screen, the user can input their username and password to sign into the system.

10.2 Generate Reports FormThis form is viewable after the user logs into the system. From here, the primary function of this page is to generate any required report.

34

11. Transition Plans

The following sections will detail the test plan, the implementation plan, and the training plan for the Lost and Found System. These plans are to be implemented to ensure a successful installation of the Lost and Found System.

11.1. Test PlanThe test plan is used to ensure proper functionality and needs of the ECCHA. This plan will include the following: Component, integration, systems, and acceptance testing. Each form of testing will be described in the following subsections.

11.1.1 Component TestingComponent testing occurs when the subsections of the system are tested individually. First, the login screen will be tested to ensure that managers are able to successfully log in. Also, the login screen will be tested to ensure that access is not allowed without proper credentials. Next, the generate reports component will be tested to ensure all aspects of the form are working and filtering properly. The Lost and Found form will be tested to guarantee information remains within the correct fields and can be easily converted into other text forms. The final component test for the system will be its ability to accurately match descriptions from third party databases.

The system developer will be responsible for conducting these tests on the prototype. Based on required fields, sample data will be created to test in each prototype mockup. From here, any errors that may have occurred will be documented and corrected to ensure proper functionality. Component testing will be complete when, and only when, all components of the system are functioning according to design.

11.1.2 Integration TestingAt completion of component testing, to confirm that all components are working together, testing for successful integration will commence. This testing is to guarantee that the Lost and Found system will integrate smoothly with existing systems used by ECCHA. To conduct this test, the system developer will use sample data and perform a mock-documentation, like that of an end-user. From these test results, we can confirm that all data is synced correctly with corresponding databases. Once any and all issues have been recorded, corrected, and tested again to confirm issues have been resolved, only then can integration testing can be completed.

11.1.3 System TestingUpon completion of the integration testing, alpha testing will begin on the development site using development personnel. In order to avoid future modifications during on site testing, any errors during alpha testing will be fixed and the test will be run again. This version of testing involves the bringing together of all the programs that a system encompasses for testing purposes. System testing will verify that the integrated system has completely satisfied the explicit requirements of the ECCHA. The system development team will be responsible for conducting the system testing and providing time frame needed for system testing. Testing will be considered complete once any deficiencies have been corrected.

35

11.1.4 Acceptance TestingAcceptance testing will begin at the development site upon successful completion of system testing. The development team, the alpha testers, will perform final acceptance testing prior to the onsite testing at the ECCHA in order to guarantee success upon implementation. During this phase of the acceptance testing, system developers will enter simulated data into the system and attempt to make the system fail. During this phase, system developers will test for security, recovery, stress, and performance.

The first component of acceptance testing is security tests. During security testing, system developers will attempt to access the system without proper credentials. Next, system developers will enter proper credentials to access the system and then restart the system while logged in which will force the user to re-enter login credentials. These tests demonstrate that a user who has either not entered the correct credentials or has not logged in after restarting their system will not be able to enter, edit, or submit data into the system.

The second component of acceptance testing is recovery tests. During recovery testing, system developers will force a system failure. The purpose of this test is to demonstrate the system’s ability to property reboot, save information that is both in the system and currently in progress, and protect submitted data from corruption.

The third component of acceptance testing is stress tests. During stress testing, system developers will log in to the system on multiple different computers in order to put stress on the system. The purpose of stress testing is to demonstrate the system’s ability to handle multiple users accessing the system simultaneously.

The fourth component of acceptance testing is performance tests. During performance testing, system developers will ensure the system performs as according to design. System developers will test the system on a computer as well as mobile devise. Performance tests will be considered complete if the system functions without glitches or errors.

After successful completion of alpha testing, the system will be ready for onsite beta testing. The ECCHA employees will be the beta testers. Beta testing will be completed by each employee who is involved in the Lost and Found process in any way. Each employee will complete each test that was completed during alpha testing, including security, recovery, stress, and performance. The beta testing will be considered complete once each test has been successfully completed by each employee. If any errors or glitches are encountered, they will be fixed, and the employees will be asked to test that section of the system again. Once the beta testing is completed and the ECCHA staff sign off on the system, the Lost and Found system will be implemented at a future date.

11.2 Implementation PlanThe implementation of the Lost and Found System will use the direct instillation approach. The old system will be shut down when the new one is set up. The direct approach will be the best way to implement the new system, because the system is designed to streamline the process and any overlap would create repeated data and wasted time.

36

The implementation will take place after all testing and training has taken place. The system will be implemented between 11pm and 1am as this will be a time of little to no use of the system. If the system is not completely functional by opening hours or if it is attempted to be used online, a message on the computer will appear saying, “The system is currently unavailable. Please try later.” The data already entered into the current system will be transferred and transformed to match the new system. Lost and Found system will be fully functional for use after it is fully implemented.

After the implementation of the Lost and Found system the staff of the ECCHA and the public will be able to more easily input lost animals and owners of lost animals into the database. This will also allow for the system to flag potential matches. The system will also allow for managers to generate specified reports that can contain important information.

11.3 Training Plan

Once the Lost and Found system is fully functional all employees and authorized users will go through training to make sure they can get full use of the system.

11.3.1 Eau Claire Humane Society StaffAll employees will be taught how to use the new Lost and Found form. All authorized users will get training on the generate report function.

The training will be completed by the system administrator in the form of a one-on-one meeting for authorized users and a group meeting of all the employees. The single training session will be held when The ECCHA isn’t open to the public and will last no longer than one and a half hours. The training session will be held one week before the implementation of the system. In case of employee turnover or a new authorized user being introduced to the Lost and Found system, a training manual will be created to guaranty the system is used optimally and properly.

37

12. AppendicesThe below information is required for the documentation process for designing the system. Information specific to this document can be found here to supplement prior content.

12.1 Revision HistoryThrough the development of the system, as a group we kept track of each step of who worked on the project. This information is for the ECCHA to review through the progression of the improvement of the lost and found system.

Date Version Description Author

2/24/2015 1.0 Started initial formatting and idea of planning Group

3/3/2015 2.0 Completed Problem Statement, Product Position Statement, and Stakeholder Summary

Group

3/10/2015 2.1 Enhanced all of Stakeholder and User Descriptions, additional formatting

Group

3/12/2015 2.2 Cover Page Mike3/13/2015 2.3 Enhanced Introductory texts, added additional table

contentGroup

3/13/2015 2.4 Table Formatting Zach3/15/2015 2.5 Final information and formatting Group3/17/2015 3.0 Completed Systems Perspective and High-level System

RequirementsAlex and Sam

3/17/2015 3.1 Added Project Risk List, elaborated on High-level System Requirements, updated Glossary

Zach

3/17/2015 3.2 Added Assumptions, Constraints, and Dependencies Sam3/18/2015 3.3 Added Alternatives and Competition Mike3/18/2015 3.4 Added System Features, updated glossary Group3/22/2015 3.5 Fixed formatting, revised section names in revision

history, fixed mistakes based off of feedbackZach

4/7/2015 4.0 Addition of Use Case Diagram and Specifications Group4/15/2015 4.1 Added Requirements Analysis Group4/21/2015 4.2 Added Data Flow Diagrams Group5/7/2015 4.3 Added Business and Entity Relationship Diagrams Group5/9/2015 4.4 Added additional information to Use Case

Specifications, Entity Relationship Diagram, Requirements Analysis, and Dataflow Diagrams

Group

5/12/2015 4.5 Added Test Plan, Component Testing, Integration Testing, System Testing, and Acceptance Testing

Group

5/12/2015 4.6 Added Implementation Plan and Training Plan Alex5/12/2015 5.0 Final Formatting Zach

38

12.2 Reference MaterialsThe below chart contains the names of the documents and databases used in creating this project.

Reference Document Name Brief Description Location of Definitive Source

Client Question Responses Answers to client questions. D2L Client InfoGuide Star ECCHA Financial information for non-profits www.guidestar.comSystem Service Request D2l Group Locker Group 17Milestone 1 Early version of this document D2l Group Locker Group 17System Description Early addition to this document D2l Group Locker Group 17Use Case for Proposed System Early version of Use case section D2l Group Locker Group 17Specify Requirements Earlier version of requirements section D2l Group Locker Group 17Data flow diagram Earlier version of DFD section D2l Group Locker Group 17Milestone 2 Updates Combination of multiple updates of

previous assignmentsD2l Group Locker Group 17

12.3 GlossaryThe following is a table for defining some of the terms we use throughout the document.

Term DescriptionActor A person or system that derives benefit from and is external to the systemAlpha testing Testing of system at developer site using fictitious dataAttribute A characteristic of an entityBeta testing Limited access testing using real users and real data in the environment the system will

be implementedBoard of Directors

The executives in charge of business decision making for ECCHA

Business Rules

Statements of the processes and policies governing the behavior of the organization. Although generally not written down, you must identify and then document those business rules that define or constrain the relationships among the people, places, things and events about which the organization is maintaining data.

Common Information

Specific information that is referenced multiple times

Constraints Events and circumstances that may restrict, limit, or regulate a projectContext Level Diagram

An overall view of the “information system” under consideration, showing its relationship with external entities

D2L Desire to Learn website for class and file hosting for students/faculty being used by the University of Wisconsin-Eau Claire.

Data Flow Diagram

A picture of the movement of data between external entities, the processes, and the data stores within a system

Data store A data repository—either permanent for temporary—for data transformed by processes. Data stores can be files or full database systems.

Database An organized set of information that is stored in a computer and accessible in multiple ways

Dependent Entity An entity whose existence is dependent upon another entity because all or part of its

39

primary key comprises a foreign key from another entity. Also known as a weak or identifying relationship.

Direct and indirect risks (related to system design)

An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.

Direct Installation

An approach to installing new software where you change over from the old information system to a new one by turning off the old system when the new one is turned on.

Director A salaried employee who works full time at The Community Table who directs business on-site and interacts with the guests

Donor Supplies funds for ECCHA operationsECCHA Eau Claire County Humane SocietyEntity A person, place, object, event or concept in the user environment about which the

organization wishes to maintain dataEntity Relationship Diagram

A model that captures the overall structure of organizational data

Foreign Key A field in one table that uniquely identifies a row of another tableFunctional Requirements

A statement of what the user must be able to do and what the system must do to support what the user must be able to do

GB Gigabyte, a measure of space on a computer hard driveGhz The unit of rating for a computer processor referring to the speed which that computer

can complete processes in a given unit of time.Graphical User Interface (GUI)

An illustration of how a person interacts with a computer-based system through graphical icons and visual indicators (e.g., contrast, repetition, alignment and proximity).

Hard drive Internal component of the computer where data is storedInformation System

A system composed of people and computers that processes or interprets information

Installation Plan A plan for installing software at user sites, including preparations, user training, and conversion from existing systems.

Integration Testing

The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion.

Level 0 Diagram Represents a system’s major processes, data flows, and data storesLevel 1 Diagram The major processes of a system are broken down into levels, with each level showing

the depth of the systemLFS Lost and Found SystemManager Salaried employee that oversees regular operationsMicrosoft Office 2010

Common processing suite that contains products such as Word, Excel, etc.

MoSCoW Technique used to categorize requirements of a system (Must, Should, Could, Won’t)Nonfunctional Requirements

Specifications of how well a software system must function

Operation (Nonfunctional Requirements)

Non-functional requirements focused on how well a system performs for daily use.

PetPoint 3rd party online database containing lost and found information

40

Primary Key Unique identifier for a record within an entityRAM Random Access Memory, the ability for a computer to handle multiple tasks at onceStakeholder Person with interest into the operations of ECCHASystem Technology and processes working together to achieve tasks

System Testing The bringing together of all the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion.

Test Case A set of conditions under which a tester will determine whether an application, software system or one of its features is working as it was originally designed

Testing An iterative process of examining the software with the purpose of confirming that the system satisfies requirements.

Transition (Nonfunctional Requirements)

Non-functional requirements focused on how easy it is to adapt to changes in the technical environment.

Use Case Relationships

Graphical depiction of connection between use-case diagram elements.

Use-Case Specification

Textual a requirements documentation that describe the step-by-step process a user goes through to achieve a specific goal using a software system. Use case specifications also describe the alternative paths: a) all the possible ways the user a user can take to achieving a goal and b) all the possible things that can go wrong along the way that prevent the user from achieving the goal.

User Any person interacting with the systemUser Interface The means by which the user and a computer system interact or what the user sees on

the screenWeighted Decision Table

A table used to analyze alternative options by assigning weights and values to different characteristics of each option.

Windows 7 Microsoft operating system

Business Analysis Project 2015

Documents