In this six-week capstone course, you will gain practical management experience in a safe, simulated software production setting. You will apply Agile practices and techniques to conquer industry-inspired challenges. Interacting with a realistic client, you will discern what they want and express what they truly need in software requirements to drive software production. Upon completing the capstone, you will be prepared to advance your career as a confident software product management professional.
1.7 Video Simulation: Development Team Meeting (Monday)
Loading...
來自 University of Alberta 的課程
软件产品管理毕业项目
372 個評分
從本節課中
Capstone Project - Week 1
Welcome to the first week of the capstone. This week, you will be primarily focusing on eliciting requirements. You will get to meet your client as well as collaborate with an expert advisor. You will also meet the development team that you will be working with. They will help you to clarify and elaborate on the information elicited from the client and expert. You will finish off the week by creating a Requirements Document.
與講師見面
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
>> So based on what you've told us,
most of this project seems very straightforward.
I mean, browse and search features are pretty standard, for example.
So, let's take some time to talk about some of the features that are a little bit
more ambiguous.
First of all, I'm personally a little confused around how users
are going to talk to one another through the app.
What sets this apart from a straight forward reading app?
>> Couldn't it just be a messaging feature?
>> Yeah, I don't know that kind of defeats the purpose of reading to someone else.
>> That's true, Josh, you raise a good point.
What if we did something like a video chat instead of text messaging?
>> Yeah, that makes sense, but I don't think we should rely on that.
Because for one,
video is going to eat through people's data plans like nobody's business.
So I think we're going to need a fall back,
I think we can design an audio only option.
I mean, I can do that up in no time.
>> Great.
Good idea, good thinking.
Daniel did mention that they should also be able to see a list of friends that they
can connect to as well, is that like a friends list?
>> Yeah, that's what I was thinking.
>> Okay.
>> My only worry is that we're going to have to create accounts for
all this stuff.
>> I can see why you wouldn't want to do that, but
it's actually going to be necessary for this project.
If were going to be storing any kind of user history.
I mean, we're going to need account for
more than just storing books they've already read.
If were going to be tracking reading comprehension,
that's going to be pre-user too.
So we're going to need accounts and all of the features that go along with that,
like logging in and resetting passwords.
>> I really don't like what Daniel was thinking about reading comprehension.
I mean, yeah, it would be useful, but couldn't we just get them to fill out
quizzes or something instead of trying to figure out voice recognition?
>> What do you mean figure out?
>> We get it, you're so good at programming.
Voice recognition is just something that I've never done before.
>> Okay, you two.
How about we put it down as something we can do, but perhaps,
we raise it as a concern before we actually start to design for that feature?
Does anyone else have concerns about the project?
>> Well, they said that there should be a pass and play feature.
>> Why couldn't we do both?
>> But isn't pass and play, just read a book like a normal eReader?
What's cool about that?
There has to be some kind of interactive technology integrated in order to add
value.
>> What about Bluetooth?
We could connect two devices together wirelessly and
then display the same content on each.
>> That sounds like something we can handle,
although we need to have the user able to read on their own too.
So there is still some value to having the app function as an eReader at times.
>> Wait, what is this product being built for?
Because I know Lisa said that she wanted it to be portable and accessible.
So maybe it could be a web app, because that's going to need Wi-Fi, so
it could be a smartphone app.
>> No, Daniel said that this device has to look like a book and I don't think using
a smartphone is going to replicate a book nearly as easily as a tablet would.
I think we should design this specifically for tablets.
We can also restrict online downloads to tablets only too, I've done that before.
>> Yeah, you're right.
Reading a book off of a smartphone would be kind of hard.
So, are we creating this for Android or for iOS or both?
>> I think they want both, but we should double check with Lisa and see.
Doing both is going to be a lot of work, but perhaps, they just want one for now.
>> Hopefully, just one.
Doing both would be a nightmare.
So, should they be able to use this in portrait and landscape mode?
I picture reading a book in portrait mode.
>> What about both?
We can do portrait and landscape mode.
In landscape, you'd have two pages side by side.
And then in portrait mode, you would have one, but everything would be bigger.
>> It would also be awesome if you could have the pages animated to look like
they're actually turning too.
>> That makes sense.
>> Yeah.
>> Yeah, that would be cool.
Are we going to do that?
>> I think so.
What does everyone else think?
>> Yeah, it makes sense.
>> Cool.
>> Lisa said that they were going to be providing us with a database of material.
Are we going to be pulling that information from the database?
And I know Lisa said that she wanted the material to be used anywhere, but
storing all of that material on the app just seems unrealistic.
>> Wow, yeah, that would be horrible.
Can you imagine how much space that would take up on people's devices?
There's no way we can do that.
If we just pull the titles of the books from the database that would free up
memory usage a lot.
>> Yeah and then when they begin reading a book, then we would store it onto
the tablet, so they don't have to access the database every time they want to read.
>> Good ideas you two.
Yeah, I mean, I don't think the user would expect to be able to browse content when
they're not connected to the Internet anyway.
Now, do you think that would be the same for the favorites and to-read list?
>> I think that those lists should be saved locally onto the device, so
that they can choose to read those books whether they're connected or not.
>> That makes sense.
Let's just jot down that the user should also be able to delete items from
their device as well.
I just think it would be irritating if adding an item to the list was
irreversible and that will need to be connected to the accounts, as well.
>> Are we also doing that definition thing?
Is there going to be a dictionary in the app that they can use?
>> No, remember that wouldn't be useful for kids.
Daniel said, he wanted the kids to be able to get definitions right away by
asking the person they're reading with?
>> Yeah, what if they're reading alone or
the other person doesn't know the definition?
>> That's what I was thinking.
>> Well, couldn't we just have the definition pop-up when they use their
select the word?
>> Yeah, yeah.
No, I see that, yeah.
>> Awesome.
I can totally see it.
Things seem pretty good.
I think we have enough information to move forward with design,
what does everyone else think?
>> Yeah, I think so.
>> Yeah, great.
Perfect.
Thank you, all so much and let's get going on this.
