Low Level Goal Types

Loading...

来自 University of Colorado System 的课程

Requirements Specifications: Goals and Conflict Analysis

12 个评分

浏览相关视频

您将在 Coursera 发现全球最优质的课程。以下是为我们为您提供的部分个性化建议

University of Colorado System

Requirements Specifications: Goals and Conflict Analysis

12 个评分

课程 3（共 5 门，Specialization Requirements Engineering: Secure Software Specifications）

In Requirements Goal Development and Language Analysis, we move from the spoken word to precise writing. A first step in this is writing goals. We will talk about goals used in requirements engineering and, from this, writing use cases from what we learn. Use cases can be in diagram and written form. Then- the villains enter- misuse cases and abuse cases are discussed in how we can deal with them in a Requirements environment. In gathering requirements, you'll have many questions remaining. Often this leads to the need of more interviews and group sessions. We'll go through how to handle group meetings, dealing with inconsistency, and handling conflict between stakeholders.

从本节课中

Goal Creation

After learning a lot from your customers, you now need to analyze, evaluate, and negotiate. One way to begin working with the data is to write out explicit goals from the information you've gathered. Goals can be written at high and low levels, but they need to be clear and measurable at any level. The first step is determining behavioral goals.

Introduction to Goal Development and Language Conflict Analysis6:59

Generating Goals6:34

Goal Overview6:34

High Level Goal Types6:23

Low Level Goal Types8:33

与讲师见面

Kristen Walcott-Justice
Assistant Professor
Department of Computer Science

Goals can be expressed in a number of ways, the first type is the Achieve goal.

The Achieve goal prescribes intended behavior,

where the TargetCondition must sooner or later hold,

whenever some other condition holds the current system state.

The corresponding specification would look like what's shown here.

Achieve a TargetCondition, if the CurrentConditon holds,

then at some point, you know you will reach the TargetCondition.

For example, to achieve the BookRequestSatisfied condition

in our library system, the Achieve goal would state,

if the book is requested, then sooner or later,

a copy of the book is borrowed by the requesting page write.

For our train system, in order to achieve the goal of a fast journey,

one goal could be stated as, if the train is at some platform,

then within five minutes, it's going to be at the next platform.

Let's also consider our meeting scheduling system.

Let's say we want to achieve the goal of, a meeting request is satisfied.

Think about this for a few seconds, the meeting request needs to be satisfied.

One way that we could write this is to say achieve meeting request satisfied.

If a meeting is requested, then sooner or later the meeting does take place and

is attended by all important invited participants.

We can also write maintain goals for our system.

Maintain goals prescribe intended behaviors where

some good condition must always hold.

Accuracy goals are usually a type of Maintain statement.

Maintain goals follow the temporal pattern of Maintain, Some GoodConditioon.

Potentially if CurrentCondition then always Some GoodCondition.

These statements can also leave out the if part,

if SomeCondition, then GoodCondition.

For example, a Maintain goal in our train system may be that

the doors are closed while the train is moving.

Always, if a train is moving, then its doors are closed.

If the goal is to Maintain WorstCaseStoppingDistance then

a requirement might be, if the train is following another train then its

distance must be sufficient to allow the other to stop suddenly.

As another concrete example, let's go back to that library system again.

Let's say we want to maintain accurate book classification,

again, that's maintain accurate book classification.

What might you write there?

If a book is registered in the library directory,

then always it's key word base classification

reflects on its covered topics, makes sense, right?

Notice the structure of these statements,

and look at these examples, remember, the if then is optional.

So ask yourself, always what,

or, if this condition, then always what?

Another type of goal that we can write are Avoid statements.

Avoid goals are related to Maintain goals, very, very similar.

Avoid goals are often used in security.

Achieve goals refer to some future state given some arbitrary Current one.

Maintain and Avoid goals refer to every future possible state.

You can possibly rewrite those so that they go up to some particular point

rather than anything in the future, but, in general.

In an Avoid goal, you write it as Avoid Some BadCondition,

and then define it as if Some CurrentCondition then if that happens,

then never let that bad condition happen.

Or if you just never want something to be able to happen, ignore the if.

For example, if you don't want others in the library system to see BorrowerLoans,

you could write a statement like this one here, Avoid BorrowerLoansDisclosed.

Never let patron loans be disclosed to other patrons.

These statements are especially useful in security.

Avoid goals are very useful in security, because usually we're saying,

don't ever do this, we can never allow this.

Try to think of some of the examples that you've seen in your own work, and

in systems that you've used of how avoid goals could be useful.

One example might be Avoid unauthorized access.

We want to avoid unauthorized access if the user has less

than top secret security clearance.

If they don't have top secret security clearance then never,

the user cannot access documents or systems above their security level.

Unlike behavioral goals, soft goals prescribe preferences,

where these preferences go along alternative system behaviors.

In soft goals, the overall goal is to be more fulfilled

as along some alternatives than along others.

Please see the additional reading for

more information on how we define soft goals, and how we evaluate them.

Goal satisfaction doesn't make a lot of sense for soft goals,

because we can't observe that the a're actually

satisfied by some course of behaviors, and not satisfied by others.

Soft goals are not the same as goals whose satisfaction is

required X percent of cases, those are behavioral goals.

Soft goals are more probabilistic goals,

with behavioral goals, is it satisfied or is it not?

In soft goals, it's only required to be satisfied sometimes.

And in your analysis, you're looking at how much has it satisfied

along this alternative, versus this other alternative?

This concept of partial satisfiability led to the creation of the term satisficing.

This defines a partial degree of satisfaction.

The state of the art of evaluating, validating and

verifying our probabilistic goals, is still really limited right now.

So, especially while you're reading the additional reading,

think about what kinds of goals the paper's talking about.

What are some examples of those goals?

In soft goals, you'll often use the words like maximize,

minimize, increase, reduce, improve.

For example, we might, for our library program, say,

the workload of the library staff should be reduced.

Also in the library system, the biographical

search engine of our library should be usable,

usable by non-computer science students.

In most cases, soft goals should be clarified much more when you're writing

your actual requirements document, so that those requirements can be testable.

But for right now, we're using our soft goals to learn more about alternatives and

prioritizations.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取