System Goals Model and Software Specifications.

System Goals Model and Software Specifications.

Introduction

There are two discussions here that need to be responded to thoroughly. Responses must be on APA format 150+words 1-2 legitimate verifiable sources per response.

CIS555 discussion 1 post responses.

Respond to the colleagues posts regarding:

“Goal Types and Categories” Please respond to the following:

• Compare and contrast behavioral goal and soft goals. Provide four examples to support your points. 

• Propose five functional goals and five non-functional goals. Propose how you would determine if a goal should be classified under the functional category or the non-functional category.

MHs post states the following:

Compare and contrast behavioral goal and soft goals. Provide four examples to support your points.

All goals are imperative statements about a desired result toward which a concerted effort is being made.  Behavioral goals “prescribe intended system behaviours declaratively” (Lamsweerde, 2009, p. 264).  These goals are either satisfied or not satisfied by how the system performs (Lamsweerde, 2009; Alspaugh, 2010).  For example:

• A seatbelt warning light is triggered when the car is moving and the driver’s seatbelt is not fastened.

• Turn on the soundbar automatically when the television is turned on.

• Turn off the soundbar automatically when the television is turned off.

Meanwhile, soft goals prescribe “preferences among alternative system behaviours” (Lamsweerde, 2009, p. 264).    Unlike behavioral goals, soft goals are achieved to a degree that is considered acceptable by stakeholders.  For example:

• Improve the completeness of patient records.

• Reduce the risk of data breaches.

Propose five functional goals and five non-functional goals. Propose how you would determine if a goal should be classified under the functional category or the non-functional category.

The best way to determine a goal’s category as functional or non-functional is to determine if the goal “prescribes intended system services or quality constraints on such services” (Lamsweerde, 2009, p. 271). 

Functional goals state “the intent underpinning a system service” (Lamsweerde, 2009, p. 269).  For example, an Electronic Health Record system may have:

• Satisfaction goals which are “concerned with satisfying agent requests” (Lamsweerde, 2009, p. 270). For example:

o Patient requests for a same-day sick appointment shall be fulfilled when an appointment is available.

o Physicians can view a patient’s medical history.

o Patients can view educational materials about their diagnosed medical conditions.

• Information goals which are “concerned with keeping agents informed about important system states” (Lamsweerde, 2009, p. 270). For example:

o Patients shall be notified when lab results are available.

• Stimulus-response goals which are “concerned with providing appropriate responses to specific events” (Lamsweerde, 2009, p. 270). For example:

o The system shall update the patient’s list of medications when a prescription is created by the physician.

Non-functional goals state “a quality or constraint on service provision or development” (Lamsweerde, 2009, p. 269).  Non-functional goals include

• Accuracy goals which require “the state of variables controlled by the software to reflect the state of the corresponding quantities controlled by environment agents accurately” (Lamsweerde, 2009, p. 270). For example:

o Lab results are available for every lab order entered in the system.

o Lab results are available to patients only after a physician has reviewed the results.

• Security goals which “prescribe different types of protection of agent assets against unintended behaviours” (Lamsweerde, 2009, p. 270). For example:

o Lab results are disclosed only to patients and clinicians.

o Only clinicians can prescribe medications.

o Only authorized users can access the Electronic Health Record system.

References

Alspaugh, T. A. Goals. (2010, September 18). Retrieved from https://www.ics.uci.edu/~alspaugh/cls/shr/goal.html

Lamsweerde, A. van. (2009). Requirements engineering: From system goals to UML models to software specifications. West Sussex, England: John Wiley.

CIS555 discussion 2 post responses.

Respond to the colleagues posts regarding:

“Goal Model Building” Please respond to the following:

• The textbook provides fifteen heuristic rules, tips, and common refinement patterns that can be applied during the goal model building process. Suppose that you are building a goal model of a system you are designing. Propose three best practices for selecting one or more of the fifteen heuristic rules that apply to the building of a goal model.

• From the e-Activity, determine if you can you easily depict these AND/OR nodes on a goal diagram. Predict three challenges you foresee in using a graph-based diagram to model goals.

MH’s post states the following:

The textbook provides fifteen heuristic rules, tips, and common refinement patterns that can be applied during the goal model building process. Suppose that you are building a goal model of a system you are designing. Propose three best practices for selecting one or more of the fifteen heuristic rules that apply to the building of a goal model.

Since any or all of the heuristic rules provided in the course text may be used to build a goal model, I would propose the following as potential best practices.

1. As early in the requirements engineering process as possible, identify individual goals by “[analyzing] the current objectives and problems in the system-as-is, [searching] for intentional keywords in elicitation material and [browsing] goal taxonomies to explore relevant instantiations” (Lamsweerde, 2009, p. 309).  

2. Develop a preliminary draft of the goal model.

3. Review each heuristic rule to determine its applicability to the current goal model and, where appropriate, use the rule to further refine the model.   

Repeat #3 above as needed until the model is finalized.

From the e-Activity, determine if you can you easily depict these AND/OR nodes on a goal diagram. Predict three challenges you foresee in using a graph-based diagram to model goals.

Challenges that I foresee in using a graph-based diagram to model goals are related to the familiarity of stakeholders with this type of diagram and the size of the diagram.

Stakeholders may be unfamiliar with this method of capturing and representing goals.  Or, the diagrams created in one system may be inconsistent (i.e. diagram shapes, etc.) with diagrams created in another system.  However, this may be overcome with training and legends.

Exceptionally large diagrams can be hard to process.  It may difficult for stakeholders to provide feedback without receiving supplemental documentation such as a dictionary or specification listing, at a minimum, the goal name and definition.

It is likely impossible to print a fully decomposed goal diagram on a single sheet of paper.  The diagram would have to be provided digitally.  Alternatively, the model may need to be represented as multiple hierarchical diagrams so that each diagram may be printed on a single page. 

References

Lamsweerde, A. van. (2009). Requirements engineering: From system goals to UML models to software specifications. West Sussex, England: John Wiley

CLOSE
CLOSE