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.
Low Level Goal Types
Loading...
来自 University of Colorado System 的课程
Requirements Specifications: Goals and Conflict Analysis
4 个评分
University of Colorado System
4 个评分
课程 3（共 5 门，Specialization Requirements Engineering: Secure Software Specifications）
从本节课中
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.
与讲师见面
Kristen Walcott-JusticeAssistant 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.
