Let’s work on the student org IS. Reminder:

Gamerz is a student org at your university. They’re all about modding games, like Skyrim and Fallout. They have project teams that work on specific mods. For example, they made a Fallout mod called Mr. Clumsy. Like the Mr. Handy robot, except that it keeps dropping things, saying “Oops!”, “Dear me!” and the like. It shoots a laser at bad guys, but always misses.

They want an IS to keep track of the members and projects.

How do we make the IS? Here’s our project model, that is, the description of how to do an IS project:

  • Requirements
  • Models
  • Build


For the requirements step:

  • Identify the stakeholders
  • For each stakeholder, list what they want from the system


Here are three:

  • Gamerz members
  • People who run the org
  • People who are thinking about joining the org

Members’ goals

Members already know what the club is about. They want to know:

  • What project teams could I join?
  • What events are coming up?
  • What are the rules for:
    • Starting a project
    • Recommending a speaker
  • Works on a phone

The last one is important. Students will want to use their phones to check the IS.

Let’s start with that.

That’s a short list, compared to others we’ve had. What if, later, members tell us that we missed some things?

Good question, Adela! You’re thinking ahead, about how the project might go wrong. Always a good thing to do.

It’s normal to miss requirements. You have to cycle back, and add new requirements to the list.

Be ready for this, from the beginning of the project. Assume that you’ll miss something, and allow some extra time.


Like other student orgs, Gamerz has a president, secretary, and treasurer. They manage the group. Sign up members, schedule meetings, find speakers, like that.

They want to:

  • Contact members about meetings, projects…
  • Find out who hasn’t paid their dues
  • Know who to contact about project status
  • Publicize the org

Some of these goals are different from others we’ve seen. Take:

  • Contact members about meetings, projects…

Gamerz will need a list of members. For each one, they’ll need attributes like Email address, and Paid dues.

A member list is different from other other data in two ways:

  • Structure
  • Security

Structured and unstructured data

Here’s are two partial pages from Adopt-a-Dog:



The content on the first page has no particular structure. It’s a mix of text and images. It’s unstructured data.

The second one has structured data. There’s a table. Each row is about the same type of thing: a class. Each column is an attribute of a class:

  • When
  • Topic
  • Where
  • Fee

If you’re thinking content type, fields, and views, you’re right. We didn’t do it for Adopt-a-Dog, but now you know how to make content types for structured data.

Many IS have lots of lists (views). Think about how many lists of products there are on Bazillions!

Now think about this: one product can be in a dozen different lists: new products, products on sale, products with free shipping, products your friends bought…

So Amazon has all these lists on its IS. The price of a product, let’s say Vegemite, changes. Amazon could have someone manually change the price of Vegemite on all the lists Vegemite is on. They’d have to employ hundreds of people, just to keep the bazillion lists up to date.

Or, they could have a Product content type, and a view for each list. Someone could change the price field of the Vegemite node, and all of the lists would be updated automatically.

Hmmm… which way is cheaper? Would let Amazon lower its costs a lot, so it could charge customers less, and dominate online retail? Hmm… (Don’t think too hard. The answer is as obvious as you think it is.)

Here’s a headline: Amazon Is Absolutely Eviscerating Other Retailers Online. How do they do it? Part of the answer: they do a lot with structured data, and views.

Back to Gamerz. When you see requirements like this…

  • Contact members about meetings, projects…

… think to yourself:

Self, that’s structured data! Members could be a content type, with views.


Look at those that requirement one more time:

  • Contact members about meetings, projects…

The site managers need to know members’ email addresses. But should just anyone be able to see the emails? No! Ain’t nobody got time for spam.

Imagine two different views of member data. One doesn’t have email addresses. Everyone can see it. The other view does have emails. Use roles and permissions to control who can see that view.

Summary of this part

Managers need lists of members. It’s structured data, so think content types and views. Use roles and permissions to control who gets access to different views.

Potential members

This is the third stakeholder. They have questions like:

  • What does the org do?
  • Why would I want to join?
  • What projects are they working on?
  • Who can join?
  • Do I have what it takes to work on a project?
  • What does the org expect from members?
  • How do I get more info?

Oh, and…

  • Works on a phone


How to do an IS project: requirements, models, build. It’s normal to miss requirements, and have to go back and add new ones. We identified some stakeholders, and listed their goals.

When you see structured data, think content types and views. Modify a node once, and every view containing that node changes.