By the tiswa editorial team, from the official sources listed at the end of this guide. How we write our guides
A project manager asked an information systems student on a phone interview what he could do for her team in his first week. “I program,” he said. She had been hoping for someone who could sit with the sales team, see how they log orders, and write down what the technical team needs. The case is an example, but it sums up the problem: students from this major present themselves as programmers when they are analysts.
Your major sits between business and technology. That is a strong position if you can prove it, and a weak one if you cannot, because the reader does not know where to put you. What follows is what to collect from your university projects before you apply, without claiming the requirements of any particular employer.
Is co-op training for information systems different from computer science?
Your courses most likely start from understanding the business: systems analysis, databases, project management and enterprise systems. Computer science students go deeper into algorithms and programming. For the comparison from the study side, see the information systems major guide; here we cover what you show in an application.
If you apply to an employer looking for a business analyst or a data team assistant, do not copy a programmer’s CV. Write what you did with people: you interviewed the owner of the process, wrote the requirements, drew the process and designed the tables. If you have a coding project, keep it as a secondary line. For the programming route, the plan is in computer science co-op skills.
How do you turn your courses into three pieces of evidence?
Three are enough: a data model, a process map and a requirements sheet. Each is a page or two, opened from a link or a PDF. The table below shows a way of thinking, not a claim that your courses match it.
| Evidence | From which course (example) | What you write under it |
|---|---|---|
| Data model | Databases | Chose a foreign key linking order to customer because one customer has many orders |
| Process map | Systems analysis | Found a duplicated approval step between two departments and proposed merging it |
| Requirements sheet | Requirements engineering | Wrote ten requirements and ranked them by importance to the process owner |
| Data report | Business intelligence | Summarised a week of sales in a table and chart and wrote what calls for a decision |
How do you build a data model a reviewer reads in two minutes?
Microsoft’s documentation explains that a primary key identifies each row in a table and that a foreign key links one table to another and protects the relationship between them.2 This is exactly what a reviewer wants to see: that you understand why there is one table for customers and another for orders.
- Pick a small activity you know
A college library, a student club, a small shop. Something you can explain without research.
- Write the entities and relationships
Three to five tables, each with a primary key. State one relationship in words: one customer, many orders.
- Create the tables with sample data
Ten rows per table is enough to test a query.
- Write two queries
One joining two tables, one summarising a count or a total. Save a screenshot of the result.
- Explain one decision
Why did you put the address in its own table? One line is enough.
How do you write a process map and a requirements sheet?
The BPMN specification published by the Object Management Group defines a shared set of symbols for drawing processes, including events, activities and gateways.3 You do not need to read all of it, but using the standard symbols saves the reviewer from decoding your drawing. Draw one process from start to finish, then mark the step where the work waits.
The requirements sheet starts with one question: what does the user need to do their job? Write each requirement as a sentence someone can test, such as “the system shows the order status within three seconds.” Avoid “the system is fast and easy”, since nobody can say whether that was met.
What weakens an information systems student’s application?
The first is a tool list with no work: naming Power BI, SQL, Excel and an ERP product together suggests you have passed them, not used them. Name one tool and put work under it. The second is a process drawing with no comment, which looks copied. The third is requirements that are all “must” with no success measure. The fourth is skipping a line on communication, though an analyst’s job rests on listening and writing.
A less obvious fourth: submitting a team project without stating your share. Write “designed the tables” or “drew the process”, not “took part in the project”.
How do you apply for co-op training in three weeks?
Week one: gather and tidy the three pieces. Week two: the CV. The student CV guide helps with layout, and the résumé check for automated systems shows what screening software reads. Week three: apply to employers you chose with care, and prepare for the interview question about your project, as in explaining your project in an interview.
To practise “what was the hardest part of your project?”, write three sentences: the problem, the choice you made, and what you would do differently. The interviewer hears how you think, which is what an employer wants from a junior analyst.
For the general frame of a trainee’s relationship with an employer, such as contract, duration and rights, check the Ministry of Human Resources and Social Development and ask your university’s training office what it applies.1 As for where to look: employers’ careers pages, your college training office, then the general guide to co-op training.
