Software Engineering and

Software Quality
Introduction
 Introduction
Programming is fun, but developing quality
software is hard.
In between nice ideas, the requirement or
vision and working software product, there is
much more than programming.
Aim is not just to develop working programs,
but to develop good quality maintainable
programs!
Software Engineering vs Programming.
Software engineering is a discipline for solving
business problems.
software engineering require great emphasis
on
methodology or method for managing the
development process
great skill with tools and techniques.
 Why Software Engineering Is Difficult
Need to know about software domain
Need to know about the problem domain
Some problems require extensive periods of dedicated research
(years, decades, or even longer)
Software is a formal domain(inputs and goal states well
defined).
The real world is informal (ill-defined inputs and goal states)
Software engineering is mainly about modeling the physical
world and finding good abstractions.
Finding abstractions in a problem domain involves certain level of
coarse graining. We cannot describe the problem domain in
perfect detail. Given that every physical system has very many
parts, the best we can do is to describe it in terms of only some of
its variables.
we live in a changing world: things wear out and break, business
practices change, government regulations change, etc.
 Change is inevitable in all large software projects.
The system requirements change as the business procuring
the system responds to external pressures and
management priorities change.
As new technologies become available, new design and
implementation possibilities emerge. Therefore whatever
software process model is used, it is essential that it can
accommodate changes to the software being developed.
Peculiar nature of the problems (wicked problems)
solved by software engineering.
A wicked problem is a problem that is difficult or
impossible to solve because of incomplete, contradictory,
and changing requirements that are often difficult to
recognize.
These wicked problems can be properly defined only
after being solved.
 Software and entropy
A virtue of software: relatively easy to change than
hardware.
But the more complex a software system gets, the harder
it is to change. why?
Larger software systems are harder to understand
The more changes get introduced into a system, the more it
tends toward entropy
I.e., its internal order breaks down
 Change adds to the costs of software
development
It usually means that work that has been completed has to be redone
If the relationships between the requirements in a system have been analyzed
and new requirements are then identified, some or all of the requirements
analysis has to be repeated. It may then be necessary to redesign the system to
deliver the new requirements, change any programs that have been developed,
and re-test the system.
There are two related approaches that may be used to reduce the costs of
rework:
Change avoidance, where the software process includes activities that can
anticipate possible changes before significant rework is required.
For example, a prototype system may be developed to show some key features of the
system to customers. They can experiment with the prototype and refine their
requirements before committing to high software production costs.
Change tolerance, where the process is designed so that changes can be
accommodated at relatively low cost. This normally involves some form of
incremental development. Proposed changes may be implemented in
increments that have not yet been developed. If this is impossible, then only a
single increment (a small part of the system) may have to be altered to
incorporate the change.
 Planning for change
How can good comments facilitate and reduce
the cost of software maintenance?
Hint: think about invariants, things that dont
change.
Comments describe meaning of code
Assuming programmers maintain comments
when they change the code!
How can modularity help manage change?
Modules help to isolate and localize change
 Triple constraints for software projects.
Aim is to deliver quality product, keeping the cost within
budget and deliver the project as per scheduled.
There are several factors, both internal and external, which
may impact this triple constrain triangle.
Any of three factor can severely impact the other two.
Therefore, software project management is essential to
incorporate user requirements along with budget and time
constraints.
4 P model of successful project
 People
People (Team members)
The most important element in success
The one who gets the job done
What to consider
Skills, abilities, talents
Motivation, Interest
Temperament
Reliability
The Other People
Senior Management
Keep informed of your work, the senior managers expertise can smooth out
bumps (technical or managerial) in the path from start to finish
Customers
Sometimes these people are the same as the end user and sometimes they
are the sponsor of the project. Know the difference, because you need to
support both parties.
End Users
Those wholl actually use your product. They wield the power of acceptance.
 Product
Its why youre in business
Determine what are you building
(market/customer research)
How big a job (scope)
What do you have to accomplish task (resources)
How hard (effort + ability + resources = feasibility)
 Process
The framework organizing tasks of your
development work
Provides structure and context for
development effort
Gives guidance on best practices for s/w
development
Identifies common concerns, e.g.,
organization, resources, risks
 Project

Organizes and integrates the other three

Contains the plan of action
Uses the process as a guideline
Considers the people and resources in estimating
Decomposes the product and develops the schedule,
resource needs, cost, and risk
Provides the concrete information needed for
tracking (or monitoring) and controlling the effort.
 A software life cycle is a process
A software process is a set of related activities that
leads to the production of a software product
A process involves activities, constraints and resources
that produce an intended output.
Each process activity, e.g., design,
must have entry and exit criteriawhy?
A process uses resources, subject to constraints (e.g., a
schedule or a budget)
A process is organized in some order or sequence,
structuring activities as a whole
A process has a set of guiding principles or criteria that
explain the goals of each activity
 Software development life cycle (SDLC)

1. A structured step-by-step approach for

developing information systems.
2. A framework that describes the activities
performed at each stage of a software
development project.
3. There are many activities associated with
each phase of the SDLC
Such activities include:
Determining budgets
Gathering systems requirements
Documentation
Domain Modeling
1. In some form, these activities are part
of all software processes
 Apart from activities process descriptions include:
Products
The outcomes of a process activity.
For example, the outcome of the activity of architectural design may
be a model of the software architecture.
Roles
The responsibilities of the people involved in the process.
Examples:- project manager, configuration manager, programmer,
etc.
Pre- and post-conditions
Statements that are true before and after a process activity has been
enacted.
For example, before architectural design begins, a pre-condition may
be that all requirements have been approved by the customer; after
this activity is finished, a post-condition might be that the UML
models describing the architecture have been reviewed.
 Design & Architecture in the
Development Process
Requirements

Architecture

Design Design Design Design

Code C&ut C&ut C&ut C&ut C&ut C&ut

&
Unit
Test
Integration Test

System Test
Why Process/SDLC
 Planning Phase of SDLC
Define business problem and scope
Produce project estimation and schedule
Confirm project feasibility
Economic, organizational, technical, resource, and
schedule

Staff the project (resource management)

Launch project official announcement
 Project plan
Developing a project plan is the final activity
of the planning phase.
Defines the what, when, and who questions of
system development including
all activities to be performed,
the individuals, or resources, who will perform the
activities,
and the time required to complete each activity.
 Software Project Manager
Is a person who develops the project plan and tracks the plan
to ensure all key project milestones are completed on time.
may never directly involve in producing the end product but
he controls and manages the activities involved.
A project manager
closely monitors the development process
prepares and executes various plans,
arranges necessary and adequate resources,
maintains communication among all team members
address issues of cost, budget, resources, time, quality and
customer satisfaction.
Does risk analysis at every phase
take necessary step to avoid or come out of problems
act as project spokesperson
 Scope Management
Define the scope and its verification and control
Divide the project into various smaller parts for ease of
management.
Project estimation
Software size, Effort, Time and Cost.
Project Scheduling
Break down the project tasks into smaller, manageable
form
Find out various tasks and dependency on other tasks
Estimate time frame required for each task
Divide time into work-units
Assign adequate number of work-units for each task
Calculate total time required for the project from start to
finish
 Resource management
Create project team and allocating responsibilities to each
team member
Determining resources required at a particular stage and
their availability
Project Risk Management (Identify, Categorize,
Manage, Monitor )
Experienced staff leaving the project and new staff coming
in.
Change in organizational management.
Requirement change or misinterpreting requirement.
Under-estimation of required time and resources.
Technological changes, environmental changes, business
competition.
 Project Execution & Monitoring
Activity Monitoring - All activities scheduled within a task
can be monitored on day-to-day basis.
Milestones Checklist - Every project is divided into
multiple phases where major tasks are performed
(milestones) based on the phases of SDLC. This milestone
checklist is prepared once every few weeks and reports
the status of milestones.
Project Communication Management
Effective communication plays vital role in the success of a
project.
It bridges gaps between client and the organization,
among the team members as well as other stake holders in
the project.
Communication can be oral or written.
 Configuration Management
Process of tracking and controlling the changes in software in
terms of the requirements, design, functions and development
of the product.
Generally, once the SRS is finalized there is less chance of
requirement of changes from user. If they occur, the changes are
addressed only with prior approval of higher management, as
there is a possibility of cost and time overrun.
Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a
measurement that defines completeness of a phase.
A phase is baselined when all activities pertaining to it are
finished and well documented.
If it was not the final phase, its output would be used in next
immediate phase.
 Analysis Phase of SDLC
Gather information to learn problem domain

Define system requirements

Build prototypes for discovery of requirements

Prioritize requirements

Build prototypes for discovery of requirements

Estimate the project

Software size, Effort, Time and Cost.

Generate and evaluate alternatives

Review recommendations with management

 Software Requirement Specification(SRS)
Consists of all the product requirements to be designed and
developed during the project.
Functional Requirements
Requirements, which are related to functional aspect of
software fall into this category.
Eg: Search option given to user to search from various
invoices
Non-Functional Requirements
Requirements, which are not related to functional aspect of
software, fall into this category. They are implicit or expected
characteristics of software, which users make assumption of.
Eg: Security, Configuration, Performance, Interoperability, etc
 The activities in the requirements process are not
simply carried out in a strict sequence.
Requirements analysis continues during
definition and specification and new
requirements come to light throughout the
process. Therefore, the activities of analysis,
definition, and specification are interleaved.
In agile methods, requirements are developed
incrementally according to user priorities and the
elicitation of requirements comes from users who
are part of the development team.
 Requirements management
The requirements for large software systems are always changing.
One reason for this is that these systems are usually developed to
address wicked problemsproblems that cannot be completely
defined. Because the problem cannot be fully defined, the software
requirements are bound to be incomplete.
During the software process, the stakeholders understanding of the
problem is constantly changing. The system requirements must then
also evolve to reflect this changed problem view.
Requirements management is the process of understanding and
controlling and tracing changes to system requirements.
You need to keep track of individual requirements and maintain links
between dependent requirements so that you can assess the impact
of requirements changes.
need to establish a formal process for making change proposals and
linking these to system requirements.
The formal process of requirements management should start as soon
as a draft version of the requirements document is available.
 Software Analyst (SA)
Should have good problem(application) domain knowledge.
Prepares a Functional Requirements Specification, from
Business Requirements Specification, which breaks down
each business requirement into logical components that
might be more easily translated into a computer program.
May also prepare a Non-Functional Requirements
Specification, which would specify system needs such as
Performance and Security.
Mediator between Business Analyst(or Product Owner) and
the programmers.
Software Analyst is not a stand-alone role, but combined
with the programming/design role.
 Design Phase of SDLC
Design the application architecture
Design the user interfaces
Design the system interfaces
Design and integrate the database
Prototype for design details
Design and integrate system controls
 Architecture is Early
Architecture represents the set of earliest design decisions
Hardest to change
Most critical to get right
Architecture is the first design artifact where a systems
quality attributes are addressed
The first stage in the software design process.
Critical link between design and requirements engineering.
The main structural components in a system and the
relationships between them.
The output of the architectural design process is an
architectural model that describes how the system is
organized as a set of communicating components.
 Architectural Design
In agile processes, an early stage of the
development process should be concerned
with establishing an overall system
architecture. Incremental development of
architectures is not usually successful.
System architectures are often modeled
using simple block diagrams. Each box in
the diagram represents a component.
 Design & Architecture in the
Development Process
Requirements

Architecture

Design Design Design Design

Code C&ut C&ut C&ut C&ut C&ut C&ut

&
Unit
Test
Integration Test

System Test
 Architecture Drives
Architecture serves as the blueprint for the
system but also the project:
Team structure
Documentation organization
Work breakdown structure
Scheduling, planning, budgeting
Unit testing, integration
 Architectural Feasibility
The designers might have concerns about a systems ability to meet
its performance targets, work within resource limitations, or be
adequately supported by the implementation environments.
The architecture should demonstrate that the system is technically
feasible.
If infeasibility in any area could render the project unworkable, the
architecture should indicate how those issues have been investigated
through proof-of-concept prototypes, research, or other means. These
risks should be resolved before full-scale construction begins.

The final architecture must meet you needs in terms of

Time
Cost
Technical feasibility
Flexibility
 Design Modeling (OOAD)
Modeling - the activity of drawing a graphical representation
of a design.
Modeling activities performed during the design stage
Graphical user interface (GUI)
The interface to an information system.
the ability to model the information system screens for an entire system.
Entity relationship diagram
Data flow diagram
Flowcharting
UML Diagrams
Class diagram (structure)
sequence diagram (behavior)
 Development (Construction)
Take all of your design documents from the
design phase and transform them into an
actual system.
Activities during this phase include
Detailed design (OOAD)
Coding programs
Creating databases
Unit testing/Integration testing.
Deploying the programs
Installing hardware and software
 Testing(validation)
Verifies that the system works and meets all of the
business requirements defined in the analysis phase.
Must have test plans
Write the test conditions
detailed steps the system must perform along with the
expected results of each step

A mixture of manual and automated testing.

In manual testing, a tester runs the program with some test data
and compares the results to their expectations. They note and
report discrepancies to the developers.
In automated testing, the tests are encoded in a program that is
run each time the system under development is to be tested.
This is usually faster than manual testing, especially when it involves
regression testing (re-running previous tests to check that changes to
the program have not introduced new bugs)
 Types of Testing
System testing or Integration testing.
System meets its functional and non-functional requirements.
Regression Testing
Acceptance(Release) testing
This is the final stage in the testing process before the system is
accepted for operational use.
The system is tested with data supplied by the system customer rather
than with simulated test data.
Acceptance testing may reveal errors and omissions in the system
requirements definition, because the real data exercise the system in
different ways from the test data.
Performance Testing
Load Testing.
Security Testing
Beta testing or User testing
Beta testing involves delivering a system to a number of potential
customers who agree to use that system. They report problems to the
system developers. This exposes the product to real use and detects
errors that may not have been anticipated by the system builders
 Release (Deployment)
Bringing the system into life by placing it in the organization
During this phase
distribute the system to all users and they begin using the
system to perform their everyday jobs.
create User documentation
perform training to the employees to use the system
 Maintenance(Support)
Maintain system
Small patches, repairs, and updates
Enhance system
Small upgrades or enhancements to expand system capabilities
Larger enhancements may require separate development project
Support users
Help desk and/or support team
Monitor and support the system to ensure it continues to meet the
business goals.

Most large companies spend more on maintaining existing systems

than on new systems development.
7590% of organizational software costs are maintenance costs.
 Disposition
As time elapses, the software may go
completely obsolete or may need intense
upgradation.
This phase includes archiving data and
required software components, closing down
the system, planning disposition activity and
terminating system at appropriate end-of-
system time.
 SDLC Models
Also referred as "Software Development Process
Models".
A framework that describes the activities
performed at each stage of a software
development project.
Each process model follows a Series of steps
unique to its type, in order to ensure success in
process of software development.
Waterfall Model
Iterative Model
Agile
 Waterfall Model
All phases are cascaded to each other in which
progress is seen as flowing steadily
downwards (like a waterfall) through the
phases.
The next phase is started only after the
defined set of goals are achieved for previous
phase and it is signed off, so the name
"Waterfall Model".
In this model phases do not overlap.
 When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is well understood.
New version of an existing product
Porting an existing product to a new platform.

High risk for new systems because of specification and

design problems.
Low risk for well-understood developments using
familiar technology.
 V-Shaped SDLC Model
A variant of the
Waterfall that
emphasizes the
verification and
validation of the
product.
Testing of the
product is planned
in parallel with a
corresponding
phase of
development
 When to use the V-Shaped Model
Excellent choice for systems requiring high
reliability hospital patient control
applications
All requirements are known up-front
When it can be modified to handle changing
requirements beyond analysis phase
Solution and technology are known
 Why Not Waterfall/V?
Complete Requirements Not Known at Project
Start
Requirements are not stable/unchanging.
The market changesconstantly.
The technology changes.
The goals of the stakeholders change.
 Incremental/Iterative

Release 1
Design Coding Test Deployment
Requirements

Release 2
Design Coding Test Deployment
Release 3
Design Coding Test Deployment

Each release adds more functionality, i.e., a new

increment
 Iterative Model
Does not attempt to start with a full
specification of requirements.
Development begins by specifying and
implementing just part of the software, which
is then reviewed in order to identify further
requirements.
This process is then repeated, producing a
new version of the software at the end of
each iteration of the model.
 Incremental vs. Iterative
Subtle difference:
Incremental: add to the product at each phase
Iterative: re-do the product at each phase
Example: Building a House
Incremental: Start with a modest house, keep adding
rooms and upgrades to it.
Iterative: On each iteration, the house is re-designed and
built anew.
Big Difference: One can live in the incremental house the
entire time! One has to move to a new iterative house.
 Rational Unified Process
Iterative and incremental
Use-case-driven
Architecture-centric
Uses UML as its modeling notation
Process framework
Comprehensive set of document templates, process
workflow templates, and process guidelines
 Rational Unified Process Is Use-Case-
Driven
Use cases are concise, simple, and understandable by a wide
range of stakeholders
End users, developers and acquirers understand functional
requirements of the system
Use cases drive numerous activities in the process:
Creation and validation of the design model
Definition of test cases and procedures of the test model
Planning of iterations
Creation of user documentation
System deployment
Use cases help synchronize the content of different models
 Rational Unified Process Is Architecture-
Centric
Architecture is the focus of the elaboration phase
Building, validating, and baselining the architecture constitute the
primary objective of elaboration
The Architectural Prototype validates the architecture and
serves as the baseline for the rest of development
The Software Architecture Description is the primary artifact
that documents the architecture chosen
Other artifacts derive from architecture:
Design guidelines including use of patterns and idioms
Product structure
Team structure
 Process Architecture - Lifecycle Phases
Inception Elaboration Construction Transition

time

Inception
Define the scope of project
Plan the project.
Evaluate risk
Elaboration
Understand problem domain.
Design system architecture.
Plan development.
Construction
Build the product (Design, programming and test)
Transition
Moving system from developer to user environment.
Acceptance testing, release of full system.
 RUP Overview
Phases
Process Workflows Inception Elaboration Construction Transition

Business Modeling
Requirements
Architecture & Design
Implementation
Test
Deployment In an iteration,
you walk through
Supporting Workflows all workflows

Configuration Mgmt
Workflows group
Management
activities logically Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
 Agile Model
Agile Methods break the product into small
incremental builds.
These builds are provided in iterations.
Each iteration typically lasts from about one to three
weeks.
Every iteration involves cross functional teams working
simultaneously on various areas like planning,
requirements analysis, design, coding, unit testing, and
acceptance testing.
At the end of the iteration a working product is
displayed to the customer and important stakeholders.
 Popular agile methodologies
Scrum
Extreme Programming
Adaptive Software Development
Feature Driven Development
Dynamic Systems Development Method
(DSDM)
Thank You
Architectural design

Can be built by one person

Requires
Minimal modeling
Simple process
Simple tools
 Architecting a house

Built most efficiently and timely by a team

Requires
Modeling
Well-defined process
Power tools
Architecting a high rise
Differences
Scale
Process
Cost
Schedule
Skills and development
teams
Materials and
technologies
Risks
 Design & Architecture in the
Development Process
Requirements

Architecture

Design Design Design Design

Code C&ut C&ut C&ut C&ut C&ut C&ut

&
Unit
Test
Integration Test

System Test
 Architecture vs. Design
Architecture: where non-functional decisions are cast, and
functional requirements are partitioned
Design: where functional requirements are accomplished

non-functional architecture
requirements
(ilities)

functional
requirements design
(domains)
 System Quality Attribute

Performance
Time To Market
Availability
End Users view Cost and Benefits
Usability Business
Projected life
Security time Community
view
Targeted Market
Integration with
Maintainability
Legacy System
Portability Roll back
Reusability Developers view Schedule
Testability
Representing Architecture: The 4+1
View Model

Logical Implementation
View View

Analysts/
End-user Programmers
Designers
Structure Functionality Software management
Use-Case
View
Process Deployment
View View
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
 Use Case View
Use Case Analysis is a technique to capture business
process from users perspective.
Encompasses the behavior as seen by users, analysts
and testers.
Static aspects in use case diagrams; Dynamic aspects in
interaction (state-chart and activity) diagrams.
Architecturally significant use cases:
critical use cases, those that are most important to the
users of the system (from a functionality perspective)
use cases that carry the major risks
use cases that have the most important quality
requirements, such as performance, security, usability, etc.
Use-case View : Example
 Design(Logical) View
Encompasses classes, interfaces, and collaborations
that define the vocabulary of a system.
Supports functional requirements of the system.
Static aspects in class and object diagrams;
Dynamic aspects in interaction diagrams.
The Logical View is a subset of the Design Model which
presents architecturally significant design elements
describes the most important classes
their organization in packages and subsystems
organization of these packages and subsystems into layers
It also describes the most important use-case realizations,
for example, the dynamic aspects of the architecture
Logical View : Class Diagram
Logical View : Collaboration Diagram
Deposit Use case
Logical View : Package Diagram
Logical View: Sequence diagram
 Process View
Consists of the processes and threads that
form the systems concurrency and
synchronization mechanisms, as well as their
interactions
Addresses performance, scalability, and
throughput.
Static and dynamic aspects captured as in
design view; emphasis on active classes.
 Implementation View
Describes the organization of static software modules
(source code, data files, executables, documentation etc.)
in the development environment in terms of Packaging
and layering
Encompasses components and files used to assemble and
release a physical system.
Addresses configuration management.
Static aspects in component diagrams;
Deployment View
Encompasses the nodes that form the system hardware
topology.
Addresses distribution, delivery, and installation.
Static aspects in deployment diagrams; Dynamic aspects in
interaction diagrams.
Component diagram
Deployment diagram
Deployment diagram
 Architectural patterns
Architectural patterns are a means of reusing
knowledge about generic system architectures.
They describe the architecture, explain when it
may be used, and discuss its advantages and
disadvantages.
Commonly used architectural patterns include
Model-View-Controller,
Layered Architecture,
Repository,
Clientserver
Pipe and Filter
 External Quality
External quality consists of those highly desirable
attributes perceived during the execution of the
software.
They are highly visible and rarely requested. But,
their absence quickly causes dissatisfaction.
Fortunately, not all of them are of equal
importance.
Ignoring those nonfunctional requirements is one
of the shortcomings found abundantly in many
software applications.
The lack of expertise regarding architecture.
Affect the entire system and difficult to isolate.
 Nonfunctional Requirements
known as technical requirements, quality attributes, or
quality of service requirements, enforce the structural
quality of the software
Desirable characteristics of the software. These
characteristics include usability, reliability, maintainability,
security, portability, testability, and many others.
These quality requirements can be divided into two main
categories:
1. External quality such as performance, reliability, correctness,
scalability, robustness, security, and usability, which carry out
the softwares functions at run time, and as such, is not only
visible to stakeholders but is also highly desirable.
2. Internal quality such as maintainability, modifiability, and
testability, which are barely visible to stakeholders but simplify
how to build and evolve the software.
 Dependability
The dependability of systems is more important
than their detailed functionality
Availability - up and running and able to deliver
useful services to users at any given time.
Reliability - over a given period of time, the system
will correctly deliver services as expected by the user.
Robustness to cope to with errors during execution.
Safety - how likely it is that the system will cause
damage to people or its environment.
Security - how likely it is that the system can resist
accidental or deliberate intrusions.
 Other External qualities
Accessibility
Ease with which software can be accessed by as many
people as possible
Performance
Measured as response time or throughput
Scalability
Capability of the software to handle growing amount of
work in graceful manner.
Usability
Ease with which the software can be used by specified
users to achieve specified goals.
 Architecture
The issue is so critical that teams should formalize
the role of the architect and ensure that at least
one team member takes ownership of this role.
The architect specifies an emergent architecture
in two ways:
By addressing nonfunctional requirements in small
chunks and in a timely manner
By designing technical abstractions through
thoughtful reduction and organization. The architect
leads the design of the structural foundation upon
which the solution is built by the team. The architect
works collaboratively with every team member to
remove accidental complexity and pursues simplicity
in the design.
 Architect
Correctly addressing quality attributes is one of the
most visible areas of architects work.
Learning to master the nonfunctional requirements is a
skill that architects acquire with experience.
Translate nonfunctional requirements into restrictions
and make them explicit knowledge shared by the
whole team.
A factor often underestimated is that explicit and
highly visible elements are always taken into
consideration by the team. As such, restrictions are the
visible elements that guide the work and help
determine whether the team has satisfied the
nonfunctional requirements.
 Improving External Quality Using
Restrictions
The most common mistake when specifying software is the lack of a
clearly defined set of restrictions that summarize the required quality.
A restriction imposes conditions that set a limit to comply with.
SMART principle suggests that a restriction should be:
Specific: It should target a piece of functionality that is small, consistent, and
simple.
Measurable: It imposes a limit that is measurable; otherwise, how would you
know when youve addressed it?
Attainable: It is recognized as achievable by the team.
Relevant: It is directly related, connected, and pertinent to the nonfunctional
requirement.
Traceable: It is linked with a functional requirement that justifies why it exists.
Explicitly setting restrictions is a simple and obvious step to start with.
This simplifies the design by setting a goal that will be recognized and
shared by the whole team. When this first step is done correctly, those
restrictions can guide the team to successfully address nonfunctional
requirements.
 Example
Given the buyer is a student, Restrict with response time
less than 5 seconds.
Given the buyer is user 'KnownBuyer' Restrict with the
buyer to be authenticated positively
Given the buyer is user 'UnknownBuyer' Restrict with the
buyer to be authenticated negatively Then issue is saved in
security database and user is redirected to "Login" page
Imagine that the software should not handle more than
10,000 concurrent users. You could express the restriction
as this: Restrict after 10001 occurrences with a failed login
Then user is redirected to page "Server unavailable. Please
try later.
 Testing Restrictions with Proven
Practices
Non functional Requirement Testing practice
Correctness Acceptance testing
Performance Measure response time and inspect throughput

Reliability Seek extraordinary resource conception over a

specified time (CPU, memory, disk space)
Robustness Test for invalid input and stressful environment
condition (stress testing)
Scalability Verify software behavior under anticipated peak load
conditions (Load Testing)
Security Perform intrusion detection and vulnerability scanning
Usability Consistency inspection, activity analysis to verify user
has achieved their specified goal.
 Restriction takes effort
Confirming restrictions with proven practices
can be expensive in terms of effort.
Question every nonfunctional requirement to
validate whether it is actually required.
Often people underestimate the work to be
done for Nonfunctional requirements.
Deferring the restriction can lead to a large
amount of reworking in future sprints, due to
architectural considerations.
 Internal Quality
When dealing with software construction, the team
must always deliver a sprint with enough internal
quality so that it can easily continue to extend it in
future iterations.
If the nonfunctional requirements that affect the
internal quality are successfully met, the software
under construction is not only simplified, but its
sustainability is also preserved for future changes.
Use sound software engineering practices to ensure
the software construction is done correctly.
 Internal Quality
Name Definition
Simplicity Ease of understanding and explaining
Maintainability Ease of changing and evolving with minimal effort
Testability Ease of confirming conformance by testing
Portability Ease of reuse by multiple platform
Extensibility Ease of feature additions and future changes
(Many teams consider fictitious extensibility requirements at the
expense of the stakeholders immediate needs. Extensibility requires
the team to anticipate and predict the future, which is precisely
what agile software doesnt do in development. This is significant
because whatever you build upfront, as a response to an anticipated
future, will have to be refactored to fit the final requirements.)
 Improving Software Construction with
Explicit Practices
Non functional Practices
Requirement
Simplicity Self documenting code: naming convention, code layout, logic
structure, useful and up to date comments.
Code metrics: measure complexity of the source code
Maintainability Continuous Integration: Immediately tested and reported one
developer check-in
Branching and merging: Tagging with the user story or scenario
or tractability.
Testability Red-green-refactor: TDD, write test first from spec and code for
tests written to pass.
Code coverage: measure test code coverage
Portability Multi-target compiling
 Definition of Done checklist
It is current practices and standards of the team.
This is the checklist team members complete when
producing software.
Code completed.
0 (known) bugs.
Passed unit tests.
Code peer-reviewed or paired.
Code checked in.
Deployed to test environment and passed tests.
Documentation updated.
From time to time practices should be revised in response
to retrospective and continuous improvement
 In contrast to the external quality, you can
hardly postpone the work required to ensure
simplicity, maintainability, testability, or
portability. Postponing creates a technical
debt that can cripple the teams ability to add
new functionality.
It is therefore important for the team to
master the engineering practices and apply
them on a daily basis.