User Requirements

This week we are getting started with the semester project by working on the user requirements and outlining some use cases.

It is probably a weak point in the course that you not only specify and implement the system, but are also responsible to come up with the requirements for the system. There is no real customer that you can interview, and that can tell you in the end if your system satisfies their requirements or not. (We could fill an entire course with just the user requirements.) We need to keep that in mind. The goal is hence to come up with a sensible set of good use cases that we take as input for the subsequent specification and implementation process.

We guide the design of these use cases using a partial Vision-and-Scope document.

Discuss the Semester Project

We provided you with a partial and vague outline of the semester project. It is vague because it should allow you to adjust the system idea with your own ideas and plans. Defining the detailed requirements is part of the task.

Have a short round where each of you explains their understanding of the system, and make a list of good ideas. For example:

This is an open-ended task, so make sure to conclude the discussion after some maximum time. (Like 20 minutes maximum.)

Partial Vision and Scope Document

Based on your idea, create a preliminary Vision and Scope Document. The entire document should be short and concise, probably only about two to three pages. Capture the following sections:

This task kicks off your work with the semester project, but is open-ended in the sense that you will probably not come up with the final document in this session. You will most likely have question about this document. Submit them in this form. We will collect these questions, group similar ones and then answer them.

Based on the coarse idea of the system you will describe a set of use cases in the following.

You don't need to deliver this document this week, as it will be part of the delivery for the semester project. Create a folder in your own Team channel where you store all semester project related documents. You can also create a private team for that, where only you can access the documents.

What are Good Use Cases?

You have now already learned a lot about use cases and seen some examples, and know which goal we have when designing use cases. So what are the characteristics of good use cases?

Step 1: Individual Work

As always, have an individual round first:

Step 2: Teamwork

Now combine your work together:

Deliver your solution in the Teams folder for this unit. Use filename ttm4115-use-case-qualities-Team-XX.docx

Use Case Levels

Recall the different levels of use cases from the preparation, where we assigned use cases to different levels on a horizon:

In the document above, you see a number of use cases lined up at the sea-level, but many of them belong either to a higher or a lower level. In case you have troubles with the document, here is a list of all the use cases it lists:

As you can see, these use cases do not relate to the same system. Use some fantasy to think about the systems around them, most should be obvious. Your task is to assign these use cases to the level where they fit best. The exercise has the main intention to make you familiar with the use case levels, before we apply this kind of thinking on your semester project.

Use Cases for Your Project

Turn your attention now to your semester project.

For your project delivery, you should focus on three use cases at the sea-level. As you have seen above, these are the use cases most important to get right. The ones above provide direction and connect to your system's goals and purpose, but are more abstract. The ones below sea-level provide too much detail, but may be valuable when implementing the system.

As an example, look at the use cases below I sketched for one of the many toilet paper ordering systems that were popular when students could choose their own systems. The focus is at the sea-level, where I added two use cases (a third one is yet unspecified). I added a few use cases at the fish, kite, and cloud level, and connected the use cases with some arrows to show their dependencies. Try to follow the same strategy for your use cases.

Example use cases on their respective levels for a toilet paper management system.  

Of course, store the use case level document for your work on the semester project. Also, deliver a screenshot of your use case levels on Blackboard. (Once per team.)

Team Reflection for This Unit

Individual Reflection

Questions and Answers

Risks

The Vision-and-Scope document lists business risks, which may be difficult for us to come up with. (These would be related to the operation and for instance financial aspects of the system.) Instead, think about the risks that can affect your specific situation of being able to delivering a the semester project with high quality.

For the risks, are you looking for the risks for planning the system, for the production of the system or our teams risks?

How many risks should be included? There are plenty of different risks, both regarding development and once in production.

Objectives

How business-oriented should the objectives be?

Regarding business objectives: are we supposed to have numbers and percentages in our goals, or do we use more of a qualitative approach?

How specific should the objectives be? Should we just use our imagination, or find some possible source?

We have a question about the field objectives. Can we make assumptions on how the workplace is today, if we want to come up with some measurable values for improvement?

Similar question:

How big assumptions can we make? Concerning background: can we assume there are problems with the prior system and that we have solutions for this?

And yet another similar one:

Do we need to consider already existing solutions? Compare whether our solution is better?

Stakeholders

Are developers stakeholders?

Scope and Functions

Is encryption/security something we should think about in this project?

How much do we have to realize in reality? What should we implement?