Case Study

Preliminary Investigation and Requirements Report Template
Version 0.0: [Date published]

Presented by: [Presenter’s name]

Worksheet
Client approval: Yes No

Note whether your case study needs to be ready in time for a specific event:

Date: Event:

Template
Case Study for [Customer Name] 1. GENERAL INFORMATION
Company profile
[Briefly describe your customer’s products or services. Include information about the company’s history.

Example:
Wingtip Toys, established in 1956, is the premier supplier to toy retailers worldwide.

Revenues in 2003: $3.5 million

Estimated IT budget for 2004: $1.2 million

Wingtip Toys ceased IT development after September 11, 2001, and has not pursued any recent IT development.]

Business situation
[Identify the problems that your customer is facing and their goals and objectives. List the strategic business or competitive reasons that caused the customer to reevaluate its current situation. Be as specific as possible, citing examples when appropriate and including supporting customer quotes.

Example: As a result of the recovery of the market, Wingtip Toys wants to procure software for improved tracking of inventory and purchasing.]

Technical situation
[Provide a detailed evaluation of the customer’s current technical situation. Identify what the customer uncovered during the evaluation of its systems, the technical challenges the customer is facing, and how the customer believes it can meet the challenges.

Example: Wingtip Toys’ current environment runs on older computers that are no longer capable of handling the bandwidth necessary for servicing Wingtip Toys’ worldwide customer base. Additionally, Wingtip Toys would like to allow customers to automate their orders and also would like to eliminate telephone and paper orders.]

Problem or Opportunity
[Create SWOT or Fishbone diagram] A popular technique for investigating causes and effects is called a fishbone diagram, or Ishikawa diagram.

]

Project Scope and Constraints
[In this section, include descriptions of each of the following as they pertain to your system:

· Project scope

· Project creep

· Constraints

· Present versus future

· Internal versus external]

Perform Fact-Finding
[Document how you conducted fact finding and how you diagrammed current processes.] Fact-Finding
· Fact-finding involves various techniques

· Depending on what information is needed to investigate the systems request, fact-finding might consume several hours, days, or weeks

· Analyze Organization Charts

· Obtain organization charts to understand how the department functions and identify individuals you might want to interview

· Conduct interviews

· Review documentation

· Observe operations

· Conduct a user survey]

Survey / Interview Questions:
· Make up lists of questions that you will ask to various personnel of the area which you are investigating

Current Processes
[This “Current Processes” section is sometimes missed by students. This is an important section and carries 15 points. You need to show at least 3 different current processes i.e. the current way of how things are done.] The format to be followed can be

1. the way we designed processes in week 3 class discussions i.e. Process Name; Input, Process, and Output… OR

2. use Data Flow Diagrams (Logical DFD) which show the same thing as #1 but in a visual format. The advantage of using DFD for PIR is that later during SDS, you can use the same format but you can expand them adding physical information i.e. using “Physical DFD”. See the following resource: https://www.visual-paradigm.com/guide/data-flow-diagram/what-is-data-flow-diagram/#dfd

2. REQUIREMENTS
List of Requirements
[Define system requirements and list the general categories into which system requirements fall: functional, non-functional, etc…].
As you can see the grading rubric below, this “Requirements” section is allotted 40% of the PIR. So, this should be the biggest and in most depth of the entire PIR. Please do not turn in just a couple sentences for this section. This section requires the most thought and work on your part.
DO NOT USE THE SAME FORMAT AS IN CURRENT PROCESSES SHOWN ABOVE

i.e. do not show input/process/output for requirements.

Requirements show lists of features/functionality we want the new system to have. These take the form of: The system must have… or the system shall have …. See the EXAMPLE highlighted in blue below. See also https://en.wikipedia.org/wiki/Functional_requirement

Example:

Process

· System must handle registration for regular students and children in after-care.

· Must track the payment method and status of students including calculation of payments and amount due.]

This section must show requirements broken down into various categories, with a minimum of the following: functional ( by far, the biggest section of the PIR ), non-functional, etc. Here are some resources to help you with this section:

· https://en.wikipedia.org/wiki/Requirements_analysis

· Pay particular attention to section 3 i.e. the following https://en.wikipedia.org/wiki/Requirements_analysis#Types_of_requirements

· https://en.wikipedia.org/wiki/Functional_requirement

· https://en.wikipedia.org/wiki/Non-functional_requirement

“FUNCTIONAL REQUIREMENTS” ARE THE BIGGEST & MOST IN-DEPTH SECTION OF THE PIR

Later in the SDS, you will take the same list of Functional Requirements and will create a Physical DFD based on them. So, it’s to your advantage to learn DFD from now, and solidify your skills.

Grading Rubric