lecture 7 quality attributes = nonfunctional req. topics quality attributesreadings: january 29,...

36
Lecture 7 Quality Attributes = Nonfunctional Req. Topics Topics Quality Attributes Readings: Readings: January 29, 2008 CSCE 492 Software Engineering

Post on 21-Dec-2015

215 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

Lecture 7 Quality Attributes = Nonfunctional Req.

Lecture 7 Quality Attributes = Nonfunctional Req.

Topics Topics Quality Attributes

Readings:Readings:

January 29, 2008

CSCE 492 Software Engineering

Page 2: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 2 – CSCE 492 Spring 2008

OverviewOverviewLast TimeLast Time

Documenting Software Architecture Rational Unified Process (RUP) - Kruchten

Today’s Lecture Today’s Lecture Quality Attributes = Nonfunctional requirements

References: References: Documenting Software Architectures: Views and Beyond, 2002,

Addison-Wesley, SEI series.

Next Time:Next Time: Quality Attributes = Nonfunctional requirements

Page 3: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 3 – CSCE 492 Spring 2008

Creating An ArchitectureCreating An Architecture

““Beauty is in the eye of the beholder”Beauty is in the eye of the beholder” Booth Tarkington (1838–1918).  The Magnificent

Ambersons.  1918.

So whose concept of “Quality” does the architect use?So whose concept of “Quality” does the architect use? His/her own? Customer? Can’t we all just agree? (paraphrasing Rodney King)

Can we move to a more objective less subjective def.?Can we move to a more objective less subjective def.? We will use quality attribute scenarios

Page 4: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 4 – CSCE 492 Spring 2008

Understanding QualityUnderstanding Quality

The surest foundation of a manufacturing concern is The surest foundation of a manufacturing concern is quality. After that, and a long way after, comes cost.quality. After that, and a long way after, comes cost.

Andrew CarnegieAndrew Carnegie

Quality is never an accident; it is always the result of Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction high intention, sincere effort, intelligent direction and skillful execution…and skillful execution…

Will A. FosterWill A. Foster

Page 5: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 5 – CSCE 492 Spring 2008

QualitiesQualitiesExamplesExamples

1.1. UsabilityUsability

2.2. ModifiabilityModifiability

3.3. PerformancePerformance

4.4. SecuritySecurity

5.5. AvailabilityAvailability

6.6. TestabilityTestability

7.7. On cost, on scheduleOn cost, on schedule

8.8. Cost and benefitCost and benefit

9.9. Integration with legacy systemsIntegration with legacy systems

10.10. Functionality? Functionality?

Page 6: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 6 – CSCE 492 Spring 2008

Functionality vs QualityFunctionality vs Quality

Functionality and other quality attributes are Functionality and other quality attributes are orthogonal.orthogonal. Orthogonal ? At least independent? Note functionality does not imply anything about others!

What is functionality anyway?What is functionality anyway? The system works as intended.

If functionality was the only concern we could If functionality was the only concern we could implement as one large module in Cobol or even implement as one large module in Cobol or even assembly language.assembly language.

So functionality is a prime goal, but it should not be the So functionality is a prime goal, but it should not be the only goal.only goal.

Page 7: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 7 – CSCE 492 Spring 2008

Architecture and Quality AttributesArchitecture and Quality Attributes

Achieving quality attributes must be considered thru:Achieving quality attributes must be considered thru: Design Implementation, and Deployment

No attribute is entirely dependent on design or other No attribute is entirely dependent on design or other phases.phases.

Satisfactory inclusion of quality attributes means you Satisfactory inclusion of quality attributes means you must get the big picture ( architecture) and the must get the big picture ( architecture) and the details (implementation) right!details (implementation) right!

Page 8: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 8 – CSCE 492 Spring 2008

Usability: Arch. Vs Non-Arch AspectsUsability: Arch. Vs Non-Arch Aspects

Non-architectural aspects of usability:Non-architectural aspects of usability: Making the user-interface clear and easy to use Should we use radio button or check box? What font? All a crucial to end-user usabilty, but they are not

architectural

Examples of architectural aspects of usabilityExamples of architectural aspects of usability Whether the system provides an “undo’ capability to the

user? Can we – reuse data previously entered? These are architectural because they are going to require

the cooperation of several elements.

Page 9: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 9 – CSCE 492 Spring 2008

Modifiability: Arch. Vs Non-Arch AspectsModifiability: Arch. Vs Non-Arch Aspects

Architectural aspects of Modifiability:Architectural aspects of Modifiability: How functionality is partitioned

Non-architectural aspects of Modifiability :Non-architectural aspects of Modifiability : Coding techniques used within a module

Note: in spite of having the perfect decomposition, the Note: in spite of having the perfect decomposition, the implementation may be not be maintainable.implementation may be not be maintainable.

You must be concerned about modifiability at all levels, You must be concerned about modifiability at all levels, all the time.all the time.

Page 10: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 10 – CSCE 492 Spring 2008

Performance: Arch. Vs Non-Arch AspectsPerformance: Arch. Vs Non-Arch Aspects

The performance of a systems depends on both The performance of a systems depends on both architectural and non-architecture aspects.architectural and non-architecture aspects.

Architectural aspects of Performance: Architectural aspects of Performance: Communication between components Partially on partitioning of functionality Allocation of resources

Non-architectural aspects of Performance: Non-architectural aspects of Performance: Choice of algorithms How these algorithms are coded

Page 11: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 11 – CSCE 492 Spring 2008

Architectural Vs Non-ArchitecturalArchitectural Vs Non-Architectural

1.1. Architecture is critical to achieving quality Architecture is critical to achieving quality attributes.attributes.

2.2. Architecture alone cannot achieve these qualities.Architecture alone cannot achieve these qualities.

Quality attributes can never be achieved in isolation.Quality attributes can never be achieved in isolation.

The achievement of one attribute may negatively (or The achievement of one attribute may negatively (or perhaps positively) influence the achievement of perhaps positively) influence the achievement of another.another.

E.g., security and reliability, (or security and usability or E.g., security and reliability, (or security and usability or performance and modifiability) are often at cross–performance and modifiability) are often at cross–purposespurposes

Page 12: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 12 – CSCE 492 Spring 2008

Types of Quality AttributesTypes of Quality Attributes

1.1. Qualities of the systemQualities of the system Availability Performance Security Testability Usability

2.2. Business qualitiesBusiness qualities Time-to-market Cost and benefit Projected lifetime

3.3. Overall architectural qualities.Overall architectural qualities. Conceptual integrity Correctness and completeness Constructability

Page 13: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 13 – CSCE 492 Spring 2008

System Quality AttributesSystem Quality Attributes

Been a focus of the software industry since the 1970’sBeen a focus of the software industry since the 1970’s

Each attribute ( usability, performance, reliability) has Each attribute ( usability, performance, reliability) has its own focus group of researchers, conferences, its own focus group of researchers, conferences, journals, terminology etc.journals, terminology etc. Usability (SIGCHI) - http://www.upassoc.org/conf2003/ Performance (SIGMETRIC)

http://www.sigmetrics.org/conferences.html Reliability - http://www.issre2001.org/

Attributes are not “operational”. What does it mean to Attributes are not “operational”. What does it mean to say a system is modifiable, it needs to be say a system is modifiable, it needs to be measurable so we can make comparisons, measurable so we can make comparisons, judgments.judgments.

Page 14: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 14 – CSCE 492 Spring 2008

Quality Attribute ScenariosQuality Attribute Scenarios

Quality Attribute Scenario is a quality-attribute-specific Quality Attribute Scenario is a quality-attribute-specific requirement.requirement.

There are 6 parts:There are 6 parts:

1.1. Source of stimulusSource of stimulus

2.2. Stimulus – a condition that needs to be consideredStimulus – a condition that needs to be considered

3.3. Environment - what are the conditions when the stimulus Environment - what are the conditions when the stimulus occurs?occurs?

4.4. Artifact – what elements of the system are stimulated.Artifact – what elements of the system are stimulated.

5.5. ResponseResponse

6.6. Response measure – when the response occurs it should be Response measure – when the response occurs it should be measurable so that the requirement can be tested.measurable so that the requirement can be tested.

Figure 4.1Figure 4.1

Page 15: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 15 – CSCE 492 Spring 2008

Availability ScenariosAvailability Scenarios

Figure 4.2 General availability scenarioFigure 4.2 General availability scenario

Figure 4.3 Example availability scenarioFigure 4.3 Example availability scenario

Page 16: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 16 – CSCE 492 Spring 2008

Modifiability ScenariosModifiability Scenarios

Same general format as for availability scenarios. (4.2)Same general format as for availability scenarios. (4.2)

Figure 4.4 Example Modifiability scenarioFigure 4.4 Example Modifiability scenario

““change the UI; make the background color blue.”change the UI; make the background color blue.”

Source: developerSource: developer

Stimulus: request for change (maybe email)Stimulus: request for change (maybe email)

Artifact: the code for the UIArtifact: the code for the UI

Environment: design timeEnvironment: design time

Response: modification with no side effects madeResponse: modification with no side effects made

Response measure: three hoursResponse measure: three hours

Page 17: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 17 – CSCE 492 Spring 2008

Quality Attribute Scenario GenerationQuality Attribute Scenario Generation

Architect’s Goal: generate meaningful quality attribute Architect’s Goal: generate meaningful quality attribute requirements for the systemrequirements for the system

Quality-attribute-specific tables Quality-attribute-specific tables General scenarios General scenarios System specific scenariosSystem specific scenarios

Page 18: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 18 – CSCE 492 Spring 2008

Availability Scenarios in PracticeAvailability Scenarios in Practice

Availability is concerned with system failure and Availability is concerned with system failure and duration of system failures.duration of system failures.

System failure means … when the system does not System failure means … when the system does not provide the service for which it was intended.provide the service for which it was intended.

Failure vs fault – Failure vs fault – A “system failure” is observable by the system’s user A system fault may cause a “system failure” or it might be

masked.

Measuring availability?Measuring availability?

Page 19: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 19 – CSCE 492 Spring 2008

Measuring AvailabilityMeasuring Availability

Mean time to failure – Mean time to failure –

Mean time to repair –Mean time to repair –

Availability = MTF / (MTF + MTR)Availability = MTF / (MTF + MTR)

How do we figure in scheduled downtime?How do we figure in scheduled downtime?

Page 20: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 20 – CSCE 492 Spring 2008

Availability General Scenario GenerationAvailability General Scenario Generation

Table 4.1Table 4.1

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource Internal to system or external to systemInternal to system or external to system

StimulusStimulus Crash, timing, no response, incorrect response Crash, timing, no response, incorrect response

ArtifactArtifact System’s processors, communication System’s processors, communication channels, persistent storagechannels, persistent storage

EnvironmentEnvironment Normal operation; degraded (failsafe) mode Normal operation; degraded (failsafe) mode

ResponseResponse Log the failure, notify users/operatorsLog the failure, notify users/operators

RespMeasureRespMeasure Time interval when it must be available, Time interval when it must be available, availability%, unavailability time intervalavailability%, unavailability time interval

Page 21: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 21 – CSCE 492 Spring 2008

Modifiability Scenarios in PracticeModifiability Scenarios in Practice

Modifiability is about the cost of change, both in time and money. Modifiability is about the cost of change, both in time and money. (Time is money. Who said this?)(Time is money. Who said this?)

Two major concerns:Two major concerns:

1.1. What can change the artifact?What can change the artifact? Changes top the function the system computes Changes to the environment in which it operates (portability) Qualities of the system

2.2. When is the change made and who makes it?When is the change made and who makes it? In the past developers changed the code. Changes made at several levels:

User changing a screen color to her liking Modifications to source code Modifications to compile-time switches During execution

Page 22: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 22 – CSCE 492 Spring 2008

Modifiability General Scenario GenerationModifiability General Scenario Generation

Table 4.2Table 4.2

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource End-user, developer, system-administratorEnd-user, developer, system-administrator

StimulusStimulus Add/delete/modify functionality or quality attr. Add/delete/modify functionality or quality attr.

ArtifactArtifact System user interface, platform, environmentSystem user interface, platform, environment

EnvironmentEnvironment At runtime, compile time, build time, design-At runtime, compile time, build time, design-time time

ResponseResponse Locate places in architecture for modifying, Locate places in architecture for modifying, modify, test modification, deploys modificationmodify, test modification, deploys modification

RespMeasureRespMeasure Cost in effort, money, time, extent affects other Cost in effort, money, time, extent affects other system functions or qualitiessystem functions or qualities

Page 23: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 23 – CSCE 492 Spring 2008

Performance Scenarios in PracticePerformance Scenarios in Practice

Performance is about time.Performance is about time.

Events occur and the system must respond in a timely Events occur and the system must respond in a timely fashion.fashion.

Probabilistic distribution of arrival of events. Queue of Probabilistic distribution of arrival of events. Queue of events, queue lengths …events, queue lengths …

Response time can be measured by:Response time can be measured by: Latency = Throughput = Deadlines in processing Jitter of response = variability of latency Number of events not processed (system overwhelmed) Amount of data loss when system is overwhelmed

Page 24: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 24 – CSCE 492 Spring 2008

Performance General Scenario GenerationPerformance General Scenario Generation

Table 4.3Table 4.3

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource A number of sources both external and internalA number of sources both external and internal

StimulusStimulus Periodic events, sporadic events, stochastic Periodic events, sporadic events, stochastic eventsevents

ArtifactArtifact System, or possibly a componentSystem, or possibly a component

EnvironmentEnvironment Normal mode; overload mode Normal mode; overload mode

ResponseResponse Process stimuli; change level of serviceProcess stimuli; change level of service

RespMeasureRespMeasure Latency, deadline, throughput, jitter, miss rate, Latency, deadline, throughput, jitter, miss rate, data lossdata loss

Page 25: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 25 – CSCE 492 Spring 2008

Security Scenarios in PracticeSecurity Scenarios in Practice

Security is the ability of the system to prevent or resist Security is the ability of the system to prevent or resist unauthorized access while providing access to unauthorized access while providing access to legitimate users.legitimate users.

Attack – is an attempt to breach securityAttack – is an attempt to breach security Unauthorized login Sniffing data on communication channel Unauthorized access/modification of data Denial of services attacks – crash the system

Page 26: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 26 – CSCE 492 Spring 2008

Aspects of System SecurityAspects of System Security

Security can be characterized by providing:Security can be characterized by providing: Nonrepudiation – a transaction cannot be denied Confidentiality – data or services are protected from

unauthorized access Integrity - data or services are delivered as intended Assurance – (authentication) the parties to the transaction

are who they say they are Availability - the system will be available for legitimate use;

no DOS. Auditing – the system tracks activities at several levels

sufficient to reconstruct them

Page 27: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 27 – CSCE 492 Spring 2008

Security General Scenario GenerationSecurity General Scenario Generation

Table 4.4Table 4.4

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource User/system who is legitimate/imposter/unknown User/system who is legitimate/imposter/unknown with full/limited accesswith full/limited access

StimulusStimulus Attempt to display/modify data; access services Attempt to display/modify data; access services

ArtifactArtifact System services, dataSystem services, data

EnvironmentEnvironment Normal operation; degraded (failsafe) mode Normal operation; degraded (failsafe) mode

ResponseResponse Authenticate user; hide identity of user; Authenticate user; hide identity of user; grant/block access …grant/block access …

RespMeasureRespMeasure Time /effort/resources to circumvent security Time /effort/resources to circumvent security measures with probability of successmeasures with probability of success

Page 28: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 28 – CSCE 492 Spring 2008

Testability Scenarios in PracticeTestability Scenarios in Practice

Software testability refers to the ease with which the Software testability refers to the ease with which the software can be made to demonstrate its faults or software can be made to demonstrate its faults or lack thereof.lack thereof.

40% of the cost of developing systems is taken up by 40% of the cost of developing systems is taken up by testing (CSCE 747)testing (CSCE 747)

If the architect can reduce this cost through design If the architect can reduce this cost through design then the payoff is substantial.then the payoff is substantial.

Measures?Measures? Probability that a fault will be revealed by test suite (or test)

To be testable the system must control inputs and by To be testable the system must control inputs and by able to observe outputsable to observe outputs

Test harness – test suites; regression suitesTest harness – test suites; regression suites

Page 29: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 29 – CSCE 492 Spring 2008

Testability General Scenario GenerationTestability General Scenario Generation

Table 4.5Table 4.5

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource Unit developer, increment integrator, system Unit developer, increment integrator, system verifier, client acceptance tester, system userverifier, client acceptance tester, system user

StimulusStimulus Analysis, architecture, design, class, subsystem Analysis, architecture, design, class, subsystem integration, system deliveredintegration, system delivered

ArtifactArtifact Piece of design, piece of code, complete systemPiece of design, piece of code, complete system

EnvironmentEnvironment At design time, at development time, at compile At design time, at development time, at compile time, at deployment timetime, at deployment time

ResponseResponse Provide access to state data values, observes Provide access to state data values, observes results, comparesresults, compares

RespMeasureRespMeasure Coverage; prob of failure, time to perform tests, Coverage; prob of failure, time to perform tests, length of time to prepare test environmentlength of time to prepare test environment

Page 30: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 30 – CSCE 492 Spring 2008

Usability Scenarios in PracticeUsability Scenarios in Practice

Usability is how easy is it for the user to accomplish Usability is how easy is it for the user to accomplish tasks and what support the system provides for the tasks and what support the system provides for the user to accomplish this.user to accomplish this.

Dimensions:Dimensions: Learning system features Using the system efficiently Minimizing the impact of errors Adapting the system to the user’s needs Increasing confidence and satisfaction

Usability Mea Culpa – p 92Usability Mea Culpa – p 92

Page 31: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 31 – CSCE 492 Spring 2008

Testability General Scenario GenerationTestability General Scenario Generation

Table 4.6Table 4.6

Scenario Scenario Portion Portion

Possible ValuesPossible Values

SourceSource End userEnd user

StimulusStimulus Wants to: learn system, use system, recover from Wants to: learn system, use system, recover from errors, adapt system, feel comfortableerrors, adapt system, feel comfortable

ArtifactArtifact SystemSystem

EnvironmentEnvironment At runtime, or configure time, install-timeAt runtime, or configure time, install-time

ResponseResponse

RespMeasureRespMeasure Task time, number of errors, number of tasks Task time, number of errors, number of tasks accomplished, user satisfaction, gain of user accomplished, user satisfaction, gain of user knowledge, amount of time. data lost knowledge, amount of time. data lost

Page 32: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 32 – CSCE 492 Spring 2008

Usability Scenarios in Practice: ResponsesUsability Scenarios in Practice: Responses

System responses to stimuli:System responses to stimuli:

To learn systemTo learn system Help system is context sensitive Interface familiar, consistent

To use system efficientlyTo use system efficiently Reuse of command or data already entered Navigation support, comprehensive searching

To recover from errorsTo recover from errors Undo, cancel, recover from system failures forgotten passwords

To adapt system: customize the system to user likingTo adapt system: customize the system to user liking

To feel comfortableTo feel comfortable

Page 33: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 33 – CSCE 492 Spring 2008

Quality Attribute StimuliQuality Attribute Stimuli

AttributeAttribute StimulusStimulus

AvailabilityAvailability Unexpected event, nonoccurrence of expected Unexpected event, nonoccurrence of expected eventevent

ModifiabilityModifiability Request to add/delete/modify functionality, Request to add/delete/modify functionality, platform, quality-attribute or capacityplatform, quality-attribute or capacity

PerformancePerformance Periodic, stochastic or sporadicPeriodic, stochastic or sporadic

SecuritySecurity Attempt to access/display/modify information or Attempt to access/display/modify information or resources; reduce availability of systemresources; reduce availability of system

TestabilityTestability Completion of phase of system developmentCompletion of phase of system development

UsabilityUsability User wants to: learn, use, minimize impact or User wants to: learn, use, minimize impact or errors, adapt the system, feel comfortableerrors, adapt the system, feel comfortable

Page 34: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 34 – CSCE 492 Spring 2008

Business QualitiesBusiness Qualities

Time to marketTime to market

Cost and benefitCost and benefit

Projected lifetime of systemProjected lifetime of system

Targeted marketTargeted market

Rollout scheduleRollout schedule

Integration with legacy systemsIntegration with legacy systems

Page 35: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 35 – CSCE 492 Spring 2008

Architectural QualitiesArchitectural Qualities

Conceptual integrity – do similar things in similar waysConceptual integrity – do similar things in similar ways

“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” Brooks Mythical Man-Month 1975

Correctness and completenessCorrectness and completeness

BuildabilityBuildability

Page 36: Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering

– 36 – CSCE 492 Spring 2008

ReferencesReferences

1. ACM Digital Library http://www.acm.org/ You You have access to this from any USC (129.252.x.y) IP have access to this from any USC (129.252.x.y) IP address. Google “ACM digital library”address. Google “ACM digital library”