Scenarios

Loading...

En provenance du cours de University of Colorado System

Requirements Elicitation: Artifact and Stakeholder Analysis

14 notes

University of Colorado System

Requirements Elicitation: Artifact and Stakeholder Analysis

14 notes

Cours 2 sur 5 dans Specialization Requirements Engineering: Secure Software Specifications

In Elicitation: Artifact and Stakeholder Driven Analysis, you will learn to use both recorded and presently unrecorded knowledge in your elicitation techniques. As you get started in finding out about the new product, you must first learn about the product that was (if there was one) and then learn about the system to be. Oftentimes, you'll find yourself in an environment you know nothing about! This course will help you find ways to learn about the domain, the system that was, and the system to be. Please review: "Who this class is for to determine if you are ready to take this graduate level course".

À partir de la leçon

Storyboarding and Scenarios

As you talk with customers early on, developing storyboards and scenarios help. They are easily communicable to both the customer and later to developers and work in all software development lifecycles. Mockups and prototypes can also be used- CAREFULLY. Here we explain these concepts along with their large benefits and dangers.

Scenario Advantages and Disadvantages7:18

Rencontrer les enseignants

Kristen Walcott-Justice
Assistant Professor
Department of Computer Science

When we create storyboards and

begin discussing them, whether we're doing it in a passive way or an active way,

we try to find the happy and the sad paths that should be addressed in the program.

One way to address the happy and the sad paths is through the use of scenarios.

Scenarios are similar to storyboards in that they illustrate

sequences of interactions.

But they have quite a bit more detail.

Instead of just little stick figures, you're actually defining who, what,

when, where, and how things are interacting.

Answering those questions becomes a scenario.

The scenario shows how all of the system components are interacting

to accomplish the implicit objectives and

determine how the implicit objective can be met.

You also discover, as you go through the scenarios,

how you would hit the sad paths, like I can't find the movie or

I pulled the dollar away from my friend and they fell into the street and died.

Ugh.

When we create scenarios, creating scenarios is made simpler

by discussing the concrete examples of real life interaction sequences.

From these interactions,

you can gather concrete examples of hypothetical interaction sequences.

You can ask specific questions about them.

From that, you can also elicit underlying objectives.

By that I mean, you can say, well, why would you do that?

Or why could that happen?

All of these ideas can later be pulled together to generalize the interactions

into models of the desired behavior.

Let's say that in our meeting scheduler, the meeting initiator

asks that the scheduler plan a meeting with some particular date range.

This request includes a list of desired participants.

The scheduler goes and checks to see that first,

the initiator is allowed to create a meeting and that their request is valid.

So for example, you can't say that you want the meeting to

start in January of 2017 and end in December 2016.

That would be a faulty date range.

The scheduler should be checking that.

As an additional requirement, one of the participant returns their constraints.

Then, the scheduler will validate those constraints.

Just like in making sure it's not looking at invalid dates,

it does that for both the initiator and the participant.

Additionally, when the participant returns their constraints,

the scheduler will validate them.

Just like they did for the initiator of the meeting,

we also check to see that the participants' dates are also correct.

In this confirmation, the constraints are confirmed as being received.

Once all of the valid constraints are received, the scheduler

determines a meeting date and a location that will fit the constraints.

We all know this never really goes well.

There are going to be conflicts.

But these are the key goals.

Finally, the scheduled meeting date and the location are notified to

the initiator and also to all the invited participants.

Again, this is the happy path where everything goes well.

In scenarios, we have positives and negatives.

Positive scenarios are what should happen in terms of the one or

more behaviors that the system should cover.

Negatives, you can think of as counter examples.

Negatives illustrate what may not happen.

These are behaviors that the system should include, but they should deal with them.

This relates to our sad paths.

In our scenario example, what are these?

What might a negative scenario look like?

Well, one sad path might be that the participant returns a list of constraints

that covers all of the dates within the prescribed date range,

but they mess it up and go a couple days later too.

Is that really a sad path?

They're saying they're available.

So what do you do?

As another example, let's say that the scheduler forwards the message of

confirming the dates to all participants,

asking for alternative constraints with some extended date range.

In this case, while this is not a sad path, it is a negative scenario.

Because we have an implicit requirement that participant behaviors

are not disclosed to others.

If I say, nope, I can't be there Friday, you shouldn't know that.

So this is an example of a negative scenario that isn't a sad path,

as sad paths are described in the software development life cycle.

However, it is not allowed by the system.

That's why we define it as the negative scenario.

Within the program, that functionality should just not exist.

We do need to think about it though, so that,

that would provide an error if it occurred, maybe.

Do we need to code that in or not?

Balancing act.

So scenarios can also be defined as normal or abnormal.

Normal scenarios capture the course of the action as it is expected.

These overlap very closely with the positive scenarios.

Abnormal behavior scenarios show the desired interaction

under exceptional circumstances.

If you work in an agile environment, all of these terms end up being confused.

We confuse normal, abnormal, positive, negative, happy path, sad path.

Be careful when you are hearing these terms because we don't always use them

in very firm ways.

Sad paths overall are covering the abnormal paths.

Negative scenarios can usually be considered as sad paths too.

In this example of an abnormal scenario, where that abnormal scenario is

that the participant constraints are not valid, that would be a sad path.

You wouldn't want to raise an exception.

You wouldn't want to just throw up an error.

You wouldn't want the program to crash.

You need this abnormal scenario to make sure that it's accounted for.

However, this is not a negative scenario, despite the terminology.

It sounds negative.

But negative scenarios are policies or ideas that are not allowed to happen.

This scenario is abnormal in that it's allowed,

given the policies and expectations, but we do not expect it.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play